Boost logo

Boost :

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
for the current version.

Jens Maurer

Boost list run by bdawes at, gregod at, cpdaniel at, john at