Apart from the counter-intuitive behaviour of the match() function (and I suppose this holds also for the lookup functions) as shown here:
Due to the definition of z and A, none of the results should change when the value of TOL is changed. However:
It seems like the value of TOL does 'influence the precision of the comparison' but in an unclear, unpredictable way.
I would suggest that ONLY the 'fuzzy' descriptor/modifier "near" uses the value of TOL. Then "eq" should be implemented as 'equals exactly' and likewise for "leq", "lt", "gt", "geq" and "not". Then with "range" the comparison should be to the borders set by z exactly, after specifying whether or not the border values are in range or not. Then the description of "near" should not use the word, 'closest', because "near" is supposed to use the implicit range from (1-TOL)*z to (1+TOL)*z, where some values may be found closer to z than others.
I suggest to add an option "nearest" to find the value(s) in A that is/are truely 'closest' to z: all values of A that (exactly) equal min(|A-z|). Then also an option "furthest" for the opposite condition.
Success!
Luc
I agree that the behaviour of the match and lookup functions are not the way they should be (and I guess they never were, not even in real Mathcad).
For a 'true' equal you would have to use
It should not be necessary but generally you are better off defining your own comparison functions
Because only simple boolean functions with two arguments are allowed I guess its not possible to create a "nearest" functionality.
@Cornel wrote:
@Werner_E wrote:Because only simple boolean functions with two arguments are allowed I guess its not possible to create a "nearest" functionality.
What do you mean by only simple boolean functions with two arguments? Two arguments? Do you mean that its not possible to have for example lt(x,y,z):= x-y-z < -TOL?
Of course thats not allowed! How should "match" handle a function with three arguments?
Why don't you look it up in the help, it clearly says
It looks to me that the example is not really clever chosen as it should rather read 10% b and not 10% z - so you don't have to edit the function just because you want to use a different value for the first argument of "match" 🙂
match" and "lookup" use this function f just to select those values for which f(a,z) returns "true". z is the value you provide as first argument of "match" and a loops through the vector (second function argument). Each element of the vector is treated separately and independent from the others and therefore no "nearest" could be created that way.
Of course you can write a match_nearest function, but it can't be created using the built-in match function by providing a custom function as last argument,
Because this function uses 'exact' equality and not that weak "equ" , it may miss values just because tiny round-off errors.
For example using Lucs vector A (using default TOL=10^3) the following function call should return indices 3 and 4, but index 3 is missing:
The absolute values of the differences at index 3 and 4 should be equal
But when we look closer we see that the value at index 3 is slightly larger
The usual workaround is not to ask for exact equality but rather for approximate equal within a certain tolerance
