5

I started to use Boost ICL and I stumbled upon very basic stuff. For example the function contains should return true or false depending if a given element is in the interval or not. However that works for [right,left]_open_intervals but not for [open,closed]_inteval (see example below).

This seems to be too obvious to be an oversight. I am using the library in the intended way?

For example (using gcc 4.8 or clang 3.3 and Boost 1.54):

#include <boost/concept_check.hpp> //needed to make this MWE work, boost icl should include it internally

#include<boost/icl/right_open_interval.hpp>
#include<boost/icl/closed_interval.hpp>
#include<boost/icl/open_interval.hpp>
int main(){
    boost::icl::right_open_interval<double> roi(6.,7.);
    assert(boost::icl::contains(roi, 6.) == true);  //ok
    assert(boost::icl::contains(roi, 6.) == false); //ok

    boost::icl::closed_interval<double> oi(4.,5.); // or open_interval
    assert(boost::icl::contains( oi, 4.) == false); //error: "candidate template ignored"
    assert(boost::icl::contains( oi, 5.) == false); //error: "candidate template ignored"
}

Note: The above are called "static" intervals (because their bound properties are part of the type). Dynamic intervals work as expected.

alfC
  • 14,261
  • 4
  • 67
  • 118
  • After rereading the documentation of Boost ICL, I found this obscure comment in an example: "...You will probably use one kind of static intervals `right_open_intervals` are recommended. ... static closed, left_open and open intervals are implemented for sake of completeness but are of minor practical importance." So for the moment I understand that anything other than `right_open_interval` is not guaranteed to work. I guess I can implement an overload of `contains` but I probably will find another limitation in the future if I insist in using intervals other than `right_open_interval`. – alfC Mar 20 '14 at 17:21

1 Answers1

4

I would guess it comes down to the relative uselessness of floating point equality testing.

Have you ever tried to do assert(0.1 + 0.2 == 0.3)?

Try it. I'll wait.

In case you already know the answer, it'll be clear why a closed interval is not easy to implement correctly. Backgrounders:

Also, if you have two consecutive closed intervals [a,b][b,c]. in which interval does b belong?

Community
  • 1
  • 1
sehe
  • 374,641
  • 47
  • 450
  • 633
  • Makes sense, I guess I was thinking in terms of `open_interval`s for my problem for conceptual reasons. But in reality I shouldn't count on the difference between the different kind of intervals for floating point values and fallback to a single interval type. Still, I would say that the limitation is surprising (although by itself raises your good point). I think at this point we are guessing what was the intention of the library author. (there should be a comma in `[b.c]`) – alfC Mar 20 '14 at 18:49
  • 1
    Also, the dynamic version of the intervals (the ones described above are called static) works as expected (within the limits of floating point) for example `contains(boost::icl::interval::open(1.,5.),5.) == false`. – alfC Mar 20 '14 at 20:04
  • I agree that the feature set for static intervals seems asymmetric w.r.t. the feature set for dynamic intervals. Mmm. – sehe Mar 20 '14 at 21:47
  • Using the library a little more I realize that (at least for continuous variables) no effort is made to integrate static(-bounds) intervals with the inteval-containers and dynamic(-bounds) intervals (not even conversion). So at the end the static intervals is like a leftover obscure corner of the library. – alfC Mar 20 '14 at 22:34