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-28 03:51:27

I think this is the only part of our discussion that is still open...

John.

On 24/02/11 12:52, John Reid wrote:
>
>
> 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.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>