Re: Midpoint paper (2012-02-08 version)
> 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:
> > > Date: Wed, 15 Feb 2012 15:40:20 +0100
> > > From: Vincent Lefevre <vincent@xxxxxxxxxx>
> > > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> > > Subject: Re: Midpoint paper (2012-02-08 version)
> > >
> > > On 2012-02-15 15:36:36 +0100, Vincent Lefevre wrote:
> > > > On 2012-02-14 13:27:18 +0000, John Pryce wrote:
> > > > > When I suggested a while back that a floating point format F should
> > > > > be associated to T as part of its definition, I seem to recall this
> > > > > was pooh-poohed as unnecessary. But the current discussion shows,
> > > > > IMO, that it IS necessary, and might indicate some requirements for
> > > > > such an F.
> > > >
> > > > I think that what can be necessary are the requirements, not the
> > > > fact that some FP format is associated with T, i.e. such a FP
> > > > format need not be unique.
> > >
> > > And hence, the notion of "compatible" format, with a list of
> > > requirements.
> >
> > 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.
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?
For all the (simple) types we have in mind, that is trivial.
> (error) is an integer number of ulp's, one of the endpoints may not
> be representable if the midpoint is close to a binade boundary (and
> a fix would make the implementation more complex and possibly with
> strange properties).
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
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.
As always, I come at this from a floating-point perspective
in which similar floating-point types in the past have had
no end of strange behaviors because of their exceedingly
variable distribution of numbers.
Perhaps it is not so much of a problem among the intervals.
Still, as soon as any narrowing procedure has produced some
<m,r> in which r < ULP(m)/2, we are in the relm of disjoint
sets on the Real number line. Which means that the accuracy
with which you can report a result depends on how near it is
to a representable number. Often, by a lot.
This makes results no longer scale free in strange & complex
ways. That cannot make it easy for correctness proofs.
Dan