Thread Subject: Found bug in SUM?

Hi folks,

I wonder why SUM does not work correctly. Please see the examples
below:

OK:
sum([-0.2:0.1:0.1])
 -0.2000

WRONG:
sum([-0.2:0.1:0.2])
-2.7756e-017

OK:
sum([-0.3:0.1:0.2])
  -0.3000

WRONG:
sum([-0.3:0.1:0.3])
 -5.5511e-017

It doesn't work correctly with vectors which are symmetric around
zero. Is this a know bug (or "feature")?

The Matlab version I am currently using is: 6.5.0.180913a (R13)

It is a very annoying behaviour because there are inbuilt functions in
Matlab like MEAN which call SUM and therefore MEAN in this case
doesn't work as intended either.

Any comment on the above?

Regards,
Enrique

__________
Enrique Vidal Sanchez
Ph.D. in EE. (Automation)
www.vidal.dk

<enrique.vidal.sanchez@gmail.com> schrieb im Newsbeitrag
news:1186556245.706712.251660@19g2000hsx.googlegroups.com...
> Hi folks,
>
> I wonder why SUM does not work correctly. Please see the examples
> below:
>
> OK:
> sum([-0.2:0.1:0.1])
> -0.2000
>
> WRONG:
> sum([-0.2:0.1:0.2])
> -2.7756e-017
>
> OK:
> sum([-0.3:0.1:0.2])
> -0.3000
>
> WRONG:
> sum([-0.3:0.1:0.3])
> -5.5511e-017
>
> It doesn't work correctly with vectors which are symmetric around
> zero. Is this a know bug (or "feature")?
>
> The Matlab version I am currently using is: 6.5.0.180913a (R13)
>
> It is a very annoying behaviour because there are inbuilt functions in
> Matlab like MEAN which call SUM and therefore MEAN in this case
> doesn't work as intended either.
>
> Any comment on the above?
>
> Regards,
> Enrique
>
> __________
> Enrique Vidal Sanchez
> Ph.D. in EE. (Automation)
> www.vidal.dk
>

Hi Enrique,
this is not a bug but the effect of using a computer with finite precision
instead
of a paper and pencil. Take a look at
http://www.mit.edu/~pwb/cssm/matlab-faq.html#eps
where this is described in detail...

Titus

On 8 Aug, 09:19, "Titus" <titus.edelho...@mathworks.de> wrote:
> <enrique.vidal.sanc...@gmail.com> schrieb im Newsbeitragnews:1186556245.706712.251660@19g2000hsx.googlegroups.com...
>
>
>
>
>
> > Hi folks,
>
> > I wonder why SUM does not work correctly. Please see the examples
> > below:
>
> > OK:
> > sum([-0.2:0.1:0.1])
> > -0.2000
>
> > WRONG:
> > sum([-0.2:0.1:0.2])
> > -2.7756e-017
>
> > OK:
> > sum([-0.3:0.1:0.2])
> > -0.3000
>
> > WRONG:
> > sum([-0.3:0.1:0.3])
> > -5.5511e-017
>
> > It doesn't work correctly with vectors which are symmetric around
> > zero. Is this a know bug (or "feature")?
>
> > The Matlab version I am currently using is: 6.5.0.180913a (R13)
>
> > It is a very annoying behaviour because there are inbuilt functions in
> > Matlab like MEAN which call SUM and therefore MEAN in this case
> > doesn't work as intended either.
>
> > Any comment on the above?
>
> > Regards,
> > Enrique
>
> > __________
> > Enrique Vidal Sanchez
> > Ph.D. in EE. (Automation)
> >www.vidal.dk
>
> Hi Enrique,
> this is not a bug but the effect of using a computer with finite precision
> instead
> of a paper and pencil. Take a look athttp://www.mit.edu/~pwb/cssm/matlab-faq.html#eps
> where this is described in detail...
>
> Titus- Hide quoted text -
>
> - Show quoted text -

Thank you for the fast answer. It explains the problem partially. You
will still see some errors if you write the vectors in the extended
form:

sum([-0.2 -0.1 0.0 0.1 0.2])
-2.7756e-017
sum([-0.2 -0.1 0.0 0.1 0.1])
-0.1
sum([-0.3 -0.2 -0.1 0.0 0.1 0.2 ])
-0.3
sum([-0.3 -0.2 -0.1 0.0 0.1 0.2 0.3])
0.0

So it is not only a question of how the vector is generated but how
SUM makes the computation.

Regards,
Enrique

__________
Enrique Vidal Sanchez
Ph.D. in EE. (Automation)
www.vidal.dk

 enrique.vidal.sanchez@gmail.com wrote in message
