Re: [boost] Formal Review for Interval Library beginning

From: Herve Bronnimann (hbr_at_[hidden])
Date: 2002-09-03 22:04:44

On Tue, Sep 03, 2002 at 05:35:35PM -0400, Rozental, Gennadiy wrote:
> > Thanks Gennadiy for confirming my suspicion. If you want half-open
> > intervals, though, a range library would be more suited than an
> > interval arithmetic library.  We cannot (and will not) represent all
> > kinds of intervals. This would unnecessarily burden the library, and
> > for most users it  would not represent a benefit.
> 
> IMO plain interval would not be enough in many domains, not only
> static analysis. Let say you want to represent the results of solving
> multiple inequations.  You immediately face the need for this kind of
> more generic abstraction. Or area of definition for variable.

While I agree it would be nice to have all those things, we did not
write a library for such a purpose (which IMHO is a totally different
and more time-consuming endeavor).

You have to judge the library by what it CAN do and not what it CANNOT
do. Otherwise, many of the great boost libraries might not have been
included in boost to start with.  Just because the Graph library does
not have a module for representing and manipulating finite automata and
neural networks doesn't make it useless. Far from it.

Please, by the way, I did not mean to start a thread on the usefulness
of the Graph library. It's a great thing, and I wouldn't want to drag it
into the debate beyond just using it for illustrative purpose.

> Even more simple example: How you going to
> represent result of operation 1/x where x = [-1, 1]?

Well, in the framework of intervals, it's [-inf, inf]. And quite rightly
so.

>    From what I view, without such generalization the library will have much
> more limited usability.

But still quite useful I assure you. First as a building block for all
those libraries for lists of intervals, then I have quite a few
applications where simple intervals are what you need. And if a simple
library weren't usable, why would we have Profil/BIAS, and so many other
packages?

> I think it just one small step ahead in terms of generalization. In most
> cases it does not require too much efforts. Instead of operation over pair
> you will operate over list of pair. There are some specific challenges of
> course. Like we will need intersection, union and difference. But it should
> be pretty strait forward also. You current interval will became just a
> particular case for more abstract implementation.

I don't think it's pretty straightforward. For one thing, I don't want
to wrestly with the memory management issues. For another, I still
maintain that you shouldn't try your hands at a library on lists of
intervals without having a solid and reliable library for simple
intervals. Small steps...

In short, while I agree with you and others that it would be nice to use the
proposed interval arithmetic library for representing multidimensional
data (such as systems of inequations, or equivalently Boolean functions
on the reals), or ranges (for dates, or for static analysis), the
implications of doing so are highly non-trivial and should be the object
of further work. If some step can be made towards this within the
proposed framework, or  the framework extended without a complete
redesign, we will gladly have your comments.
-- 
Herve'