On 7/23/07, Matthias Brennwald <address@hidden> wrote:
Dear Franceso and James
Thanks for you replies. I've got a few more comments:
"Francesco Potorti`" <address@hidden> wrote:
>>Ok, that's a start. If I calculate the sum of N numbers, what is the
>>maximum 'offset' of the numerical result to mathematically correct
>>result?
>
> Not a numerical expert, but the error magnitude should be bounded by
> eps*sum(abs(x[1:N])).
Are you sure this is what you intended to write? For example:
octave:5> eps
ans = 2.2204e-16
octave:6> x = [ 1E5 -1E5 ]; N = length(x);
octave:7> eps*sum(abs(x(1:N)))
ans = 4.4409e-11
I just hope (pray) that Octave can do better than this when calculating
the sum of the values in x (i.e. sum(x))...
You asked for the maximum error that could happen. And if you actually compare Francesco's estimate and mine, his is actually lower (I am not saying that mine is correct, again I am not an expert). Also note that what
Przemek says in his mail. This really isn't an Octave thing, but floating point calculations in general. Stuff like sorting numbers by absolute value can help reduce the error of the operations. I'm not sure how accurate you need this to be. Does it matter to you if your set of numbers is like [1e20
0.1 -1e20] doesn't (mathematically) exactly add up to zero, if you're dealing with values on the order of 1e20, what does 0.1 mean in the grand scheme of things?
"James Sherman Jr." <address@hidden> wrote:
> I don't know if this is even possible to quantify absolutely. take for
> example:
>
> octave:55> 1e20+0.1-1e20
> ans = 0
>
> Because underflow happens when you add 1e20 and 0.1, the result is still
> 1e20. So I believe the maximum offset for a set of numbers (worse case
> scenario) is something on the order of: (let N be the vector of numbers)
> maximumOffset = length(N)*eps*max(abs(N));
>
> Which would be like adding 0.1 to 1e20, N-1 times. Note that this because
> eps is not an absolute value, but a relative one.
Ok, that makes sense to me. In fact, I've found the following:
octave:36> 1e20+8.197e3-1e20
ans = 16384
octave:37> 1e20+8.196e3-1e20
ans = 0
This is because you're flirting with underflow, see that
1e20*eps = 2.2204e+04
Which is relatively close to your
8.197e3 when you're looking at scales of 1e20
However:
octave:39> 8.196e3
/1e20
ans = 8.1960e-17
This is much less than eps, which is:
octave:41> eps
ans = 2.2204e-16
So, maybe your estimate is still on the conservative side? Or am I missing
something here?
Matthias
This has to do how the numbers are stored, it isn't stored "exactly" as 8.196e3. I don't know the all the gory details (read some papers if you really want to know), but it seems to me that (unless you have some very specific application that requires it), is something off by 15ish orders of magnitude less than the numbers you're dealing with, really that big of a problem? This is like aiming for a spot on the sun, and being off my less than a millimeter.