# Boost :

From: Hervé Brönnimann (hervebronnimann_at_[hidden])
Date: 2008-04-13 03:38:20

Steven: You seem to be following a partial differential approach,
where you record the partial derivative of an expression wrt to each
of the variables that compose it. Your particular approach is using
a sparse representation of the vector of derivatives wrt to all the
variables in your system. Wrt the evaluation of the uncertainty (sqrt
(0.2*0.2 + 0.2*0.2) = 0.28 in your example), this just corresponds to
a norm for the vector, here the Euclidean norm, with a twist that
you're not dividing by the total number of variables (not even by the
number of variables that are actually involved in your expression).
(Note that with a finite number of variables, all norms are
equivalent anyway.) It's not an especially new idea. If you go to
second derivatives, you can do the same with the Jacobian matrix of
your expression. The discussion then becomes sparse vs. dense
representation. Your idea seems to boil down to using a sparse
representation of this otherwise well known aproach. Am I missing
something?

BTW, error propagation can also be handled by boost.interval. Note,
I am not talking about tracking dependencies (it's the same kind of
thing that makes square(x) have a smaller interval enclosure than x *
x). Although in general, for small errors, there isn't much
difference and we've used interval analysis exactly for that purpose,
assuming all the variables are always independent (you get an
guaranteed enclosure either way, just not as tight as it could be if

My apologies if I missed another particularity of your approach.

```--
Hervé Brönnimann
hervebronnimann_at_[hidden]
On Apr 13, 2008, at 12:51 AM, Steven Watanabe wrote:
> There are several ways this can be made more accurate.
> 1) instead of taking x + uncertainty_of_x we can take several
>    sample points inside the range x +- uncertainty_of_x
> 2) it should be possible to track dependence on groups
>    of variables in addition to dependence on single variables
>    independently.
>
> All of this adds overhead of course, but I think that a reliable
> mechanism for error propagation is often going to be worth
> that cost.
>
> The code is attached.
>