NaN comparisons - Call For Anecdotes
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Wed Jul 9 12:53:47 EDT 2014
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
More information about the Python-list
mailing list