Question

Lets have matrix A say A = magic(100);. I have seen 2 ways of computing sum of all elements of matrix A.

sumOfA = sum(sum(A));

Or

sumOfA = sum(A(:));

Is one of them faster (or better practise) then other? If so which one is it? Or are they both equally fast?

Answer 1

It seems that you can’t make up your mind about whether performance or floating point accuracy is more important.

If floating point accuracy were of paramount accuracy, then you would segregate the positive and negative elements, sorting each segment. Then sum in order of increasing absolute value. Yeah, I know, its more work than anyone would do, and it probably will be a waste of time.

Instead, use adequate precision such that any errors made will be irrelevant. Use good numerical practices about tests, etc, such that there are no problems generated.

As far as the time goes, for an NxM array,

sum(A(:)) will require N*M-1 additions.

sum(sum(A)) will require (N-1)*M + M-1 = N*M-1 additions.

Either method requires the same number of adds, so for a large array, even if the interpreter is not smart enough to recognize that they are both the same op, who cares?

It is simply not an issue. Don’t make a mountain out of a mole hill to worry about this.

Edit: in response to Amro’s comment about the errors for one method over the other, there is little you can control. The additions will be done in a different order, but there is no assurance about which sequence will be better.

A = randn(1000);
format long g

The two solutions are quite close. In fact, compared to eps, the difference is barely significant.

sum(A(:))
ans =
          945.760668102446

sum(sum(A))
ans =
          945.760668102449

sum(sum(A)) - sum(A(:))
ans =
      2.72848410531878e-12

eps(sum(A(:)))
ans =
      1.13686837721616e-13

Suppose you choose the segregate and sort trick I mentioned. See that the negative and positive parts will be large enough that there will be a loss of precision.

sum(sort(A(A<0),'descend'))
ans =
          -398276.24754782

sum(sort(A(A<0),'descend')) + sum(sort(A(A>=0),'ascend'))
ans =
            945.7606681037

So you really would need to accumulate the pieces in a higher precision array anyway. We might try this:

[~,tags] = sort(abs(A(:)));
sum(A(tags))
ans =
          945.760668102446

An interesting problem arises even in these tests. Will there be an issue because the tests are done on a random (normal) array? Essentially, we can view sum(A(:)) as a random walk, a drunkard’s walk. But consider sum(sum(A)). Each element of sum(A) (i.e., the internal sum) is itself a sum of 1000 normal deviates. Look at a few of them:

sum(A)
ans =
  Columns 1 through 6
         -32.6319600960983          36.8984589766173          38.2749084367497          27.3297721091922          30.5600109446534          -59.039228262402
  Columns 7 through 12
          3.82231962760523          4.11017616179294         -68.1497901792032          35.4196443983385          7.05786623564426         -27.1215387236418
  Columns 13 through 18

When we add them up, there will be a loss of precision. So potentially, the operation as sum(A(:)) might be slightly more accurate. Is it so? What if we use a higher precision for the accumulation? So first, I’ll form the sum down the columns using doubles, then convert to 25 digits of decimal precision, and sum the rows. (I’ve displayed only 20 digits here, leaving 5 digits hidden as guard digits.)

sum(hpf(sum(A)))
ans =
945.76066810244807408

Or, instead, convert immediately to 25 digits of precision, then summing the result.

sum(hpf(A(:))
945.76066810244749807

So both forms in double precision were equally wrong here, in opposite directions. In the end, this is all moot, since any of the alternatives I’ve shown are far more time consuming compared to the simple variations sum(A(:)) or sum(sum(A)). Just pick one of them and don’t worry.