Peculiar behavior regarding matrix operations

2 vues (au cours des 30 derniers jours)
Robert
Robert le 1 Fév 2016
Commenté : Walter Roberson le 1 Fév 2016
Hi,
I just discovered something that I found really weird when I was working with some element-wise multiplication and division for large matrices. I found that the order in which I carry out the operations gives me different results, the line of code giving this behavior is the following:
efrog2=efrog./abs(efrog).*spectrogram;
where efrog and spectrogram are 1325x1325 (efrog contains complex values) matrices. Now if I change the order to:
efrog3=spectrogram.*efrog./abs(efrog);
I get a different result, I if look at the maximum difference I get:
max(max(abs(efrog3-efrog2)))=6.0024e+08
However, if I change the order to:
efrog4=efrog.*spectrogram./abs(efrog);
I get:
max(max(abs(efrog3-efrog4)))=0
I tried the same thing with small 4x4 matrices, but for them the order (as one would suspect) didn't matter. Does anybody have any idea about what is going on here?
Thanks in advance
Cheers
Robert
  2 commentaires
Walter Roberson
Walter Roberson le 1 Fév 2016
what is max(abs(efrog(:)), max(spectrogram(:)) ?
Is it possible that 6.0024e+08 is on the order of max(eps(efrog(:)) or max(eps(spectrogram)) ?
Robert
Robert le 1 Fév 2016
Hi Walter,
I think I might have used different input vectors (in the function that this is in) when I posted the question. With the current ones, I get:
max(max(abs(efrog3-efrog2)))=3.4527e-04
and:
max(max(abs(efrog3-efrog4)))=0
which for some reason seems better, but there's still a difference which I find a bit puzzling. As for your question:
max(abs(efrog(:)))=4.5796e+30
and:
max(spectrogram(:))=1.7614e+12
I'm sorry for not saving the input vectors I used earlier, I hope that this will be of use. Furthermore, if I normalize spectrogram to its maximal value, then I get:
max(max(abs(efrog3-efrog2)))=2.2215e-16
max(max(abs(efrog3-efrog4)))=0
Does this help you in understanding what's going on?
Thanks in advance
Robert

Connectez-vous pour commenter.

Réponse acceptée

John D'Errico
John D'Errico le 1 Fév 2016
Modifié(e) : John D'Errico le 1 Fév 2016
Congratulations. You are the 10 millionth person to have discovered that floating point operations can have subtly different results depending on the order in which those operations were performed. Of course, you award for having done so will be your name appearing in USA today, the Washington Post, and Time magazine, to name just a few. No money though.
Essentially, the basic properties of arithmetic that you learned in grade school no longer EXACTLY apply in floating point arithmetic. In fact, that which you do on a computer only resembles/approximates true mathematics when done in floating point arithmetic.
  2 commentaires
Robert
Robert le 1 Fév 2016
Thanks for the answer as well as the promise of fame and glory!
Given the nature of floating point operations as you mention, I have one more question. Which order of carrying out the operations is the "correct" one?
Cheers
Robert
Walter Roberson
Walter Roberson le 1 Fév 2016
There is no "correct" order, really. But division has more potential to lose precision than multiplication does, so best do that last provided that you don't need to divide in the middle to avoid overflow.

Connectez-vous pour commenter.

Plus de réponses (0)

Catégories

En savoir plus sur Matrix Indexing dans Help Center et File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by