Re: [Boost-users] [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today

Subject: Re: [Boost-users] [boost] [review][constrained_value] Review ofConstrainedValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-08 19:39:48

	> From: Jesse Perla

	> 2) Dynamic Bounded Types: Right now the static bounds are associated
globally with a type, and the dynamic bounds are associated with an instance of
a type.  Since many use cases involve setting dynamic sets and then creating
instances, it is crucial that this type of set is implemented.  See Robert's
rough notes in: http://lists.boost.org/boost-users/2008/12/42959.php
        
Yes, this might be added in the future to the library itself. But first I want
to become confident this is what actually users need and that this solution is
general enough. Therefore, I'd be grateful if you (and other possible users)
could test the provided code and say how well is it fulfilling the requirements.
;-)

	> 3) Representing Disjoint Sets: Because most of the use cases have been
thinking about predicates and bounds checking, the key use cases of unions of
bounds has not been addressed.  In most of the discussions, people talk about
layering constraints on top of each other, which is an intersection.  This
library needs to also have ways to easily create sets like: (-infinity, 0] union
[1,2] union [3,infinity)   This would be a union of constraints which could be
set or accessed on the type (at runtime or compiletime), hopefully with simple
iterators to access this type information.  I think that thinking through
closed/open/halfopen/etc. intervals as separate objects in themselves is
critical, especially to layer this type of bound on.  Perhaps it could be
integrated with the interval template library in the sandbox for example.
        
I think the best solution for dynamic constraints union (or intersection) is to
use boost::signal, and this is how I would implement this. Again, this is a
possible addition to the library in the future if it proves generally needed.

	> 4) Testing with Numerics:  This library needs to be tested with key
boost numeric packages such as ublas, boost math, accumulators, etc.  The key
here will also be to verify that it compiles with the static and dynamic bounded
types, the storage is identical to the underlying type, and the operations it
generates are not any slower.  Also that all of the elementary operators on
intrinsic types in C++ work as normal for by value/ref/pointer, numeric_limits
is thought through, etc.  All of the former is performance/storage testing would
be conditional on a good compiler of course (gnu and Intel seem to be the main
ones to worry about)
        
I have no experience with such computations and no code like you describe to
test. However, I'll be grateful for any reports from users after trying to use
the library in such applications.

Best regards,
Robert