Re: Motion P1788/M007.01_NaI: Discussion period begins
P1788 members
On 6 Aug 2009, at 14:24, Arnold Neumaier wrote:
J. Wolff v. Gudenberg schrieb:
Vincent Lefevre schrieb:
2.2 Arguments
Another argument against NaI: there are different and contradictory
NaI concepts. For instance, if NaI is used for missing data, then
min(some_interval,NaI) should return some_interval, not NaI.
if NaI means illegal construction which is what this motion proposes
it must propagate
"There is an obvious analogy to 754 NaN"
Very partially. NaN can also mean [−∞,+∞] (any real number),
as in
hypot(+∞,qNaN), or also the empty set (e.g. result of sqrt(-1)).
The fact that there are different uses for NaI suggest that NaI, if it
is made available, should exist with a payload, so that different
uses can be distinguished.
I concur with this. I think it's worth copying a recent exchange
between Dan Zuras and me:
On 2 Jun 2009, at 10:44, Dan Zuras Intervals wrote:
On 1 Jun 2009, at 23:21, Dan Zuras Intervals wrote:
See, there are a lot of things that can happen on the way to
a standard.
We should have answers for as many of them as we can live with.
John Pryce:
You are right. NaI, if we choose to have it, will mean different
things to different people.
NaN can mean
"On the execution trail to here, something went wrong"
which I suppose was the original 754 intent.
"Gap" in sequential data
used e.g. by Matlab in the plot function
"Unknown real value"
but in that case 0*NaN should be 0 ...?
and probably "Missing value" in stats data, etc.
Dan Zuras:
I was there & *I* can't tell you what the original intent was.
All of these & more (has a value but not a real one, domain
error, system/language/user extension, debugger breakout, ...)
were mentioned.
I think people went for it because it provided a useful
mechanism for giving back an answer you don't know how to
give.
The 754 specifications of qNaN and sNaN are not quite clear to me.
But it seems qNaN implements, mostly, the notion of "On the execution
trail to here, something went wrong" -- except for things like max
(3,qNaN) giving 3, which embodies the "missing value" notion. While
sNaN can be used to implement other meanings, but only by trapping an
exception, probably with a serious performance loss. As David Hough
wrote yesterday, we have a dilemma:
On 6 Aug 2009, at 21:40, David Hough 754R work wrote:
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. ...
My feeling is that 754's definition of qNaN as a compromise between
two (or more) "meanings" is NOT a good idea. For NaI, I am a
supporter as you know. I favour
- Make a list of all the "meanings" that people think deserve support
and that they can _precisely_ specify the behaviour of.
- Take the meaning in Juergen's motion as the default one.
- Support this meaning, and some others, officially in P1788, after
careful
discussion of how to make NaI run efficiently, in the various
contexts
mentioned by David above. And decide which is the most important of
these contexts.
There's a chicken & egg flavour to all this. If one knows a certain
construct or event hurts performance, one tries to use a coding style
that avoids the construct or event. One may avoid a certain
algorithm, or rewrite it to avoid these things. And then hardware
vendors will say "NaI doesn't occur often, so there's no need to make
it efficient"...
But I feel, the clearer we are about what uses an NaI *might* offer,
the better we shall understand the tradeoffs, and the more chance
there will be of persuading someone to implement one or more
(precisely specified) meanings of NaI efficiently.
Best wishes
John Pryce