Re: [boost] Re: Formal Review for Interval Library beginning

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-09-04 08:49:16

On Wednesday 04 September 2002 06:07 am, Guillaume Melquiond wrote:
> I didn't say I had to reinvent the wheel. I just wanted to say that the
> complexity of such an implementation should be the object of a library
> built on the top of this one rather than added to the library (which is
> already quite complex).

That's fine. However, the ability for an interface to work well with multiple 
data types is the essence of generic programming. We don't need to have a 
data type that implements a list of intervals, but by considering the effect 
of such a data type on the interface we can ensure that the interface would 
be ready if someone were to write that data type. 

The Graph library really shines in this area. The graph interface applies to 
all of the Graph library classes, of course, but it can also be used with 
graphs from other graph libraries and many other data structures that have 
some graph-like view. 

> > 4. It's obvious that if we use list of pairs instead of one pair all the
> > operation with intervals will take more time. But what if problem require
> > namely multi-interval values.
>
> Just use a specialized library. :-)
> You don't expect this library to directly be able to do the static
> analysis of a program, or have functions able to solve a 100x100
> inequations system, do you?

I'd expect the library to give me an interface I can use to solve tasks using 
intervals and to give me some concrete model of that interface. With such an 
interface, I can write a static analysis that is parameterized by the 
interval type:

template<typename Interval>
class interval_based_analysis
{
  // ...
};

Actually, with a resolution of the comparison policies issue (such that we can 
use tribool with the , I can implement most of generalized constant 
propagation (a simple static analysis) in just a few lines of code. Maybe if 
I get a chance to do this before the end of the review it will prove how 
close the interval library is to supporting these other domains.

> Sorry, I don't understand your question. But I suppose you have understood
> that I think it is really not the job of this library to support such a
> monster (on the implementation point of view, and on the interface point
> of view!).

To summarize my view: it isn't the job of this library to provide an 
implementation of the interval list that Gennadiy proposed, but we should 
consider this type and its impact on the interface of this library. 

        Doug