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
> 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.
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