Turn off ZeroDivisionError?

[John Nagle]

Mark Dickinson wrote:
> On Feb 10, 7:07 pm, Grant Edwards <gra... at visi.com> wrote:
>> On 2008-02-10, Christian Heimes <li... at cheimes.de> wrote:
>>>>>> from somemodule import ieee754
>>>>>> with ieee754:
>>> ...    r = a/0
>>> ...    print r
>>> inf
>> That would be great.
> 
> Seriously, in some of my crazier moments I've considered trying to
> write a PEP on this, so I'm very interested in figuring out exactly
> what it is that people want.  The devil's in the details, but the
> basic ideas would be:
> 
> (1) aim for consistent behaviour across platforms in preference to
> exposing differences between platforms
> (2) make default arithmetic raise Python exceptions in preference to
> returning infs and nans.  Essentially, ValueError would be raised
> anywhere that IEEE 754(r) specifies raising the divide-by-zero or
> invalid signals, and OverflowError would be raised anywhere that IEEE
> 754(r) specifies raising the overflow signal.  The underflow and
> inexact signals would be ignored.
> (3) have a thread-local floating-point environment available from
> Python to make it possible to turn nonstop mode on or off, with the
> default being off.  Possibly make it possible to trap individual
> flags.
> 
> Any thoughts on the general directions here?  It's far too late to
> think about this for Python 2.6 or 3.0, but 3.1 might be a possibility.

     You also need to think about how conditionals interact with
quiet NANs.  Properly, comparisons like ">" have three possibilities:
True, False, and "raise".  Many implementations don't do that well,
which means that you lose trichotomy.  "==" has issues; properly,
"+INF" is not equal to itself.

     If you support quiet NANs, you need the predicates like "isnan".

     I've done considerable work with code that handled floating
point exceptions in complex ways.  I've done animation simulations
(see "www.animats.com") where floating point overflow could occur,
but just meant that part of the computation had to be rerun with a
smaller time step.  So I'm painfully familiar with the interaction
of IEEE floating point, Windows FPU exception modes, and C++ exceptions.
On x86, with some difficulty, you can turn an FPU exception into a
C++ exception using Microsoft's compilers.  But that's not portable.
x86 has exact exceptions, but most other superscalar machines
(PowerPC, Alpha, if anybody cares) do not.

     For Python, I'd suggest throwing a Python exception on all errors
recognized by the FPU, except maybe underflow.  If you're doing
such serious number-crunching that you really want to handle NANs,
you're probably not writing in Python anyway.

					John Nagle