apgsearch v4.0

[dvgrn]

Please immediately update to v4.62 -- it fixes a problem causing GoL objects to appear in other lifelike rules.

i left mine running at home...

Which version was the GoL-object-spewing bug introduced in? Is it something recent, since v4.52-ll1.62 let's say, or has it been around a while?

[calcyman]

Please immediately update to v4.62 -- it fixes a problem causing GoL objects to appear in other lifelike rules.

i left mine running at home...

Which version was the GoL-object-spewing bug introduced in? Is it something recent, since v4.52-ll1.62 let's say, or has it been around a while?

Very recent: the bug was introduced in v4.58-ll2.0.15 and repaired in v4.62-ll2.0.16.

[calcyman]

In terms of further rule families, the next one I intend to implement is outer-totalistic rules up to range 5.

Higher-range outer-totalistic (HROT) rules are implemented as of v4.63 (in apgsearch) and ll2.0.17 (in lifelib).

The syntax is rXbXXX...XsXXX...X[z]

where the range can be either 2, 3, 4, or 5, and the 'b' and 's' must each be followed by exactly r(r+1) hexadecimal characters. For instance, the LtL rule r2b4t4s10t19 has the outer-totalistic rulestring r2b000008s03ff00, where:

• 000008 = 0000 0000 0000 0000 0000 1000 because we have birth only on 4 neighbours, and the 4th-from-last bit is 1 (the others are 0).
• 03ff00 = 0000 0011 1111 1111 0000 0000 because we have survival from 9 to 18 neighbours, and those bits are 1.