<1186559546.144661.168740@w3g2000hsg.googlegroups.com>...
> On 8 Aug, 09:19, "Titus" <titus.edelho...@mathworks.de>
wrote:
> > <enrique.vidal.sanc...@gmail.com> schrieb im
Newsbeitragnews:1186556245.706712.251660@19g2000hsx.googlegr
oups.com...
> >
> >
> >
> >
> >
> > > Hi folks,
> >
> > > I wonder why SUM does not work correctly. Please see
the examples
> > > below:
> >
> > > OK:
> > > sum([-0.2:0.1:0.1])
> > > -0.2000
> >
> > > WRONG:
> > > sum([-0.2:0.1:0.2])
> > > -2.7756e-017
> >
> > > OK:
> > > sum([-0.3:0.1:0.2])
> > > -0.3000
> >
> > > WRONG:
> > > sum([-0.3:0.1:0.3])
> > > -5.5511e-017
> >
> > > It doesn't work correctly with vectors which are
symmetric around
> > > zero. Is this a know bug (or "feature")?
> >
> > > The Matlab version I am currently using is:
6.5.0.180913a (R13)
> >
> > > It is a very annoying behaviour because there are
inbuilt functions in
> > > Matlab like MEAN which call SUM and therefore MEAN in
this case
> > > doesn't work as intended either.
> >
> > > Any comment on the above?
> >
> > > Regards,
> > > Enrique
> >
> > > __________
> > > Enrique Vidal Sanchez
> > > Ph.D. in EE. (Automation)
> > >www.vidal.dk
> >
> > Hi Enrique,
> > this is not a bug but the effect of using a computer
with finite precision
> > instead
> > of a paper and pencil. Take a look
athttp://www.mit.edu/~pwb/cssm/matlab-faq.html#eps
> > where this is described in detail...
> >
> > Titus- Hide quoted text -
> >
> > - Show quoted text -
>
> Thank you for the fast answer. It explains the problem
partially. You
> will still see some errors if you write the vectors in
the extended
> form:
>
> sum([-0.2 -0.1 0.0 0.1 0.2])
> -2.7756e-017
> sum([-0.2 -0.1 0.0 0.1 0.1])
> -0.1
> sum([-0.3 -0.2 -0.1 0.0 0.1 0.2 ])
> -0.3
> sum([-0.3 -0.2 -0.1 0.0 0.1 0.2 0.3])
> 0.0
>
> So it is not only a question of how the vector is
generated but how
> SUM makes the computation.
>
> Regards,
> Enrique
>
> __________
> Enrique Vidal Sanchez
> Ph.D. in EE. (Automation)
> www.vidal.dk
>
>

I suspect this might be something to do with the vector
creation working some thing like a for loop with succesive
additions of the "gap" which won't neccessarily hit exactly
the intervals you specified explicitly.

0:0.1:0.3 -> becomes -> 0 , 0+0.1+/-eps , 0+0.1+0.1

enrique.vidal.sanchez@gmail.com writes:

>So it is not only a question of how the vector is generated but how
>SUM makes the computation.

Adding the same numbers in a different order needn't give the same
answer - in matlab, C, etc. Some behind-the-scenes optimisations
change the order of operations to speed things up, so it's not a good
idea to make too many assumptions beyond the promised ones. See the
quoted refs for details.

On 8 Aug, 10:11, t...@eng.cam.ac.uk (Tim Love) wrote:
> enrique.vidal.sanc...@gmail.com writes:
> >So it is not only a question of how the vector is generated but how
> >SUM makes the computation.
>
> Adding the same numbers in a different order needn't give the same
> answer - in matlab, C, etc. Some behind-the-scenes optimisations
> change the order of operations to speed things up, so it's not a good
> idea to make too many assumptions beyond the promised ones. See the
> quoted refs for details.

Oh... I see. I guess I have to accept that my PC has not infinite
precision...

Thank you.

enrique.vidal.sanchez@gmail.com wrote:
> On 8 Aug, 10:11, t...@eng.cam.ac.uk (Tim Love) wrote:
>> enrique.vidal.sanc...@gmail.com writes:
>>> So it is not only a question of how the vector is generated but how
>>> SUM makes the computation.
>> Adding the same numbers in a different order needn't give the same
>> answer - in matlab, C, etc. Some behind-the-scenes optimisations
>> change the order of operations to speed things up, so it's not a good
>> idea to make too many assumptions beyond the promised ones. See the
>> quoted refs for details.
>
> Oh... I see. I guess I have to accept that my PC has not infinite
> precision...
>
> Thank you.
>

