On Sunday 03 July 2005 10:47 pm, Steven D'Aprano wrote: > Any floating point package that supports the IEEE > standard should give you a test to see if a float > represents a NaN. That's what you need. You certainly > can't rely on "x == SOME_NAN" because there are 254 > different NaNs. > > There is no sensible reason to test equality of NaNs. > It is logically nonsense to say that one NaN is equal > to another, as such a thing implies contradictions like > -1==-2. If you support IEEE, you will have a test for > NaNs, so you can detect them when you need to.
I have to mention that the idea of a math package that allows NaN to propagate as though it were a number scares the willies out of me. God help me if I were to use it on something like Engineering where lives might depend on the answer being right. That'd be like having a math package that allowed, say 0/0 = 1 or Inf/Inf = 1. It's not hard at all to come up with dozens of problems for which that is the WRONG guess -- getting an actual answer for dividing two infinities requires using limits and calculus. The reason Inf/Inf isn't defined is that it can actually be just about any number --- finite or infinite. I can seriously imagine structures breaking and collapsing because they were designed using such a package, and a NaN was generated and missed somewhere. Really, the only *right* thing to do is to raise an exception ASAP after the NaN comes up. On a more practical note, *is* there a isNaN() function? Seems like it ought to be in the math module. Looks like you have to do it through "fpectl" as things stand. Is anyone else bothered that "math" and "cmath" are in the "Miscellaneous Services" section of the LR? Seems like we ought to get Numeric and/or Numarray and group all of these in a separate "Math & Science" section. -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
