Problem finding the index?

I am facing a surprising problem. I assigned a range of values for a variable t=-10:0.2:89.8. When I am finding index of 30 by doing find(t==30) its printing 201.

But while finding the index of 40 by find(t==40) its printing 1x0 empty double row vector instead of 251. Why this problem is occuring?

Answer 1

[ME]

The problem is the precision which which your machine is able to store numbers. You are asking MATLAb to find an exact match to t=40, but when you open up the variable browser (or whatever it is called) and double click on the t = 40 box then you can see that it is actually stored as t = 39.999999999999990.

You'd probably be better off trying to find a value extremely close to t = 40 as this will find the right index.

[UPPALA SRINU]

Its resolved. Thank You.

[Stephen23]

See also:

https://www.mathworks.com/matlabcentral/answers/57444-faq-why-is-0-3-0-2-0-1-not-equal-to-zero

https://www.mathworks.com/matlabcentral/answers/316889-why-two-equal-numbers-are-not-equal

http://www.mathworks.com/matlabcentral/answers/102419-how-do-i-determine-if-the-error-in-my-answer-is-the-result-of-round-off-error-or-a-bug

http://www.mathworks.com/matlabcentral/answers/140656-about-numerical-difficulty-of-equality-comparison-operation-between-two-double-real-numbers-in-matlab

This is worth reading as well:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

http://faculty.tarleton.edu/agapie/documents/cs_343_arch/papers/1991_Goldberg_FloatingPoint.pdf

Answer 2

[Constantino Carlos Reyes-Aldasoro]

Ok, a problem of precision, I will edit the previous answer to have the complete solution

Answer 3

[Constantino Carlos Reyes-Aldasoro]

Hello, you have a very subtle problem, and it is that you do not have a value of 40 in your matrix. If you see the value of location 251 like this:

>> t (251)

ans =

   40.0000

you see that is not the same as when you try 201

>> t (201)

ans =

    30

Notice all the zeros after the decimal point in 251? To probe further you can subtract 40 from the value stored in 251:

>> t (251)-40

ans =

  -7.1054e-15

so you will have that the value stored there is NOT 40 but 40.0000000 ... 0000015. You can fix this easily by changing the definition of t like this

  >> t=-10:0.2:90;

and then try again

>> find(t==40)

ans =

   251

Alternatively, you can change the precision of t from the beginning like this

   >> t=round(10*(-10:0.2:90))/10;

by doing the rounding you have eliminated all the 0.0000000 parts of the vector, then you divide and return to your original precision and then it should work fine:

>> find(t==39.8)

ans =

   250

Problem sorted.

[Stephen23]

"by doing the rounding you have eliminated all the 0.0000000 parts of the vector..."

This method does not "remove" those digits. In some cases it might change the stored value, but there is absolutely no guarantee of this either: if the values in the vector t cannot be represented exactly using binary floating point numbers then they will always be represented using the closest approximation (which include those decimal trailing digits).

"...then you divide and return to your original precision and then it should work fine:"

It might work in some limited cases, but this is not a general solution for comparing binary floating point numbers, and can introduce artifacts into the data:

https://www.mathworks.com/matlabcentral/answers/321709-strange-behaviour-of-matlab-find-command#comment_444258

https://www.mathworks.com/matlabcentral/answers/350303-why-0-6-is-not-equal-to-0-2-3#comment_472139

"Problem sorted."

A much more robust solution is to compare the absolute difference against a tolerance, or use ismembertol. This is particularly relevant when the values being compared have been generated have different origins, e.g. constants, different algorithms, colon, linspace, etc..

[UPPALA SRINU]

Yes, now its fine.

[x,y]=min(abs(t-40)); also works in this case where y is the index.

Thank You.

Answer 4

[UPPALA SRINU]

By assigning it as t=-10:0.2:90 then also for find(t==39.8) it shows empty vector.

Because 39.8 is stored as 39.8000000000000004.

Thank You.