Re: [Boost-users] [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today
Robert:
>First, I hope that you are aware of the issues with using floating point
types
>with this library. If not, please read the rationale section of the
>documentation and the discussion in the related thread on the developers'
list.
Yup, been following. You did a good job of educating me on a previous
post... I think I understand the issue now, but don't really have much of
an option. As far as I can undestand from the discussions, this is a
general problem with equality operations with floating points and has
nothing to do with your library. If this is true, I would change
the "rationale" section to say that the mess is not your fault and it
isn'ta library problem and that you need to be just as careful as you would
normally.
>The constraint could look like this (written out of my head, not tested):
If this is possible, I am very happy. It looks like it is.
The only other things that I would say need to be thought through in the
design is unions of constraints instead of just intersections of them. For
example, I was checking this out a while back, and it manages the sets of
intervals/etc. well: http://www.herold-faulhaber.de/itl/
I would wonder if formalizing intervals in this library (or using another)
is a good way to deal with different bounds... but that is beyond my level
of competence.
> Why not just use numeric_limits<risk_aversion::value_type>?
1) Because I was too stupid to think of that, and
2) Because I want to be able to write generic functions such as:
template<typename T>
bool is_NaN(T& t)
{
return (t == std::numeric_limits< T >::quiet_NaN());
}
Again, my idea is that I want to be able to throw around elements of
constrained types to generic functions and all of the standard types of
things I would do with the superset type.
>Actually, only the mutating operators (++, --, =, += etc.) are overloaded.
For
>I don't think this is needed. If you write:
> constrained<int> x, y, z;
> z = x + y;
>Then simply the + operator for int is used.
Even better. As long as it works for all of the auto conversions between
intrinsic types we are also in business. eg
constrained<int> x, y, z;
double c;
z = c * x + y;
Thanks Robert. Great library, time for me to submit a glowing review.
Hi Jesse, > From: jesseperla > The only other things that I would say need to be thought through in the design is unions of constraints instead of just intersections of them. For example, I was checking this out a while back, and it manages the sets of intervals/etc. well: http://www.herold-faulhaber.de/itl/ Well, maybe in the future. This should be relatively easy to add as extension to the library, but may require some time to define the requirements and interface well. > Why not just use numeric_limits<risk_aversion::value_type>? 1) Because I was too stupid to think of that, and 2) Because I want to be able to write generic functions such as: template<typename T> bool is_NaN(T& t) { return (t == std::numeric_limits< T >::quiet_NaN()); } Then you may specialise those functions for constrained -- I think it's a better solution than providing numeric_limits for constrained in the library. >Actually, only the mutating operators (++, --, =, += etc.) are overloaded. For >I don't think this is needed. If you write: > constrained<int> x, y, z; > z = x + y; >Then simply the + operator for int is used. Even better. As long as it works for all of the auto conversions between intrinsic types we are also in business. e.g. constrained<int> x, y, z; double c; z = c * x + y; Yup, should work. Best regards, Robert
On Dec 8, 2008, at 7:24 PM, Robert Kawulak wrote:
From: jesseperla
The only other things that I would say need to be thought through in the design is unions of constraints instead of just intersections of them. For example, I was checking this out a while back, and it manages the sets of intervals/etc. well: http://www.herold-faulhaber.de/itl/
Well, maybe in the future. This should be relatively easy to add as extension to the library, but may require some time to define the requirements and interface well.
I think this is solved as long as any predicate functor is accepted, which will require testing which I will be glad to help with. Again, it's just plain old std::logical_* templates.
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.
Ditto. Nothing needs to be added to the library, but a bunch of stuff needs to get tested.
From: Gordon Woodhull
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.
Ditto. Nothing needs to be added to the library, but a bunch of stuff needs to get tested.
The point is that if such multi-constraint predicates prove needed in many use cases, it'd be nice to add them to the library so users don't have to define them on their own. Regards, Robert
I have not looked at the ConstrainedValue library enough to review it, but from the discussion here the "multi-constraint predicates" are a somewhat different thing. Specifically, the disabling of run-time checking, the ability to query and change constraints at run-time, and the performance issues for numerics. Rather than delay a library that appears useful and promising, and diffuse the testing effort, it might be better to add multi-constraint predicates later, after the appropriate requirements and design efforts. John -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Kawulak Sent: Tuesday, December 09, 2008 6:38 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] [review][constrained_value]ReviewofConstrainedValueLibrary begins today
From: Gordon Woodhull
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.
Ditto. Nothing needs to be added to the library, but a bunch of stuff needs to get tested.
The point is that if such multi-constraint predicates prove needed in many use cases, it'd be nice to add them to the library so users don't have to define them on their own. Regards, Robert _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (4)
-
Gordon Woodhull -
jesseperla＠gmail.com -
John Wilkinson -
Robert Kawulak