Re: [boost] [Boost-users] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Boost-users] [Review] ITL review starts today, February 18th
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2010-03-03 17:56:13

Hi John,

thank you for reviewing the ITL library!

2010/3/3 John Reid <j.reid_at_[hidden]>:
> Hartmut Kaiser wrote:
>>
>> The ITL is available from the boost vault:
>>
>> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_2
>> _0.zip&directory=Containers
>
> I have to say first I have been evaluating the version of ITL called
> itl_plus_3_2_1 rather than the version in the boost vault. Perhaps someone
> can tell me whether that is a big mistake or not.

Using  itl_plus_3_2_1 is completely ok. It is a later release than the
review version itl_3_2_0. But the differences are marginal. Also
itl_plus_3_2_1 contains more than the core library that is submitted
for review. But you did not refer to these parts. So everything is
fine.

>> Please always state in your review, whether you think the library should
>> be
>> accepted as a Boost library.
>
> I think it should be accepted subject to the inclusion of an interval tree
> implementation.
>
>>
>> - What is your evaluation of the design?
>
> I suspect that making the open/closedness of an interval a template
> parameter would suit more users although I don't have a strong opinion on
> this one.

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.

>> - What is your evaluation of the implementation?
>
> I would have liked to see interval trees in the implementation. For what
> I've needed the library for so far this has not been a problem as most of
> the intervals don't overlap. In the future I can see use cases where the
> lack of interval trees would make the library impractical. I don't know how
> much impact adding an interval tree implementation would have on the
> existing interface.

I think the current implementation has its value and application. It
should not and can not completely be replaced by an implementation
based on an interval_tree. This would improve certain use cases but
lead to problems in others. I will report on this in more detail. An
interval_tree based split_interval_map will be a valuable optimization
that should be done as an additional class template. The current
implementation is fully functional, correct, useful and efficient in
most cases of application.

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

>> - What is your evaluation of the potential usefulness of the library?
>
> Very useful. It seems to have many applications in several different
> domains.
>
>> - Did you try to use the library?  With what compiler?  Did you have any
>> problems?
>
> I used gcc 4.4.1 and boost.python to make a python module for most of the
> main elements of the library. I used this module successfully in an
> application in genomics. However so far I have only had use for the
> SplitIntervalMap so I have not used most of the library.
>
>> - How much effort did you put into your evaluation? A glance? A quick
>> reading? In-depth study?
>
> A reasonable amount - enough to get up to speed and use the library.
>
>> - Are you knowledgeable about the problem domain?
>
> Not especially.
>

Thank you again.

Best regards,
Joachim