Chris Angelico wrote:
Why *should* all NaNs be equal to each other? You said on the other
list that NaN==NaN was equivalent to (2+2)==(1+3), but that assumes
that NaN is a single "thing".
I don't actually care if all NaN bitpatterns are in the same equivalence group
or if each bitpattern is its own equivalence group. I just want the ==
equivalence relation to be sound.
For hash keys, float object identity will successfully look them up:
Except you can't expect to rely on object identity in most interesting cases.
>>> x = float('nan')
>>> import struct
>>> y = struct.unpack('<f', struct.pack('<f', x))[0]
>>> d[x] = "found"
>>> d[y]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: nan
and also:
>>> def f(): return float('inf')/float('inf')
>>> f() == f()
False
>>> f() is f()
False
But any time you compare floats for equality, you *already* have to
understand what you're doing (because of rounding and such), so I
don't see why the special case on NaN is significant, unless as
mentioned above, you want all NaNs to be equal, which doesn't make
sense.
Let me conjure up a simple example:
| class Monitor(Thread):
| def run(self):
| old = self.get_current_value()
| while not self.Terminated:
| new = self.get_current_value()
| if new != old:
| print(time.asctime(), "changed to", new)
| old = new
| time.sleep(1)
This is a completely generic change detection algorithm, and not a
"floating-point algorithm" in any way: It will work on strings, lists, sets,
anything that get_current_value returns, including non-NaN floats. You don't
need to know anything about floating-point representation to write or use such
an algorithm, why should you? It works on tuples, sets, lists, serial port
handles, module objects, pretty much anything you can imagine -- except NaN floats.
regards, Anders
--
https://mail.python.org/mailman/listinfo/python-list
