4 ms·

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 ch

by 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?
        Dylan16807 5y ago
        > 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.
        HWR_14 5y ago
        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.
        Dylan16807 5y ago
        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.
      - Akronymus 5y ago
        Oh that sounds pretty useful. Just storing the address would help a lot. Altough, with position independant code that could start to break down.

by 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?
      - Dylan16807 5y ago
        > 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.
        HWR_14 5y ago
        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.
        Dylan16807 5y ago
        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.
    - Akronymus 5y ago
      Oh that sounds pretty useful. Just storing the address would help a lot. Altough, with position independant code that could start to break down.