Re: Table 4 proposal version 0.2...
On 02/29/2012 05:33 PM, Dan Zuras Intervals wrote:
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.
So if it comes up, it should signal that something bad happened - and
NaN does this.
A user may write a legal function like this.
function yy=centered_form(f,xx)
x=mid(xx);
y=f(x); r=sup(abs(f(xx))*rad(xx);
yy=midrad(y,r);
end
with your proposal to set mid and rad of empty to 0, you get
centered_form(f,Empty)=[f(0),f(0)].
Not really wrong, but nevertheless quite unexpected, with nontrivial
consequences:
If the problem to solve is to cover the set of x such that f(x) in F
and F happens to contain f(0) then the final covering contains lots of
empty sets, one for every leaf that otherwise would have been discarded.
With my proposal, the user is warned since forming midrad gives an error.
Therefore, any answer returned, say 3.7, is as good as
any other.
This doesn't provide a service but at best an ''it doesn't matter''.
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.
There is nothing wrong with this reasoning. NaN indicates a nonexisting
answer, and is a meaningful results of functions that return floats, the
domain of 754.
You want to go back to the old Fortran times, where nonexisting results
are replaced by zero for systematic reasons!
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.
Interval results should always be intervals.
Float results should always be floats.
I cannot see why anything more stringent is needed.
If we don't want to have NaN on level 1 we simply declare the
corresponding real function values to be nonexistent at this level.
This translates naturally to level 2 as NaN values.
Still, as I mentioned, these cases should never come
up in any algorithm that deserves the name.
So using 0 in place of NaN doesn't serve any purpose,
but makes the call more expensive.
This is enough reason not to have it if no other advantages arise.
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.
I gave a case above where unexpected things happen.
I have no idea whether something worse could also happen.
So better give the diagnostic information if it comes for free.
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?
The second, because it shouldn't come up in a well-designed program.
So returning NaN gives some extra safety, while it never harms.