NaN comparisons - Call For Anecdotes
rosuav at gmail.com
Wed Jul 9 17:13:26 CEST 2014
On Thu, Jul 10, 2014 at 1:08 AM, Anders J. Munch <2014 at jmunch.dk> 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. I have no idea how you imagine
> processing IEEE-754 floating-point values in int form.
> 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.
> And doing so in a way that does not require special handling in algorithms
> that are otherwise generic.
> 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, then NaNs stand out as
> the values that have special algorithm-breaking magic.
> I gave an example of such an algorithm in an earlier reply to Chris.
If you need to do bitwise comparisons, then the easiest way is to use
the bitpattern, converted to an integer. A 64-bit float becomes a
64-bit integer. It's then very simple to compare them, and reflexivity
is maintained. At what point do you actually need them to be floats?
What are you really doing with them?
More information about the Python-list