Some median Python NaNsense

Posted Jan 5, 2020 16:48 UTC (Sun) by scientes (guest, #83068)
Parent article: Some median Python NaNsense

> Sort the list using total order (which would move NaNs to both ends of the list, depending on their sign bits).

This is not a viable solution, as there is no such thing as negative NaN in the IEE 754 standard, and as such ARM processors normalize negative NaN to positive NaN, unsetting the signed bit, which differs from the behavior of x86_64 processors, and would mean you would get different results on differn't cpus.

Some median Python NaNsense

Posted Jan 5, 2020 19:19 UTC (Sun) by khim (subscriber, #9252) [Link] (3 responses)

That's if you do a stupid thing and try to compare them as floats. Treat the same bit sequence as integer, use regular comparison operator - and you always get the same correct result on all CPUs.

Trouble comes when you need to compare float and non-float (e.g. large integer). EEE 754 doesn't even define "total order" for cases like these.

Some median Python NaNsense

Posted Jan 7, 2020 18:39 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

That's too late. The architecture has already normalized them by the time you call median().

Basically, the problem is not in median() at all. The problem is that the architecture changed the numbers out from under you, so you are passing a different list of numbers under ARM than under x86. "Most people" won't notice that, because it's "just" replacing one NaN-valued bit pattern with another, and "most people" don't care about which NaN is which. But if you're casting to int, then you'll certainly notice differing bit patterns.

Some median Python NaNsense

Posted Jan 10, 2020 19:57 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

That's nonsense. Both NEON and SSE use THE SAME registers for both interger and floating point values. And instructions like movhlps don't even care if they move interger or floating point values.

Now, certain floating point operations may normalize NaNs... but then - they are supposed to change values anyway, it's unclear why you think NaNs shouldn't be affected that point. I mean: should "1.0 + NaN" give you the same NaN or a different NaN? IEEE 754 doesn't say and the solution is simple: just don't do it.

P.S. Now, if you would say that PYTHON would destroy these NaN values... this could happen, I don't work with Python at that level all that often. But I happen to DO work with ARM⇔x86 translation - which means I deal with all these changes regularly... neither x86 nor ARM change NaN unless they are supposed to.

Some median Python NaNsense

Posted Jan 10, 2020 20:03 UTC (Fri) by anselm (subscriber, #2796) [Link]

Python doesn't destroy NaN values if the underlying C implementation doesn't. At the end of the day, leaving aside unusual implementations such as JPython, the Python interpreter is just another program written in C, and for floating-point arithmetic it does whatever the C implementation on the system does (which in this day and age is presumably to rely on the floating-point instructions of the host processor).