t1 = 0:deltast:deltast*(N-1);
zeropos=find(t1==xlow)
zeropos =
1×0 empty
double row vector
Empty. No exact matches.
[found, idx] = ismembertol(xlow, t1)
There is only a "close" value if N is at least 1198.
[mindiff, idx] = min(abs(t1-xlow))
Though it is pretty close.
Remember that the == operator between double precision numbers is looking for bit-for-bit identical values (exception: -0 will compare equal to 0). Two values that differ in their final bit will not == to be equal.
When you use the colon operator : with values that are nice fractions of a decimal, like 1e-5 = 1/100000 then you need to take into account that MATLAB (and nearly all computers) use double precision binary numbers, which are not able to exactly represent 1/10 or any negative power of 10.
This is just the same way that no finite decimal representation is able to exactly represent 1/3. You might represent 1/3 as 0.33333 decimal, but multiply that by 3 and you get 0.99999 decimal, which is not the same as 1.0 . Same problem if you use 0.333333333333333 -- multiply by 3 and you get a bunch of .9 that is not exactly 1.0
Double precision numbers are binary, using the sum of 1/2, 1/4, 1/8, 1/16, and so on. Stop at any finite number of terms and the result is not going to be exactly 1/10 .
When you use the colon operator, all those round-off errors accumulate. 2e-5 is not exactly represented . The inexact representation of 2e-5 is added to that, but the result may have twice the error that you would get if you had written 4e-5 directly..
Never use == for comparing floating point numbers unless you are certain the two numbers are drawn from the same source. For example it is fine to ask
the result of the min() will be a bit-for-bit identical copy of some element in A [except: technical details of NaN], and it is fine to use == to do bit-for-bit comparisons when you know that minA is going to be a bit-for-bit copy.
