Re: [boost] proposal: interval containers

From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2008-05-17 08:48:19

2008/5/17, vicente.botet <vicente.botet_at_[hidden]>:

> >> * Why do you use virtual functions? Are the classes sets, and
> >> interval_base_set public?  I think this can and should be avoided.
> >
> > The original design was classical OO-design, defining an interface
> > class that allows different implementations being used uniformly by a
> > weak polymophic interfacepointer.
>
> Do you need this polymorphism now?
>
No I don't. While it was a good thing to design those basic interfaces
as a way of getting aware what the minimal abstract essence of sets
and maps are (now done via c++0x-concepts), we did never really use
them in the various applications built with interval_containers at
Cortex Software. Also within the library such base pointer
polymorphism is not used. So it is no problem to remove the interface
class templates 'sets' and 'maps' from the design.

> >> * Does it works with boost::interval?
> >>
> > Unfortunately not. Interval containers rely on the notion of open
> > interval bounds. This was necessary to express operations for
> > flotingpoint numbers:
> > interval_set<double> is;
> > is.insert([1,pi)); is.insert([pi,4]); // is=={[1,4]} merging INTENDED
> > is.insert([1,pi)); is.insert((pi,4]); // is=={[1,pi), (pi,4]} must not
> > merge
>
> This is not a reason your library should not work for boost::intervals. If
> interval_set works for any kind of intervals, why should not work for closed
> intervals?
>
The reason is this:

interval_set<double> is;
is.insert(closed_interval(0.0, 4.0));     // {[0.0, 4.0]}
is.subtract(closed_interval(1.0, 3.0)); // {[0.0, 1.0), (3.0, 4.0]}

Elements 1.0 thru 3.0 are being subtracted from is. How can this be
expressed otherwise?

The current implementation uses a borderflipping semantics for
interval subtraction or intersection. This works fine for all interval
instance types. A special semantics for discrete interval types that
are used with closed intervals only can be implemented. Yet the code
would suffer from conciseness.

> > As I've read in the archives an extension for open interval bounds
> > have been suggested for boost::interval in the past.
>
> It will be a good thing to see how to extend the interval library to manage
> with open boundaries and continuous semanstics. Why not make a separated
> proposal for intervals?
>
well ... as a boost newbee I'm not keen on stomping into other peoples
gardens. I'd rather offer them a few flowers from mine ;-)

cheers
Joachim

interval container code and documentation see:
http://sourceforge.net/projects/itl