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

Subject: Re: [Boost-users] [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2008-12-08 23:21:31

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