Re: [Boost-users] [boost][boost-users][ICL] ICL Compilation errors. Ticket #5207

Subject: Re: [Boost-users] [boost][boost-users][ICL] ICL Compilation errors. Ticket #5207
From: John Reid (j.reid_at_[hidden])
Date: 2011-02-23 06:52:28

On 22/02/11 20:03, Joachim Faulhaber wrote:
> 2011/2/22 John Reid<j.reid_at_[hidden]>
>>
>> I have started to use statically bounded intervals
>> and am finding more compilation issues. For example
>> with finding elements in a map:
>>
>> #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS
>> #include<boost/icl/interval_map.hpp>
>>
>> void f() {
>>         namespace icl = ::boost::icl;
>>         icl::interval_map<  float, int>().find( 0 );
>> }
>>
>> This compiles without the #define but fails on static intervals.
>
> This is on purpose. The reason is that we can not represent a single
> element x using a right-open interval [x,?) of continuous values.
> right_open_interval is the default for statically bounded intervals,
> if BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS is defined. In order to use
> find on an interval_map we have to construct an interval that
> represents a single element (internally). This is not possible in the
> logic of the ICL so this code won't compile.

Nevertheless, users will expect to be able to locate elements in sets. 
How should they do this?

Does
        icl::contains( icl::interval_set< int >(), 0 );
compile, but
        icl::contains( icl::interval_set< float >(), 0. );
does not for the same reason?

>
> interval_map::find is a pretty late addition to ITL/ICL, because using
> find in the STL way makes little sense on interval containers most of
> the time. We can not "find" an large interval in an icl::interval_set
> of small intervals.
>
> {[0,2),[5,7)}.find([0,9))
If we cannot find the large interval, isn't the end() iterator a 
suitable return value to suggest it was not in the set/map?

>
> The generalization of find is intersection. And the following function
> calls compile for statically bounded right-open intervals of
> continuous types:
>
> #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS
> #include<boost/icl/interval_map.hpp>
> {
>    icl::interval_map<  float, int>  iclmap;
>    icl::interval_map<  float, int>  found;
>    add_intersection(found, iclmap,
>                    right_open_interval<float>(0,1));
>    add_intersection(found, icl::interval_map<  float, int>(),
>                    right_open_interval<float>(0,1));
>    found = iclmap&  right_open_interval<float>(0,1);
>    found = icl::interval_map<  float, int>()
>               &  right_open_interval<float>(0,1);
> }
>
I'm interested to hear reasons why the following don't compile when 
using static bounds:

icl::add( icl::interval_set< int >(), 0 );
icl::add( icl::interval_set< int >(), icl::interval< int >::type( 0, 1 ) );
icl::interval_set< int >() += 0;
icl::interval_set< int >() += icl::interval< int >::type( 0, 1 );

icl::subtract( icl::interval_set< int >(), 0 );
icl::subtract( icl::interval_set< int >(), icl::interval< int >::type( 
0, 1 ) );
icl::interval_set< int >() -= 0;
icl::interval_set< int >() -= icl::interval< int >::type( 0, 1 );

icl::interval_set< int >() &= 0;
icl::interval_set< int >() &= icl::interval< int >::type( 0, 1 );

icl::interval_set< int >() ^= ( icl::interval< int >::type( 0, 1 ) );

They all seem reasonable operations to me. In particular, for a discrete 
domain, operations like icl::interval_set< int >() += 0 make sense to 
me. That is the following are equivalent:
icl::interval_set< int >() += 0
icl::interval_set< int >() += icl::interval< int >::type( 0, 1 );

I agree the documentation needs to be more explicit about what is 
permissible.

On a side note, I don't understand the rationale for having static 
bounds configured by #define whilst other aspects of intervals are 
parameterised using templates. I would have liked to have both types of 
interval in the same compilation unit. However I guess it must be too 
late to change this fundamental design choice.

Regards,
John.