[boost] Re: Proposal: Interval arithmetic library

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-03-07 06:46:43

Gavin Collings wrote:
> I've thought about this a bit more.  The trigger that formed the
> thought in my head was the division operator with its special meaning
> for identical objects giving a result of 1.0 to machine precision.  My
> thinking was that this was a special case of handling correlations
> between the errors - i.e. special use is made of the fact that when the
> dividend is at the top of its range, then so is the divisor.

If that makes you nervous, I will happily remove the special case.
I just felt happy about how naturally C++ supports at least a partial
solution to the correlation problem.

> So, OK, instead of simply reversing the order of terms to reflect
> correlation (too simple), lets have a flag, derived from a constructor
> argument, stating how the term is correlated with others -
> uncorrelated, forward correlated or reverse.  And determine some
> propogation rules, while retaining the class invariant.

Since correlation is always defined between two variables,
we would have to be able to specify the correlation of some
interval A with all other intervals.   For example, A could
be forward correlated with B, B reverse with C, and A reverse
with D.  Furthermore, some functions such as sin() may break
correlation for certain argument ranges. For example, sin()
is correlation-conserving if you're lucky enough to be on a
subrange of sin() where it is monotonously increasing, it is
correlation-reversing on a subrange where it is monotonously
decreasing, and it breaks correlation otherwise.

This seems to be the job of a specialized package, but it is
definitely beyond the scope of the current interval class.
 
> A more general implementation would allow terms in expressions to
> somehow register their interest in particular sub-correlation(s) and
> have those correlations propogated through sub-expressions.  It could
> be done, but may not be worth it.

Keep simple things simple.

> I'm conscious that I may be way past the line drawn between pragmatic
> implementation and over-design.  My feeling, though, is that the
> interval class should have a coherent policy on this issue, even if it
> is explicitly to do nothing.

I am happy to live with "do nothing", since we have the square()
member function and an overloaded pow(x, int) which handle
the important x**y cases.  However, I would like to leave the special
case for x*x in, because there's no other natural expression
for it in standard C++.

Jens Maurer