or use a symbolic math tool (like maple or mathematica). but then, never
use floating point numbers (e.g 0.2) but symbolic representations, such
as 1/5 and never convert it to a floating point result (e.g. the N
function in mathematica).


michael

enrique.vidal.sanchez@gmail.com:
<SNIP FP evergreen...

> So it is not only a question of how the vector is
generated but how SUM makes the computation...

correct; the snippet below shows you the shocking truth:
the SUM is not the SUM...
- FP representation of each number, even if typed in
  <cleanly by hand>, eg, <-0.2> ...
- additional error during accumulation...

just a note
us

one output looks like this (p5/1.6g/512m/win2k.sp4/r2007a)
results
 1 0.00000000000000005551
 2 0.00000000000000000000
 3 0.00000000000000000000
 4 -0.00000000000000008327
 5 -0.00000000000000008327
 6 -0.00000000000000002776
 7 0.00000000000000005551
 8 0.00000000000000002776
 9 0.00000000000000000000
10 0.00000000000000000000
11 0.00000000000000002776
12 -0.00000000000000005551
13 -0.00000000000000002776
14 -0.00000000000000008327
15 0.00000000000000011102
16 0.00000000000000000000
17 0.00000000000000002776
18 0.00000000000000005551
19 0.00000000000000008327
20 0.00000000000000002776

% SNIPPET
     d=[-0.3 -0.2 -0.1 0.0 0.1 0.2 0.3].';
     nt=20;
     r=zeros(nt,2);
for j=1:nt
     disp(sprintf('trial %10d/%6d',j,nt));
     ds=[];
     dr=d(randperm(numel(d)));
for i=1:numel(d)
     dt=dr(1:i);
     ds=sum(dt);
     as=accumarray(ones(size(dt)),dt);
     disp(sprintf('%23.20f %23.20f %1d',dr(i),ds,ds==as));
end
     r(j,:)=[j,ds];
end
     disp('results');
     disp(sprintf('%2d %44.20f\n',r.'));

Hi,
and yet again a very nice example of enlightenment to others, thanks <us>!

Just a very little comment to add: when you replace the last line of <us>
experiment by

disp(sprintf('%2d %44.20f\n',(r*[1 0; 0 1/((numel(d)-1)*eps(0.3))]).'));

then you will see the result r scaled by (numel(d)-1)*eps(0.3). This should
be an upper bound for the summation error (erroryou do for every summation
is about eps(0.3), and there are d-1 summations, so if the numbers you see
are all smaller then one, then everything is fine... This of course is a
quite pessimistic upper bound, because in general negative and positive
errors cancel somewhat out.

Titus

"us " <us@neurol.unizh.ch> schrieb im Newsbeitrag
news:f9c50e$fco$1@fred.mathworks.com...
> enrique.vidal.sanchez@gmail.com:
> <SNIP FP evergreen...
>
>> So it is not only a question of how the vector is
> generated but how SUM makes the computation...
>
> correct; the snippet below shows you the shocking truth:
> the SUM is not the SUM...
> - FP representation of each number, even if typed in
> <cleanly by hand>, eg, <-0.2> ...
> - additional error during accumulation...
>
> just a note
> us
>
> one output looks like this (p5/1.6g/512m/win2k.sp4/r2007a)
> results
> 1 0.00000000000000005551
> 2 0.00000000000000000000
> 3 0.00000000000000000000
> 4 -0.00000000000000008327
> 5 -0.00000000000000008327
> 6 -0.00000000000000002776
> 7 0.00000000000000005551
> 8 0.00000000000000002776
> 9 0.00000000000000000000
> 10 0.00000000000000000000
> 11 0.00000000000000002776
> 12 -0.00000000000000005551
> 13 -0.00000000000000002776
> 14 -0.00000000000000008327
> 15 0.00000000000000011102
> 16 0.00000000000000000000
> 17 0.00000000000000002776
> 18 0.00000000000000005551
> 19 0.00000000000000008327
> 20 0.00000000000000002776
>
> % SNIPPET
> d=[-0.3 -0.2 -0.1 0.0 0.1 0.2 0.3].';
> nt=20;
> r=zeros(nt,2);
> for j=1:nt
> disp(sprintf('trial %10d/%6d',j,nt));
> ds=[];
> dr=d(randperm(numel(d)));
> for i=1:numel(d)
> dt=dr(1:i);
> ds=sum(dt);
> as=accumarray(ones(size(dt)),dt);
> disp(sprintf('%23.20f %23.20f %1d',dr(i),ds,ds==as));
> end
> r(j,:)=[j,ds];
> end
> disp('results');
> disp(sprintf('%2d %44.20f\n',r.'));
>