[boost] Re: Proposal: Interval arithmetic library

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-03-07 18:49:50

Martin Schürch wrote:
> e.g. [1,2] <2.0 is false with the direct implementation:
>     template<class RealType, class Traits>
>     inline bool operator<(const interval<RealType, Traits>& x, double y)
>     {
>       return x.upper() < y;
>     }
> 
> 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?

> 1) scale relative to a given value
> 2) special case for scale-point == median()
> 3) bool do_overlap( I1, I2);

I'm not happy with the name "do_overlap", but "overlap_p" sounds
too Lisp-like.  Could the combined expressive power of the
mailing list please provide a better name?

> 4)  intervall combine(const intervall& r1, const intervall& r2);
> 5)  intervall intersect(const intervall& r1, const intervall& r2);

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?

> 6) Not directly related:
> What I found a very big help in my work, is to have a concept of a uniform
> intervall intersection.
> I have attached (not boost compatible) the code.

There was no attachment, so I'm not sure I understood your point here.

> 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).
 
> So why not seperate the different concepts by different namespaces.
> 
> e.g.
> 
> {
> using namespace boost::interval_error_arithmetic;
>     ...
>     //you behaviour : your <, *=, ...
> }
> {
>     using namespace boost::interval_centre_based;
> 
>     intervall I(0.1,0.5);
>     I *= 2.0;    // [0.1, 0.5] -> [-0.1, 0.7]
>     I += 7;    // shift of the range without introducing any tolerance

We could have two classes: interval_error and interval_centre.
However, I'm unfamiliar with the potential use of interval_centre,
so I cannot estimate the notational convenience of operator* vs.
a scale() function.

At the moment, I don't think it's worth the effort.

Please check out the docvault at
http://www.egroups.com/docvault/boost/interval
for the current version.

Jens Maurer