<div class="gmail_quote">On Sun, Mar 20, 2011 at 5:46 PM, Tom Nielsen <span dir="ltr">&lt;<a href="mailto:tanielsen@gmail.com">tanielsen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Interval arithmetic is of course not the same as uncertainty, although<br>computer scientists like to pretend that is the case. (and uncertainty<br>
estimates do not have the be &quot;rough&quot;.)<br></blockquote>
<div> </div>
<div>Very true. </div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">In general the propagation of errors depends on whether the errors are<br>independent or not. The rules are given in Taylor: An introduction to<br>
Error analysis (1997). Interval artihmetic corresponds to the worst<br>case of non-independent and non-random errors. In the case of<br>independent of random errors, you get:<br></blockquote>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">data Approximately a = a :+/-: a<br><br>instance Num a =&gt; Num (Approximately a) where<br> (m1 :+/-: err1) +  (m2 :+/-: err2) = (m1+m2) :+/-: (sqrt(err1^2+err2^2)<br>
 (m1 :+/-: err1) -  (m2 :+/-: err2) = (m1-m2) :+/-: (sqrt(err1^2+err2^2)<br> (m1 :+/-: err1) *  (m2 :+/-: err2) = (m1*m2) :+/-:<br>(sqrt((err1/m1)^2+(err2/m2)^2)<br><br>the general rule is<br><br>if y = f xs where xs :: [Approximately a], i.e f :: [Approximately a]<br>
-&gt; Approximately a<br><br>the error term= sqrt $ sum $ map (^2) $ map (\(ym :+/-: yerr) -&gt;<br>partial-derivative-of-yerr-with-respect-to-partial-ym * yerr) xs<br></blockquote>
<div>The danger here is, of course, the side-condition of independence, which can make inhabitants of that type very difficult to reason about. e.g. x + x and 2*x in that world are very different.</div>
<div><br>In this sense the interval arithmetic bounds _are_ safer to work with in the absence of sharing information even if they are less useful in the hands of an expert.</div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">You can verify these things by running your calculation through soem<br>sort of randomness monad (monte-carlo or random-fu packages) Anyways,<br>
I ended up not going down this route this because probabilistic data<br>analysis gives you the correct error estimate without propagating<br>error terms.</blockquote>
<div> </div>
<div>We are in total agreement here. =)</div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"><font color="#888888">Tom<br></font><br>PS if you&#39;re a scientist and your accuracy estimate is on the same<br>
order as your rounding error, your are doing pretty well :-) At least<br>in my field...</blockquote>
<div> </div>
<div>True enough, but in the case of interval arithmetic I like to be able to preserve the invariant that if I am working with intervals (even if only to collect accumulated rounding error in a Taylor model) that the answer lies within the interval, and doesn&#39;t escape due to some tight boundary condition or accumulated rounding error from when I was working too close to a pole. </div>

<div> </div>
<div>In the case of Taylor models we try to keep the size of the intervals as small as possible by using the first k terms of a Taylor polynomial and only catching the slop in an interval.This is important because of course adding and multiplying intervals will cause the size of the intervals to baloon very quickly. Since the intervals in question are very close to the scale of floating point rounding error as possible, and we often have to conservatively slop the rounding error over from the Taylor coefficients into the interval, accurate handling of tight corner cases is critical.</div>

<div> </div>
<div>-Edward</div></div>