sum() function in different Matlab version give different result

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?

Answer 1

[Matt Fig]

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

[Hope]

they are -0.5789 for version 7.0 and -0.8743 for version 7.9, quite different

[Matt Tearle]

But what size are the values themselves? There might be roundoffs or cancellations due to adding and subtracting large numbers. Then, again, as Matt says, the order becomes significant:

a = 1e12*(rand(300,1)-0.5);
b = [a;-a];
s1 = sum(b)  % not 0!
s2 = sum(b(randperm(600)))  % also not 0, nor s1!

[James Tursa]

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]

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]

@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 ...?