don't NaN & infinities hide FP errors

[Bengt Richter]

On 20 Nov 2004 05:32:54 -0800, danb_83 at yahoo.com (Dan Bishop) wrote:

>kartick_vaddadi at yahoo.com (kartik) wrote in message news:<940ee3e8.0411182041.74321118 at posting.google.com>...
>> Grant Edwards <grante at visi.com> wrote in message news:<419bbb08$0$531$a1866201 at visi.com>...
>> > On 2004-11-18, Jeremy Bowers <jerf at jerf.org> wrote:
>> > Let's say you've got a bunch of process control modules. Each
>> > of them takes a set of input values and produces a set of
>> > outputs.
>> > 
>> > Now let's say one of the inputs fails (no valid value is
>> > available).  You can just shut down the whole refinery, you've
>> > got to try to keep going as best you can.  The easiest way to
>> > do that is to feed a NaN in on the invalid input, and let it
>> > propogate through the network of modules.  The outputs that
>> > don't depend on the invalid input remain valid.  The outputs
>> > that do depend on the invalid input are NaNs.  
>> > 
>> > At the output end of things you don't have to do all sorts of
>> > logic to figure out which outputs are valid and which ones
>> > aren't -- all you have to do is decide what to do when each
>> > output is a NaN.
>> 
>> I understand. But I wasn't saying NaN should be removed, only that
>> arithmetic operations shouldn't produce it; you will still be free to
>> explicitly set a variable to NaN if you don't have valid input.
>> 
>> Besides, Python seems to raise exceptions instead of generating NaNs
>> or infinities, at least on my machine (Linux, GCC 3.3.2, Python
>> 2.3.3). Doesn't that support my view?
>
>Python's inconsistent about OverflowErrors:
>
>Python 2.3.4 (#2, Nov 13 2004, 18:58:41)
>[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
>>>> 1e1000
>inf
>>>> 10. ** 1000
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>OverflowError: (34, 'Numerical result out of range')
>
>Python 2.1.1 (#1, Aug 25 2001, 04:19:08)
>[GCC 3.0.1] on sunos5
>Type "copyright", "credits" or "license" for more information.
>>>> 1e1000
>Infinity
>>>> 10. ** 1000
>Infinity

I would guess that 1e100 is passed to a c library so the inconsistency
comes from c libraries. I'm not sure what would be the best policy. Silent
promotion to infinity is kind of squirrely in a context where a long
can easily represent the number exactly and finitely, unless you view
floating point as a special context of its own, in which case I might
like an optional exception hook that by default creates infinities and NaNs
but that I could use if I wanted to raise whatever or trace stuff etc.

But in the larger picture of numbers, overflow is a representation failure.
With decimal available, ISTM we could as well promote floats to decimal as
ints to longs, to get a unified policy across numerical representations.

BTW, my 2.4b1 returns a strange representation of infinity, that has no
round trip capability:

 Python 2.4b1 (#56, Nov  3 2004, 01:47:27)
 [GCC 3.2.3 (mingw special 20030504-1)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> 1e1000
 1.#INF
 >>> 1.#INF
 1.0

???
For calculated-by-python floats it seems fairly consistent, if limited:

 >>> 10.**1000
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 OverflowError: (34, 'Result too large')
 >>> float(10**1000)
 Traceback (most recent call last):
   File "<stdin>", line 1, in ?
 OverflowError: long int too large to convert to float

... But not too large for decimal (or rational based on longs).

Regards,
Bengt Richter