Re: An error-catching question
Nate Hayes wrote (in the context of avoiding dependence on NaN signs):
> Perhaps it might be better if certain bits in the NaN payload are used to
> make a distinction between empty set and bare decorations (NaI) instead.
The problem here is unpredictability of WHICH payload survives when
two NaNs meet in an operation.
We have had a chicken-and-egg problem with NaN payloads for 25 years.
Propagation is unreliable so we can't depend on it -- so payloads are
not used much. As a result, there is no incentive to do better.
Since NaN propagation is generally a hardware issue (it would be too
expensive always to check in software), incompatible propagation rules
are the rule, which 754-2008 could do little about because mandating new
behaviour would have been too expensive. For the new world of DFP the
specification is tighter, but still not completely tight -- most likely
because hardware implementers don't want to slow down common paths in
order to have more predictable NaN propagation rules (e.g. the ability
to determine the sign in parallel with other operand decoding and/or
arithmetic).
The reason for using NaNs in intervals is that this permits almost
automatic propagation without the need to check at EVERY intermediate
point. The question facing the implementer is how to strike a balance
between the need to classify operands for case-based processing and
the desire for speed in common cases. This suggests to me that the
standard might require distinguishable encodings for, say, Empty and
NaI, but leave the choice to platform-savvy implementers. Any given
platform may have predictable propagation rules (e.g. first operand
wins, or perhaps even selection based on payload ordering), and could
pick encodings (e.g.[Nan,non-NaN]) that are most effective on that
platform. There must of course be generic operations that return the
logical type of an interval (I'm referring to IsEmpty(), IsNaI() etc.).
Judging by how decorations are to be used, defining a (non-754) NaN
payload propagation rule that has lattice properties would be nice!
Michel.
---Sent: 2010-09-10 19:53:07 UTC