Chris Angelico writes: > The reason NaN isn't equal to itself is because there are X bit > patterns representing NaN, but an infinite number of possible > non-numbers that could result from a calculation.
I understand that. But you're missing at least two alternatives that involve raising on some calculations involving NaN, as well as the fact that forcing inequality of two NaNs produced by equivalent calculations is arguably just as wrong as allowing equality of two NaNs produced by the different calculations. That's where things get fuzzy for me -- in Python I would expect that preserving invariants would be more important than computational efficiency, but evidently it's not. I assume that I would have a better grasp on why Python chose to go this way rather than that if I understood IEEE 754 better. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
