Re: [Boost-users] [ICL] More compilation questions/problems

Subject: Re: [Boost-users] [ICL] More compilation questions/problems
From: John Reid (j.reid_at_[hidden])
Date: 2011-03-08 09:52:31

On 08/03/11 14:41, Joachim Faulhaber wrote:
> 2011/3/8 John Reid<j.reid_at_[hidden]>:
>> On 07/03/11 19:40, Joachim Faulhaber wrote:
>>>
>>> 2011/3/7 John Reid<j.reid_at_[hidden]>:
>>>>
>>>> On 07/03/11 14:49, John Reid wrote:
>>>>>
> [..]
>>> thanks for your thorough work on the many instances of ICL class
>>> templates. The compilation failures of the current examples
>>>
>>> icl::closed_interval<    float>()
>>> icl::open_interval<    float>()
>>>
>>> are by design again. The related information can be found in the docs
>>>
>>> http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface.html#boost_icl.interface.class_templates
>>> in: Table 1.6. Usability of interval class templates for discrete or
>>> continuous domain types.
>>
>> OK I could have found this in the documentation.
>
> if you don't find it (you are probably my most experienced and most
> thorough user :) other people won't find it all the more.
>
> What troubles me a bit is, that the improvements proposed during the
> review are making the ICL obviously more difficult to use. The old
> interval template although inferior in design and a little fatter than
> statically bounded intervals just worked in all instances, some of
> which may now lead to astonishment and make consultation of
> documentation or even the author necessary.

Don't worry, this is probably my ineptitude as much as anything.

>
>> It is not always obvious
>> from the documentation why some code does not compile. It could have been a
>> constraint on the which types are OK to instantiate intervals with or how
>> the contains function works.
>>
>>>
>>> The reason for this: All icl interval objects, that can be constructed
>>> are supposed to work with interval containers. If I have an interval
>>> set
>>> {[0.0, 2.0]}
>>> of a continuous domain type using statically bounded closed intervals
>>> and I want to subtract another closed interval
>>> {[0.0, 2.0]} - [1.0, 1.0]
>>> I am unable to represent the result
>>> {[0.0, 1.0),(1.0, 2.0]}
>>> with the same kind of statically bounded interval.
>>>
>>> Therefore I don't allow statically bounded closed and open intervals
>>> (the symmetric interval types) to be instantiated with continuous
>>> types.
>>
>> I'd rather see the intervals be as general as possible but I can see why
>> you've done it this way. In fact having statically bounded open and closed
>> intervals in ICL seems quite unnecessary and almost pointless if you can
>> only use them with discrete types.
>
> That's true. I've just implemented all of the possible variants the
> check my concepts for completeness. Yet for practical purposes right
> open intervals are suitable for all situations.

Right-open intervals are the ones I am most interested in. I would be 
happy without the others, I've just been using them for completeness's 
sake. I thought it would be nice to give the library a good work-out.

>
>> One thing that might help you support the library is to use compile-time
>> checks to prevent users instantiating types that the library does not
>> support.
>
> I use BOOST_STATIC_ASSERT and BOOST_CONCEPT_ASSERT but I have not
> checked out the all the possibilities to make those compile time
> checks maximally informative
>
>> It would have been easier for me (and presumably others in the
>> future) if no code involving closed_interval<float>  had compiled rather than
>> just a subset of the functions.
>>
>> Thanks again for ICL and the prompt reply,
>
> My pleasure :)
> Joachim
>
Cheers,
John.