Could anyone help me to solve the issue.

I tried with the following code and asked about the question already.

As i am unable to get the answer i am asking it again.

C = 5.6;
A = 1:0.1:5.6;
B = 1:0.1:5.6;
[A,B] = meshgrid(A,B)  ;
A(A>B) = NaN ;
C = A+B  ;
idx = find(C==5.6);
D=[A(idx) B(idx) A(idx)+B(idx)];

with respect to code given above C value wil be generated by the code itself.

for example i am storing the value 5.6 in location a

So i changed the above code as

C=a;
A=1:0.1:a;
B=1:0.1:a;
[A,B]=meshgrid(A,B)
A(A>B) = NaN 
C=A+B;
idx = find(C==a);
D=[A(idx) B(idx) A(idx)+B(idx)];

But unable to get the result.

Could anyone please help me on this.

[Geoff Hayes]

jaah - please clarify what you mean by But unable to get the result. Are you observing an error? If so, what is it?

[jaah navi]

when i run the code i am getting

D = Empty matrix: 0-by-3

but the value of D should be equal to a value

if a=4 then Dshould be also equal to 4.

could you please help me on this.

Answer 1

[Walter Roberson]

The two sets of code give me the same output for 5.6

However, you should generally expect no outputs from the code. You are doing exact floating point comparisons. You would not be able to find 1.7, 2.4, 2.9, 3.4, 3.5, 3.6, 3.7, 3.9, 4, 4.2, 4.4, 4.7, 4.9, 5.2, or 5.4 this way, because those numbers entered as text evaluate to something that is not exactly the same as what is calculated by the colon operator in 1:0.1:5.6 .

http://matlab.wikia.com/wiki/FAQ#Why_is_0.3_-_0.2_-_0.1_.28or_similar.29_not_equal_to_zero.3F

Nearly the only time you should ever compare for equality for floating point numbers is if you are comparing against a number that you extracted from the matrix. For example A == min(A) is valid because min(A) will return a value that is bitwise identical to something that is already in the matrix.

[jaah navi]

the first code gives the result of D = 5.6

but the second code gives D = Empty matrix: 0-by-3

[Walter Roberson]

The value 4 does not appear in 1:0.1:5.6

Consider the decimal equivalent of the fraction 1/3 . It is 0.(3)* where the * indicates infintely repeating. Suppose you have only 4 decimal digits available to represent it: 0.3333 . Now think about 0:1/3:2 with the representation of 4 decimal digits. 0 first. Add 0.3333 to that, to get 0.3333 as the second element of the sequence. Add 0.3333 to the second element to get 0.6666 as the third element of the sequence. Add 0.3333 to the third element to get 0.9999 as the fourth element of the sequence. Add 0.3333 to the fourth element to get 1.3332 as the fifth element of the sequence. Add 0.3333 to the fifth element to get 1.6665 as the sixth element of the sequence. Add 0.3333 to the sixth element to get 1.9998 as the seventh element of the sequence. If we add 0.3333 to that we would be beyond our limit of 2, so we stop.

Now, where is 1.0000 in the sequence? Where is 2.0000 in the sequence? Neither of them is there!

But, okay, 4 digits wasn't very much. So suppose you have 8 decimal digits to work with instead, tnat will fix things, right? 1/3 to 8 decimal digits is 0.333333333 , and you will have elements 0.99999999 and 1.99999998 in the sequence, but still no 1 exactly or 2 exactly.

Okay, so 8 digits wasn't enough either. 16 digits for sure will do the job, right? 1/3 to 16 decimal digits is 0.3333333333333333 and that leads to elements 0.9999999999999999 and 1.9999999999999998... and still no 1 exactly or 2 exactly.

No matter how many finite number of decimal digits you use, working by adding the decimal equivalent of 1/3 each time to the previous value, repeatedly, will never exactly equal 1 or 2.

The same kind of problem happens for 1/6, 1/7, 1/9, 1/11, 1/12, 1/13, 1/14, 1/15, 1/17, 1/18, 1/19, 1/21, 1/23, 1/24, 1/26, ... In other words, it happens in decimal representation any time the denominator does not exactly divide a power of 10. 1/5, 5 divides 10, 1/5 does not have the problem. 1/8, 8 divides exactly into 1000 (giving 125), so 1/8 does not have the problem. 1/16 divides into 10000 so 1/16 does not have the problem. 1/20, 20 divides into 100, so again no problem.

Now switch to thinking about the binary representation of 1/10 . 10 factors as 2*5, and while the 2 part divides into powers of 2, there is no power of 2 that is exactly divisible by 5. Therefore in binary, 1/10 requires an infinite repeating fraction. And that means that you are going to get the same kind of problem that happens for 1/3 in decimal: there are going to be numbers that are logically exact multiples of 1/10, but which cannot be exactly reached by repeated addition from 1.

I gave the exact list, above, the 1.7, 2.4, 2.9 and so on, including 4 . None of the numbers on that list is exactly present in the sequence 1:0.1:5.6 and the number that you do get from repeated addition in the colon operator is different than what writing the number down would round to.

DO. NOT. TEST. FOR. FLOATING. POINT. EQUALITY. Not unless you have extracted the target from the same source, like I showed above. (Or sometimes comparing to 0.0 exactly can be justified on theoretical reasons... mostly for avoiding dividing by 0.)

Any time you are tempted to test for floating point equality, you should stop and ask yourself what you really need. Do you really need to find 4.0 exactly? Or do you need to find an entry that is 4.0 to within reasonable round-off error? Or do you need to find the entry which is numerically closest to 4.0 ?