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