why setdiff function ignores to delete the element in the first column of an array

>> w =[0.54883746334269044248968027421965, 1.5707963267948966192313216916398,  0.59916277322729276097921590697775;1.5707963267948966192313216916398,  0.7011471887975026432568455778359,   1.5707963267948966192313216916398;-0.54883746334269044248968027421965, -0.7011471887975026432568455778359, -0.59916277322729276097921590697775]

e=setdiff(w,1.5708,'stable')

w =

0.5488 1.5708 0.5992

1.5708 0.7011 1.5708

-0.5488 -0.7011 -0.5992

e =

0.5488

1.5708 (this entry should not be there, but it persists)

-0.5488

0.7011

-0.7011

0.5992

-0.5992

please let me know what change i need to make in setdiff so that the second entry in 'e' gets deleted

[Stephen23]

Because those values are not the same, and in fact none of those values can be precisely represented using binary floating point numbers that are used on all contemporary computers. Read these to know more:

https://www.mathworks.com/matlabcentral/answers/423132-why-is-matlab-messing-up-this-very-simple-calculation

https://www.mathworks.com/matlabcentral/answers/512542-issue-about-ismember-wrong-output

You need to learn about the limits of floating point numbers. Start by reading these:

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

[MUTHUKUMARASAMY V]

Thanks stephen. I got it right

Answer 1

[Fangjun Jiang]

You've show its value is 1.5707963267948966192313216916398.

It is the floating point data precision issue.

[MUTHUKUMARASAMY V]

Thanks Fangjun. Got it right