round off error in mtimes

I've noticed that mtimes produces a slightly different answer than the answer I would get from multiplying two vectors directly. Does anyone have any insights on why it's the case?

For example: z is a small single-precision floating point array

z =

   0.6970215
   0.7363197
   0.7967772
   0.8811227
   0.9433413

Using mtimes: z'*z = 3.3291292 Direct method: sum(z.^2) = 3.3291297

Notice how the last decimal place is different? For my problem, I'm computing a bunch of array multiplications in a loop, and this small error gets propagated. The final result using mtimes can be quite different compared to just doing the calculations by hand.

What's causing the difference? Is the small error in mtimes to be expected?

[Stephen23]

You are doing two different calculations using floating point numbers... of course floating-point error will be propagated:

http://blogs.mathworks.com/loren/2006/08/23/a-glimpse-into-floating-point-accuracy/

[Clare]

z'*z multiplies a row vector to a column vector. It's identical to computing sum(z.*z), isn't it?

[Stephen23]

Only in the abstract world of mathematics. Your computation uses floating point numbers, which behave in ways that only bear a passing resemblance to mathematics.

[Roger Stafford]

The difference between your two results, 3.3291292 and 3.3291297, for single precision numbers is just two of the least bits in their 24-bit significands. That is perfectly acceptable in such a computation. If you want higher accuracy, you should use double precision.

[Clare]

Thanks for all of your comments.

The direct method, sum(z.*z), is also applied on single-precision floating point numbers z, so the result 3.3291297 from the direct method isn't exact either.

My take-away is that mtimes uses highly optimized math to calculate matrix multiplication, and the error you get from mtimes is perhaps slightly larger, but the result is still perfectly acceptably. I'll switch to double-precision and see if it might work. (the system is memory constrained).