Searching Array of Strings for Element Quick sanity check

[Kevin_Price]

Jeff,

"Match First" has been on my blacklist for a long time because of the odd "expected" behavior described by Norbert_B.   I think I recall other odd-to-me behaviors regarding whitespace & empty strings.  The times I feel stuck using it instead of coding something myself,

I always follow a found match with a regular "=" comparison between the string-to-be-found and the allegedly matching string-element-at-found-index.

I'd second Altenbach's other suggestion about using variant attributes for a string lookup table.  I believe its storage/traversal algorithm is inherently more efficient for strings that are unique near the beginning.  So if you have a lot of strings of type, "COMMON_UNIQUE", you might want to reverse them for use as variant attributes.

-Kevin P

Edit: not only can't I write code that executes faster than altenbach, I can't write posts about his ideas faster than altenbach either...

[altenbach]

---

@Kevin Price wrote:

I'd second Altenbach's other suggestion about using variant attributes for a string lookup table.  I believe its storage/traversal algorithm is inherently more efficient for strings that are unique near the beginning.  So if you have a lot of strings of type, "COMMON_UNIQUE", you might want to reverse them for use as variant attributes.

---

Yes, reversing all strings right after generation, speeds up the variant attributes method from 170µs to 140µs. Significant, but probably not really worth it here. It's not orders of magnitude as the other improvements. 😄

[JÞB]

---

@Norbert_B wrote:

EDIT: What i'm trying to say: The shorter string limits the comparison, regardless if it's string or string array index. 

So since you have "counter" in the end of the string without prefexing '0's, it is somehow expected:

XXX_1 (string array index) 

XXX_123456 (string, what you are searching for)

=> This is a match.

---

That explains why null strings always match! AHHH! Thank you Norbert Looks like the Help file needs an edit to explain just what you explained!

Christian-  Thank you again for pointing out my bug and offering an even better method.  I'll gladly deal with the ugly myself.

[altenbach]

I guess it would have helped to use a zero padded format for the number, so the digit count is always the same. 🙂

[nathand]

---

@Jeff Bohrer wrote:

That explains why null strings always match! AHHH! Thank you Norbert Looks like the Help file needs an edit to explain just what you explained!

---

I think the help file is pretty clear - it even says, explicitly, "If the function encounters an empty string in string array, the function considers it a match."  Personally I like this behavior of searching for a string prefix instead of an exact match, I've used it a number of times.

[JÞB]

---

@altenbach wrote:

I guess it would have helped to use a zero padded format for the number, so the digit count is always the same. 🙂

---

I did, immediately after you pointed out the bug and Norbert explained the functionality.  Yup, 6:1 improvement [reverse strings Match First over search 1D array] without changing data structures at a lower level.  500:1 makes it very tempting to change the underlying data structure... I Will evaluate how often we need to update the array to search.  Creating the varient attributes has a time penalty that your excellent benchmark did not show (add the create attribute loop to the test case- its actually slower than search array) THUS, the "variant with attributes" must be stored in the AE rather than the "array of strings."  Tempting and a lesson I will not forget but, a huge change of scope for revalidation.

Yet, for the application, I am not garunteed an array of strings that are square (strings of equal length)  I will noodle on this a bit... I think an IE suggestion might be in the future to add a "Find First Exact Match" function for strings.......BOOL input to reverse first?  Probably.

Enough for now!  Thanks again.

[nathand]

---

@Jeff Bohrer wrote:

Yet, for the application, I am not garunteed an array of strings that are square (strings of equal length)  I will noodle on this a bit... I think an IE suggestion might be in the future to add a "Find First Exact Match" function for strings.......BOOL input to reverse first?  Probably.

---

 You mean, the "Search 1D Array" function? 😛

[JÞB]

---

@nathand wrote:

---

@Jeff Bohrer wrote:

Yet, for the application, I am not garunteed an array of strings that are square (strings of equal length)  I will noodle on this a bit... I think an IE suggestion might be in the future to add a "Find First Exact Match" function for strings.......BOOL input to reverse first?  Probably.

---

 You mean, the "Search 1D Array" function? 😛

---

IMHO, (not that humility is my strong suit)  If, a better methods exist for searching nD arrays of strings- Search 1D array should break if an array of strings is wired to it.  Explain errors would point to the "Better" function.  Today Search 1D array (String) and Match First. are not interchangable.  As I said, I will think about this - there is a potintial IE idea here. 

Your input would be valuable.

[nathand]

---

@Jeff Bohrer wrote:

IMHO, (not that humility is my strong suit)  If, a better methods exist for searching nD arrays of strings- Search 1D array should break if an array of strings is wired to it.  Explain errors would point to the "Better" function.  Today Search 1D array (String) and Match First. are not interchangable.  As I said, I will think about this - there is a potintial IE idea here. 

---

"Search 1D Array" and "Match First" aren't intended to be interchangeable.  In my view Match First has a very specific function: you want to find out which prefix from a list is at the beginning of a string, and then split the string returning everything following the prefix.  This is a function that applies only to strings, so it's in the String palette.

Search 1D Array should internally implement the best algorithm for the search.  It's a polymorphic function and the data types are known at compile time, so the compiler can easily substitute whatever algorithm is appropriate (for example, searching only as far through a string as necessary to determine that there is no match).  It should NOT tell the user "Use this other function instead" - it should be smart enough to do this automatically, and perhaps it already is.