Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: John Phillips (phillips_at_[hidden])
Date: 2008-12-04 10:59:15

Deane Yang wrote:
> Joe Gottman wrote:
>> Deane Yang wrote:
[snip]
>>> Could you give an example?
>>
>>
>>    One example: adding 2 to Monday to get Wednesday, or adding 2 to 
>> Saturday to get Monday.
>>
>>
> 
> But that does not correspond to the built-in arithmetic operation. This 
> is modular arithmetic in disguise, so wouldn't make more sense to use a 
> modular integer class (integers mod 7) and represent the days of the 
> week using the numbers 0 to 6?
> 

   I agree that the examples given so far (this one, and one elsewhere) 
are really modular arithmetic, and not constrained values in many 
meaningful ways. In these cases, the processing to shift them into a 
meaningful range is simple and provided by C++, so you may feel checking 
the answer for whether it fits within the constraints is not valuable.

   Lets try a different route. You are doing a time constrained, complex 
calculation, that has to be finished before a certain time interval has 
elapsed.(This may be in a real time system, as part of some financial 
calculation or something else where there is no choice but to stay 
within a time frame.) The data you are operating on are not well 
constrained at compile time, so how long each step in the calculation 
will take is only found during the calculation. To adjust for this, you 
include two different implementations of a costly step in the 
calculation. One is quick and dirty. The other takes substantially 
longer, but provides a better answer. You would prefer to do the more 
accurate calculation when time permits, but you have to get done on time.

   A constrained type can keep a time counter, that adds up the times 
taken by each of the steps in the calculation. Then, a fast estimate can 
provide the time needed for the step where you have options of which 
strategy to use. If the sum of the current time plus the estimate for 
the accurate implementation falls outside the constrained range, you use 
the quick and dirty method. Otherwise use the accurate method.

   This could be refined into less of a toy implementation, but it 
should at least get the idea across. I could be built to include 
multiple phases of checks and other such layers.

   You could argue that this could be done using in line checks in the 
code. That is, of course, true. However the abstraction is useful in 
many cases.

                        John