RE: [boost] Formal Review for Interval Library (was: IntervalLibraryreminder)

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-09 22:09:52

Herve,

I got the impression that you have fixed your library to one-dimensional
continuums (in C++ defined by float, double and long double).

This impression stemmed from the arguments in this verification process.
That is what I meant by you regarding the template instantiations as
something I denote by "implementation specialization". This is why the
requests for more generic use (traversal, partial ordered types etc.)
went unresponded, or responded by reminders of the scienific purpose of
this library, that it should allow for direct substiution of exact
arguments with these intervals in arithmetic and transcendental
operations.

There is nothing wrong with that, by the way. A purely "mathematical"
(read "operating on a linear continuum") interval is good in itself. I
just do not want us to cheat ourselves by thinking that the interval
abstraction could be used for other elements. And, I do not mean "being
able to instantiate without compiler objections". I mean real use.

No problem, by inserting it into "boost::numeric" the nature of the
abstraction will be further defined, as well.

To reiterate what I meant with my two categories of template
specializations (or instantiations): (1) conceptual specialization, is
where we get some new concept, inheriting properties from the template
and (2) implementation specialization, is where we get the same concept,
but with other implementation-defined characteristics. I argue that
"interval<float>" and "interval<double>" are category-2 variants.

A lot of Boosters complain and warn other developers to not be overly
abstract, so the pragmatic choice you made, with heavy focus on rounding
policies is probably the right one.

Regards,

David

 

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Herve Bronnimann
Sent: Monday, September 09, 2002 10:40 PM
To: boost_at_[hidden]
Subject: Re: [boost] Formal Review for Interval Library (was:
IntervalLibraryreminder)

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'
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost