Idea for generating a large-scale census

[Lewis]

Before Geocities closed, I saved a copy of Andrzej Okrasinski's Life Screensaver, which generates statistics based on random soups. The key feature is, different censuses can be produced for different densities but the same area, and these can be combined into one final census.

My idea is that if several people run a copy of the screensaver (keeping track of who is already using which density) and the results files are combined every so often, a very large set of statistics could be generated, and a possibility for natural constructions of rare objects to be found.

The only problem I can see is that the allowed densities are limited to whole numbers between 10 and 50, meaning only a maximum of 40 people could generate data (unless the 'random seed' number affects that; I'm not sure how it works).

http://soakerhoo.110mb.com/lifess15.zip : Here is a backup of the installer for the screensaver.
http://soakerhoo.110mb.com/lf020n.pdf : Here is the census originally on the site, generated by the software.

[ohennel]

Hi All,

Initial seed indeed helps to avoid overlapping of areas (within the same edge and density) searched by the saver on different machines.
But a user must be careful not to run into initial seed of other users. Program does not check for this, as far as I remember.
It is nice to hear that anyone uses this software.
My results posted on geocities (site closed) I covered 20x20 patterns with even densities in range 18..46.
Computers become faster, so I think I would implement 64-bit seeds instead of 32-bit if I updated the saver.
That would practically solve the problem of overlapping, until quantum computers

Regards,
Andrzej Okrasiński

[Lewis]

My results posted on geocities (site closed) I covered 20x20 patterns with even densities in range 18..46.

Are your results still being updated somewhere after geocities closed? I have the version saved which has 8747 object types, is there a newer one than this?

Also, on the subject of an updated version of the screen saver, would it be difficult/possible to allow the saver to operate using different rules (eg. 2x2 or B3/S2456)?

[tysonlee12]

Historically, the one big piece of famous hardware for this is the Connection Machine. There's a great article about Richard Feynman's involvement here:

[ohennel]

I stopped generating results a long ago (life turbulences)...
But I am going to continue.

[ohennel]

I just completed making sources compatible with 64-bit Visual C++ 2022, and implemented 64-bit seeding.
Next will be, I think, counting 288- and 384- period puffers in the census (currently the soup falls in "Game failed" basket).
I think of resolving cis- and trans- queen bee shuttles (Aachim's census resolves them, so it will be interesting to compare).
Time and wife allow, this will all be done promptly.

And next I think of a version that employs more than a single CPU. Using modern C++, this should not be difficult as well.

As of other than standard rules implementation, there is too much strange standard rule specific code, it is there to cope with problems that I found developing census code, so this is not my priority.

[apg]

I just completed making sources compatible with 64-bit Visual C++ 2022, and implemented 64-bit seeding.
Next will be, I think, counting 288- and 384- period puffers in the census (currently the soup falls in "Game failed" basket).
I think of resolving cis- and trans- queen bee shuttles (Aachim's census resolves them, so it will be interesting to compare).

Have you looked at the https://catagolue.hatsya.com/statistics page, which is the largest distributed census to date? The main census (B3/S23, asymmetric 16x16 soups, CPU-only) has censused 3.8 * 10^15 objects so far. It's also the longest continuously running census, celebrating its 8th birthday next month.

There have been 3401331 trans and 3338327 cis queen bee shuttles observed so far -- i.e. 50.467% trans and 49.533% cis, with a standard error uncertainty of 0.019% -- so we can be sure that trans queen bee shuttles are slightly more common in 16x16 random soups.

Sample soups are recorded for rare objects. One of the rarest objects that we've seen is the c/7 Loafer:

Code: Select all

x = 16, y = 16, rule = B3/S23
4b2o3bo2bo$4ob2obo3b2o$4bob2ob6o$bobo3bob2ob4o$5obob4obo$3o6bo4bo$5o3b
o5bo$o5b7o2bo$b3ob4ob4obo$ob2obo2b3obo$2bo5b3o3bo$2b6o3b3o$o2bob2o2bob
obo$3b2obob2obob2o$2bo2b2obobob2o$o2bob6o!

and this p16 oscillator first discovered by Rob Liston using a GPU-accelerated version of the search program:

Code: Select all

x = 16, y = 16, rule = B3/S23
7o3b2ob2o$ob3o3b2o2bo$obo4b2o2b2ob2o$2o3b2ob2ob2obo$6o2bobobo2bo$6obo
5bo$bo2bobo3bo2b3o$ob2ob2obobobobo$3b2o2b3obob2o$o3bo2bobo3b2o$5bo2bo
3bob2o$3b3o5bo$3obobo2b2o2b2o$7obo3b3o$3o2bo3b3o$b2o2bo4bob3o!

Any long-lived soups are also recorded. The record is this one, which lasts 52513 generations before stabilising:

Code: Select all

x = 16, y = 16, rule = B3/S23
3o2b2obob2ob3o$2obob3o4bobo$bo2bo2bobob3obo$2bo2b2o3bo2bo$2bo5bobo3b2o
$o4b2o3b3obo$3b2o2bo2bobo2bo$2b4obo2bob2o$2ob2o2b2o5b2o$ob4obo4b3o$o3b
4o2b3o$b10o2b3o$2o3bob3obob3o$b2ob6o3bobo$obo5b4obo$3obobob2o5bo!

The record for longest-lived soup that dies out completely is 1398 generations:

Code: Select all

x = 16, y = 16, rule = B3/S23
2ob3ob3ob3o$o2bo3b4obobo$obob3ob2o2bo$2obo2bob3ob3o$b5obob4ob2o$o2bo7b
2obo$ob3o3b4o$b3ob2ob3o2bo$5obo3bob2obo$4ob2ob2o2bo$4b2o2bob2ob3o$6o6b
3o$o3bo2bo2b5o$obob4obo4bo$o2bo2bo2bo2b3o$2obobobobobo3bo!

We're still waiting for a Gosper glider gun (it hasn't appeared yet out of 174 trillion CPU-generated soups or 238 trillion GPU-accelerated soups), but we have seen natural occurrences of pairs of queen bee shuttles that strongly suggest that we might see one eventually. This one, found in December 2022, differs from a Gosper glider gun only inasmuch as one of the shuttles has been rephased by two ticks:

Code: Select all

x = 16, y = 16, rule = B3/S23
2obo3b2o3bob2o$4bo5bo4bo$3bo2b2ob2o2bo$obobo7bo$b2o2bobob5obo$b2ob2ob
2o3bobo$2bobob5obo2bo$b2o2bob3obob2o$b5o4b2ob3o$ob2o3bob2obo2bo$o3bob
2o2b3o$3bobobo3b4o$bob2obobob2o3bo$o2b2ob3o4b2o$2o7bobo$3o6bo2b2obo!

The soup size (16x16) is slightly smaller than the soups in your census (20x20), because the soup is populated by the output of the 256-bit cryptographic hash function SHA-256. This both ensures very high statistical quality and also prevents reverse-engineering (so someone can't take an engineered object such as a 2-engine Cordership, engineer a 16x16 predecessor using SAT solvers, and then submit that to Catagolue to distort the census statistics, because doing so would involve the computationally intractable problem of finding a SHA-256 preimage).

[ohennel]

...and compare it with Catagolue from time to time. Circa 100 objects appeared in my census not in Catagolue, even though my sample is ~1500x smaller, but what can I do with a single 8 year old desktop.

As of today, here are the results:
https://file.kiwi/37b6b409#d_vmu7M1WmK6Po_sUfbvYw

Best regards, folks!
Andrzej

[PK22]

...and compare it with Catagolue from time to time. Circa 100 objects appeared in my census not in Catagolue, even though my sample is ~1500x smaller, but what can I do with a single 8 year old desktop.

As of today, here are the results:
https://file.kiwi/37b6b409#d_vmu7M1WmK6Po_sUfbvYw

Best regards, folks!
Andrzej

Nice work!
Here's the census results in .csv format:

results.csv

(616.78 KiB) Downloaded 42 times

And here are the apgcodes which have not occurred in an asymmetric Catagolue soup:

Code: Select all

xs27_o8bbgzx3lkk8z0ca52
xs24_xml1eg84czca52011
xs36_069b8bbgz0255lldz31243
xs22_8k4o798gzwd8711
xs21_ggmk21egoz1w346
xs22_o8blkia4z0c96
xs30_0gbb88gz34b9ab43zw33
xs23_02lmge1e8z25ac
xs26_01no3tgz3egnc
xs20_69q4oa6z32x23
xs22_c871z31178c453
xs24_g6p7o796z11x56
xs20_0j5oz34b415a4
xs23_0gil5iz1221019la4
xs25_2llmgma4z34aa4
xs25_8u19u0uiz01254c
xs26_0354kmggoz39e0346
xs25_g8j1u8z11wju06a4
xs26_0ggmkl3z34ak81156
xs25_0ca5lmz6511d452
xs26_0oe1qcz643gv066
xs25_0ca1u0uicz2lp1
xs25_0caajk4oz6996221
xs30_0gill2z32w696o8a6zy1321
xs18_25a88cz624871
xs26_69r4kmicz4ab41
xs25_25b88ehe8zw35521
xs26_01784kl3z69d110252
xs24_25b88ba96zx6952
xs29_0db0bdz255d11d96
xs23_c88bp2sgz3pm
xs26_c88bb8oz330fhp
xs24_6a8c88brz253w32
xs28_okimgu156z66w6a4
xs26_ca9mkkoz33034a6
xs25_0178c871z69d553
xs26_25ic88gzwd5hv074
xs20_0c93z651132ak8
xs25_0gs2pmz1qq22ak8
xs26_cic0v1e8zx23035a4
xs27_0g8k453z2fgf0eik8
xs25_wca970sia4z3596
xs22_8kaic0si52zx343
xs30_0cc0sill2z65122qq1
xs22_08u1t6gz32x1cb
xs21_wmmge123z25ac
xs22_0gjl86246z3ego
xs27_0g8e1dagzc4lp13032
xs24_39c88ciiczw6953
xs21_2eg88c453zx11da
xs31_0ml1u0ooz641uh22ac
xs22_ck8xqd1e8zw11321
xs23_c9jzw1qq3qic
xs27_8o6pa4z2js1uic
xs24_08o6lliczcib41
xs25_09v0ckz321w2fgkc
xs30_2eg6p2sgzxdd0fgkc
xs25_0354kmggzckgf2w23
xs28_gilm0uiz1w12egnc
xs29_02llmz69aa43z03596
xs18_321j4k8z4a611
xs21_2ld2oczc93032
xs23_252sgzcis078a6
xs27_3lkmgm996z01w69c
xs24_caabp2sgzc871
xs26_6a8a53z699raa4
xs20_354m9jz4a521
xs22_69ra96z3ego
xs24_cimggs2qrzw4a4
xs19_xkc32qrzca1
xs23_628c88brz4a513
xs25_0gs29u0oozcc0f9
xs30_g88b9mggzdlhf03421
xs27_mm0u93zd861696
xs19_c9jzw1ht2sg
xs25_0gg0g08o652z345c5lo
xs25_08owiu0696zcib43
xs20_2560u5h248czy111
xs24_9f0s4ozw23cl96
xs24_9f0s2koz314b8o
xs25_0ggmmgm93z3ego1
xs24_0cq1eozoje0346
xs22_354mggzw32qi96
xs22_o8goge132acz066
xs29_wiu06996zo4q2qicz01
xs24_259q4o0oka6zx1243
xs24_358mkkm952zx66
xs23_gbb886178k8z123
xs26_0mlhe0eik8zpic
xs25_252s0ggzcid1eip
xs29_0gjlkmzraaqa9o
xs24_g4c88brz178jd
xs28_mlhe88gz12klldzw1
xs26_caabqicz358gz0321
xs22_32ak8gzxc8706ak8
xs21_0g8o652zqb88gzx121
xs22_xj9cz2ll5oz1221
xs26_xmllmzg0t6w346z11
xs24_0ok453zg2u079cz11
xs24_04a96zg6d11dicz11
xs20_3146o8gzy1230eio
xs23_08oxo4871zoif0321
xs23_2596o8gzx23032ako
xs24_xg0t3ob96zca521
xs24_259eg88gzx23034ako
xs33_35is0s4o0oozw6a87078c
xs23_069ab96zg8jdz11
xs27_4a9egm96zx1qa4zw321
xs31_g8o0uhmkk8z11y0622qic
xs29_651u0ok8zg85t066z121
xs22_ckgil96zg8426z11
xs25_wgill2zi5s2643z11
xs20_dbgzj5c48cz11
xs26_w6a8970si6z65156
xs29_0ggca52gz125431pl4ko
xs23_330fh8ozy1622ako
xs26_0c93s4ozml5521z11
xs32_69icwg4s0siczw8lld11
xs30_gs2qc0sie0e96zx343
xs24_x69a4z4a9d93z253
xs34_x6t1u8z0ggp9gf0e96z32
xs26_8k4owg8o653zw122qr
xs28_gwg6p2s0si6zdd11011
xs28_0ggxg88m952z34430fgp1
xs31_0c88b96zml5lmz2543
xs25_0gbdzw5t2sgz3543
xs29_6t1eoz08ll4kozx343
xs37_3lkmkkmggm96z34606226
xs23_356o8ge1fgkc
xs26_6t1u0oge132aczw1
xs25_y0ml96z3lk452z321
xs22_j9cz0h9l96z321
xs30_354pb88bp453zx23032
xs31_69b8bb8rj871zx33
xs24_j1u06akg8og4cz11
xs30_w6a88b96z0ca953z6513
xs29_c88b96z3ll2sgz643
xs21_mliczpi6z65
xp2_c8b8a4ozw9f03453
xp2_039q48gz158f0fho
xp2_04k1v0cczok45d
xp3_g84km9b8oz123cj871
xp2_31a08zy0harzoga02
xp6_0rrz4bl8gooo0oozx1
xq4_6frcxcrf6

[ohennel]

Actually not all objects that you listed are legitimate.
This is my algorithm to resolve objects is far from perfect and I list also some pseudo objects, especially periodic/moving.
E.g. in case of xq4_6frcxcrf6 algorithm found it 342 times and resolved each occurrence to a pair of LWSSs.
Thus "corr. = -342" and no line with count (meaning "corrected" count is 0).
I have plans to add option to omit such objects (pseudo-objects and object parts which corrected count is <= 0; negative values for a few tiny debris happens because algorithm is not perfect) in PDF, but it did not happen yet.