arigo@codespeak.net writes:

+* fix floats:: + - translator/c/float_include.h should catch floating-point signals + with a technique similar to CPython's.

This is not 100% clear, by the way. I wouldn't claim that all of what follows is solid fact (but I think I know more about this sort of thing than most of the other PyPyers...). The floating point standards define a bunch of conditions: Overflow (eg huge number * huge number) Underflow (tiny number / huge number) DivisionByZero (finite value / zero) InvalidOperation (0 / 0) Inexact (for things like 1.0 / 10.0) Rounded (when rounding occurs, not entirely sure how this differs from Inexact, tbh) and maybe a few more. Each condition has an independent setting ('trap') as to whether it's occurence should halt computation. There is some standard (not sure which, IEEE 754, SUS, POSIX, ...) that says programs should start up with all traps disabled, so we shouldn't really need to catch SIGFPE. I'm also far from convinced that the SIGFPE code is ever used today in Python (does anyone pass --with-fpectl to configure?). I think that there are some platforms which don't start up with all traps disabled, but the correct approach for them is to find out the incantation to whack them into standards mode and use that. At the PyPy level we should probably decide on which traps are enabled by default (at least DivisionByZero is traditional) and try to be consistent about applying it (something CPython does less than well, as various groans about strutil.string_to_float indicate). We probably don't want to get into the business of doing this at the FPU level, or at least not yet. My opinion: PyPy should trap DivisionByZero and InvalidOperation. There's a case for trapping Overflow, but CPython doesn't do this (most of the time...). It would be insane IMHO to trap Underflow or Inexact or Rounded. Another question is whether we want to support user control of this stuff. All these issues affect Lib/decimal.py by the way, and reading the documentation of that module is probably a good way to get an idea of the area. A possible post-sprint task would be making the aforementioned strutil.string_to_float less horribly naive and finally fixing the rounding issues in _float_formatting.py (for the last, some guy a while ago sent me some dylan code that might help... let me upload it: http://starship.python.net/crew/mwh/format.dylan http://starship.python.net/crew/mwh/float.dylan ). I can provide references for both these tasks, if anyone looks interested. Cheers, mwh -- You sound surprised. We're talking about a government department here - they have procedures, not intelligence. -- Ben Hutchings, cam.misc