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

From: Guillaume Melquiond (gmelquio_at_[hidden])
Date: 2002-09-07 08:15:48

On Sat, 7 Sep 2002, Joerg Walter wrote:

> ----- Original Message -----
> From: "Beman Dawes" <bdawes_at_[hidden]>
> To: "Boost main mailing list" <boost_at_[hidden]>
> Sent: Friday, September 06, 2002 10:37 PM
> Subject: [boost] Interval Library reminder
> 
> 
> > The Formal Review period of the Interval Library ends on Monday, September
> > 9.
> >
> > While there has been a lot of discussion of comparison operator issues, we
> > need more reviews of the library in its entirety.
> 
> [snip]
> 
> Here is my trial to review the interval library. I'll answer the questions
> as listed at the boost website.
> 
> - What is your evaluation of the design?
> 
> I'm not a domain expert, so I didn't try to evaluate the design as a whole.
> I tried to evaluate the usefulness of the library as a generic component,
> porting an uBLAS test and an uBLAS benchmark to use intervals of floating
> point numbers instead of floating point numbers. This worked seamlessly. So
> the design is intuitive and seems appropriate.
> 
> Remark: the documentation states
> ---
> Conversion from interval<T1> to interval<T>. There is no such conversion in
> the library. Specifically, there is no way to change the base number type
> without explicitly casting both the lower and upper bounds from T1 to T2 and
> using a constructor.
> ---
> 
> I understand the reasoning behind this decision for truncating conversions
> (i.e. conversion of interval<double> to interval<float>), but it should be
> possible to support some kind of mixed operations (i.e. interval<double> =
> interval<double> + interval<float>). If I'm not mistaken, the library is not
> designed to support mixed operations. This is a severe limitation IMHO.

You are not mistaken, the library is not designed to support mixed
operations and it's a limitation (I'm not sure about "severe"). And since
you have understood why there is no conversion between intervals with
different base types, you should easily understand why there is no mixed
operation: the situation is even worse.

Indeed, let's consider this operation: 'interval<T1> + interval<T2>'.
First, what should be the type of the result? Next, how do we do the
computation? One (or maybe the two intervals) need to be converted to a
common type, but we don't have such a conversion. It's always the same
problem: we can't afford to convert between interval types with different
base types.

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>').

> - What is your evaluation of the implementation?
> 
> I skimmed the implementation and it looked fine to me.
> 
> - What is your evaluation of the documentation?
> 
> The documentation seems to be comprehensive and comprehensible.
> 
> - What is your evaluation of the potential usefulness of the library?
> 
> The library is surely useful for verified numerical computing.
> 
> - Did you try to use the library?  With what compiler?  Did you have any
> problems?
> 
> I checked the implementation with GCC 3.1 under Linux on a Intel CPU. I had
> some problems building parts of the supplied examples and tests, but didn't
> investigate further.
> Everything else worked fine, the results looked reasonable, the performance
> was acceptable even without the unprotected rounding optimization.
> 
> Remark: the documentation states
> ---
> There are some issues with Borland on x86 (Windows), and Visual C++ which
> we're working on. We know some workarounds but they wouldn't be portable
> enough to put into the library.
> ---
> 
> I don't understand the second sentence and therefore have to assume, that
> the problems with BCC and MSVC aren't solvable through conditional
> compilation. That's sad.

Let's say it another way. We know the current code doesn't compile with
BCC and MSVC because they are not conforming enough on some points. By
changing some parts of the library, the situation could become better. But
they are not our favourite compilers, so we don't know the tricks to avoid
the problems we encountered without having to greatly change the library.
I hope the situation will improve later.

> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
> 
> I didn't spent enough time to evaluate it ;-(.
> 
> - Are you knowledgeable about the problem domain?
> 
> I've some mathematical background.
> 
> - Do you think the library should be accepted as a Boost library?
> 
> Yes, provided the mixed operation problem will be considered.

Thanks.

> Regards
> 
> Joerg
> 
> P.S.: I've seen another severe restriction, but I don't believe that this is
> a problem of the interval library. It isn't possible to instantiate
> std::complex<interval<float> >. How shall we cope with this?

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.

Regards,

Guillaume