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
--
https://mail.python.org/mailman/listinfo/python-list
