Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
Joe Gottman wrote:
Deane Yang wrote:
Edward Diener wrote:
Deane Yang wrote:
I have an even more extreme view on this. I don't believe any arithmetic operations should be permitted for constrained numbers. They just don't make sense (would you ever want to add two different days of a month?).
You have chosen a particular type for which arithmetic operations sometimes make little sense. In many other situations this is not the case.
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?
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
participants (2)
-
Deane Yang -
John Phillips