And Jeffrey Sarnoff writes:
> IEEE 754-2008 makes it clear that QNaN payload values are fare game:
> (is says details of NaN propagtion may have vender differences, and)
Having been in the room at the time of utter despair... (And
admittedly not having looked at your package yet.)
One "right" way of using the NaN values without following their
propagation is the following:
- ensure the input has NaN payloads denoting something about
their origin and the likelihood of causing issues later,
- check the invalid flag at a felicitous time, then
- scanning to the inputs to rank the possible issues.
This somewhat fits a Lispy with-NaN-debugging macro style (that
can at compile time ignore absolutely everything depending on the
safety level). Naturally, it's not guaranteed to work, and I'm
not at all sure how a user could fill in the payloads
appropriately. If there is a good answer to filling in the
payloads, well, the standard is up for revision...
