4 ms·

> return Double.longBitsToDouble( > Double.doubleToRawLongBits(value) & 0x7fffffffffffffffL); Technically, this will change NaN values into different one

by im3w1l 5y ago

> return Double.longBitsToDouble( > Double.doubleToRawLongBits(value) & 0x7fffffffffffffffL); Technically, this will change NaN values into different ones.

ectopod 5y ago
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.
- im3w1l 5y ago
  NaN values can have sign bit set. This will unset it.
  - toxik 5y ago
    So we defined abs(NaN), sounds like a feature to me ;-)
  - gene91 5y ago
    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.
    - HWR_14 5y ago
      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"
  - im3w1l 5y ago
    Too late to edit now, but the floating point standard actually specifies that this is what abs should do.
- kennywinker 5y ago
  They really missed an opportunity to call it caNaNicalization
FabHK 5y ago
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?
- HWR_14 5y ago
  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.
  - Dylan16807 5y ago
    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.
    - HWR_14 5y ago
      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.
      - Dylan16807 5y ago
        > 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.
        HWR_14 5y ago
        > 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?

by im3w1l 5y ago

> return Double.longBitsToDouble( > Double.doubleToRawLongBits(value) & 0x7fffffffffffffffL); Technically, this will change NaN values into different ones.

ectopod 5y ago

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.

im3w1l 5y ago
NaN values can have sign bit set. This will unset it.
- toxik 5y ago
  So we defined abs(NaN), sounds like a feature to me ;-)
- gene91 5y ago
  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.
  - HWR_14 5y ago
    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"
- im3w1l 5y ago
  Too late to edit now, but the floating point standard actually specifies that this is what abs should do.
kennywinker 5y ago
They really missed an opportunity to call it caNaNicalization

FabHK 5y ago

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?

HWR_14 5y ago
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.
- Dylan16807 5y ago
  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.
  - HWR_14 5y ago
    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.
    - Dylan16807 5y ago
      > 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.
      - HWR_14 5y ago
        > 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?