use-livecode Digest, Vol 169, Issue 18

[Peter Reid]

I agree that the redundant indexing is an expensive approach, however I have found that this abnormal structure of a repeat for each loop can be a lot faster than the other loop forms in some circumstances.

I can't find the reference that first highlighted to me the lack of guaranteed sequence of chunks, but I've assumed this was a restriction for some time. It would be great if this is incorrect as I've got some heavyweight looping in several of my apps that would benefit from this!

Can anyone from LiveCode give a definitive answer to this please?

Peter
--
Peter Reid
Loughborough, UK

> On 12 Oct 2017, at 4:36pm, use-livecode-request at lists.runrev.com wrote:
> 
> Message: 17
> Date: Thu, 12 Oct 2017 08:35:50 -0700
> From: Richard Gaskin <ambassador at fourthworld.com>
> To: use-livecode at lists.runrev.com
> Subject: Re: Atkinson dither algorithm & 'for each' loop
> Message-ID: <fa9d19a3-f8c0-a6af-bd90-d4b63b1611b3 at fourthworld.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Peter Reid wrote:
> 
>> One note of caution regarding the use of the "repeat for each" loop,
>> whilst you will get a loop iteration for every value in the collection
>> (fldhexa3 in your example), you are not guaranteed the order in which
>> they will occur.
> 
> Maybe I misunderstand, but are you thinking of arrays there?
> 
> With string containers a "repeat for each" expression should parse from 
> beginning to end, sequentially.
> 
> Any exception to that would be prohibitively unpredictable, and should 
> be reported as a bug.
> 
> 
>> The following adjusted loop guarantees the sequence at the expense of
>> speed:
>> 
>>  put 1 into i
>>  repeat for each word theWord in fldhexa3
>>     put word i of fldhexa3 into theWord
> 
> The speed lost there appears to be the result of a redundancy, and a 
> particularly expensive one:
> 
> We love the convenience of chunk expressions, but in loops we want to 
> remain mindful of "<chunk> <number> of <container>" because satisfying 
> such expressions will require the engine to start from the beginning of 
> the container, examine every character and counting delimiters, until it 
> reaches the number of such delimiters specified in "<number>".
> 
> So the "repeat" line above parses the chunk value into theWord, but then 
> the next line ignores that that's already happened and reassigns the 
> same theWord value using an expression that requires then engine to 
> count words from the beginning of fldhexa3 each time through the loop.
> 
> 
> With this specific algo I believe there may be further benefits in using 
> a chunk type other than word (based on a a hunch derived from word 
> chunks being parsed more flexibly than items or lines), and perhaps not 
> converting the binary data to hex at all, instead parsing bytes directly 
> with a "step 4" option in the loop to keep track of the four components 
> that define each pixel.
> 
> -- 
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  ____________________________________________________________________
>  Ambassador at FourthWorld.com                http://www.FourthWorld.com