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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
