4 ms·

I'm not sure why the IEEE's original floating point specs didn't manage to make the NaN "quiet" (position 22) bit be the the leading "sign" bit -- although I'm

by dvt 5y ago

I'm not sure why the IEEE's original floating point specs didn't manage to make the NaN "quiet" (position 22) bit be the the leading "sign" bit -- although I'm sure there's a good reason. The NaN vs -NaN distinction is purely representative and has no semantic implications. As opposed to negative infinity or negative zero, for example. Also worth adding is that NaN comparisons will break catastrophically when using gcc's -ffast-math`.

pklausler 5y ago
There's no standard bit position for that flag, unfortunately, or even a standard interpretation (flag set -> quiet/signaling). A NaN just have to have at least one bit set in its significand to distinguish the NaN from an infinity. (So the fact that a binary value is a NaN is portable, but not the distinction between qNaN and sNaN.)
- dbaupp 5y ago
  I think that’s not the full story. The standard says: A quiet NaN bit string should be encoded with the first bit (d1) of the trailing significand field T being 1. A signaling NaN bit string should be encoded with the first bit of the trailing significand field being 0 That does use “should” (not “shall”) and is described as a “preferred encoding”, so it’s standards-compliant to do something else, but it’s not recommended.
  - pklausler 5y ago
    Sure, that's in the 2008 update. But OP was lamenting that the original IEEE-754 didn't encode qNaN/sNaN with the sign bit, no?
    - dbaupp 5y ago
      Yeah, you’re right that was the 2008 version. Fair enough.
lazulicurio 5y ago
Probably so if you bitcast a floating point value into a signed int it maintains the proper sign for comparisons.
- saagarjha 5y ago
  Yeah, but why have a signed NaN at all? It’s not like they have a defined ordering anyways…
- dvt 5y ago
  I think casting a NaN to an int will always just return gibberish, signed or not. In fact, this is explicitly undefined behavior in C.
dbaupp 5y ago
This would mean hardware/software tricks like those below wouldn’t work directly and would need additional gates/operations, because they’d noticeably change the meaning of NaNs. -x => x xor 0b100…00 abs(x) => x and 0b011…11
- dvt 5y ago
  Yeah, I'm sure plenty of things would break, though I don't really think the IEEE was thinking of bit-twiddling trickery when they were writing the spec.
  - volta83 5y ago
    We had quite a bit of existing FP hardware before the IEEE spec. Code using that hardware was not portable, because each FP unit did things subtly (and sometimes not that subtly) different. All those already existing hardware units were already doing this type of bit trickery. That's one of the main things that differentiated units from each other. The people that developed these units all had a stake and were involved in the IEEE process. That's what "standardization" used to mean. Once you have enough implementations of something that compatibility is an issue, then, with the hindsight of all those implementations, you create a standard. Today, the meaning of "standardization" is lost. I've seen so many standards that are based on zero actual experience, that had no implementations before the process began, and that 10 years later after many people invested thousands of man hours into a standard document, still have no implementation, some of which, like OpenCL 2 and OpenCL 3 have ended up being "retracted" and we are back to OpenCL 1. This is particularly true for Khronos standards, Vulkan being the most recent exception. Khronos failures include OpenCL 2, OpenCL 3, OpenMP, SyCL (getting first implementations now, 5-6 years before the first standard was written....). Even for the relatively widely used OpenMP standard, now at version 5, there are still so many features of OpenMP3 that have never been implemented and are arguably useless, that it isn't even funny. Same for OpenMP4 and 5 which mainly added "useless" GPU support (GPU support is important, but the way it was added makes it useless). The reason Khronos standard suck is because "designers" that can't program hello world write some idea on toilet paper, and sign it off as a standard. Then they ask "the community" to implement it for them, and either nobody cares, or the problem the standard solves are problems nobody has, or the ideas are just wishful thinking that aren't implementable, etc. The C++ standard is going the same route with signing off on tons of stuff that has little implementation experience, zero proven actual practical value delivered to users. The best C++ standard spectacular failure example is Concepts. 15 years and thousands of man years invested in designing Concepts, a feature whose main goal is to improve template error messages. Turns out, concepts actually make template error messages worse. They aren't completely useless, but still... who would have thought, right? Well, turns out that every standard that was standardizing standard practice would have... known this... you know... from actual experience...

by dvt 5y ago

pklausler 5y ago

There's no standard bit position for that flag, unfortunately, or even a standard interpretation (flag set -> quiet/signaling). A NaN just have to have at least one bit set in its significand to distinguish the NaN from an infinity. (So the fact that a binary value is a NaN is portable, but not the distinction between qNaN and sNaN.)

dbaupp 5y ago
I think that’s not the full story. The standard says: A quiet NaN bit string should be encoded with the first bit (d1) of the trailing significand field T being 1. A signaling NaN bit string should be encoded with the first bit of the trailing significand field being 0 That does use “should” (not “shall”) and is described as a “preferred encoding”, so it’s standards-compliant to do something else, but it’s not recommended.
- pklausler 5y ago
  Sure, that's in the 2008 update. But OP was lamenting that the original IEEE-754 didn't encode qNaN/sNaN with the sign bit, no?
  - dbaupp 5y ago
    Yeah, you’re right that was the 2008 version. Fair enough.

lazulicurio 5y ago

Probably so if you bitcast a floating point value into a signed int it maintains the proper sign for comparisons.

saagarjha 5y ago
Yeah, but why have a signed NaN at all? It’s not like they have a defined ordering anyways…
dvt 5y ago
I think casting a NaN to an int will always just return gibberish, signed or not. In fact, this is explicitly undefined behavior in C.

dbaupp 5y ago

This would mean hardware/software tricks like those below wouldn’t work directly and would need additional gates/operations, because they’d noticeably change the meaning of NaNs. -x => x xor 0b100…00 abs(x) => x and 0b011…11

dvt 5y ago
Yeah, I'm sure plenty of things would break, though I don't really think the IEEE was thinking of bit-twiddling trickery when they were writing the spec.
- volta83 5y ago
  We had quite a bit of existing FP hardware before the IEEE spec. Code using that hardware was not portable, because each FP unit did things subtly (and sometimes not that subtly) different. All those already existing hardware units were already doing this type of bit trickery. That's one of the main things that differentiated units from each other. The people that developed these units all had a stake and were involved in the IEEE process. That's what "standardization" used to mean. Once you have enough implementations of something that compatibility is an issue, then, with the hindsight of all those implementations, you create a standard. Today, the meaning of "standardization" is lost. I've seen so many standards that are based on zero actual experience, that had no implementations before the process began, and that 10 years later after many people invested thousands of man hours into a standard document, still have no implementation, some of which, like OpenCL 2 and OpenCL 3 have ended up being "retracted" and we are back to OpenCL 1. This is particularly true for Khronos standards, Vulkan being the most recent exception. Khronos failures include OpenCL 2, OpenCL 3, OpenMP, SyCL (getting first implementations now, 5-6 years before the first standard was written....). Even for the relatively widely used OpenMP standard, now at version 5, there are still so many features of OpenMP3 that have never been implemented and are arguably useless, that it isn't even funny. Same for OpenMP4 and 5 which mainly added "useless" GPU support (GPU support is important, but the way it was added makes it useless). The reason Khronos standard suck is because "designers" that can't program hello world write some idea on toilet paper, and sign it off as a standard. Then they ask "the community" to implement it for them, and either nobody cares, or the problem the standard solves are problems nobody has, or the ideas are just wishful thinking that aren't implementable, etc. The C++ standard is going the same route with signing off on tons of stuff that has little implementation experience, zero proven actual practical value delivered to users. The best C++ standard spectacular failure example is Concepts. 15 years and thousands of man years invested in designing Concepts, a feature whose main goal is to improve template error messages. Turns out, concepts actually make template error messages worse. They aren't completely useless, but still... who would have thought, right? Well, turns out that every standard that was standardizing standard practice would have... known this... you know... from actual experience...