IMPORTANT: the middle cell is included in LtL (for consistency with Kellie Evans' original notation), but excluded in HROT (for consistency with the usual outer-totalistic B/S notation).

If you want survival on zero neighbours, stick a 'z' on the end of the rule. For instance, if we were allowed r1 (which we're not, because that pointlessly duplicates the outer-totalistic rulespace), then B3/S02456 would have the rulestring r1b04s3az:

• 04 = 0000 0100 because we have birth only on 3 neighbours, and the 3rd-from-last bit is 1 (the others are 0).
• 3a = 0011 1010 because we have survival on 2, 4, 5 and 6 neighbours.
• z because we have survival on zero neighbours.

A maximum range of 5 is supported (in which case each of the birth and survival conditions have exactly 30 hex chars), because due to extremely technical reasons* the HROT code can't support neighbourhoods of area greater than 127.

* The easiest way to explain it is that PSHUFB allows me to index into a lookup table of at most 16 bytes, and I can (with some effort) use that as a 128-bit lookup table. I have separate 'birth' and 'survival' lookup tables, PSHUFB each of them, and combine the results using the result of PCMPEQB-ing the centre cell with zero. This extracts the relevant byte; to extract the specific bit, I PSHUFB a 'powers of 2' lookup table and take the bitwise AND with the vector of bytes.

Also, I haven't combined this with Generations yet (it's 3:58 am here and I want to have food and sleep soon!), but the changes to do so would be utterly trivial.

[cordership3]

Thanks for noticing this. I've enabled the 'incubator' method of object separation for all non-B0 lifelike rules, and replaced the 'apg::pattern' with (a pair of!) 'apg::upattern's in linearlyse(). In Golly language, this corresponds to using QuickLife instead of HashLife. Now we get huge speed improvements, especially for rules with common linear growths:

Thank you for changing that, here are some preliminary results with the same rules as before (and actual rule standardization):

B368/S245: ~115 soups/s to 2000 soups/s
B3678/S34678: 7700-7800 soups/s to 11000 soups/s
B36/S23: 3-6 soups/sec to ~3? soups/s

Although there is a significant increase from before, this still doesn't compare to the v3.x speeds I reported earlier in the thread. Not that this is very bad-- it just shows that v3.x is still in fact (for me at least) not quite deprecated yet.

[Apple Bottom]

Higher-range outer-totalistic (HROT) rules are implemented as of v4.63 (in apgsearch) and ll2.0.17 (in lifelib).

Very cool!

I'm seeing segfaults for these rules on Cygwin, however:

Code: Select all

$ ./apgluxe-r2b000008s03ff00-C1.exe -L 1 -v 0 -s AppleBottomTestHaul -n 1000000000

Greetings, this is apgluxe v4.63-ll2.0.17, configured for r2b000008s03ff00/C1.

Lifelib version: ll2.0.17
Compiler version: 7.3.0
Python version: '2.7.14 (default, Oct 31 2017, 21:12:13)  [GCC 6.4.0]'

Using seed AppleBottomTestHaul
Running 1000000000 soups per haul:
Instruction set AVX1 detected
Chaotic-growth pattern detected: zz_LINEAR
r2b000008s03ff00/C1: 4287 soups completed (185.689 soups/second current, 185.689 overall).
r2b000008s03ff00/C1: 9357 soups completed (282.845 soups/second current, 228.153 overall).
Chaotic-growth pattern detected: zz_LINEAR
Failed to detect periodic behaviour!
r2b000008s03ff00/C1: 23680 soups completed (958.445 soups/second current, 423.190 overall).
Failed to detect periodic behaviour!
r2b000008s03ff00/C1: 55617 soups completed (3193.700 soups/second current, 843.244 overall).
Failed to detect periodic behaviour!
r2b000008s03ff00/C1: 68695 soups completed (892.757 soups/second current, 852.242 overall).
Chaotic-growth pattern detected: zz_LINEAR
r2b000008s03ff00/C1: 73203 soups completed (401.926 soups/second current, 797.236 overall).
Chaotic-growth pattern detected: zz_LINEAR
r2b000008s03ff00/C1: 85513 soups completed (873.855 soups/second current, 807.427 overall).
r2b000008s03ff00/C1: 128138 soups completed (3012.580 soups/second current, 1067.310 overall).
Failed to detect periodic behaviour!
r2b000008s03ff00/C1: 139141 soups completed (1048.005 soups/second current, 1065.757 overall).
r2b000008s03ff00/C1: 193617 soups completed (5447.600 soups/second current, 1377.508 overall).
Failed to detect periodic behaviour!
Chaotic-growth pattern detected: zz_REPLICATOR
r2b000008s03ff00/C1: 211899 soups completed (1336.306 soups/second current, 1373.853 overall).
Failed to detect periodic behaviour!
r2b000008s03ff00/C1: 240600 soups completed (2870.100 soups/second current, 1464.956 overall).
Failed to detect periodic behaviour!
r2b000008s03ff00/C1: 245135 soups completed (449.321 soups/second current, 1406.155 overall).
Chaotic-growth pattern detected: zz_LINEAR
r2b000008s03ff00/C1: 249600 soups completed (405.393 soups/second current, 1346.685 overall).
Chaotic-growth pattern detected: zz_REPLICATOR
r2b000008s03ff00/C1: 263282 soups completed (1368.200 soups/second current, 1347.786 overall).
Failed to detect periodic behaviour!
Pathological object detected!!!
r2b000008s03ff00/C1: 264282 soups completed (17.227 soups/second current, 1042.977 overall).
r2b000008s03ff00/C1: 299845 soups completed (3540.016 soups/second current, 1138.200 overall).
r2b000008s03ff00/C1: 338396 soups completed (3849.326 soups/second current, 1237.492 overall).
Segmentation fault (core dumped)
$


There's no actual core dump (this is Cygwin after all), but the stackdump file reveals that this is actually a stack overflow:

Code: Select all

Exception: STATUS_STACK_OVERFLOW at rip=00100431735
rax=000000060E184880 rbx=00000000FFE06410 rcx=000000060E184880
rdx=0000000000000002 rsi=00000000FFE06418 rdi=6AAAAAAAAAAAAAAC
r8 =00000000FFE06410 r9 =00000000FFE06418 r10=0000000000000000
r11=0000000100454C50 r12=00000000FFFFC4F0 r13=00000000FFE04101
r14=0000000000000000 r15=0000000000000002
rbp=00000000FFE04150 rsp=00000000FFE03F90
program=[...]\apgluxe-r2b000008s03ff00-C1.exe, pid 13440, thread
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame        Function    Args
000FFE04150  00100431735 (00000000000, 00000000000, 00000000000, 00000000001)
000FFE04270  0010043165F (00000000000, 00000000000, 00000000000, 00000000001)
000FFE04390  0010043165F (00000000000, 00000000000, 00000000000, 00000000001)
000FFE044B0  0010043165F (00000000000, 00000000000, 6FFFBAB0010, 00000000001)
000FFE045D0  0010043165F (00000000000, 00000007000, 00000000000, 00000000001)
000FFE046F0  0010043165F (00000000000, 00000000000, 00000000000, 00000000001)
000FFE04810  0010043165F (00000000000, 00000000000, 00000000000, 00000000001)
000FFE04930  0010043165F (00000000000, 00000000000, 00000000000, 00000000001)
000FFE04A50  0010043165F (00000000000, 000004EEBD8, 001004317B1, 00000000001)
000FFE04B70  0010043165F (00000000000, 00000126824, 001004316C5, 00000000001)
000FFE04C90  0010043165F (00000000000, 00000321C5C, 001004316C5, 00000000001)
000FFE04DB0  0010043165F (000FFE050B0, 0000000000F, 001800BEE5C, 00000000001)
000FFE04ED0  0010043165F (00000000001, 00000000002, 000FFFFC4F0, 00000000001)
000FFE04FF0  0010043165F (000FFE06B54, 0060E14AF50, 0010042FB87, 00000000001)
000FFE05110  0010043165F (00000000000, 00000752E00, 00000000000, 00000000001)
000FFE05230  0010043165F (000000451E6, FFFFFFFFFFFFFFFF, 0010042C310, 00000000001)
End of stack trace (more stack frames may be present)


Looks like this is due to deep recursion, perhaps.

[calcyman]

Thanks! It looks like it was trapped in an infinite recursion in pbbosc, which I've now fixed. This wasn't related to the new rules (the same thing happened in the LtL equivalent rule):

https://catagolue.appspot.com/hashsoup/C1/AppleBottomTestHaul348534/r2b4t4s10t19

I've also added multistate HROT rules.

[gameoflifeboy]

When terminating an instance of apgluxe right before restarting my Linux computer to fix the Internet connection, I glanced at the output and noticed the reporting of 17 switch engines in only 79424 soups at the end of my last haul. I then looked through the previous hauls and found similarly disproportionate numbers of switch engines after the last "soups processed..." line.

Code: Select all

679100000 soups processed...
679200000 soups processed...
Rare oscillator detected: xp8_gk2gb3z11
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
679300000 soups processed...
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
679400000 soups processed...
Rare oscillator detected: xp8_gk2gb3z11
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
679500000 soups processed...
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
679600000 soups processed...
679700000 soups processed...
679800000 soups processed...
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
679900000 soups processed...
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
680000000 soups processed...
680100000 soups processed...
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
680200000 soups processed...
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Rare oscillator detected: xp8_gk2gb3z11
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Rare oscillator detected: xp30_w33z8kqrqk8zzzx33
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
----------------------------------------------------------------------
680279424 soups completed.
Attempting to contact payosha256.
Internet does not exist; henceforth trying catagolue.appspot.com instead of gol.hatsya.co.uk...
No response!
Connection was unsuccessful.
Continuing search...
680300000 soups processed...
[...]


Code: Select all

566600000 soups processed...
566700000 soups processed...
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
566800000 soups processed...
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl384_1_59_7aeb1999980c43b4945fb7fcdb023326
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
----------------------------------------------------------------------
566899520 soups completed.
Attempting to contact payosha256.
Internet does not exist; henceforth trying gol.hatsya.co.uk instead of catagolue.appspot.com...
No response!
Connection was unsuccessful.
Continuing search...
566900000 soups processed...
[...]


None of these hauls were able to get submitted due to my connection problem. Does anyone know why this is happening? I suspect it might be simply because the number of soups processed is inaccurate. I was running hauls of 22^6 soups each, by the way, because I like my haul sizes to be important numbers that aren't divisible by large powers of 10.

[calcyman]

This is normal. When you run apgluxe in parallel mode (using the -p flag), the reported number of soups is an estimate which is often generated by one thread. If that thread finishes much before the others (possibly due to random fluctuations, or competing background processes on that CPU core, or suchlike) then there will be a hiatus where apgluxe waits for the other threads to complete (potentially finding switch engines) without generating any more 'soups processed' status lines.

[wwei23]

Almost nothing in this census produces what it's supposed to, really bad classification error?
https://catagolue.appspot.com/census/b2 ... 5678/D4_+1

[muzik]

Will gutter symmetries ever be supported officially? Given that Life preserves both orthogonal and diagonal gutter symmetry, it seems as though officially including gutter variants would be of more use than existing symmetries for finding patterns such as pre-pulsar and twin bee shuttle variants among others due to these oscillator classes preserving said gutters.

[muzik]

Regarding the hexagonal rule support implemented in v4.66: why is it barred from being searched with regular square-grid symmetries? I know they don't preserve such symmetries, but a lot of rules don't preserve inflation either, but they're still compatible with those.

[cordership3]

@muzik: He disabled those symmetries precisely for the reason you mentioned (they aren't preserved), also calcyman is planning to implement hexagonal symmetries sometime.

[muzik]

It seems as though object separation could use a bit of work:
https://catagolue.appspot.com/census/b2 ... /2x128/xq3

[muzik]

Also want to note it's very easy to send apgluxe into an infinite loop. Might want to look into stopping it from accepting such invalid rulestrings.

Code: Select all

./apgluxe --rule b3s23#

[muzik]

The infinite loop bug seems to have been patched.

Still, I feel object separation needs to be looked at a bit better: https://catagolue.appspot.com/haul/bs0h ... 1c55331fc4

[wwei23]

Still, I feel object separation needs to be looked at a bit better: https://catagolue.appspot.com/haul/bs0h ... 1c55331fc4

The hacked apgsearch script has better object separation than apgluxe, maybe calcyman could use that as a guide? In fact, I noticed that apgluxe classified almost everything wrong in B2-a4e5/S134e5678 and similar rules, while the script classified almost everything correctly.

[muzik]

apgsearch doesn't seem to differentiate between these synonymous rulestrings:

https://catagolue.appspot.com/census/b2o3m5s2om4o6h/C1
https://catagolue.appspot.com/census/b2o3m5s2-p4o6h/C1

It seems as though it has safeguards for moore outer-totalistic rules, so a check should probably be added for hex rules as well. (It also might be worth merging the first census into the second one before incorrect hexagonal rulestrings gets out of hand.)

[Ian07]

apgsearch v4.69 now tracks diehards lasting ≥500 generations:

https://catagolue.appspot.com/object/messless_5h/b3s23

[muzik]

Object separation in b0 rules really needs looked at.

https://catagolue.appspot.com/census/b0 ... _+2/xq1386

[calcyman]

Regarding the hexagonal rule support implemented in v4.66: why is it barred from being searched with regular square-grid symmetries? I know they don't preserve such symmetries, but a lot of rules don't preserve inflation either, but they're still compatible with those.

Some news about symmetries:

v4.7-ll2.0.26 now includes two bilateral symmetries for hexagonal rules: D2_x (same as square-grid rules) and D2_xo (which is D2_x after flipping the square grid vertically). On a square grid, these are the same symmetry; on a hexagonal grid, they're two different forms of bilateral symmetry:



In particular, in D2_x the line of symmetry runs perpendicular to the edges of the hexagons (like the vertical line above) and in D2_xo the line of symmetry runs parallel to the edges of the hexagons (like the horizontal line above).

The other hexagonal grid symmetry subgroups will be introduced once I've classified them.

Also, I've fixed the C2_2 sample soup problem. Now lifelib, Catagolue, and every version of apgsearch fully agree as to how soups are constructed (and this applies retrospectively to all existing sample soups, so they no longer claim to produce objects that they don't).

[muzik]

D2_xo is currently recognised as an unofficial symmetry though, might want to fix that. (EDIT: seems to be amended now)

Also, it seems you can search some more of the "regular" symmetries as well now

EDIT2: looks like we have even more symmetries to choose from, as of 13 minutes ago...

[calcyman]

As of version 4.71, lifelib and apgsearch support the following hexagonal symmetries:

["1x256", "2x128", "4x64", "8x32", "C1", "C2_4", "C2_1", "C3_1", "C6", "D2_x", "D2_xo", "D4_x4", "D4_x1", "D6_1", "D6_1o", "D12"]

Catagolue does not understand any of the C3, C6, D6, and D12 symmetries, but you can use lifelib's hashsoup functionality (from within Python) instead:

Code: Select all

import lifelib, os
sess = lifelib.load_rules('b2s34h')
lt = sess.lifetree()
lt.hashsoup('b2s34h', 'C6', 'm_6JDhGJZbpRqQ2175442').save('thing.rle')
os.system('cat thing.rle')

The missing hexagonal symmetries are C3_3 and D6_3.

[dvgrn]

Catagolue does not understand any of the C3, C6, D6, and D12 symmetries, but you can use lifelib's hashsoup functionality (from within Python) instead...

My (Windows 10) system isn't too happy with the final os.system() call to 'cat' -- just seems to hang indefinitely until I close the blank pop-up command windows. But the script does a fine job of generating the thing.rle soup:

Code: Select all

x = 61, y = 61, rule = B2/S34H
15bo$15b2o2$16bobo$15bob3o$17bob2o$15bo2b3o$15bob3o2bo$16bobo2bo$15bo
4b2ob2o$16b2o2b4o$16bo2bo4bo$15b5obobob2o$19bobo2b4o$16b2o2bo4bob2o$2o
b3obobo5bo4bo3bo2bo2bo2bo2bob2obo2b2o$bo2b3o2bo2b3ob5o4bobo2bobob3obo
4bobo$3b2obobob5o2b2obo4b2o3b2obobobo2bob2o$5b3ob2o2bobo2bo2b3o3b6o3bo
3b3ob2o$4bo2bob2ob3obob5o3b2ob2o2bo2b3o3b4o$7b2obo7b4o2b4o2b2ob4o3b2o
2b2o$6bo5bo2b4o3b7o2b3o4b2ob3o$7b2o2bobo3bobo4b2ob3obob2o7bo2bo$10bobo
6b6o2bo2bobo2bo5bob2o$9b2ob3o5b3o4bo3b4o4bobobobo$11b2o2bo2bob3o2b3ob
2o2b3o2b2ob3o$12bo3bobob2obob3ob3o3b3obo3b2o$12bobob4ob2obob2o2b10ob4o
$14bobo2bob2o2bo2bobo5b2o2bo3bo$16b2ob3obob2o2b2o2b2o2bo2b2o$15b6o2bob
5ob5obo2b6o$19b2o2bo2b2o2b2o2b2obob3ob2o$16bo3bo2b2o5bobo2bo2b2obo2bob
o$16b4ob10o2b2obob2ob4obobo$16b2o3bob3o3b3ob3obob2obobo3bo$17b3ob2o2b
3o2b2ob3o2b3obo2bo2b2o$15bobobobo4b4o3bo4b3o5b3ob2o$16b2obo5bo2bobo2bo
2b6o6bobo$15bo2bo7b2obob3ob2o4bobo3bobo2b2o$17b3ob2o4b3o2b7o3b4o2bo5bo
$15b2o2b2o3b4ob2o2b4o2b4o7bob2o$15b4o3b3o2bo2b2ob2o3b5obob3ob2obo2bo$
15b2ob3o3bo3b6o3b3o2bo2bobo2b2ob3o$17b2obo2bobobob2o3b2o4bob2o2b5obobo
b2o$15bobo4bob3obobo2bobo4b5ob3o2bo2b3o2bo$15b2o2bob2obo2bo2bo2bo2bo3b
o4bo5bobob3ob2o$32b2obo4bo2b2o$33b4o2bobo$34b2obobob5o$36bo4bo2bo$37b
4o2b2o$36b2ob2o4bo$39bo2bobo$38bo2b3obo$40b3o2bo$40b2obo$41b3obo$42bob
o2$44b2o$45bo!
#C [[ THUMBNAIL THUMBSIZE 3 ]]

[muzik]

apgluxe doesn't seem to realise that these two rulestrings are identical either:

https://catagolue.appspot.com/census/b2o3m5s2om4o6h/C1
https://catagolue.appspot.com/census/b2o3m5s2mo4o6h/C1

Personally, instead of forcing them to obey alphabetical order like Moore non-totalistic rulestrings do, I think it'd be better to negate a transition when two or more with the same amount of neighbours are present, since that way, either only a single transition will be present or only one will be negated, which will stop the site from being clogged up with extra synonymous rulestrings.

https://catagolue.appspot.com/census/b2o3m5s2-p4o6h/C1

[muzik]

This D12 search result is not D12 symmetric due to object separation not partitioning these extra oscillators:

https://catagolue.appspot.com/object/xp ... 513/b2s34h