Re: [boost] Formal Review for Interval Library beginning

From: Sylvain Pion (pion_at_[hidden])
Date: 2002-09-03 23:15:54

On Tue, Sep 03, 2002 at 05:41:23PM +0100, Paul A. Bristow wrote:
> And an example of use with a bigint type would provide proof of
> extensibility.

There's no bigint in Boost :(, so I attach an example program using
boost::rational<double>, which I have just committed as examples/rational.cpp.
(an exact rounding policy would need some work, but rational<double> is
probably non-sense anyway in practice, we'd need a bigint.)
E.g. using the MPFR as bigint, using the rounding modes from there, will
be a target.

The library is definitely meant to support that kind of things.

> On a detail, I note that PI is only defined to 21 decimal digits, which
> might be insufficient
> for some potential uses.  Why is it not just defined to 40 decimal digits,
> sufficient for any foreseable floating point hardware,
> even allowing for the known need for a few extra digits - see Kahan's paper.
> We should be able to assume that the compiler will convert this to
> the best representation that is possible for the floating point type,
> (if it doesn't then it is not compliant).
> Then shouldn't + and - numeric_limits epsilon, pred and succ,
> or nextafter(x, +inf) and (x,-inf) function provide the pi() interval
> values?

The C++ standard doesn't guarantee that a decimal notation is rounded to
the nearest (float/double) value.  This prevents from defining PI (the
lower/upper value of the smallest interval containing PI) the way you
suggest.
Guillaume first implemented a version which specified exactly the
bits of the lower/upper values, using casts with long long.
It was not very clean.

Then I found the current solution, which is guaranteed to do what we want,
provided that doubles and floats have the minimum precision mandated by IEEE
(i.e. 24 and 53 bits of mantissa).  For long double, I'd love to provide a more
precise interval for PI, but all we can assume portably is that the precision
is >= the precision of doubles, hence I kept the same value, because providing
more precision would not guarantee the correct rounding, hence might give an
interval not containing PI.

Thanks for the review !

-- 
Sylvain