don't NaN & infinities hide FP errors

Grant Edwards grante at visi.com
Thu Nov 18 23:50:08 EST 2004


On 2004-11-19, kartik <kartick_vaddadi at yahoo.com> wrote:

>> 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.

I don't think you do understand.  The whole _point_ of my post
was that NaNs propagate.  They're useless if arithmetic
operations don't produce NaNs.

> 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).

I don't see any exceptions for operations involving NaNs:

$ python
Python 2.3.3 (#2, Feb 17 2004, 11:45:40) 
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2
Type "help", "copyright", "credits" or "license" for moreinformation.
>>> import math
>>> x = float("nan")
>>> x
nan
>>> x+0.0
nan
>>> x*15.6
nan
>>> math.sin(x)
nan
>>> 

Python does generate exceptions for divide by zero.  I would
find it far more useful for it to produce an infinity.

> Doesn't that support my view?

I don't think so.

-- 
Grant Edwards                   grante             Yow!  This PIZZA symbolizes
                                  at               my COMPLETE EMOTIONAL
                               visi.com            RECOVERY!!



More information about the Python-list mailing list