Unable to Set Equivalence Between Variables

I am trying to create a script that generates a mesh for a BVP problem that employs FDM. The script works and is producing the mesh grid I want, but ML is not seeing that the elements I explictly want included in the matrix are there. They need to be explcitly included because these values are the boundaries within the problem and so need to be evaluated at those points directly. I have a part of my code that tells me when one of the boundaries are not included in the mesh and in this instance the radial boundary is 0.03. When I go and check the mesh though, I see it in there:

For context, this each column was created using a linspace and then repeated. I then try to explcitly check directly that element against the definition and it does say they are not equal:

So the only thing I can think of is that there is a precision mismatch occuring between the two and even though they are the same value, because of the precision difference, ML thinks they are different. The elements in the mesh and the definition are all double precision and the order range for that data type is more than enough so I prefer not to use another. I do use round for the Cr definition (Cr==0.03), so perhaps that is causing issues? I also do notice that there are more orders being included in the Cr value than what's in the mesh:

So this may hint at the issue? I thought that it was because of some hidden, nonzero number being present within the mesh node value, so I applied round() with the same order specification both to the mesh and the Cr value again, but that didn't work. So I am stuck for now.

[Stephen23]

"even though they are the same value, because of the precision difference, ML thinks they are different."

They are not the same value. ML thinks that they are different values for a very simple reason: they are different values.

"I do use round for the Cr definition (Cr==0.03), so perhaps that is causing issues?"

Different calculations producing different values, which a user thinks "must" be the same. This is very common:

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/69-why-does-1-2-3-1-3-not-equal-zero#answer_271

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

https://www.mathworks.com/matlabcentral/answers/41536-why-is-2-24-10-22-4-not-equal-to-0

https://www.mathworks.com/matlabcentral/answers/20830-1-0010-does-not-equal-1-0010

This is highly-recommended reading as well:

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

Your code tests for equivalence of floating point values, which is a buggy/fragile way to write code. You need to change your algorithm to take into account floating point error. The easy, standard, efficient, recommended approach is to compare the absolute difference against a tolerance (which you select), e.g.:

tol = 1e-10;
abs(A-B)<tol

or use ISMEMBERTOL. Do not use rounding, for the reasons explained here:

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

[John]

Thanks for the resources @Stephen23, I'll take a look at them