Re: Table 4 proposal version 0.2...
> Date: Wed, 29 Feb 2012 16:47:41 +0100
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> CC: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: Table 4 proposal version 0.2...
>
> On 02/29/2012 04:11 PM, Dan Zuras Intervals wrote:
> >
> > I still have no good answer for midpoint(Empty) so that
> > is still not part of this proposal. However, I disagree
> > with some that it should be NaN on several grounds.
> > I believe the user would be better served by an arbitrary
> > choice such as 0
>
> Could you give a concrete example how it would serve the user better?
>
> > . . .
>
> Arnold Neumaier
>
I can.
Although you may not think it so.
The use of midpoint is to split intervals. Or, in the
case of interval Newton's, to find a point around which
to evaluate the interval Newton's step.
These are both searches. And both must have some
stopping criteria. Any such stopping criterion should
have the property that it stops BEFORE you want to
split Empty.
Therefore, the case should never come up.
Therefore, any answer returned, say 3.7, is as good as
any other.
However, since 754 exists & midpoint is a function that
returns a floating-point answer, the natural desire is
to return a NaN. The reason for this is a principle
that exists in 754, namely: one returns a NaN when there
is no other answer among the extended Reals that is
better than no answer at all. That is, Not a Number,
aka NaN.
This line of reasoning is quite correct, justifiable in
this case, &, IMHO, wrong for 1788.
Up until now we have been quite careful to avoid any
definitions that REQUIRE NaNs to be introduced at any
level of 1788. There are some nonsense cases in motion
30.2 that might require it but some flavor of Empty is
available as an answer in these cases. There is no
empty available to us for the table 4 functions.
Still, as I mentioned, these cases should never come
up in any algorithm that deserves the name.
So, what's the harm in a little NaN that might never
happen? Perhaps none.
One could also ask: what's the harm in returning an
arbitrary numeric value in a case that might never
come up? Probably about the same as the NaN case.
Then you have to ask yourself the hard question: What
if that case DOES come up? Is the user better served
by a standard that is NaN-free but returns harmless
answers when it must? Or by being hit in the head with
a NaN for doing something stupid?
Are we a more trusted standard in the former case where
the answer might be ignored because it is ignorable?
Or are we more trusted because silly questions will
always be tagged with a NaN even if the rocket explodes?
It is a hard question with no easy answer.
But I think it deserves more thought than just slapping
a NaN in place.
You may end up being correct but it depends on things
which are generally outside our control.
The best we can ask ourselves is: which principle do
we apply?
Do you know?
For sure?
Dan