cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Help us improve the PTC Community by taking this short Community Survey! X

BUG: inconsequent behaviour of match() function.

LucMeekes
23-Emerald III

BUG: inconsequent behaviour of match() function.

Apart from the counter-intuitive behaviour of the match() function (and I suppose this holds also for the lookup functions) as shown here:

LucMeekes_1-1716414145713.png

Due to the definition of z and A, none of the results should change when the value of TOL is changed. However:

LucMeekes_3-1716414817532.png

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

 

 

 

6 REPLIES 6

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

Werner_E_0-1716422782850.png

It should not be necessary but generally you are better off defining your own comparison functions

Werner_E_0-1716423466768.png

Because only simple boolean functions with two arguments are allowed I guess its not possible to create a "nearest" functionality.

 

 


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

LucMeekes
23-Emerald III
(To:Cornel)

Try it.

 

Success!

Luc

Werner_E
24-Ruby V
(To:Cornel)


@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
Werner_E_0-1716449535819.png

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,

Werner_E_2-1716450649167.png

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:

Werner_E_3-1716451010335.png

The absolute values of the differences at index 3 and 4 should be equal

Werner_E_4-1716451056171.png

But when we look closer we see that the value at index 3 is slightly larger

Werner_E_5-1716451100200.png

The usual workaround is not to ask for exact equality but rather for approximate equal within a certain tolerance

Werner_E_6-1716451180771.png

Werner_E_7-1716451191923.png

 

 

 

 

 

LucMeekes
23-Emerald III
(To:Werner_E)

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

 

 


@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".

Top Tags