"Hashwar": A Battle Royale for individual GOL configurations

[hash0]

Now that Stage 1 of the Tournament is over and we have seen 16 Matches between 32 individual Conway Glyphs play out, it's time to do some statistics.

Mind you, my goal is to find out what makes a particular Glyph successful, i.e. achieves a high score according to the "Adversarial Conway" algorithm I devised. Currently, the characteristics we look at in a Glyph are "Iterative Count" (the number of Generations it lives) and "Peak Count" as a proxy for "active mass" of the generations.

I have formatted the 16 matches as three series of integers, showing the respective deltas in iteration, peak, and score:

DELTA ITERATIONS
[-65, -77, -180, +56, -45, +230, -12, -13, -41, +73, +7, -137, -42, -62, +21, +30]

DELTA PEAK
[-20, -1, +48, -44, -1, +51, -28, +15, -9, +22, +25, -6, +27, -4, -1, +7]

DELTA SCORE
[+654.934, +603.508, +1.608.383, +750.942, +885.980, +1.924.963, +104.673, +165.953, +206.651, +954.884, +781.891, +178.318, +740.547, +399.770, +616.602, +523.285]

Here is the correlation matrix for these three metrics for the entire data set:

■ PEARSON CORRELATION COEFFICIENTS (-1: perfect negative correlation, +1: perfect positive correlation, 0: no linear relationship), FULL DATA SET

Delta Iterations Delta Peak Delta Score
Delta Iterations 1.00 0.16 0.37
Delta Peak 0.16 1.00 0.68
Delta Score 0.37 0.68 1.00

KEY OBSERVATIONS

1. "Delta Peak & Delta Score" is the strongest link (r=0.68), i.e. the higher the peak count of a Glyph, the higher the chances for a win.

2. "Delta Iterations & Delta Score" (r=0.37) is only moderately positively correlated. No suprise there - we have seen far too many matches where the shorter running Glyph wins.

3. "Delta Iterations & Delta Peak" (r=0.16) is very weekly correlated. This is indeed good because it means that "Peak" is virtually independent from the number of generations a Glyph lives - so this metric does add information about a Glyph and shall be retained as a proxy for "active mass" for the time being.

CAVEAT

I noticed in the scatter graphs that these correlations might be skewed by outliers (note that, e.g. "Cobalt-60" had far higher iterative count of 805 and a delta of +230 over it's opponent "Matrix Cataract"), so excluding those gives us a more nuanced picture:

■ PEARSON CORRELATION COEFFICIENTS, OUTLIERS REMOVED (according to Interquartile Range method, i.e. $[Q1 - 1.5 \times IQR, Q3 + 1.5 \times IQR]$ were removed: Delta Iterations +230 and -180, Delta Score near 2 Million):

Delta Iterations Delta Peak Delta Score
Delta Iterations 1.00 0.07 0.43
Delta Peak 0.07 1.00 0.28
Delta Score 0.43 0.28 1.00

WHAT CHANGED WHEN DISCARDING OUTLIERS?

1. "Delta Peak & Delta Score" significantly weakens from 0.68 down to 0.28.

2. "Delta Iterations & Delta Score" increases a little from 0.37 to 0.43 which is now the single strongest indicator for the match score.

3. "Delta Iterations & Delta Peak" virtually disappears, weakening from 0.16 to 0.07.

KEY TAKE AWAYS

Ignoring outliers, "Delta Iterations" (the difference in generations two competing Conway Glyphs live) is the strongest indicator for combative performance, albeit only moderately so. "Delta Peak" seems to be a great indicator for "home run score", though, but it's clearly not a good indicator for average day-to-day matches.

FURTHER RESEARCH

The above analysis shows that the two statistical characteristics, ITERATIVE COUNT and PEAK COUNT, are of moderate and limited use for predicting performance under the "Adversarial Conway" algorithm, respectively.

The question what makes a particular Conway Glyph more successful than another is still largely open. I am thinking about gathering detailled profiles during match runtimes for both contending Glyphs, e.g. in the form of tracking the number of their "live cells" as a function of time (iterations/generations) and compare them to see if this might yield a better indicator for performance.

[hash0]

559 gens:

Code: Select all

x = 16, y = 16, rule = B3/S23:T16,16
3obo2bo2b2o2bo$5bo2b2obo3bo$2bo2bo3b2o4bo$o2b3obo2b6o$obo2bobob3obobo
$2bob2o2bobo2b2o$2bobobobobo2b3o$2bob2o2b5o$3b3o2b7o$2bo2bob2o$o4b2o4b
2obo$o3b5obo2bo$4o4bob3ob2o$o4b3ob2ob2obo$5bobobo3bo$bo3bobo2b2obobo!

This is "Toroidal Pie".
Add RLE support, please.

I have now added RLE support in addition to the binary input string:
https://lifehashes.net/Y176/

Please note that:

• you can only enter patterns into the engine that fit into the 16x16 torus, so the resulting binary string has to have length 256 exactly!

• only put in the RLE string, not the preamble "x = 16, y = 16, rule = B3/S23:T16,16"

[hash0]

I have just published a video where I explain the "Peak" metric I introduced for the "Conway Glyphs":
https://youtu.be/-JNMRHTx66Y

[hash0]

Ladies and Gentlemen,

I'd like to announce my next HASHWAR tournament - and you are invited to field your own Conway Glyphs! 16 contestants will compete against each other in a bracket tournament until we have determined the ultimate winner.

Your patterns should adhere to B3/S23 rules on the 16x16 torus, and I recommend at least 400 to 500 non-repeating generations for your Glyph to be competitive.

Note that 4 of the 16 slots are already filled, so start mining for patterns! First come, first serve!

[hash0]

After careful statistical analysis ("I looked at some numbers"), I have decided to tweak the "Adversarial Conway" algorithm. Here is the new calculation method for two competing Glyphs:

https://lifehashes.net/Y176/

Try it yourself! Put in two GOL patterns that fit on the 16x16 torus and let them compete in the Arena - my tool accepts both binary strings and RLE notation.

[hash0]

Working on the global registry for Conway Glyphs that can be deployed in a tournament:
https://lifehashes.net/Y176/catalog.php ... C&limit=24

[hash0]

Or this variant of Ignis Draconis that differs by 1 cell?

Code: Select all

x = 16, y = 16, rule = B3/S23:T16,16
4obob2o2b2obo$o3b4ob2o2b2o$3o3bo4b2ob2o$b5obo4b3o$3bob2o2bo4b2o$3bo3b
2obobobo$obobo2b2o3bobo$3obo6bo$2o2bo4bo2bo$3ob5ob3o$o2b2o3b3o$bo3bo2b
o2b2o$2o2bob2o2bobo$b3o5b4obo$o2bo2bo2b2ob3o$2o2bo2b2ob5o!

Would such variants also count as 'doppelgängers'?

I have since come up with a solution to this problem. My project will offer two tiers of Glyph registration:

• Basic Registry only checks the hash value of the starting configurations to prevent duplicate entries.

• Advanced registration ("the Glyph chain") will employ an advanced duplicate check that covers all rotational and translational variants of a Glyph as well as "off-by-one" variants that evolve in the same way.

(Here is where hashing of all generations comes in handy as this allows me to trace evoluationary paths.)

[I6_I6]

I have since come up with a solution to this problem. My project will offer two tiers of Glyph registration:

• Basic Registry only checks the hash value of the starting configurations to prevent duplicate entries.

• Advanced registration ("the Glyph chain") will employ an advanced duplicate check that covers all rotational and translational variants of a Glyph as well as "off-by-one" variants that evolve in the same way.

(Here is where hashing of all generations comes in handy as this allows me to trace evoluationary paths.)

Where's the limit? For two Glyphs that eventually converge, how many generations must they be different for in order for them to be considered different? Do you check every generation until stabilization?
By the way, I don't think it'd be too hard to write a script that produces a parent for a given Glyph. You could theoretically keep going backwards since the search space is limited to 16x16, until you meet a dead end and the Glyph is a Garden of Eden (in which case you could backtrack and keep going from a different node). I haven't tried anything like this though, so I don't know how long this sort of thing takes. (Obviously it'd take ages to find the optimal predecessor, but just a few generations backward would give the Glyph an advantage.)

[hash0]

Very good questions!

I envision my scheme to prevent "one-off exploits" (like the one you demonstrated where you changed one cell so that the origin hash was different but every single subsequent generation was identical to "Ignis Draconis"). Hence, I'd exlude any pattern where the very first generation AFTER The origin is already identical to an existing pattern.

This would, in turn, allow people to claim and register patterns that EVENTUALLY converge to the evolutionary path of a known pattern, but it would prevent above mentioned exploits.

[NNlk05]

Some patterns found by GPU search

Code: Select all

x = 16, y = 16, rule = B3/S23:T16,16
b2o2b2o6b2o$o3b4obo5bo$b3o2bo4b4o$2bobo2b2o3bo$3ob2ob4o4bo$2bob2o2bob
2o$4o2bo5b4o$o2bob5o4bo$2bo2b3o6b2o$3b3obob3obobo$2b3ob3o2bo$3obo2b2o
2bobo$b4obob8o$3b3ob2o$3ob2obobo$ob5obo2b4o!

Stabilises in Tick 1061

Code: Select all

x = 16, y = 16, rule = B3/S23
2bo2bo2b4o3bo$6b5ob2o$ob2ob3obo2b3o$ob3o2b2obo2bo$2bobo2bo6bo$2o2bo2b
3o$4o3bob2o3bo$2bo3b3o2b2o2bo$4ob2o3bobo2bo$2obob3o2b4obo$ob2o3bo2b5o
$b3o3b6obo$b5ob3ob2o2bo$o6b2o2bobobo$2bob6o2bo2bo$ob2o2bo4bob3o!

1100

Code: Select all

x = 16, y = 16, rule = B3/S23:T16,16
bo2b4obobobobo$b3o3b5o$obobob2o2b2obobo$obo2bobob2o$bobo3b2o2b2o2bo$o
2bobo2b7o$2o2b2o2bob2o$o3b2ob3ob2o$bobo2b3obob2o$obobo5b2ob2o$obo2b3o
2bob4o$2ob2obo2b3o$o2b2o4bobobo$b3o2b2ob2o2bobo$2b2o2b3o2bobobo$b2o3b
obobobo!

1076

Code: Select all

x = 16, y = 16, rule = B3/S23:T16,16
b3ob2ob4o$2ob2o2bobobo2b2o$3o2b5o4bo$3o3b3obo$2obo3bo3bo2b2o$obob3obo
bo2bo$bo2b2obo3bo$b2o6b2obo$8ob2obo2bo$ob2ob3obo2b4o$o2bob2obo3b2o$4o
bo5bo$b3obobobo4b2o$ob2ob2ob2o2b3o$2b2o4bobobo$o2b2ob2o3b2o!

New record holder, in T1283

[hash0]

Oh my!! You just shattered a record that has been standing since June 2024, good Sir! "Ignis Draconis" is finally slain! :O

I hereby confirm your pattern with Origin Hash 61d4c29de6fcda4fb101aaafc15be38c382eaec001771015e0340937a160c188 to run for 1,285 generations (my own engine calculates differently, I have yet to look into this and fix it to make it congruent with how Golly counts generations), surpassing the previous record holder of 1,273 generations.

Would you like your new pattern(s) to be registered in my catalog, full credit given to your name?
https://lifehashes.net/Y176/catalog.php ... C&limit=24

Also, if that is alright with you, I would like to announce your discovery on my x.com channel, again with full credit to your name:
https://x.com/lifehashes

[NNlk05]

Oh my!! You just shattered a record that has been standing since June 2024, good Sir! "Ignis Draconis" is finally slain! :O

I hereby confirm your pattern with Origin Hash 61d4c29de6fcda4fb101aaafc15be38c382eaec001771015e0340937a160c188 to run for 1,285 generations (my own engine calculates differently, I have yet to look into this and fix it to make it congruent with how Golly counts generations), surpassing the previous record holder of 1,273 generations.

Would you like your new pattern(s) to be registered in my catalog, full credit given to your name?
https://lifehashes.net/Y176/catalog.php ... C&limit=24

Also, if that is alright with you, I would like to announce your discovery on my x.com channel, again with full credit to your name:
https://x.com/lifehashes

Yes
I will publish my code below

Code: Select all

#include <cuda_runtime.h>
#include <iostream>
#include <vector>
#include <iomanip>

#define CHECK_CUDA(call) { \
    cudaError_t err = call; \
    if (err != cudaSuccess) { \
        fprintf(stderr, "CUDA Error: %s at line %d\n", cudaGetErrorString(err), __LINE__); \
        exit(1); \
    } \
}

struct Grid16 {
    uint64_t data[4]; 
};

__device__ __forceinline__ int get_cell(const Grid16& g, int r, int c) {
    int bit = ((r & 15) << 4) | (c & 15);
    return (g.data[bit >> 6] >> (bit & 63)) & 1;
}

__device__ __forceinline__ void set_cell(Grid16& g, int r, int c) {
    int bit = ((r & 15) << 4) | (c & 15);
    g.data[bit >> 6] |= (1ULL << (bit & 63));
}

__device__ Grid16 step16(Grid16 g) {
    Grid16 next = {0, 0, 0, 0};
    for (int r = 0; r < 16; ++r) {
        for (int c = 0; c < 16; ++c) {
            int n = 0;
            for (int dr = -1; dr <= 1; ++dr) {
                for (int dc = -1; dc <= 1; ++dc) {
                    if (dr == 0 && dc == 0) continue;
                    n += get_cell(g, r + dr, c + dc);
                }
            }
            int s = get_cell(g, r, c);
            if (n == 3 || (s && n == 2)) set_cell(next, r, c);
        }
    }
    return next;
}

__device__ bool is_equal(const Grid16& a, const Grid16& b) {
    return a.data[0] == b.data[0] && a.data[1] == b.data[1] && 
           a.data[2] == b.data[2] && a.data[3] == b.data[3];
}

__global__ void search_long_lived(uint64_t seed_base, uint32_t* results_found, Grid16* final_grids) {
    uint32_t tid = blockIdx.x * blockDim.x + threadIdx.x;
    uint64_t m = 0x9e3779b97f4a7c15ULL; 
    
    Grid16 initial;
    uint64_t s = (seed_base ^ tid) * m;
    initial.data[0] = s;
    initial.data[1] = (s ^ (s >> 17)) * m;
    initial.data[2] = (initial.data[1] ^ (initial.data[1] >> 13)) * m;
    initial.data[3] = (initial.data[2] ^ (initial.data[2] >> 19)) * m;
    
    Grid16 curr = initial;
    Grid16 teleport = initial;
    int power = 1;
    int lam = 1;

    for (int g = 1; g <= 4000; ++g) {
        curr = step16(curr);
        
        if (curr.data[0] == 0 && curr.data[1] == 0 && curr.data[2] == 0 && curr.data[3] == 0) return;

        if (is_equal(teleport, curr)) {
            if (g > 1200) {
                uint32_t idx = atomicAdd(results_found, 1);
                if (idx < 100) final_grids[idx] = initial;
            }
            return;
        }

        if (power == lam) {
            teleport = curr;
            power *= 2;
            lam = 0;
        }
        lam++;
    }
}

int main() {
    const int max_results = 100;
    uint32_t *d_found;
    Grid16 *d_grids;
    CHECK_CUDA(cudaMalloc(&d_found, sizeof(uint32_t)));
    CHECK_CUDA(cudaMalloc(&d_grids, max_results * sizeof(Grid16)));
    CHECK_CUDA(cudaMemset(d_found, 0, sizeof(uint32_t)));

    const int threads_per_block = 128;
    const int blocks_per_grid = 1024;
    const uint64_t golden_ratio_64 = 0x9e3779b97f4a7c15ULL;

    std::cout << "Searching" << std::endl;

    uint32_t last_found = 0;
    for(int i = 0; i < 20000; ++i) {
        search_long_lived<<<blocks_per_grid, threads_per_block>>>(i * golden_ratio_64, d_found, d_grids);
        CHECK_CUDA(cudaDeviceSynchronize());
        
        uint32_t current_total;
        CHECK_CUDA(cudaMemcpy(&current_total, d_found, sizeof(uint32_t), cudaMemcpyDeviceToHost));
        
        if (current_total > last_found) {
            uint32_t num_new = (current_total > max_results ? max_results : current_total) - last_found;
            if (num_new > 0) {
                std::vector<Grid16> new_patterns(num_new);
                CHECK_CUDA(cudaMemcpy(new_patterns.data(), d_grids + last_found, num_new * sizeof(Grid16), cudaMemcpyDeviceToHost));
                
                std::cout << "\r" << std::string(50, ' ') << "\r"; // Clear progress line
                for (const auto& grid : new_patterns) {
                    std::cout << "0x" << std::hex << std::setfill('0') 
                              << std::setw(16) << grid.data[3]
                              << std::setw(16) << grid.data[2]
                              << std::setw(16) << grid.data[1]
                              << std::setw(16) << grid.data[0] << std::dec << std::endl;
                }
                last_found += num_new;
            }
        }
        
        if (last_found >= max_results) break;

        if (i % 10 == 0) {
            std::cout << "\rSearched " << (uint64_t)(i+1) * blocks_per_grid * threads_per_block 
                      << " patterns... Found: " << last_found << std::flush;
        }
    }

    std::cout << "\nSearch complete. Total found: " << last_found << std::endl;
    cudaFree(d_found);
    cudaFree(d_grids);
    return 0;
}

[hash0]

Splendid!

Would you be willing to submit these four magnificent patterns into my next Hashwar tournament?

Also: You do realize that this means that - as we speak - my seeker and explorer nodes are running white hot to find a longer-lived pattern!

[hash0]

Your discovery has now been announced:
https://x.com/lifehashes/status/2032187 ... 01049?s=20

The new record holder, "Indicum" is now registered:
https://lifehashes.net/Y176/catalog.php ... C&limit=24

[hash0]

Here is an overview of the longevity of Conway Glyphs - currently, I have roughly 275,000 such patterns in my list.
This shows how many Glyphs of a given non-repeating, non-static generation count are known:

SUBLIME CLASS

1,200+ 4 (Indicum, Ignis Draconis, Lost Monarch, Copper Solstice)
1,100 - 1,199 6
1,000 - 1,099 9

SUPREME CLASS

900 - 999 16
800 - 899 44

SUPERB CLASS (HIGHER RANGE)

700 - 799 150
600 - 699 420

SPLENDID CLASS (MIDDLE RANGE)

500 - 599 1,324
400 - 499 3,359 (1%)

LOWER RANGE

300 - 399 9,209 (3%)
200 - 299 24,784 (9%)
100 - 199 63,302 (23%)

0 - 99 174,932 (63%)

I am wondering if there are Glyphs in the "TRANSCENDENT CLASS", i.e. those with generation count of 1,300+

[hash0]

This is Hypatia's Lament, the new record holder - and the first Glyph of the hypothesized Transcendent category:
1001111111111110010111000101000110111101100101000011111101010000110101100010100001011001011010100000010100100011001011001001101101111000011101010110110010100110110011000000110111101110010111110101100011001001001100100111101010111000010011011111100101001100

1,388 non-repeating steps

I used a CPU-parallelized node.js code to find it.

[hash0]

Update:

0101001010111100010001011101100001100011011100100011001110111011001100100100111111100111011110110011010111010111001100101111010011000001100011111001111100010000110111000101000110011100001010100010101011111100011011011101000101001000010111101100001010011101

This pattern ("The Algebra of Hapiness", found after testing more than 8 million configurations) runs for 1,822 non-repeating generations on the 16x16 torus, which incidentally shatters the hypothesis that the number of generations is bound by roughly "five times the available space". Were this true, the upper limit should be 5x256 = 1,280 generations.

[hash0]

These two utterly shatter my current understanding of Conway Glyphs:

Tännhauser Gate, 5,172 generations, found after 25 mio. attempts:
1110110010000101011001000101111000101111001011001101110111010001110010010110100100110111010111000010100010010101111111100010101000110101101100100010100001000000010010100101001011011100110001100110111010111110001111001011111110011100011010000011010011010111

Monstrous Moonshine, 5,117 generations, found after 33 mio. attempts:
1110110111111101101001001010011001100101011001110110011101101011100011011001100110101111101000110110001000010110101101010001001001010000110001101100000001000000110110100111100011001000011001110011001000101011110111011011111111010001101000001110010000110100

What is the upper bound for generative count? How far does the "Conway Deep Field" reach? Is it possible to find patterns that run for 10,000 generations? 100,000??

[LuveelVoom]

These two utterly shatter my current understanding of Conway Glyphs:

Tännhauser Gate, 5,172 generations, found after 25 mio. attempts:
1110110010000101011001000101111000101111001011001101110111010001110010010110100100110111010111000010100010010101111111100010101000110101101100100010100001000000010010100101001011011100110001100110111010111110001111001011111110011100011010000011010011010111

Monstrous Moonshine, 5,117 generations, found after 33 mio. attempts:
1110110111111101101001001010011001100101011001110110011101101011100011011001100110101111101000110110001000010110101101010001001001010000110001101100000001000000110110100111100011001000011001110011001000101011110111011011111111010001101000001110010000110100

What is the upper bound for generative count? How far does the "Conway Deep Field" reach? Is it possible to find patterns that run for 10,000 generations? 100,000??

It would be greatly appreciated if you used pattern tags:

Code: Select all

x= 0, y = 0, rule = B3/S23:T16,16
oo.$
.oo$
.o.$

As it stands, it's incredibly difficult to simulate any of your patterns because the formats you provide them in aren't supported by current programs.

[PK22]

These two utterly shatter my current understanding of Conway Glyphs:

Tännhauser Gate, 5,172 generations, found after 25 mio. attempts:
1110110010000101011001000101111000101111001011001101110111010001110010010110100100110111010111000010100010010101111111100010101000110101101100100010100001000000010010100101001011011100110001100110111010111110001111001011111110011100011010000011010011010111

Monstrous Moonshine, 5,117 generations, found after 33 mio. attempts:
1110110111111101101001001010011001100101011001110110011101101011100011011001100110101111101000110110001000010110101101010001001001010000110001101100000001000000110110100111100011001000011001110011001000101011110111011011111111010001101000001110010000110100

What is the upper bound for generative count? How far does the "Conway Deep Field" reach? Is it possible to find patterns that run for 10,000 generations? 100,000??

It would be greatly appreciated if you used pattern tags:

Code: Select all

x= 0, y = 0, rule = B3/S23:T16,16
oo.$
.oo$
.o.$

As it stands, it's incredibly difficult to simulate any of your patterns because the formats you provide them in aren't supported by current programs.

Converted to RLE format:
"Tännhauser Gate" evolves into a p5024 agar, which I think is almost certainly new!

Code: Select all

x = 16, y = 16, rule = B3/S23:T16,16
3ob2o2bo4bobo$b2o2bo3bob4o$2bob4o2bob2o$2ob3ob3obo3bo$2o2bo2bob2obo2bo
$2b2ob3obob3o$2bobo3bo2bobobo$7o3bobobo$2b2obob2ob2o2bo$2bobo4bo$bo2bo
bo2bobo2bo$2ob3o2b2o3b2o$b2ob3obob5o$2b4o2bob6o$o2b3o3b2obo$2b2obo2b2o
bob3o!

"Monstrous Moonshine" evolves into the same agar:

Code: Select all

x = 16, y = 16, rule = B3/S23:T16,16
3ob2ob7obo$obo2bo2bobo2b2o$b2o2bobob2o2b3o$b2o2b3ob2obob2o$o3b2ob2o2b
2o2bo$obob5obo3b2o$b2o3bo4bob2o$ob2obobo3bo2bo$bobo4b2o3b2o$2o7bo$2ob
2obo2b4o$2o2bo4b2o2b3o$2b2o2bo3bobob2o$2ob3ob2ob6o$2obo3b2obo$3o2bo4b
2obo!

Here's the resulting agar. It shifts by (7, 7) every 314 generations, for a total period of 16*314 = 5024.

Code: Select all

x = 64, y = 64, rule = B3/S23:T64,64
10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo
3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o
5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo13bobo$7bo15b
o15bo15bo$10bo15bo15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo12bo2bo12bo2b
o12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b2o14b2o14b2o$10bo2bo12bo2bo12bo
2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo3bobo9bo3bobo9bo3bo
bo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o
5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo13bobo$7bo15bo15bo15bo$10bo15bo
15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo12bo2bo12bo2bo12bo2bo$8b3o13b3o
13b3o13b3o5$11b2o14b2o14b2o14b2o$10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo
3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo
2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b
o$6bobo13bobo13bobo13bobo$7bo15bo15bo15bo$10bo15bo15bo15bo$9bobo13bobo
13bobo13bobo$8bo2bo12bo2bo12bo2bo12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b
2o14b2o14b2o$10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b
2o8bobo$bo9bo3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo
2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo
13bobo$7bo15bo15bo15bo$10bo15bo15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo
12bo2bo12bo2bo12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b2o14b2o14b2o!

[hash0]

It would be greatly appreciated if you used pattern tags:

Code: Select all

x= 0, y = 0, rule = B3/S23:T16,16
oo.$
.oo$
.o.$

As it stands, it's incredibly difficult to simulate any of your patterns because the formats you provide them in aren't supported by current programs.

Noted! I will update my own engine's code so that it freely converts between binary and RLE.

[hash0]

Here's the resulting agar. It shifts by (7, 7) every 314 generations, for a total period of 16*314 = 5024.

Code: Select all

x = 64, y = 64, rule = B3/S23:T64,64
10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo
3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o
5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo13bobo$7bo15b
o15bo15bo$10bo15bo15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo12bo2bo12bo2b
o12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b2o14b2o14b2o$10bo2bo12bo2bo12bo
2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo3bobo9bo3bobo9bo3bo
bo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o
5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo13bobo$7bo15bo15bo15bo$10bo15bo
15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo12bo2bo12bo2bo12bo2bo$8b3o13b3o
13b3o13b3o5$11b2o14b2o14b2o14b2o$10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo
3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo
2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b
o$6bobo13bobo13bobo13bobo$7bo15bo15bo15bo$10bo15bo15bo15bo$9bobo13bobo
13bobo13bobo$8bo2bo12bo2bo12bo2bo12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b
2o14b2o14b2o$10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b
2o8bobo$bo9bo3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo
2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo
13bobo$7bo15bo15bo15bo$10bo15bo15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo
12bo2bo12bo2bo12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b2o14b2o14b2o!

The concept of agars was entirely new to me, so I learned something new already. It makes total sense as I thought while looking at the evolution of "Tännhauser Gate" that it seems to be repeating a pattern that shifts across the plane.

Also, while my newer, faster "Glyph hunter" program looks for patterns, it updates a "histogram" of patterns found and their respective generational count, like this:

Total Attempts: 27.682.000terns/sec
Current Rate: 36.072 patterns/sec
Elapsed Time: 767s
Generational Distribution:
0-99 : 12.920.334
100-199 : 9.081.797
200-299 : 3.568.748
300-399 : 1.325.966
400-499 : 493.938
500-599 : 192.056
600-699 : 67.638
700-799 : 21.563
800-899 : 6.976
900-999 : 2.033
1000-1099 : 619
1100-1199 : 195
1200-1299 : 77
1300-1399 : 44
1400-1499 : 12
1500-1599 : 4
1600-1699 : 0
1700-1799 : 0
1800-1899 : 0
1900-1999 : 0
2000+ : 0

I was beginning to wonder why I did not see any patterns in the range of 2000 - 5000 generations but almost instantly found two patterns with more than 5000. This periodicity of the agar explains it, but it also raises further questions:

How many cycles can an agar evolve on the torus? Is there an upper limit to the periods or can we find agars that repeat arbitrarily many times? And why did I not find agars with a lower repeat time (no patterns in the 2000 - 5000 range)?

I am wondering if we'll have to look at something like "the number of times the agar cycle repeats itself while shifted must be a co-prime of the grid-size so that the pattern does NOT perfectly align with a previous version of itself"...

[I6_I6]

Here's the resulting agar. It shifts by (7, 7) every 314 generations, for a total period of 16*314 = 5024.

Code: Select all

x = 64, y = 64, rule = B3/S23:T64,64
10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo
3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o
5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo13bobo$7bo15b
o15bo15bo$10bo15bo15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo12bo2bo12bo2b
o12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b2o14b2o14b2o$10bo2bo12bo2bo12bo
2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo3bobo9bo3bobo9bo3bo
bo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o
5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo13bobo$7bo15bo15bo15bo$10bo15bo
15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo12bo2bo12bo2bo12bo2bo$8b3o13b3o
13b3o13b3o5$11b2o14b2o14b2o14b2o$10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo
3b2o8bobo3b2o8bobo3b2o8bobo$bo9bo3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo
2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5b
o$6bobo13bobo13bobo13bobo$7bo15bo15bo15bo$10bo15bo15bo15bo$9bobo13bobo
13bobo13bobo$8bo2bo12bo2bo12bo2bo12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b
2o14b2o14b2o$10bo2bo12bo2bo12bo2bo12bo2bo$2o8bobo3b2o8bobo3b2o8bobo3b
2o8bobo$bo9bo3bobo9bo3bobo9bo3bobo9bo3bo$bo5b2o5bo2bo5b2o5bo2bo5b2o5bo
2bo5b2o5bo$o5bo2bo5b2o5bo2bo5b2o5bo2bo5b2o5bo2bo5bo$6bobo13bobo13bobo
13bobo$7bo15bo15bo15bo$10bo15bo15bo15bo$9bobo13bobo13bobo13bobo$8bo2bo
12bo2bo12bo2bo12bo2bo$8b3o13b3o13b3o13b3o5$11b2o14b2o14b2o14b2o!

The concept of agars was entirely new to me, so I learned something new already. It makes total sense as I thought while looking at the evolution of "Tännhauser Gate" that it seems to be repeating a pattern that shifts across the plane.

Also, while my newer, faster "Glyph hunter" program looks for patterns, it updates a "histogram" of patterns found and their respective generational count, like this:

[...]

I was beginning to wonder why I did not see any patterns in the range of 2000 - 5000 generations but almost instantly found two patterns with more than 5000. This periodicity of the agar explains it, but it also raises further questions:

How many cycles can an agar evolve on the torus? Is there an upper limit to the periods or can we find agars that repeat arbitrarily many times? And why did I not find agars with a lower repeat time (no patterns in the 2000 - 5000 range)?

I am wondering if we'll have to look at something like "the number of times the agar cycle repeats itself while shifted must be a co-prime of the grid-size so that the pattern does NOT perfectly align with a previous version of itself"...

The agar evolves from this:

Code: Select all

x = 12, y = 12, rule = B3/S23:T16,16
10bo$9bobo$10bo4$6b3o$6bo2bo$6bo2bo$bo5b2o$obo$bo!

It's a teardrop hitting 2 tubs (or any other SL that has that duoplet edge). Throughout the evolution of the agar, you can see recognizable objects and active regions. In some phases, it's 2 wings hitting 2 loaves; in others, it's just U-turners; sometimes, it's U-turners+TLs, a teardrop+2 blinkers, wings+beehives, or TLs+Bs. Basically, there are a ton of natural predecessors for this thing, so you could expect it to appear in more Glyphs.

Maybe it would be better to not count the extra full cycle of the Glyph after it stabilizes, since otherwise very high-period patterns like these can last incredibly long; much longer than other Glyphs, at least. It would prevent high-period Glyphs from gaining an unfair advantage.

(Note: Isn't this basically apgsearching toroidal soups, while only checking lifespan?)

[hash0]

It's a teardrop hitting 2 tubs (or any other SL that has that duoplet edge). Throughout the evolution of the agar, you can see recognizable objects and active regions. In some phases, it's 2 wings hitting 2 loaves; in others, it's just U-turners; sometimes, it's U-turners+TLs, a teardrop+2 blinkers, wings+beehives, or TLs+Bs. Basically, there are a ton of natural predecessors for this thing, so you could expect it to appear in more Glyphs.

Thank you for the explanation! Yes, these patterns are quite "common": I found five more (among 100 million attemps) with lifespans above 5,000 that all exhibit the same Agar-behaviour with periodicity of 5,024.

Maybe it would be better to not count the extra full cycle of the Glyph after it stabilizes, since otherwise very high-period patterns like these can last incredibly long; much longer than other Glyphs, at least. It would prevent high-period Glyphs from gaining an unfair advantage.

Agreed! At the very least I should implement logic that categorizes those patterns and separates them into their own "bin" to exclude them from the "regular" patterns. Or let Agar-class Glyphs fight amongst themselves which could be interesting in its own right.

(Note: Isn't this basically apgsearching toroidal soups, while only checking lifespan?)

Correct! My lifehashes / HASHWAR project is exclusively concerning itself with the 16x16 torus and B3/S23 ruleset, where their lifespan is one of the important parameters. The "gimmick" of my approach is to also calculate SHA256 hash values of configurations to further subdivide this class of GOLs and then let them compete within their respective class.

[hash0]

If anyone wants to try this on their own machine, here is the new, optimized code I used for finding these ultra-long lived patterns (both in the "regular" category with 1800+, and the "Agar-class" patterns with 5000+ generations) - use node.js to run it in your CLI:

Code: Select all

"use strict";

const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');
const os = require('os');
const readline = require('readline');
const fs = require('fs');

// --- Argument Handling ---
// Usage: node glyph_hunter3.js [MIN_GENS_TO_STOP] [SAVE_THRESHOLD]
const args = process.argv.slice(2);
const MIN_GENS_TO_STOP = parseInt(args[0]) || 2000; 
const SAVE_THRESHOLD = parseInt(args[1]) || 1300;   

const LOG_FILE = 'found_patterns.txt';
const NUM_CORES = os.cpus().length;
const UPDATE_INTERVAL_MS = 1000;

if (isMainThread) {
    let totalChecked = 0;
    // We increase bin size dynamically based on the target
    // const numBins = Math.ceil(MIN_GENS_TO_STOP / 100) + 1;
    const numBins = Math.ceil(2000 / 100) + 1;
    const bins = new Array(numBins).fill(0); 
    const startTime = Date.now();

    fs.writeFileSync(LOG_FILE, `--- Glyph Hunter Log Started: ${new Date().toISOString()} ---\n`);

    console.log(`\x1b[2J\x1b[H`); 
    console.log(`--- [ Glyph Hunter: High-Intensity Mode ] ---`);
    console.log(`Target: ${MIN_GENS_TO_STOP}+ | Saving any > ${SAVE_THRESHOLD} to ${LOG_FILE}\n`);

    const updateDashboard = () => {
        readline.cursorTo(process.stdout, 0, 5);
        const elapsed = (Date.now() - startTime) / 1000;
        const rate = Math.floor(totalChecked / elapsed);
        
        console.log(`Total Attempts: ${totalChecked.toLocaleString()}`);
        console.log(`Current Rate:   ${rate.toLocaleString()} patterns/sec`);
        console.log(`Elapsed Time:   ${Math.floor(elapsed)}s\n`);
        
        bins.forEach((count, i) => {
            const rangeStart = i * 100;
            const isLast = i === bins.length - 1;
            const range = isLast ? `${rangeStart}+` : `${rangeStart}-${rangeStart + 99}`;
            
            // Scaled bar logic
            const barWidth = totalChecked > 0 ? Math.min((count / totalChecked) * 500, 40) : 0;
            // const bar = "█".repeat(Math.floor(barWidth)); 
            const bar = "";
            console.log(`${range.padStart(12)} : ${count.toLocaleString().padEnd(10)} ${bar}`);
        });
    };

    setInterval(updateDashboard, UPDATE_INTERVAL_MS);

    for (let i = 0; i < NUM_CORES; i++) {
        // Pass the dynamic values into the worker via workerData
        const worker = new Worker(__filename, { 
            workerData: { 
                minGens: MIN_GENS_TO_STOP, 
                saveThreshold: SAVE_THRESHOLD,
                numBins: numBins
            } 
        });

        worker.on('message', (msg) => {
            if (msg.type === 'stats') {
                totalChecked += msg.count;
                msg.localBins.forEach((val, idx) => { if(bins[idx] !== undefined) bins[idx] += val; });
            } else if (msg.type === 'save') {
                fs.appendFileSync(LOG_FILE, `Gens: ${msg.gens} | Config: ${msg.bitstring}\n`);
            } else if (msg.type === 'success') {
                fs.appendFileSync(LOG_FILE, `FINAL MATCH | Gens: ${msg.gens} | Config: ${msg.bitstring}\n`);
                updateDashboard();
                console.log(`\n\x1b[32m[TERMINAL MATCH FOUND]\x1b[0m`);
                console.log(`Generations: ${msg.gens}`);
                process.exit(0);
            }
        });
    }
} else {
    // Workers receive these values from the main thread
    const { minGens, saveThreshold, numBins } = workerData;
    let localChecked = 0;
    let localBins = new Array(numBins).fill(0);

    while (true) {
        let grid = new Uint16Array(16);
        for (let r = 0; r < 16; r++) grid[r] = Math.floor(Math.random() * 0x10000);
        const initialGrid = new Uint16Array(grid);
        const history = new Set();
        let gens = 0;

        while (true) {
            let stateKey = "";
            for (let r = 0; r < 16; r++) stateKey += grid[r].toString(16).padStart(4, '0');

            if (history.has(stateKey)) break;
            history.add(stateKey);

            grid = evolve(grid);
            gens++;
            // Safety break moved higher to accommodate larger search targets
            if (gens > 10000) break; 
        }

        localChecked++;
        const binIdx = Math.min(Math.floor(gens / 100), numBins - 1);
        localBins[binIdx]++;

        if (gens >= saveThreshold && gens < minGens) {
            parentPort.postMessage({
                type: 'save',
                gens: gens,
                bitstring: toBitString(initialGrid)
            });
        }

        if (gens >= minGens) {
            parentPort.postMessage({
                type: 'success',
                gens: gens,
                bitstring: toBitString(initialGrid)
            });
        }

        if (localChecked % 500 === 0) {
            parentPort.postMessage({ type: 'stats', count: 500, localBins: localBins });
            localBins.fill(0);
        }
    }
}

function toBitString(grid) {
    let s = "";
    for (let y = 0; y < 16; y++) {
        for (let x = 0; x < 16; x++) {
            s += (grid[y] >> x) & 1 ? "1" : "0";
        }
    }
    return s;
}

function evolve(grid) {
    const next = new Uint16Array(16);
    for (let y = 0; y < 16; y++) {
        const u = (y + 15) & 15;
        const d = (y + 1) & 15;
        for (let x = 0; x < 16; x++) {
            const l = (x + 15) & 15;
            const r = (x + 1) & 15;
            const n = ((grid[u] >> l) & 1) + ((grid[u] >> x) & 1) + ((grid[u] >> r) & 1) +
                      ((grid[y] >> l) & 1) +                        ((grid[y] >> r) & 1) +
                      ((grid[d] >> l) & 1) + ((grid[d] >> x) & 1) + ((grid[d] >> r) & 1);
            if (n === 3 || (n === 2 && (grid[y] >> x) & 1)) next[y] |= (1 << x);
        }
    }
    return next;
}

The "trick" of this code is two-fold: Firstly, it uses WebWorkers, so it can make use of all available logical CPU-cores in parallel and secondly, it uses bitstring-manipulation instead of storing patterns in nested arrays. The increase in computational speed is in the order of 1,000 to 10,000 when compared to my previous javascript code that I ran in a web browser (and that also output every step to the GUI).

Full disclosure: The code is 100% AI-generated (Google Gemini), based on my own (inefficient) code.