On 07/03/11 19:40, Joachim Faulhaber wrote:

2011/3/7 John Reid:

...

On 07/03/11 14:49, John Reid wrote:

...

#include

template< typename IntervalT> void check_contains() { IntervalT interval; typedef typename IntervalT::domain_type domain_t; ::boost::icl::contains( interval, domain_t() ); }

void h() { namespace icl = ::boost::icl; check_contains< icl::continuous_interval< float> >(); check_contains< icl::discrete_interval< int> >(); check_contains< icl::right_open_interval< float> >(); check_contains< icl::left_open_interval< float> >(); check_contains< icl::closed_interval< float> >(); check_contains< icl::open_interval< float> >(); }

The last 2 lines in h() do not compile whilst the preceeding 4 do. Is this by design or a bug? Testing elements for membership of a closed or open interval seems natural enough. I'm using gcc 4.4.3.

Thanks, John.

Also operator== does not seem to work on closed and open intervals, e.g.

icl::closed_interval< float>() == icl::closed_interval< float>()

does not compile.

Hi John!

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.h... in: Table 1.6. Usability of interval class templates for discrete or continuous domain types. OK I could have found this in the documentation. 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. 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. 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, John.

On 08/03/11 14:41, Joachim Faulhaber wrote:

2011/3/8 John Reid:

...

On 07/03/11 19:40, Joachim Faulhaber wrote:

...

2011/3/7 John Reid:

...

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.h... 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.