Re: Midpoint paper (2012-02-08 version)
On 2012-02-15 16:20:03 -0800, Dan Zuras Intervals wrote:
> > Date: Thu, 16 Feb 2012 00:16:36 +0100
> > From: Vincent Lefevre <vincent@xxxxxxxxxx>
> > To: stds-1788@xxxxxxxxxxxxxxxxx
> > Subject: Re: Midpoint paper (2012-02-08 version)
> >
> > On 2012-02-15 11:48:18 -0800, Dan Zuras Intervals wrote:
> > > At the very least, would you consider that one of those
> > > compatibility requirements should be that all endpoints
> > > within T be representable within F?
> >
> > Certainly not. Unless I'm missing something, this would prevent one
> > from using some (most) mid-rad implementations. Even if the radius
>
> Not in the slightest. It would merely require that such
> an implementation support an associated floating-point
> type that can represent both Fmax + Fmax & Fmax + Fmin.
> It requires one extra exponent bit & 2*Emax + p significand
> bits.
The goal of a compatible format is to avoid annoying problems such
as a rounded midpoint not being in the interval or (as a possible
consequence) a rounded midpoint being infinite. It is not there to
solve every problem. In particular, I think that the requirements
must not prevent the following choices:
* For an inf-sup interval type, the format of the endpoints is a
compatible format.
* For a mid-rad interval type, the format of the midpoint is a
compatible format.
And for any other interval type, the compatible format shouldn't
take more space than the one used for the intervals.
I really don't think that it should be required that the endpoints
be representable in a compatible format. The hull function is there
to take care of this problem (and I even wonder whether such a
function is really useful in practice).
> If that is too much of a burden, then how about requiring
> an associated type F sufficient to represent all endpoints
> in explicit types & the midpoint in all implicit types?
IMHO, all requirements on implicit types should be applicable to
an inf-sup type (for which the midpoint isn't always representable
exactly). So, I disagree.
Now I think that it should only be required (at least for the moment):
*** Each non-empty interval of T must contain an element of F. ***
This is necessary to have a midpoint function whose rounded result is
in the interval.
Due to point intervals, this means that F should contain at least:
* for inf-sup, all the endpoints;
* for mid-rad, all the midpoints.
IMHO, this is not a problem if F contains more values. This just means
that a F -> interval conversion would yield a non-point interval,
possibly unbounded. But this is safe, as the main property is that
the interval contains the initial number. Note that this will also
happen with text-to-interval constructors anyway.
> Forgive me but it seems to me that mid-rad's ability to
> represent 1 + Fmin but not 1 + ULP(1)/2 IS one of the
> strange & complex properties of the type.
I don't understand what you mean. Interval types represent
intervals, not numbers.
--
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)