Re: Proposal for a new structure of the standard
On 2010-07-18 20:42:53 -0700, Dan Zuras Intervals wrote:
> > Date: Sun, 18 Jul 2010 22:28:35 -2000
> > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> > From: Michel Hack <hack@xxxxxxxxxxxxxx>
> > Subject: Re: Proposal for a new structure of the standard
> >
> > Dan Zuras wrote:
> > > I think it makes more sense to have the set that lives
> > > at level 2 be a single instantiation of a GMP object as
> > > an interval type indexed by base, precision & range as
> > > well as style (explicit/implicit).
> >
> > But what if the format doesn't have the CONCEPT of bounding
> > the range? (I'll admit that not bounding precision does not
> > work for floating-point types, unlike some of the types I had
> > mentioned in earlier posts.)
With MPFR, you can change the precision of the variable (rounding
its value if the new precision is smaller). So, a lack of bound
can also make sense for the precision of floating-point types
(unless you assume that the datatype changes).
> > Are you simply ruling these out? Perhaps you are.
>
> I am.
>
> > Let me suggest an alternative: IF the underlying format does
> > not have fixed or at least specifiable bounds on range and
> > resolution, THEN functions like TightestHull() MUST have an
> > additional parameter that does specify such bounds for that
> > invocation.
> >
> > Michel.
> > ---Sent: 2010-07-19 02:28:39 UTC
>
> No bounds implies no limits on the amount of memory
> that an interval takes up. While this may be no
> problem for you, the compiler guys like to know how
> much space to allocate for things.
The number arithmetic and the interval arithmetic can be provided
by a library, in such a case the allocation doesn't matter (e.g.
GMP does everything what is needed).
> Yes, it is true that one can allocate pointers into
> a heap space. But it slows things down & makes for
> garbage collection problems.
>
> Making a datatype of fixed size avoids all these
> problems.
If what you want to solve needs arbitrary precision, you won't avoid
these problems. You can do all the computations with a fixed, large
precision, thus avoiding reallocations, but this may not be efficient
if some computations can be done at a lower precision (think of
Newton's method, for instance, where you can double the working
precision at each iteration).
The user could also seek to pre-allocate space for what will be
needed (thus avoiding any reallocation), but this may be difficult
and not necessarily more efficient in practice.
> You still have the freedom of unlimited precision &
> range so long as you consider the movement of a value
> from one size to another as a conversion operation.
But this also means that variables will not have a fixed datatype
(as said above in this post). This can be confusing.
> And fixing the range & precision also helps us come
> up with concrete ways of defining the behavior of
> intervals.
The goal of "valid" mode is to ignore the exact behavior. Only
the FTIA is important here.
--
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 / Arénaire project (LIP, ENS-Lyon)