[pypy-dev] Re: [pypy-svn] r14022 - pypy/extradoc/sprintinfo

[Michael Hudson]

arigo at 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