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@mail.cryst.bbk.ac.uk>:

...

On 22/02/11 20:03, Joachim Faulhaber wrote:

...

2011/2/22 John Reid<j.reid@mail.cryst.bbk.ac.uk>

...

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

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

On 28/02/11 19:23, Joachim Faulhaber wrote:

Ok, lookup of elements via 'find' or check for containedness via 'contains' can be implemented without too much difficulties. For statically bounded intervals of continuous domain types I am currently adding a function icl::unit_closure. Unit closure is the smallest interval for a value x that can be constructed from x using incrementation or decrementation. For numeric domain types unit_closure(x) always has a length of 1. For discrete domain_types unit_closure yields the same intervals that function icl::singleton currently computes.

Using function icl::unit_closure I am able to implement icl::find and icl::contains and icl::intersects on element types.

I will probably commit the code and related tests to the trunk today.

Fantastic. Thanks, John.