[boost] Re: Proposal: Interval arithmetic library

From: Martin Schürch (martin.schuerch_at_[hidden])
Date: 2000-03-08 06:40:40

Hi

>
>> but is true when written like [1,2] < interval(2), because the
constructor
>> introduces some tolerance.
>> 
>> I think when intervall should be used in other areas this lost of
exact control
>> is one of the main problems.
>
>For operator<, the problem is most obvious.  Do we also need special
variants
>of the other arithmetic operators+,-,*,/, which would not introduce
additional
>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
<http://www.lsc.nd.edu/>.
There this problem is solved with an additional flag. IMO a different
classname would 
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
intervall.

>> Yes it also has the same problems, but propably the user does not
expect as
>> much
>> 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
advantages.

Martin