CODEWITHSUNDEEP
matlabfloating-point-precision
SwatchPuppy
SwatchPuppy

Reputation: 334

Same matrix operations return different results in Matlab

I am having a little problem with Matlab, I think it has to do with Matlab precision, but I would really like to solve this. I have three matrices, one called f with dimension 296x3118, other called mapping.mean with dimension 1x3118 and the last called mapping.M with dimension 3118x100.
The result of the following operations should be one, but it isn't. The resulting matrices f_s_1 and f_s_2 have values that only differ in the range of 10^-12. Does any one know why, or how to fix this?

f_s_1 = ((f(1:296,:)-repmat(mapping.mean,296,1))*mapping.M)';
f_s_2 = ((f(1:295,:)-repmat(mapping.mean,295,1))*mapping.M)';
isequal(f_s_1(:,1:295),f_s_2)

ans =

 0

Upvotes: 1

Views: 965

Answers (1)

Steve
Steve

Reputation: 4097

What you are seeing is a result of Round-off error in MATLAB and likely comes from parallelization of the large matrix operations. For very large matrix operations, MATLAB automatically switches to a parallel version of the operator to increase speed this means that portions of the solution can all be computed at the same time and then combined at the end. Since different portions may finish sooner or later or be comprised of different parts of the original problem you can get different results.

Because your computer uses only a small number of bits to represent your number (on your version of matlab it probably uses 64 bits) you will often have some small part of a decimal number that gets cut off when doing operations. In fact, when you add a very large number to a very small number, the computer may return only the very large number as the result because there is "no more room" to represent the smaller number.

For example, try running the following code:

mybase = 1e17;

sum1 = mybase + sum(1e-4*ones(2^14,1)) - mybase
sum2 = mybase - mybase + sum(1e-4*ones(2^14,1))

You should get:

sum1 =

     0


sum2 =

    1.6384

even though the sums are just rearranged, they result in different numbers. If you play around with it, you will find that MATLAB adds the numbers from left to right, and when the numbers are much much different in magnitude then problems start to arise. Since 1.6384 is such a small fraction of 1e17 we might consider it no real error at all... but clearly the answer is wrong and all because of the ordering of our sum.

Why is this relevant here? As we noted before, if MATLAB chooses to parallelize the operation then each portion of the problem will be computed at the same time then combined. The pieces may get added in different order depending on many things (problem size, other things the computer is doing, etc). This means that the result will be slightly different. If you set the matrices to be the same size on my version (R2012a) then you might get the same answer... or you might not. Also, it will depend on size.

This behavior is a "feature", and I got the same answer even when using maxNumCompThreads(1)

Upvotes: 3

Related Questions