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

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-09 21:39:52

On Mon, Sep 09, 2002 at 09:45:35PM -0400, David Bergman wrote:
> About my suggestion for template instantiations to be categorized as
> either
> 	(1) conceptual specialization; or
> 	(2) implementation specialization.
> It seems to me that the interval library authors are considering their
> template use as (2), while there are ideas of using "std::complex" as a
> category (1) template with nested intervals(at least from Herve, I
> think).

I don't understand your sentence. Are you saying I have ideas of using
std::complex as a category (1) template? And where do nested intervals
come from? I'm really confused with the sentence above.

Personally I don't think I consider our template use (2) or (1). Or is
it exclusively one or the other? Then I don't understand the distinction
you are drawing.

We are not restricting interval<T> to just T=float, double, and long
double, so it is conceptual. The semantics of interval<T> depend on T
(and on the policies) but the intent is always the same: provide an
interval type suitable for replacing T in computations.

But by necessity, when T is a builtin floating type, it is to our
advantage to use template as implementation specialization.

As using std::complex, it is clear to me that you are looking for a
complex number primarily, and not an interval type over complexes.
So I'd much rather have an (implementation-defined) complex<interval<T> >.

This being said, it really stretches the use of the interval library
as we intended it, and I should think it more desirable to have a
companion library complex_interval<T> to resolve those issues. But this
is not a job for the interval library, IMHO, at least until the question
whether there should be boost::complex is resolved. If there was,
special effort could be made to coordinate. For now, it is pure science
fiction. We have neither the resources, the political will, the need,
nor the first clue on how this should be done.

I think complex and interval interact in very subtle ways for the basic
arithmetic operations, and that's not even starting to discuss the
transcendental operations or the comparisons... It would be fruitful to
discuss how to bias the design of the library so that interval and
complex would interoperate, IF complex had a well-defined semantic over
any type T (and the requirements on T explicitly stated). Given that it
is implementation-defined for any non-floating point type, I'm reluctant
to go any further on the issue.

> I suggest changing the library templates to category (1), which I think
> would be a good first step to deal with the critique regarding the
> library not being generic enough.

Since I don't understand the categories, I can't answer this. But
regarding the library being generic enough, once again, I think you're
mistaken if you want the library to address ranges, union of intervals,
iterators, and all the wonderful (wishful) things that have been dreamt
of on this mailing list. The library perhaps does one thing (manipulate
arithmetic expressions over intervals) but does it well.

Other libraries could leverage this to provide interval unions, etc. But
they would have to deal with entirely different problems (memory
management, etc.) which are of no concern to the basic user of interval
arithmetic we are trying to serve. It would be a disservice to our
intended user base (which has a real need for fast, precise and portable
arithmetic over intervals) imho to add issues which would inevitably and
unnecessarily complicate the design of the interval arithmetic library.

> It is obviously easier to define an interval over a linear type, such as
> double, than a non-linear one, such as "std::complex", so I understand
> the pragmatic reasons for wanting "complex<interval<double>>", but do
> not forget the goals for "std::complex", they define points in a complex
> number plane...

I'm not versed or proud enough to pretend I know the goals for
std::complex. I'm not sure that they are clear or identical for everyone.
In any case, I could think of many other goals for complex than
representing points in the plane.

Best,
-- 
Herve'