MATLAB: Unexpected numerical errors in matrix/vector multiplication

matrix multiplicationmtimesnumerical error

I have observed an apparently very strange behavior when running a Matlab script. I have a very long data vector t (with 4560000 elements) and several other vectors x1,…,xM, all with the same dimension as t. Now, I basically want to compute the scalar product between each xm and t. I have done that using two procedures: the first one consists in computing each scalar product between a vector xm and t inside a for loop, while the other simply consists in forming a matrix X whose columns are the vectors xm and then computing the product of X transposed and t. Surprisingly, the results are very different!
For simplicity, let us suppose M=2. If I compute:
>> y1 = [x1 x2].'*t;
>> y2 = zeros(2,1);
>> y2(1) = x1.'*t;
>> y2(2) = x2.'*t;
Then I get a large relative normalized error
>> er = norm(y2-y1)/norm(y1)
er =
(By the way, norm(y1) = 1.2665e+06). Componentwise, the error is
>> y1(1)-y2(1)
ans =
>> y1(2)-y2(2)
ans =
In principle, these alternatives should always yield the same results, regardless of the contents of those vectors, since they should be translated into machine code corresponding to equivalent operations. So, it seems odd to me that some kind of numerical issue arises.
Has anyone seen a similar behavior before and knows what might be causing that? Am I missing something with respect to the internal implementation of such operations?

Best Answer

  • The dot product implementation might differ according to the input, i.e. dot product between two vectors as opposed between two matrices. Also, a quick search on the web exposes a few implementations of the dot product in the BLAS routines themselves and Matlab might be picking one or another according to different needs.
    The example suggests zdotu.f
    edit([matlabroot '/extern/examples/refbook/dotProductComplex.c']);
    However, this doesn't tell us much about the dot product between matrices.
    The difference in the results after startup calculation seems to be just chance. In fact, if you vary the number of random draws, the difference is not 0 anymore. To reset the state of the random generator without restarting, simply use
    To address such a big discrepancy, we need to see what are the values of the dot products.