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

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

On 24/02/11 10:48, Joachim Faulhaber wrote:
> Hi John,
>
> thanks again for all the questions. I am breaking up the long posting
> into smaller portions.
>
> (1) Representation of single elements with statically bounded intervals:
>
> 2011/2/23 John Reid<j.reid_at_[hidden]>:
>> 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?
>
> they could use dynamically bounded intervals for continuous interval
> element types :P

Telling them not to use static intervals doesn't seem much of an answer!

>
> Moreover, if we work with floating point numbers, the code
>
> float pi = 3.14159 ... ;
> icl::interval_set<float>  icl_float_set = ... ;
> icl::contains( icl_float_set, pi );
>
> would be problematic anyway since pi can not be represented precisely.

Any code that uses float or double has to be concerned with what can be 
represented by the type. There is nothing special about the ICL in this 
respect. In your example, the user would know they are testing for 
containment not of the actual value of pi but rather the value in the 
variable "pi". For me this is certainly not an argument against 
implementing find for elements of continuous interval sets/maps.

>
> right_open_interval<float>  pi_itv = interval_around_pi();
>
> icl::contains( icl_float_set, interval_around_pi() ); // better
>
>> Does
>>         icl::contains( icl::interval_set<  int>(), 0 );
>> compile, but
>>         icl::contains( icl::interval_set<  float>(), 0. );
>> does not for the same reason?
>
> yes.
>
> I have mentioned in the docs, that 'continuous_interval' is the only
> class template that allows to represent a singleton interval that
> contains only one element, an have provided a small example here:
>
> http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface.html#boost_icl.interface.class_templates

I think the ICL needs functionality to look for elements in sets and 
maps that have continuous domains. It seems optimistic to think the 
users will be content without them.

Regards,
John.