Subject: Re: [boost] [ICL] some improvement proposals
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-05-23 07:22:25
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
2011/5/19 Denis <denis_at_[hidden]>:
> 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
(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"
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
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
-- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk