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
> 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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk