Incorrect calculation subtracting numeric values stored in a cell array

I'm performing a simple subtraction in Matlab. Both values are stored in a cell array (I'm using numerics and strings).

prices{2,1}{848,5} has the numeric value 4.7903, and prices{2,1}{847,5} has the numeric value 4.7586

my calculation is: prices{2,1}{848,5} - prices{2,1}{847,5}

i.e. 4.7903 - 4.7586.

The correct answer should be 0.0317 but Matlab returns 0.0318. I have used cell2mat function but still no joy.

I've tested it on different versions of Matlab on diferent machines using the same data and get the same error.

If I type in the values as a=4.7903 and b=4.7586 and then type c = a-b then I get the correct answer.

So it must be something to do with using cell arrays.

Any ideas?

Answer 1

[John D'Errico]

No. It has ABSOLUTELY NOTHING to do with cell arrays. In fact, had you said celery, you would have been as close. :)

Your numbers are stored in DOUBLE precision. So they actually have more digits than you see, but your output display only gave you 5 digits there. So while it was displayed as 4.7903, it may actually have been 4.79033797465323... (I've just added some random digits there.)

Likewise, the second number was DISPLAYED as 4.7586, yet it is stored also as a double. So perhaps the actual value may have been 4.758564324553467...

The numbers are always stored to full precision, then subtracted as such. Then you displayed the result of the subtraction, but again providing only a few digits of the result,so it too will be rounded for display. I assume that your default format is short or short g.

doc format

Answer 2

[Christian]

Thanks John, I checked my source data which normally has 4 decimal places, but as it transpires this particular time-series has 5 decimal places so it is a formatting display issue rather than anything sinister. Thankfully 0.0318 is the correct answer afterall :) Thx for your help exposing my oversight. Regards, Chris.

[John D'Errico]

In fact, 0.318 is not the correct answer, since o.318 is not stored exactly in floating point as a double. Were you to try to stuff 0.318 in a double, in fact, MATLAB would store it as

0.031800000000000001876276911616514553315937519073486328125

This is as close as a number stored in BINARY, using a 52 bit mantissa in the IEEE representation can come to 0.0318. Shift the least significant bit by just a nibble, and it looks like you get...

0.031799999999999994937383007709286175668239593505859375

But no, there is nothing sinister here, just life in the wacky world of floating point arithmetic.