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
(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/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)