Atkinson dither algorithm & 'for each' loop

[Alejandro Tejada]

A few hours ago, I send a message to the mail list, a message that vanish
without trace. Now I am resending parts of that message. The rest of the
message is in the forum...

Peter Read 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. This doesn't matter in a lot of cases but
> does matter when the sequence is significant.  In the case of your
> example I believe sequence is critical, otherwise the pixels might
> appear to be scrambled!

In my own setup, the control structure "repeat for each" is caching
the content of the working variable. This means that we could not
modify the content of this variable while the control structure is
working with it.

After reading your message, now I understand why this happens.
If developers are allowed to modify a variable used by a control
structure like "repeat for  each" then we could get unexpected
result as you describe: elements are processed in an out of order
sequence.

Ben Rubinstein wrote in response to Peter Reid:
> Are you sure? My understanding has always been that
> chunk items, e.g.
> repeat for each [ byte | char | word | item | line] <var> in <container>
> will always be sequential (indeed that's why this structure is fast)
> - it's only when dealing with hashed arrays that the sequence is
> not reliable, i.e.
> repeat for each key <var> in <array>
> repeat for each element <var> in <array>
> Do you have experience to the contrary?

As I wrote earlier in this same message, Peter could have found
some way to change the working variable in a repeat for each
control structure and the result is that elements are processed
with an out of order sequence.

By the way, after reading all comments and recommendations
about the atkinson dither algorithm, I wrote a new handler that
is a lot faster that my first handler, but the result STILL is not
visually identical to that handler.

My educated guess is that Atkinson dither algorithm requires
numbers with more than 2 numbers after the decimal point.
That is: 243.643578 instead of just 243.64
Later this week, I will try to discover the minimal number of
decimal numbers that this algorithm requires.

Please, check this new handler in the forum and suggest how to make
this faster and more precise:

https://forums.livecode.com/viewtopic.php?f=10&p=159078&sid=b46bc56428cb5b0f48d2c6520c107c47#p159078

Have a nice week!

Al