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

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to