
Boost : 
From: Jens Maurer (jmaurer_at_[hidden])
Date: 20000307 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 correlationconserving if you're lucky enough to be on a
subrange of sin() where it is monotonously increasing, it is
correlationreversing 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 subcorrelation(s) and
> have those correlations propogated through subexpressions. 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 overdesign. 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk