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.