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

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-09-07 08:43:53

----- Original Message -----
From: "Guillaume Melquiond" <gmelquio_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, September 07, 2002 3:15 PM
Subject: Re: [boost] Formal Review for Interval Library (was: Interval
Library reminder)

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

One third of the new BLAS specification covers mixed operations.

> 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?

The type is determinable through a traits class which extends the usual type
promotion system to intervals.

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

You've lost me. Don't you can afford it, because it's too dangerous?

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

You're right (I had to check this ;-(. But is this a strenght of
std::complex and a weakness of the builtin data types?

[snip]

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

Ok.

[snip]

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

Does this mean, that we need boost::complex<>?

Regards

Joerg