From the external link: "Every variable changes slightly each time it's accessed, whether to be incremented, printed to the screen, or copied to another variable."
There seems to be a bug in the implementation, going by the sample 99BoB output. Or is it pure coincidence that the value of count stays the same within the displayed precision between the printings of it within each loop iteration? — Smjg (talk) 01:51, 22 February 2012 (UTC)
- Yeah, looks like if you use the same variable multiple times in one string, it's caching until the next loop. I'll look into fixing that. - Rottytooth 15:21, 15 March 2012 (UTC)
- Took another look, seems like the problem is that I didn't describe it correctly in the article. Each time a value is accessed, there's a chance it will change, but it's not changing each and every time. By default, this tolerance value is set to ~27% (70 / 255). Perhaps it would be better to get rid of the tolerance and reduce the amount of mutation instead -- or allow to override them in the compiler. I will play around with it. Meanwhile, the reason that pattern came up in the example (of it changing only at the end of the loop iteration) is because it's actually hitting the randomization more often when changing a value (reading / writing / usually reading again) than just the one time reading to print to the screen. I re-ran 99 Bottles and got a different pattern this time (which I'll put in the article to make it less confusing). Rottytooth 15:30, 3 April 2012 (UTC)
- Decided to wipe out the tolerance, was unnecessary and confusing -- and lessened the mutation to compensate. New version of the compiler is up on my site. Will update examples on the page soon. Rottytooth 15:49, 3 April 2012 (UTC)