Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Bare decorations (was ...level 2 datums)



Michel Hack wrote:
Nate Hayes wrote:
However, I suspect another choice that will be better for many
types of implementations is that
    dec(X) = ÝSNaN,SNaN¨
returns a pair of signaling NaNs.  In this case, the decoration
"bits" of X are stored in the payload of the signaling NaNs.

Using SNaNs for this is problematic in a 754 environment.  That's
because every arithmetic operation has only two choices:  signal an
exception, or set the Invalid flag AND CONVERT the SNaN to a QNaN.

So the only way for SNaNs to propagate is to invoke an exception
handler that forces the output to be the same (or another) SNaN.
That's good in the sense that it can perform the necessary logic
for combining decorations, but it's typically BAAAD for performance!

If the point is to propagate bare decorations through a computation
so as to save on actual computation, this would be a huge net loss.

How about using quiet NaNs instead but just reserving a special bit to distinguish between empty set and bare decorations?




The only way I see to carry information in a bare interval is to use
non-standard intervals of a particular type, with a featureless NaN
as one component (to distinguish it from legitimate intervals, either
standard or perhaps Kaucher), and uninterpreted bits in the other
component.  Every operation would have to detect the NaN component
and then process the other component appropriately.  How that is done
efficiently (so that the relevant branches are almost always predicted
correctly) would be up to the implementation.

I think if I understand correctly you are suggesting something like:
   [NaN,x]
where "x" is some non-NaN IEEE 754 bit-pattern that carries the payload of decorations.

Did I get it right?

I'm ok with that, too, e.g., I can see this mechanism could be used to distinguish between empty set and bare decorations as well.




Watch out for shortcuts that would look at only one bound, as when
evaluating the Precedes relation!

Yes.



Michel.

P.S.  I hope we collect enough ammunition to force a radical redesign
     of NaN support in the next 754 revision -- but it's going to be
     painful because of existing baggage...

Help me work out the details and I'll do my very best to give you as much ammunition as you need. :-)

Nate Hayes