ConwayLife.com

I just found a bug in which the population count is momentarily, yet obviously, incorrect. Here are some notes to reproduce it:

• have 17 tabs open in two windows, each with various content, as well as a few other unrelated programs
• in a simple rule table in which one state is gradually overwritten by another (much like floodfill, but as a rule table)
• grid size of T3072,3072
• grid entirely filled with state to be overwritten
• set single overwriting cell somewhere in the grid
• while playing at step 2^4, zooming in/out or using arrow keys occasionally results in an incorrect population count (the same number every time, if it's not a question mark), which fixes itself at the next graphical update
  • happens more often if there's random debris (non-interacting cell states) in the way

(This is on an Intel® Core™ i7-5500U CPU @ 2.40GHz running Windows 10, with 8GB of RAM.)

Yep, it is possible for the population count to be temporarily incorrect. I'm pretty sure it can only happen in a hashlife-based algo (all except QuickLife) where calculating the current population can be quite time-consuming. We could avoid the problem by preventing any user interaction while doing that calculation, but that would result in Golly feeling much less responsive.

Andrew wrote:Yep, it is possible for the population count to be temporarily incorrect. I'm pretty sure it can only happen in a hashlife-based algo (all except QuickLife) where calculating the current population can be quite time-consuming. We could avoid the problem by preventing any user interaction while doing that calculation, but that would result in Golly feeling much less responsive.

Eh, probably better the way it currently is, then. I just hadn't seen that behavior before.