The sign of the NaN might change (as you'd expect from an absolute value), but the NaN payload (which IEEE 754 envisaged might carry debug information) won't change, right?

The NaN payload's debug information is allowed to use the sign bit as part of the debug code (according to my knowledge of IEEE 754). Personally, I cannot imagine needing that many debug codes in most common usage, and I don't know if many implementations do, but it would definitely be something to check in your specific implementation details.

If you're packing values into NaNs it's easy to end up using all the bits. For example, if you start storing 48 bit pointers you only have 4 bits plus the sign bit left over for the type of the value.

This is true. I doubt those are the result of an operation however (what system creates NaNs like that?). It sounds like that is interesting data manipulation.

> I doubt those are the result of an operation however (what system creates NaNs like that?).

I don't know if anything does but it could certainly be useful. Imagine if a NaN said exactly where in your code it was created.

> Imagine if a NaN said exactly where in your code it was created.

I'm not sure how that would be useful. A debugger should have better ways of identifying NaN creation and I don't see anything else using a pointer to code in production. It seems cool though.

It would also lead to problems like: x = 5.0 * y y is NaN with some address as the NaN type. NaN * 5.0 => NaN. Which address (the original or the * 5.0 line) is used?

> I don't see anything else using a pointer to code in production.

If you log it, you could trace it back to the line of code at your leisure.

> It would also lead to problems like: x = 5.0 * y y is NaN with some address as the NaN type. NaN * 5.0 => NaN. Which address (the original or the * 5.0 line) is used?

I don't mean to be rude, but isn't the answer to that question extremely obvious?

The behavior that's much more useful and enshrined in the IEEE spec is that you keep the original NaN.

If you log it, why wouldn't you just log it at creation time. Are you going to periodically scan all floating-point numbers used everywhere in your code to see where they are created?

> The behavior that's much more useful and enshrined in the IEEE spec is that you keep the original NaN.

I didn't realize it was in the spec. I just checked, and you're right! That does however seem strange - X was never set by operation NNNN, Y was.

To me, trying to handle exceptions every time a NaN shows up sounds like it's riskier to performance than a few checks at important places. You wouldn't scan. Probably depends on code base.

> That does however seem strange - X was never set by operation NNNN, Y was.

If you're using NaN payloads, it would almost never be helpful for 95% of your NaNs to turn into a generic "used a NaN in arithmetic" version.

Oh that sounds pretty useful. Just storing the address would help a lot. Altough, with position independant code that could start to break down.

Why do you say that? It extracts the bits using doubleToRawLongBits which does not do NaN canonicalization by design. And it gets back to a double with longBitsToDouble which "returns the double floating-point value with the same bit pattern". So it doesn't change anything either.

NaN values can have sign bit set. This will unset it.

Too late to edit now, but the floating point standard actually specifies that this is what abs should do.

You made a good point. But one might argue that -nan should become nan after an abs operation. I don't know enough about this topic to determine whether such an argument has merit though.

It's not -NaN vs NaN. There are a bunch of NaN types, which are not related like that. It could (according to the spec) change "NaN: Attempt to arcsin value greater than 1" to "NaN: Zero divided by Zero operation"

So we defined abs(NaN), sounds like a feature to me ;-)

They really missed an opportunity to call it caNaNicalization