Re: [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
From: jesseperla_at_[hidden]
Date: 2008-12-04 23:17:18

Robert:
>Sorry, but this makes no sense to me in the context of constrained values.  
If
>the current bounds are [0, 1] and you have r1 == .5 and r2 == .9, then what
>changing the bounds for the whole type to [.8, .99] would mean for r1? How  
the
>type is supposed to know that there is an instance that is not valid  
according
>to the new bounds? The type should keep handles to all its instances? Or  
the
>bounds should change anyway, leaving the instance in invalid state? So what
>would be the point of bounds checking, if you can't guarantee that once you
>assign a valid value then the object will remain valid?

The problem for me is that the change_bounds function at runtime operators  
on an instance rather than for the type itself (which is what the compile  
time bounds mean, and what I really want). I was using this as an example  
of why I believe the semantics are different and what I really want is  
something like what I listed next:

>typedef bounded<double, "INTEREST RATE"> interest_rate;
>typedef bounded<double, "RISK_AVERSION"> risk_aversion;
>interest_rate r;
>risk_aversion crra ;
>change_bounds(r, .8. .99); //Statically change it
>change_bounds(crra, .5, 10); //Statically.
>interest_rate r_guess; //want the right bounds

But even this is a little shady since I kept the change_bounds called on an  
instance to show the similarity to what is listed. What I would really be  
looking for is a way to change the bounds for the type itself, which would  
change static bounds. Maybe something like the following:
>typedef bounded<double, "INTEREST RATE"> interest_rate;
interest_rate::change_bounds(.8, .99); //Changes static data for the type?

Does that help you make sense of my previous questions and comments?

Now, you may say that this doesn't work because how could it throw errors  
on existing variables of type interest_rate that may not fulfill the  
bounds? The short answer is that it couldn't and it doesn't matter. In  
practice, you are changing the bounds here prior to creating instances of  
an item. It is purely a question of being able to dynamically create bounds  
for a type and then query them later... this makes the library far, far  
more than just a debugging and bounds checking utility and gives real  
semantics that can better match mathematics.

>What you ask for is not possible in C++. You cannot have one type and use  
it
>exactly the same way as other type. I'll give you some examples (having
>constrained<string> cs):
> const char * s = cs.c_str(); // not possible
>Type constrained<string> can't have members that string has.
> char c = cs[0]; // not possible

Yes, I see now why it can't work for wrapping classes. But in my mind I am  
only thinking of the wrapping of intrinsic, built in types like doubles and  
ints. Here I would never want to call member functions on them... But it  
sounds like with no implicit conversions for template instantiation, we  
could run into problems... But how often would this be in practice? My  
knowledge of generic programming is not sufficient to understand the story  
here, but it sounds like the problem with std::max is that it is forcing  
the two parameters to be of the same type and that is the failure.  
Otherwise if std::max was written to take two different types with  
compatible comparison operators, that this could work fine? And if the  
constrained_value<double> had an implicit conversion to double, then we  
would have no problem? So is std::max anomalous here, and this wouldn't  
come up in practice for most usage for most numeric work?

Thanks Robert. I really like this library and think it has great promise  
for those of us programming mathematics written on a blackboard.