Re: Motion P1788/M007.01_NaI: Discussion period begins
> to keep our standard simple, I try to avoid the payloads as far as possible.
Seems to me, as somebody not following very closely, that there have been
several themes pursued by various contributors over past months:
1) define an interval arithmetic that is about as fast as possible (while
preserving correctness) on existing hardware (presumably x86-64)
2) define an interval arithmetic that could perform well on hardware that
doesn't exist but could exist as a slight enhancement to 754 hardware
3) define an interval arithmetic that is optimal for programming
without concern for performance on existing hardware, hoping that
new hardware will be designed to help
4) define an all-inclusive meta-definition that encompasses all of the
above
Every time I have approached this problem I have been somewhat stymied by
the tradeoffs these present. For instance, it's very efficient on
current hardware to have every pair with either endpoint NaN represent
the empty interval. That doesn't leave a representation for NaI, so one
is tempted to define away all exceptions as leading either to the empty set or
the whole line.
If one dedicates certain NaN payloads to different interpretations, on
existing hardware one probably will use only signaling NaNs and trap
on each access to implement correct semantics. That's a major
performance problem on existing hardware if one believes that the empty
set will sometimes be a frequent operand.
So perhaps there's a way to use quiet NaNs for empty intervals and
signaling NaNs for various NaI symbols. You still have to trap on NaI
and take pains to return signaling NaN-based NaI results. Maybe any
computation which has lots of NaI's is already lost and performance no
longer matters.