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

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



> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Bare decorations (was ...level 2 datums)
> Date: Wed, 6 Oct 2010 21:55:15 -0500
> 
> Michel Hack wrote:
> >> 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.
> >
> > Almost.  It doesn't have to be a 754 bit pattern; indeed, if one wants
> > to perform boolean operations on the bits it's better to use a Uint.
> > On platforms where this has to live in FP registers that are more than
> > just bit buckets this might not work, so the choice will have to be up
> > to the platform-specific aspects of the implementation.
> >
> > Michel.
> > ---Sent: 2010-10-07 01:22:13 UTC
> 
> and
> 
> Dan Zuras wrote:
> >> 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?
> >
> > 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
> 
> 
> I find both of these answers interesting. We already use [NaN,x] or [x,NaN] 
> to represent NaI in the software implementation of our Kaucher arithmetic 
> interval library. This has been working for some time and is fairly 
> efficient. The main difference is we don't yet propagate any decorations in 
> the NaI: we had been following P1788, anticipating we would probably need to 
> try putting the decorations into the payload of the NaN. But I will take a 
> look at putting a "domain" decoration into x and see how that affects the 
> overall performance of the library instead.
> 
> Nate Hayes

	Sounds reasonable.

	I'm not sure what information you plan on carrying around
	there but I'm sure its safer to put it in x than in the
	payload of the NaN.  For all the reasons that Michel & I
	have described.

	Good luck.

	Let us know how it works out.


				Dan