topic BUG: inconsequent behaviour of match() function. in Mathcad

BUG: inconsequent behaviour of match() function.

LucMeekes — Wed, 22 May 2024 22:11:39 GMT

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

Re: BUG: inconsequent behaviour of match() function.

Werner_E — Thu, 23 May 2024 00:21:48 GMT

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.

Re: BUG: inconsequent behaviour of match() function.

Cornel — Thu, 23 May 2024 06:44:12 GMT

@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?

Re: BUG: inconsequent behaviour of match() function.

LucMeekes — Thu, 23 May 2024 07:47:55 GMT

Try it.

Success!

Luc

Re: BUG: inconsequent behaviour of match() function.

Werner_E — Thu, 23 May 2024 08:11:26 GMT

@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

Re: BUG: inconsequent behaviour of match() function.

LucMeekes — Thu, 23 May 2024 10:33:10 GMT

The function in the help example is an f(a, b) and it uses z....????

Re: BUG: inconsequent behaviour of match() function.

Werner_E — Thu, 23 May 2024 12:29:19 GMT

@LucMeekes wrote:

The function in the help example is an f(a, b) and it uses z....????

The help in Prime could be improved to a large extent in many respects - especially when it comes to concrete usage examples directly where the functions are described.
It's almost extraordinary for Prime standards that an example is given for this optional function - it's certainly not a very successful one.
The z mentioned in the function is the value that is passed as the first parameter for "match". So you would have to change the function every time you pass a different first parameter to "match" - pretty nonsensical.
As I wrote above, it makes much more sense to use the function parameter b instead of z.

Its no surprise that the help is of no help to find out that the second argument of the boolean function corresponds to the first argument of "match" and the first argument of the boolean function corresponds to the values in the vector (second argument of "match".