float("nan") in set or as key

[John Nagle]

On 5/29/2011 9:15 PM, Steven D'Aprano wrote:
> On Mon, 30 May 2011 11:14:58 +1000, Chris Angelico wrote:
>
>> So, apart from float("nan"), are there actually any places where real
>> production code has to handle NaN?

    Yes.  I used to write dynamic simulation engines.  There were
situations that produced floating point overflow, leading to NaN
values.  This wasn't an error; it just meant that the timestep
had to be reduced to handle some heavy object near the moment of
first collision.

    Note that the difference between two INF values is a NaN.

    It's important that ordered comparisons involving NaN and INF
raise exceptions so that you don't lose an invalid value.  If
you're running with non-signaling NaNs, the idea is supposed to
be that, at the end of the computation, you check all your results
for INF and NaN values, to make sure you didn't overflow somewhere
during the computation.  If, within the computation, there are
branches based on ordered comparisons, and those don't raise an
exception when the comparison result is unordered, you can reach
the end of the computation with valid-looking but wrong values.

				John Nagle