Re: [boost] Formal Review for Interval Library (was: Interval Library reminder)

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-07 10:56:38

dear Joerg:

First thanks for taking the time to compile ublas test and benchmark
with interval and checking that indeed the interval type behaved just as
expected in your setting.  It's exactly the kind of things we'd like to
know for a formal review.

On Sat, Sep 07, 2002 at 03:15:48PM +0200, Guillaume Melquiond wrote:
> You are not mistaken, the library is not designed to support mixed
> operations and it's a limitation (I'm not sure about "severe").
>  ...
> This problem isn't really new. A lot of libraries suffer from the same
> limitation, beginning with the standard library (just try to do
> 'complex<double> = complex<double> + complex<float>').

Note that for intervals, it was a question at some point whether we
should provide specializations for T==float, double and long double,
with additional implicit conversions for float->double->long double.
For those ones, we can guarantee at least that there is no loss of
precision.

We didn't provide it in the end because the problem remains for
converting the policies. You may have interval<float> with your own
rounding policy and it's not clear at all we can convert this rounding 
policy to operate on double, unless we know which policy you are using.
We could offer the functionality for just the default policies, but that
wouldn't be a generic solution.

If you feel that conversion should be offered between selected types,
perhaps we can start a thread to investigate how that should be done.

> You are right, it's not a problem of the interval library. The C++
> Standard says that "the effect of instantiating the template complex for
> any type other than float, double or long double is unspecified" (26.2.2).
> Not being able to instantiate complex<interval> because the Standard
> decided the only interesting types are float, double and long double is
> really a pity.

And I may add we wanted to offer a type interval<T> that is not
restricted to float, double, and long double, partly not to follow the
example of std::complex.

Thanks for your comments,
-- 
Herve'