NaN comparisons - Call For Anecdotes

[Steven D'Aprano]

On Wed, 09 Jul 2014 17:08:15 +0200, Anders J. Munch wrote:

> Steven D'Aprano wrote:
>> It seems to me that the trivial work-around is:
>>
>> * gather packed floats from some device, as ints * process them *as
>> ints* in some way which requires reflexivity * unpack back into floats
>> * (maybe) much later perform numeric calculations on them
>>
>>
>> Although perhaps I don't understand your use-case.
> 
> Clearly you do not. floats are not ints. 

Of course not. But there is a one-to-one correspondence between a 64-bit 
float and a 64-bit int, and the conversion is lossless in both directions.

When you talked about:

"So when my software reads these values in binary, unpack them using the
struct module, and goes to work."

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.


> 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. Or, if it's a C single rather 
than a double, cast the 32-bit float into a 32-bit int. Now you can 
compare them for equality without carrying about NANs, and without losing 
data. Later, when you're ready to start doing some numeric work on them, 
you cast back to floats. That's the idea I had in mind. Perhaps it 
doesn't match your use-case.


> 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?


> And doing so in a way that does not require special handling in
> algorithms that are otherwise generic.

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?


> 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.

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.


> then NaNs stand out
> as the values that have special algorithm-breaking magic.

Well yes. Floats have all sorts of problems. They're horrible really, the 
worst possible way to model real numbers, except for all the other ways.

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?


-- 
Steven