Re: Bare decorations (was ...level 2 datums)
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>,
> "Michel Hack" <hack@xxxxxxxxxxxxxx>
> Subject: Re: Bare decorations (was ...level 2 datums)
> Date: Wed, 6 Oct 2010 17:10:22 -0500
>
> Michel Hack wrote:
> > Nate Hayes wrote:
> >> . . .
> >
> >
> > 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.
>
If I may suggest, having used isNaN() to filter out
things of the form [qNaN,x], there are no longer any
constraints on x. It need not be a floating-point
number at all. It can be anything. A collection of
bits. A pointer. An ASCII string. Anything.
There is even precedent for this in 754 applications.
Feel free to define anything that suits your purpose. - Dan