I'm trying to use the "match" function and having a very ridiculous problem. If there is no match, the function returns error. Works fine if there is a match. This makes it useless. As best I can tell from the documentation the return should be "-1" if there is no match. What obvious thing am I missing?
ACCEPTED SOLUTION
Accepted Solutions
Please point me to the location where it says that upon no match the function returns -1.
As far as I know, the reaction upon no match has always been an error.
Note that -1 is not a logic indication for no match, because you could set ORIGIN:=-1, which might mean that returning -1 the value was found at the first position. On the other hand, returning any (scalar) value should mean there's something wrong, because match is supposed to return a vector with the indices/positions (as you can see in the first example); but NaN could be another choice. However it was chosen to return an error in such cases.
If you want to get -1 upon no match, you'll have to write your own match() function, or embed it in a program where you trap the error:
Success!
Luc
Please point me to the location where it says that upon no match the function returns -1.
As far as I know, the reaction upon no match has always been an error.
Note that -1 is not a logic indication for no match, because you could set ORIGIN:=-1, which might mean that returning -1 the value was found at the first position. On the other hand, returning any (scalar) value should mean there's something wrong, because match is supposed to return a vector with the indices/positions (as you can see in the first example); but NaN could be another choice. However it was chosen to return an error in such cases.
If you want to get -1 upon no match, you'll have to write your own match() function, or embed it in a program where you trap the error:
Success!
Luc
@MR_10595556 wrote:
I'm trying to use the "match" function and having a very ridiculous problem. If there is no match, the function returns error.
You may not like this behaviour and may think that different one would be more appropriate, but I won't call this ridiculous.
This makes it useless.
I disagree, Would you also say the the implemented division operator is "useless" just because it throws an error when trying to divide b zero?
Error trapping is up to the user.
As best I can tell from the documentation the return should be "-1" if there is no match.
No! This is not the case and never was. Maybe you confuse the "match" function for vectors and matrices with the "search" function for strings!?
As Luc already suggested you may redefine the match function to return something meaningful if no match is found. That way you may have more control to react accordingly.
In Prime it may look like this:
Personally I would prefer a NaN as return value if no match was found.
Note that the built-in "match" function has an optional third argument -> Lookup Functions
When you type "match" your (re)defined function is used and it will throw an error if third argument is used.
You still can use the built-in function if you label the word "match" as being "Function":
Note the different typeface.
Of course you could also redefine the match function with the third argument:
So whenever you need the match function with its third argument, use the capital M, otherwise the lower case.
You may hide the redefinition of the functions at the top of the sheet - either in a collapsed region or in the non-printable area to the right of the right margin.
@MR_10595556 wrote:
I'm trying to use the "match" function and having a very ridiculous problem. If there is no match, the function returns error. Works fine if there is a match. This makes it useless. As best I can tell from the documentation the return should be "-1" if there is no match. What obvious thing am I missing?
@LucMeekes wrote:
Please point me to the location where it says that upon no match the function returns -1.
As far as I know, the reaction upon no match has always been an error.
Note that -1 is not a logic indication for no match, because you could set ORIGIN:=-1, which might mean that returning -1 the value was found at the first position. On the other hand, returning any (scalar) value should mean there's something wrong, because match is supposed to return a vector with the indices/positions (as you can see in the first example); but NaN could be another choice. However it was chosen to return an error in such cases.
If you want to get -1 upon no match, you'll have to write your own match() function, or embed it in a program where you trap the error:
Success!
Luc
Decisions, decisions. I was going to post this replacement for match in another thread, but why not go the whole hog and reply to both - it might improve its visibility to others with the same problem.
Where IsRange, vec, and search are defined as:
I wouldn't go so far as to say built-in match's failure mode is useless, but I've always found it quite annoying. If something doesn't seem intuitive and requires a workaround, then it probably needs fixing. So I fixed it long ago, back in Original Mathcad 11 days of lore.
The built-in match is part of the lookup suite of functions and is intended for searching arrays. However, it seems a waste when it can be profitably used to search other data types, including strings. So I gave it enhanced meaning and purpose along the way.
Whilst the string data type has its search function to find a string within another string, search doesn't return the positions of all occurrences of the search string. As I'd needed this capability on several occasions, I decided to simply overload match.
In addition, if A is a range variable, new match expands it into a vector and then performs the search on that.
Rather than -1 (or ORIGIN-1) to indicate a match failure, I opted for 0 (zero), 0 being the standard Mathcad boolean false. I use 1 to indicate that a non-array (actual or implied) was the item being searched and that scalar/function z equals A (eg, 3 is 3 and cos is cos).
I've got a couple of versions of match kicking around in various stages of development. A problem with the implementation shown above is that it uses the equality operator. This is fine for a lot of data but can be problematic when dealing with reals. Another version uses the built-in match with a standard lookup function modifier to deal with this scenario. However, because user-defined functions can't take arbitrary numbers of arguments, I prefer to use the "standard" form where possible. There are always tradeoffs and cat-skinning considerations to take into account.
Stuart
