Catching up on email... On 1/8/2019 10:55 AM, Hans Boehm wrote:
The IEEE standard does say that for quiet NaNs, the value (or one of them) "should" be preserved by most operations on the quiet NaN. I have not heard of implementations violating this for anything other than the "quiet" bit. Thus I don't immediately see why it would be problematic to encode an explicitly programmer-introduced error cause in the remaining bits (as opposed to relying on hardware-generated patterns). I have not seen non-testing code that does so, but I would be mildly surprised if it doesn't exist somewhere.
The IEEE standard does recommend the "payload" of NaN bits be preserved, that is the significand bits of the NaN. The various versions of 754 and its draft revision are less committal about the sign bit of a NaN. Some processors use an implementation of, say, floating-point multiply where the sign bit of the product is the XOR of the sign bit of the inputs. In interests of keeping such calculations more straightforward, an is-NaN check is not included on this pathway. That is all well and good in terms of supporting the "retrospective diagnostics" intention of NaN payloads, but does run afoul of aspirations to have a predictable sign bit exposed via a raw-bits view.
Cheers, -Joe
