NaN comparisons - Call For Anecdotes

[Anders J. Munch]

Steven D'Aprano wrote:
> I assumed that you realised that the 64-bit(?) values you were receiving
> in binary could be interpreted as ints. After all, you have to unpack
> them from some bytes.

> Since that's not what you're doing, I have no idea what it is.

Stop obsessing over how NaN's came to exist in my software. That's just context.
The argument is over how those NaNs should behave. Their provenance is not relevant.

>> I have no idea how you imagine
>> processing IEEE-754 floating-point values in int form.
> Cast your 64-bit float into a 64-bit int.

I can construct a bijective mapping between any data structure and a subset of 
the natural numbers, but that has nothing to do with practical programming.
A "cast" value would be impossible to work with.

>
>> My use case is: Working with IEEE-754 floating-point values. That means
>> storing and retrieving them, serialising and transferring them,
>> accepting them as user input, printing them, all the usual things you do
>> with values.
> But apparently not arithmetic?
Of course also arithmetic. I left it out of the list because then you would say 
"hah! if you're doing arithmetic then it's not a generic algorithm". Apparently 
I can't win, you are going to nitpick anything I write.

> Ah, well there's your problem. NANs are special, as a signed zeroes and INFs. 
> Does it distress you that x + x = x when x is an INF?
No.

>> When the same algorithm is capable of dealing with ints, bytestrings,
>> text string, tuples, list, dictionaries, time stamps, NoneType's, bools,
>> floating-point floats and a thousand other things,
>    ^^^^^^^^^^^^^^^^^^^^^
>
> Obviously not, or you wouldn't be complaining about the inability to
> handle floats.

NaNs are not floating-point values. A floating-point value has a sign, an 
exponent and a mantissa.  They are "IEEE 754 floating point" values, though.

> The hardware devices generating your float data... do they also generate
> ints, bytestrings, text strings, tuples, lists, dicts, time stamps, None,
> bools, and a thousand other things? If not, I wonder why you are
> insisting that you have to handle a *specialised* data type using a
> *generic* algorithm.
All the other types are also specialised, for their separate purpose. That 
doesn't make them non-reflexive.


> I'm not unsympathetic to your problem, which is why I proposed two new
> operators, === and !==, and a change to == and !=, in another thread.
> Would == always doing an identity test before calling __eq__ solve your
> problem? If not, what would it take to solve your problem?
It would not solve it. Two bitwise identical NaNs would still compare different.
What would solve the problem is making identical NaNs compare equal.

regards, Anders