A Life Worth Living

[trofi]

I didn't bother finding 'life' simulators out there and hacked up my own one in haskell.
ASCII graphics showed nice building-up trail of a glider's road.

The population growth was clearly linear (thanks to quickplot).
Found repeating sequence and finally got the answer:

full loops: 746380
rest: 759
loop period: 13398
loop sum: 716
ans: 534408918

Takes about 1-2 minutes to simulate first cycle and get the answer.
The simulator itself survived 600 000 iterations :]

[Hippo]

I have known there are good enough Life simulators with exponential speedup so I was not thinking about codding it myself ... selecting propper generation was not that difficult, maybe converting the initial image to propper input was the biggest complication.

[destiny]

I created a .mc file to load the pattern into golly, which seemd a lot easier than converting to rle. From there on it was easy.

[villu164]

png -> golly -> rle -> https://copy.sh/life
site allows to set step (e.g. as big as 562 949 953 421 312)
from there, it was simply a 11 steps and writing down the number
1001010100000010111110010000000000 10000000000

1000000000000000000000000000000000 8589934592
0001000000000000000000000000000000 1073741824
0000010000000000000000000000000000 268435456
0000000100000000000000000000000000 67108864
0000000000000010000000000000000000 524288
0000000000000000100000000000000000 131072
0000000000000000010000000000000000 65536
0000000000000000001000000000000000 32768
0000000000000000000100000000000000 16384
0000000000000000000010000000000000 8192
0000000000000000000000010000000000 1024


P.S. I had already forgotten about this challenge, until I saw this
http://hackaday.com/2017/03/11/a-clock- ... ways-life/
The 1 minute on a clock, takes ~16 000 steps to make and it is watchable with 1024 step.
And when I noticed that I could make the clock run reaaaalllly fast, like a trillion steps at a time...

[Hippo]

P.S. I had already forgotten about this challenge, until I saw this
http://hackaday.com/2017/03/11/a-clock- ... ways-life/

Fantastic link ... I would not invent such a thing ...

I understand the chosen layout mimicking real circuit with nonintersecting wires to segments.
I personally would prefere synchronisation in segments switching.
In which case we want to make D wire much shorter while A wire much longer.
Of course that would be rather easy modification.

[Hippo]

OK, I have spent some time on it here is the result http://kti.mff.cuni.cz/~maj/clockFast_OK.rle.
(They are twice as fast as the original, what is allowed by almost synchronised segments switching.
Translation tables are halved by segments switching rather to their on/off, so there is more garbage near the segments.)

I still don't like full sync of state changes ... states on right should be accessed later ... 0 is really small time on the clock. May be I will work on it sometimes in the future ... .

[edit]
Synchronisation among digits added, bug around 11-12 hours corrected.
I am not sure 2/3 reduction of tick time would be possible without reducing the clock size.
Even now the 0;9 states for last digit are accessed earlier by 8*60 ticks than other states to be able to properly block hour digit changes. PM/AM switch signal must be delayed by other 8*60 ticks.
[/edit]

OK, the width of states to segments tables could be halved so the synchronisation wait's could be much smaller. States automat could be reorganised to two rows what would made it narrower as well ... so maybe halving the tick time is still possible.

Hmm, the binary tree at the top is counterproductive as I add delayes later.
Much easier method works, which is well delayed without need of delaying labirints.

I would probably change the state logic. translation tables digits and PM AM mark.
(so no full block from original clock would remain ... but same microconstructions would be used often)

It seems to me the size of digits was chosen to match rather big state memory.
I am probably able to reduce the width to half what would allow ticks faster than rewriting a single segment of current size. But making segments smaller would work well.

... as a speed of light is limited, one must make smaller circuits to get higher frequency .

[Hippo]

A have finished my miniclocks (downloadable as http://kti.mff.cuni.cz/~maj/clockMini.rle)

There were several improvements from the original closks. All segments are fully synchronised (including glider phases). Translation tables are narrower. Digits delaying could be probably done by spliting transition to C/2 C/4 glider subpaths rather to labyrinths that would be more "natural" as it would "minimise wire crossings".

Resulting frequency is 4 times higher than the original one. It would be really hard to make clock state automata faster. Even work with segments would be much more difficult. You have to reduce their size or swich them from both ends to halve the "glider" trajectory.

[a.goth]

With the knowledge of the population sizes of the first 13,398 generations, e.g. by using Golly, the population of the gth generation can be determined as follows:

    Pop(g) = 716 * ⌊g / 13,398⌋ + Pop(g % 13,398).

In silent tribute to John Horton Conway, the creator of the Game of Life, who unfortunately died earlier this year as a result of COVID-19. May he rest in peace!