
Boost : 
From: Jens Maurer (jmaurer_at_[hidden])
Date: 20000307 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 scalepoint == median()
> 3) bool do_overlap( I1, I2);
I'm not happy with the name "do_overlap", but "overlap_p" sounds
too Lisplike. 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 15. I think that points 35 are
obvious requirements which should be fulfilled. However,
I'm not sure what to make of points 12: 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk