2008/5/17, vicente.botet <vicente.botet@wanadoo.fr>:
* 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