Michel Hack wrote:
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.
Right.
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.
Exactly.
This suggests to me that the
standard might require distinguishable encodings for, say, Empty and
NaI, but leave the choice to platform-savvy implementers.
I really like this idea.
This is why in Motion 8 (exception handling) and even Motion 18 (domain
tetrit) I tried very hard to specify the behavior only at Level 1 and Level
2, since I appreciate the delicate balancing problems at Level 3 you
mention
and finding the best Level 3 solutions might be platform-specific.
I'd also suggest that the standard should require NaI to carry its payload
of decorations, too (the "domain" tetrit and the "defined and continuous"
bit).
But as you mention, as long as the Level 1 and Level 2 model is conformed
to, implementors can choose any mechanism they wish at Level 3 and Level 4
for the actual implementation.
Except perhaps there might be needed a standardized encoding used for
interchange. However, vendors wouldn't be required to use that as an
internal encoding for thier Level 3 and Level 4 implementations.
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.).
I wholeheartedly agree.
Also required would be generic operations to extract decoration values out
of the NaI.
Judging by how decorations are to be used, defining a (non-754) NaN
payload propagation rule that has lattice properties would be nice!
I think so, too.
Especially to see that someday it might be done fast and cheap in
hardware... this really would be a boon for many kinds of interval
algorithms... particularly those of the branch-and-bound variety, but I'm
sure others as well.
Nate