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