Robert:

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

Absolutely.  I will test around the beginning of the year.

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

Yes, the signals approach would solve multiple constraint bounds-checking through a predicate.  But it doesn't solve my main use case:  Querying the sub-type information associated with a type for numeric algorithms, which may not be connected intervals.  For my code (and I would guess most people's) numeric applications, I will turn off bounds-checking when running in release, and manually trigger inclusion testing as I see necessary.  But the type information will be perfectly efficient at runtime for generating grids, checking convergence of optimizers, etc.  The reason that I think you need to think through the unions sooner rather than later is that there is a chance it could change your design to have the library return statically available type data as lists/iterators.  And it is worth thinking if you want to generalize the interval concept sooner rather than later.  If it is possible and there is no future-proofing necessary, then that is fine.

>On numerics:

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

Yup.  I write code some test cases when I get started.

>On numeric_limits:
>Then you may specialise those functions for constrained -- I think it's a better
>solution than providing numeric_limits for constrained in the library.

I hear what you are saying.  Yu can't write your own numeric_limits classes/functions... they are very platform specific and are part of the standard.  Though there may be ways to subclass from your super-type.

If it is possible to automatically subclass the numeric limits from the underlying type it would really make writing generic code for numerics much easier.  If not automatically, then perhaps we could just have a usage pattern where you declare the constrained type, then the numeric_limits through inheritance?  This is also related to the testing of this library with existing numerics libraries.  Some of these (mine for example) are relying on numeric_limits existing for whatever type is passed in to the function.  So there is a good chance that some numeric libraries would fail without this, and it would be a major disincentive for people to using this library.


Thanks Robert,
I will get back in contact early January to see how I can help after the review has died down.

-Jesse