Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

To resolve issues starting MATLAB on Mac OS X 10.10 (Yosemite) visit: http://www.mathworks.com/matlabcentral/answers/159016

sum() function in different Matlab version give different result

Asked by Hope on 20 Sep 2012

I use sum() function in my code. I find it give different result in different Matlab version, such as Matlab 7.0 and Matlab 7.9. I load data from .mat file and compute sum of a 300dim vector. It gives the same result when computing sum of the first 100dim, but gives different results for the total 300dim. I wonder why? And how to deal with it?

0 Comments

Hope

Tags

Products

No products are associated with this question.

1 Answer

Answer by Matt Fig on 20 Sep 2012
Edited by Matt Fig on 20 Sep 2012
Accepted answer

How different are the results, percent-wise?

It is possible that the underlying algorithm has changed, and of course the order of summation affects things in floating point arithmetic. For example:

>> N = 3e6;
>> a = rand(1,N);
>> S1 = sum(a);
>> S2 = sum(a(randperm(N)));
>> (S2-S1)/S1  % Not zero.
ans =
       -1.3355e-014

5 Comments

James Tursa on 21 Sep 2012

The sum function may have been one that used to be single-threaded and later became multi-threaded. This could affect summation order (as Matt pointed out).

Jan Simon on 22 Sep 2012

As far as I know, SUM uses multiple threads only if 89000 ore more elements are processed. Then in R2009a the results from the different threads are added in the order the corresponding threads are finished. Therefore the results can randomly switch between a set of values. But I've do not think that happens for 300 elements in any Matlab version.

The order of the elements matters for small vectors also:

s1 =  1 + 1e17 - 1e17 - 1;   % replies -1
s2 = -1 - 1e17 + 1e17 + 1;   % replies +1

[EDITED after James comment] Doh! Of course I meant 1e17 instead of 1e7. But another problem remains: There is no indication that Matlab evaulates the SUM in backward direction ever. But the above argument matters, if e.g. the sum is distributed to 4 threads. Then the order of adding the partial sums matter. If 128 Bit registers of the SSE-unit are used, this is equivalent to sum(1:2:end) + sum(2:2:end). Unfortunately the underlying method is not documented.

James Tursa on 22 Sep 2012

@Jan: I think you are missing something in your post. In double precision, both s1 and s2 are 0. Were you meaning to do a single precision example, or ...?

Matt Fig

Contact us