On Thu, 25 Mar 2010 10:25:35 pm Nick Coghlan wrote: > Steven D'Aprano wrote: > > I'd like to turn the question around ... what algorithms are there > > that rely on NaN == NaN being True? > > Absolutely anything that expects "x is y" to imply that "x == y". The > builtin containers enforce this by checking identity before they > check equality, but there are plenty of algorithms that won't.
Fair point, but I was actually thinking about mathematical algorithms. Builtin containers may also fail with any object that violates the expectation that identity implies equality, e.g.: class AlwaysDifferent: def __eq__(self, other): return False def __ne__(self, other): return True I don't see this as a problem -- if you choose to use such objects, you're responsible for understanding what is going on. If you choose to use floats, then you need to understand that NANs are weird. Personally, I'm less concerned about sets of floats ending up with strange combinations of NANs than I am about the possibility of disastrous maths errors caused by allowing NANs to test as equal. Here's a simplistic example: def func(a, b): if a == b: return 1.0 return math.sin(a*b)**(a-b) (I say "simplistic" because it currently fails for a=b=INF.) Currently this function will do the right thing for a, b both NANs: >>> func(float('nan'), float('nan')) nan but making NANs test as equal will cause it to give the wrong answer. I fear that kind of error far more than the current funny behaviour of builtin containers with NANs. -- Steven D'Aprano _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com