fastes way to search an array?

Bob Sneidar bobsneidar at iotecdigital.com
Mon May 4 17:32:10 EDT 2015 

That may be. I never use multiple words in an array so it would never have occurred to me to test for that. 

Bob S


> On May 4, 2015, at 14:30 , Eric Corbett <eric at canelasoftware.com> wrote:
> 
> Cool function Bob, I always love a good recursive handler.
> 
> It might be broken when an array element contains more than one word. (Limited testing tho.)
> 
> Eric
> 
> On May 4, 2015, at 2:14 PM, Bob Sneidar <bobsneidar at iotecdigital.com> wrote:
> 
>> I wrote a couple functions that “flatten” an array into a string in such a way that it can be converted back into an array again when done. Here they are:
>> 
>> function altPrintKeys @pArray, theKeyList, pFullData 
>>   put numtochar(11) into vertTab
>>   put numtochar(30) into altCr
>>   put the keys of pArray into theKeys
>>   sort theKeys numeric
>> 
>>   repeat FOR each line theKey in theKeys
>>       put "[" & theKey & "] " after theKeyList
>>       if theKey is not a number then
>>             replace "[" & theKey & "]" WITH "[" & quote & theKey & quote & "]" in theKeyList
>>       end if
>>       if pArray[theKey] is an array then
>>           put pArray[theKey] into theTempArray
>>           put altPrintKeys(theTempArray, theKeyList, pFullData) after theText
>>           put empty into the last word of theKeyList
>>           delete the last char of theKeyList
>>           put cr into the last char of theText
>>       else
>>           put "pArray " & the last word of theKeyList into theKeyName
>>           -- put "put " & theKeyName & " into theValue" into theCommand
>>           -- do theCommand
>>           put value(theKeyName) into theValue
>>           replace tab WITH vertTab in theValue
>>           replace return WITH altCr in theValue
>>           put theKeyList & tab & theValue & comma after theText
>>           put empty into the last word of theKeyList
>>           delete the last char of theKeyList
>>       end if
>>   end repeat
>> 
>>   return theText
>> end altPrintKeys
>> 
>> function altKeysToArray theText
>>   put numtochar(11) into vertTab
>>   put numtochar(30) into altCr
>>   repeat FOR each line theRecord in theText
>>       repeat FOR each item theKeyData in theRecord
>>           put the itemdelimiter into theOldDelim
>>           set the itemdelimiter to tab
>>           put item 1 of theKeyData into theKeyList
>>           put item 2 of theKeyData into theValue
>>           replace vertTab WITH tab in theValue
>>           replace altCr WITH return in theValue
>>           set the itemdelimiter to theOldDelim
>>           put "put " & quote & theValue & quote & " into theArrayA " & theKeyList into theCommand
>>           do theCommand
>>       end repeat
>>   end repeat
>>   return theArrayA
>> end altKeysToArray
>> 
>> 
>> They work together, one for converting an array to text and the other for converting back again. This is handy when you need to eliminate keys using the filter command and then converting back to an array again. But it can be useful for finding an array key or element. Try it on a multidimensional array and view the results. You can see that if you find a line, you will be able to discern the actual array key. 
>> 
>> Bob S
>> 
>> 
>>> On Apr 22, 2015, at 14:44 , Mike Bonner <bonnmike at gmail.com> wrote:
>>> 
>>> I wonder how easy it would be to add an option to arrayencode.  It already
>>> flattens an array nicely, but not in a searchable way. It would be cool to
>>> add an optional argument that still flattens, but doesn't encode.  The code
>>> to traverse the array is already there, with an option to leave the data
>>> and keys readable, it would then make an interesting batch of searchable
>>> text. Just glancing at an encoded array, it looks relatively
>>> comprehensible.
>>> 
>>> One issue would be the unordered way arrays are stored. (making
>>> arrayencoded arrays come out different despite identical data, as per the
>>> dictionary page)
>>> 
>>> On Wed, Apr 22, 2015 at 2:26 PM, Phil Davis <revdev at pdslabs.net> wrote:
>>> 
>>>> Hi Tiemo,
>>>> 
>>>> How many levels deep are the array elements you want to search?
>>>> 
>>>> How many words might each of the searchable array elements contain?
>>>> 
>>>> How is the array keyed - by sequential number, a preassigned numeric ID, a
>>>> content description, ...?
>>>> 
>>>> Would it be worth your time when loading the primary array to build a
>>>> second array that indexes the primary keys by word? (i.e. make an alternate
>>>> index) Then finding which words are in which primary array elements would
>>>> be easy.
>>>> 
>>>> But if your array is "flat" enough, I like Geoff's idea of combining and
>>>> filtering it. But you haven't told us much about its structure.
>>>> 
>>>> Thanks -
>>>> Phil Davis
>>>> 
>>>> 
>>>> On 4/22/15 6:20 AM, Tiemo Hollmann TB wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I have an array with 20000 records, where I want to extract all records,
>>>>> which either "begins with" or "contains" a search string.
>>>>> 
>>>>> Up to now I just loop thru the whole array, do the compare and extract the
>>>>> result records. I wonder, if there is a way to speed up this search? E.g.,
>>>>> does it makes a difference, if I compare the string in the key or the data
>>>>> of the array while looping thru? I mean, would it make a difference, if I
>>>>> would create an "associative" array, where my search looks up in the keys
>>>>> of
>>>>> the array, either by looping thru the array, or by extracting first the
>>>>> keys
>>>>> of the array into a separate variable, instead in the data of the original
>>>>> array?
>>>>> 
>>>>> Would it make a difference looping thru a variable, which just contains
>>>>> the
>>>>> keys of the array, instead of looping thru the complete array, because of
>>>>> the smaller "footprint" in the memory?
>>>>> 
>>>>> Or shouldn't I care about these differences and just let LC makes its job?
>>>>> 
>>>>> Any experiences welcome,
>>>>> 
>>>>> Tiemo
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> use-livecode mailing list
>>>>> use-livecode at lists.runrev.com
>>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>>> subscription preferences:
>>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>>> 
>>>>> 
>>>> --
>>>> Phil Davis
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> use-livecode at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

More information about the use-livecode mailing list