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:
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