don't NaN & infinities hide FP errors

[Dan Bishop]

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