Re: Table 4 proposal version 0.2...
On 2012-02-29 17:57:48 +0100, Arnold Neumaier wrote:
> On 02/29/2012 05:33 PM, Dan Zuras Intervals wrote:
[...]
> > 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.
I entirely agree (as I've already said).
> 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:
In accurate mode, I would even see this as wrong.
> > 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.
Even though not all FP arithmetic are IEEE-754 conforming, the
fact that P1788 already requires +inf and -inf means that NaN
should be available in the FP implementation.
BTW, I think that P1788 should allow non-FP formats (e.g.
double-double and rational arithmetics). Requirements could
be at least: the number of values is finite, the format is
symmetric (-x is exact), and +inf, -inf and NaN are available.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)