# Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-16 15:32:43

From: "michael toksvig" <michaeltoksvig_at_[hidden]>
> > "Rob Stewart" <stewart_at_[hidden]> wrote in message
> > news:200509161700.j8GH0nHo017101_at_shannonhoon.balstatdev.susq.com...
> > It's surprising for the result type to have a less restrictive
> > range than the inputs.
>
> add two numbers in the 1-10 range, and you invariably end up with a number
> in the 2-20 range

Yep. However, when considering constrained ranges, I find it
surprising that the result would be *permitted* to exceed the
constraints of the inputs.

IOW, I'd have expect the result to be constrained to be 2-10.
Yes, that means that combinations exist that violate that
constraint, but at least it wouldn't surprise me.

> that is both more (in the low end) and less (in the high end) restrictive
> than the inputs

Yes, but I find that surprising.

> i don't find that surprising at all; indeed, i wouldn't consider using a
> checked integral class that did not reflect that

Consider that the class is used to model, say, permitted voltages
in an electonic circuit. Say that an input on the circuit is
constrained by only being able to support voltages of 2-5V. (If
you connect two batteries in series, the voltages add.) If each
battery's voltage is expressed with a checked integer of the 2-5V
range, and their voltages are summed, your result would be a
checked integer with a 4-10V range. That exceeds the permitted
input voltage range and two batteries of 4V each would blow the
input. How would you handle that in your model?

In my approach, the result would be a value with a 4-5V range.
That fits within the 2-5V range and so a successful sum of
battery voltages doesn't exceed the range of the input.

Unless I've missed something, your approach requires a runtime
check to see whether the actual result of the addition exceeds
the input voltage range during some later computation or
comparison. My approach catches the range error during the
```--