Re: Bare decorations (was ...level 2 datums)
> Date: Wed, 06 Oct 2010 15:45:06 -0400
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: Bare decorations (was ...level 2 datums)
>
> 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.
>
> 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.
>
> Watch out for shortcuts that would look at only one bound, as when
> evaluating the Precedes relation!
>
> 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...
Folks,
I concur with Michel's assessment of the dangers of using
sNaNs to flag things. And it is "BAAAD for performance"
for values of BAAAD that run into the hundreds of times
slower. Thousands for parallel applications.
His suggestion for how to approach bare intervals would
work well. Putting a qNaN in one component & the needed
information in the other could be done quickly with just
an isNaN() test. And you don't have to count on any
propagation behavior. ANY qNaN will do.
And, while I don't personally agree with the need for bare
intervals, let me suggest another approach: Have a decoration
that SAYS its a bare interval. I know it sounds silly but
maybe it will work.
Indeed, we are getting enough exceptional states now that
perhaps we should consider a flavor decoration. It could
take on values like {standard, nonStandard, bareInterval,
bareDecoration, empty, NaI}. And with each value would
come its own convention as to whether the interval part
or the other decorations have meaning & how to interpret
them.
As for collecting enough ammo to force a redesign of 754,
I have to tell you that there are aspects of Arnold's idea
that I think have merit.
Adding new values is not one of them.
But either redefining the use of directed roundings or
installing new roundings just might fly. Properly designed,
such a thing could well work its way back into the next
revision of 754. After all, directed roundings were
originally intended for US. It is why they are there.
If they are not correctly designed for our use they should
be redesigned.
And I would support such a thing when the time comes.
However the time comes in 2023 & I will be 70 years old by
then & lucky to be making any sense at all.
In the mean time, I think it unwise to require modifications
to 754 in order for a conforming implementation to perform
reasonably fast.
Michel's approach works better. Or a flavor decoration.
Anything but new values in 754.
Yours,
Dan