Re: axes labels on errorbar plots

[Przemek Klosowski]

   suite of programs that could trade-off speed for additional
   calculation, such as:

   * numerical error propagation.

   * measurement error propagation.

Welcome to the church of error worship! Actually, I think that the
numerical and measurement error should be treated the same; I think
the fundamental principle is that there are two sources of error:

 - data error: 

   - for physical/measurement data, equal to the measurement's
     standard deviation

   - for purely numerical data, like Pi/E/Ln(2), the inaccuracy is the
     rounding error resulting from truncation inherent in floating
     point representation.

 - algorithm error: even with precise and accurate input data, most
   algorithms will introduce errors, because they use interval-wise or
   polynomial approximations, or iterative solutions, etc.



   Also, my dream-package would also allow for arbitrary precision
   calculations.

Yeah, but even then you still have to do error propagation.

There is a neat technique for error propagation called 'interval
arithmetic': it reperesents each quantity as two floating point
numbers, describing the confidence interval (true value minus and plus
the standard deviation, or true value with LSB rounded down and
up). The rules for simple operations are then fairly simple: e.g. if A
and B are represented by intervals [al,ah], and [bl, bh], the addition
will be A+B=[al+bl,ah+bh], etc; the memory usage doubles, and the calculation
cost is a constant factor larger than simple numerical calculation (note that
you can't discard second order terms in error, because, a priori, intervals
can be quite large).

Interval arithmetic has been studied in the past: there was a german
group (at Univ. Karlsruhe, IIRC) that did significant studies on
implementing it via discrete algorithms, compiler modification, and
even hardware implementations. The problem with it was that for many
algorithms the interval approximation, as applied naively by simply
propagating errors via individual arithmetic operations, gives
impractically large error estimates (i.e., result = [0, Inf]).
Apparently, the challenge is to reformulate those algorithms so that
they either give a robust error estimate, or expose explicit error
cancellation that helps to obtain a reasonable error estimate of the
final result.

I think that in the future, error propagation is bound to be the
important; done correctly, it will make a difference between, e.g.
weather forecast that says 'two feet of snow' and 'rain or snow'.  The
air temperature difference between the two can be as small as a
fraction of degree, so if one gets a result of [-0.5,0] degrees
Celcius, it is very much different than [-0.75,0.25] deg C---note that
the traditional arithmetic would give the result of -0.25 degC in both
cases.



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------