Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [Review] ITL review starts today, February 18th
From: John Reid (j.reid_at_[hidden])
Date: 2010-03-04 04:55:29


Joachim Faulhaber wrote:
> There has been a discussion on this point already.
> http://permalink.gmane.org/gmane.comp.lib.boost.devel/199905
>
> For continuous data types it seems like interval bounds are needed as
> data member. For intervals of integral types the bound_type can be a
> static property. I will adapt the design in this point.
>

I assume most uses of the library will either be over discrete domains
or continuous domains where the presence/absence of individual elements
is irrelevant. In both cases right-open intervals are a natural way of
implementing a solution. I haven't thought of an application over a
continuous domain where it is necessary to cater for the
inclusion/exclusion of individual elements. Do you know of one? So it
might be better to have both continuous and discrete intervals as
right-open by default and to allow some mechanism whereby the user can
choose to allow different runtime bound types if they need them.

I have some further unrelated design questions/points:

Is there a function to return the distance between two intervals?

The default interval type is closed. Isn't right-open a more natural
choice for most applications? It makes interval subtraction slightly
simpler for example. I've always found right-open intervals an easier
concept to think about and they make coding easier although this library
removes any concerns about the latter.

What is the meaning of the cardinality of a continuous interval? It
seems to be defined to be 0? Why not make it only available for discrete
domains?

I would like to see interoperability with other boost libraries such as
boost.hash and boost.serialization. Both would be very useful for my
current application.

Why were the interval combining styles implemented as subclasses?
Wouldn't the design have been more flexible if they were implemented as
a policy template parameter? That's just my feeling about it, I don't
feel qualified to offer a strong opinion.

>
>>> - What is your evaluation of the documentation?
>> Good. A tutorial would be a welcome addition. Some functions were
>> undocumented, I'm assuming they're documented in the review version.
>
> The "handcrafted" documentation relates to the major interface of
> overloaded functions and function templates. In order to keep that
> short, more specific functions are only documented in the part of the
> documentation that is generated from doxygen comments:
> http://www.joachim-faulhaber.de/boost_itl/doc/libs/itl/doc/html/interval_template_library_reference.html
>
> And yes, there may be few that have been forgotten. Please tell me,
> which ones you missed specifically.

I'll try to find them again.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk