Re: [boost] [ICL] some improvement proposals

Subject: Re: [boost] [ICL] some improvement proposals
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-05-23 07:22:25

Hi Denis,

thanks for your input again. You're a good analyzer of code. Maybe you
want to consider writing a code review for libraries that are
submitted for formal review on the boost developer's list from time to
time :)

2011/5/19 Denis <denis_at_[hidden]>:
> Hi
>
> 1. (questionable because it changes the visible interface): rename
> `left_open` and `right_open` to `right_closed` and `left_closed`.
>
> Reason: interval_bounds is used in bitwise operations with bit=1 means
> `closed`.

(1) I tried to consider common usage of naming of intervals that is
known from math. There seems to tendency to assume closedness as
default, while openness is indicated by naming:
[x, y] an interval  (also closed interval)
[x, y) a right open interval
(x, y] a left open interval
(x, y) an open interval.

(2) The bits are chosen so closedness is indicated by 1 and openness
is indicated by 0

11 [x, y] an interval  (also closed interval)
10 [x, y) a right open interval
01 (x, y] a left open interval
00 (x, y) an open interval.

> `left_closed() | open()` resulting in `left_closed()` is more readable than
> `right_open() | open()` resulting in `left_closed()`.
>
> Also, there are checkers `is_left_closed()` and `is_right_closed()` but not
> for *_open

... again following common usage [see (1)].

> I had to use `class bounded_value` in my program (as in Icl details:
> calculating lower and upper bound of interval separately, then constructing
> the interval, bitwise or'ing bounds)
> and I commented every usage of `right_open()` as `left closed` in order to
> explain why I use `interval_bounds::right_open()` in constructing the left
> `bounded_value` of the interval.
> This resulted in the idea of renaming.
>
> Maybe making bit=1 mean `open` would be less painful for other users ?

You see me inconsolable to hear that you are suffering pain from my library =(

There is an concept "interval_bound"

http://svn.boost.org/svn/boost/trunk/boost/icl/concept/interval_bounds.hpp

that allows you to combine and-ing or-ing etc. of interval_bounds
directly. I think that'll reduce your suffering, at least I hope so.
Yes, it's missing from the docs. Would you create a ticket?

BTW, you may locally extend the concepts in the way you desire and add
functions according to you naming rational.

> 2. define `contains(interval, elt)` as `!below(interval, elt) &&
> !above(interval, elt)` allowing the user to use `below()` and `above()`.
> Sometimes it is useful.

(3) Thanks for this suggestion. The design of the icl::interval's
interface is done under the general requirement of minimality. The
concept approach allows you always to add own function templates
locally to the concept if you need them.

> Anyway, all the versions of `contains()` are made of checking for both
> bounds.

If you found a suboptimal function implementation, please refer them
specifically. I'd appreciate a suggestion for an optimization. You can
also create a ticket.

> 3. It would nice if the functions taking two intervals will have versions
> taking an element as second argument.
> I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all
> the list at the moment)
> Constructing temporary `close_interval` object in order only to pass it into
> those functions is cheap with ints but would be expensive with
> heap-allocated domains (blobs, strings, etc).

This is worth considering. In my own use of intervals within the
implementation of interval containers I never encountered the need for
such functions ... yet they may be useful in other situations. What do
others think?

Best regards,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de