> 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