Matlab provides different results for same formula

Hi guys,

I am asking this question in a rather dirty way now:

How is it possible that the "for loop results" on the index {425,79} differ from the results for "AAAAA"?

This is really really frustrating as I can't find a solution.

Currcallprices is a cell array which are either empty or filled with a 1001x1 double. Same holds true for Interpol_ki.

Many thanks for your help. I will provide further details immediately in case they are necessary.

Thanks in advance

Thomas

Answer 1

[James Tursa]

Is this just an index typo? You state 429,79 in your text, but the code has index 425,79.

Also, the calculation in the loop is inside an if-check, so it might not have been done.

And you don't replace all of the m's in your manual AAAAA calculation with 79. There is an m divisor that will be using whatever the current value of m is instead of 79.

[Thorben Green]

Wow, it is kinda crazy how blind you get writing a code. I spent 6 hours on that yesterday and I didn't even see that I use the variable "m" twice, though they extremely distinct from each other.

many many thanks, you saved me a lot of time and nerves. I really appreciate it.

[Thorben Green]

and yes, the 429 / 425 thingy was a typo. Sorry for the confusion and the inconvenience. I should at least be able to provide you guys with a correct question. Sorry again and many many thanks for your help

Answer 2

[Walter Roberson]

interpol_ki{429,79} might be empty so that loop iteration might be skipped.

More generally, in MATLAB when it detects loops or arrays that are "sufficiently large" and which happen to match one of several code patterns, then MATLAB might hand of parts of the calculation to high performance libraries, and those libraries might not give a bitwise identical result.

For example, if you had

   d = rand(1,100000);
   t = 0;
   for K = 1 : length(d)
     t = t + d(K);
   end

then this pattern of totaling might be detected, and instead of just adding the values one by one in a "plain reading" loop, it might be dispatched to a multiprocessor library that might end up doing the equivalent of

t1 = sum(d(1:25000));         %on one processor
t2 = sum(d(25001:50000));     %on processor #2
t3 = sum(d(50001:75000));     %on processor #3
t4 = sum(d(75001:100000));    %on processor #4
t = t1 + t2 + t3 + t4;

Algebraically these are the same as the original, but in floating point arithmetic, these two approaches can have different round-off error, just the same way that .1-.3+.2 is different than .1+.2-.3

[Thorben Green]

Hi Walter,

thanks for your answer. Although the actual problem was something different, this is very interesting to know. I have intense calculations in my code and mostly work with for loops to make those calculations dynamic (i.e. to calculate thru different points and time and within those points in times to calculate with different maturities). I should really try to find another solution given that the loop results might not be "correct" in a certain way. Thanks for the hint