0

When I compare the position of an axis with a double array containing the exact same values, the comparison returns false. Below, I compare both using A == B and isequal(A,B):

>> ax = gca;
>> ax.Position

ans =

    0.0500    0.1000    0.9000    0.4250

>> comparePosArray = [0.0500    0.1000    0.9000    0.4250]

comparePosArray =

    0.0500    0.1000    0.9000    0.4250

>> comparePosArray == ax.Position

ans =

  1×4 logical array

   0   1   0   0

>> isequal(comparePosArray, ax.Position)

ans =

  logical

   0


>> class(comparePosArray)

ans =

double

>> class(ax.Position)

ans =

double

I.e. both arrays contain double values. Both arrays are seemingly identical (I created the axis with those exact values, so I am certain that there is no small extra value, e.g. 1e-9 or so. Given that Matlab has not added it a posteriori). the A == B claims that ONE value is the same, why? Why not all? Why does not isequal return true?

If I use num2str() and then strcmp(), the comparison will return true.

All help is much appreciated.

jkazan
  • 1,149
  • 12
  • 29
  • 2
    Try `0.1+0.2==0.3`. Welcome to the world of numerical analysis in computers! – Ander Biguri Jan 17 '17 at 09:00
  • Read here: https://stackoverflow.com/questions/588004/is-floating-point-math-broken – Ander Biguri Jan 17 '17 at 09:05
  • I understand the limits of numerical analysis. However, I manually set the axis position to [.05 .1 .9 .425]. Unless matlab, for some questionable reason, tampers with those values, they should be exact. I could imagine that the values change to what can be represented by the screen as the values are not in pixels. However, this aught to be treated in a way such that these errors cannot occur. Can anyone verify that matlab changes the values of axes? – jkazan Jan 17 '17 at 09:54
  • 2
    Its not that. When you write `comparePosArray = [0.0500 0.1000 0.9000 0.4250]` you are not ensured to get the exact bit-per-bit representation of the number that `ax.Position` gives. Its probably on the 9th decimal place or so, which in screen positions it would be converted to about the sizes of some atoms, so not really a physical problem. Maybe MATLAB the screen just needs a float instead of a double when printing in screen and catching that value gives a slightly different value. When using decimals, always just do `(comparePosArray-ax.Position)<10e-6` – Ander Biguri Jan 17 '17 at 12:58
  • I see. Strange. As the values are small and simple, I'd expect them to be represented correctly, regardless of possible tampering inside axes attributes. Very interesting indeed! Thank you for the insight, I really appreciate it! – jkazan Jan 17 '17 at 16:06
  • Nonono, do not expect them to be represented correctly. That is true *only* and really **only** for integer values. Any other number, you can not trust – Ander Biguri Jan 17 '17 at 16:07
  • Even nice finite rational numbers? – jkazan Jan 17 '17 at 16:08
  • If the value is a float (or `single` or `double` in matlab, as they are called) the **ONLY** numbers 100% accurate are integers. Try `0.3+0.5==0.8` and `3+5==8`. Change numbers as pleased – Ander Biguri Jan 17 '17 at 16:29
  • 1
    Those numbers actually worked fine, however, 0.0003+0.0005==0.0008 returned false... Also, mind == blown returned true! I can't believe I have been so gullible for so long! I was aware of the fact that numerical analysis is much limited, but this was beyond my expectations! Thanks for straightening me out @Ander Biguri – jkazan Jan 18 '17 at 17:14
  • The question that this has been closed as duplicate with has an amazing updated answer about how/why/when this happens and what to do about it – Ander Biguri Jan 18 '17 at 17:26

0 Answers0