From: Martin Schürch (martin.schuerch_at_[hidden])
Date: 2000-03-08 06:40:40
>> but is true when written like [1,2] < interval(2), because the
>> introduces some tolerance.
>> I think when intervall should be used in other areas this lost of
>> is one of the main problems.
>For operator<, the problem is most obvious. Do we also need special
>of the other arithmetic operators+,-,*,/, which would not introduce
>tolerance for operations involving RealType's?
IMO the user should always know for sure if tolerances are possibly
added or not.
I had a brief look at the link a booster posted yesterday
There this problem is solved with an additional flag. IMO a different
perhaps be better e.g. fix_intervall.
>> 1) scale relative to a given value
>> 2) special case for scale-point == median()
>I have implemented points 1-5. I think that points 3-5 are
>obvious requirements which should be fulfilled. However,
>I'm not sure what to make of points 1-2: scale(). Do you have an
>example where it is useful?
I will present an example of a current problem of mine.
Supose you have an intervall [a,b] where a represents the minimal and b
the maximal derivation to get from a point y[i] to y[i+1]:
intervall I = getMinMaxDer();
I *= ds; // I is now dy intervall
I = scale( I, I.median(), 0.95 ); // introduce some security factor
I += y[i]; // is now absolut
I think there are a lot useful situations more general than that.
scale can also be interpreted as a linear affine transform of an
>> Yes it also has the same problems, but propably the user does not
>> from a function called "set_less_eq" as from "<"
>I still think it's useful for the error analysis use case,
>because some algorithm may say "if(x < 1) do_this(); else do_that();",
>and this should at least have a slight chance of working (if the width
>of x is not too large, and is not close to 1).
True. When the behaviour of the operators are clear they would have big
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk