0E0P constructions

[Hippo.69]

So shell is entirely built, path to input stop seed should be created, EEEE simkin gun should be reduced to speboe at the desired position.

Then planning directed construction should start ... to determine where the targets for the construction should be positioned (and how the path to input stop should be modified).

All 4 main diagonals (SSSS-WWWW), (SSSE--NWWW), (SEEE-NNNW) and (EEEE-NNNN) allow to do the modifications.
Allocation on SSEE-NNWW would be more complicared.

0e0pcells.mc

(726.83 KiB) Downloaded 3 times

Reduction of the simkin gun to the required speboe block is done ... so the path to input stop and then the directed construction.

0e0pcells.mc

Let us hope this is the newer attachment...

(728.7 KiB) Downloaded 2 times

[NNlk05]

How close are we anyways to a new and smaller 0E0P?

Is anyone up to a 1D Wolfram rule 0E0P?

[otismo]

OMG this is epic - just tried to read it

[Hippo.69]

How close are we anyways to a new and smaller 0E0P?

With the simkin oggca technology we are close . It seems to me I luckily chosen the correct size for the cell (DNA length).
I can save some time ... if I allocate NNNN closer to the required position, the allocation using spliters for synchronization is suboptimal,
but main part of required time is the waiting for collision allocations which are dictated by the huge sizes.

I bet directed shell construction would be faster (both in planning and in the length of the recipe) as it does not require that much allocation. Of course, there is the main clock heart, which requires a lot of slow gliders to build, but I have already made bespoke recipes for it for pslmake.

I hope I would be able to finish it during 2026 or 2027, but it could happen more important problems would require my attention.

Is anyone up to a 1D Wolfram rule 0E0P?

I do not know what 1D Wolfram rule is ... but I bet it requires more than 2 states. This 0e0p technology is able to implement any rule using 2 states in 3x3 neighborhood (by translating it to 2^9 combinations of 6 states in orthogonal (2x2) neighborhood (of odd-half coordinates)) therefore each of 2^9 options could be independently specified to be dead/alive in next generation.

This technology would be difficult to extend to more then 2 states.
But 1D suggests there is no need for 3x3 neighborhood to implement ... so another concept of metacell ... is there a reason to implement it in Life at all? ... may be someone else would be interested in it ...

[NNlk05]

*snip*

Is anyone up to a 1D Wolfram rule 0E0P?

I do not know what 1D Wolfram rule is ... but I bet it requires more than 2 states. This 0e0p technology is able to implement any rule using 2 states in 3x3 neighborhood (by translating it to 2^9 combinations of 6 states in orthogonal (2x2) neighborhood (of odd-half coordinates)) therefore each of 2^9 options could be independently specified to be dead/alive in next generation.

This technology would be difficult to extend to more then 2 states.
But 1D suggests there is no need for 3x3 neighborhood to implement ... so another concept of metacell ... is there a reason to implement it in Life at all? ... may be someone else would be interested in it ...

See One-dimensional_cellular_automaton/Wolfram_rule.
This can lead to strange growth such as:

Code: Select all

x = 2, y = 1, rule = W225
2o!
[[ GRAPH AUTOSTART ]]

[Hippo.69]

See One-dimensional_cellular_automaton/Wolfram_rule.
This can lead to strange growth such as:

Code: Select all

x = 2, y = 1, rule = W225
2o!
[[ GRAPH AUTOSTART ]]

I have just scanned the description and it seems to me for the 3 cell neighbourhood simillar/same technique would work.

[Hippo.69]

OK seems shell building demo version is working (including the input lane stop).
Now it's time to plan the oriented build ... and refine the shell building after deciding required positions of (symmetric) targets for the oriented build.

0e0pcells.mc

(713.83 KiB) Downloaded 12 times

There are 4 (symmetric start construction blocks) forgotten in the demo central cell so the self destruction at the end does not work in the example, but it works well without them ...

I am not sure how to build the starting snark with SoD ... I would probably build everything except it using one simkin oggca and then using two snarks and a simkin oggca ... I would build it from side ... then destroying the oggca and the 2 snarks ... to "ignite"/transfer the gen. Let us see how much time it would require ... if we are still in $2^{24}$ DNA length.

So if fitting in envelope recipe for snark with a (backward glider) SoD would be ready, I would gladly replace the end of the construction...

Hmmm, I had to make bespoke for clockheart more compact to get enough space ... and bespoke for boat close to eater eater2 pair ... refreshing p1.dat.

Hmmm, I have detected another bug in pslmake ... let us hope would be able to isolate it ... it probably is caused by the new bespoke ...
Unfortunately I am not able to replicate it. ... I do not have the predecessor in the beam ... and new run does not have the problem.

OWWBSalvo_146_1bad.mc

(73.28 KiB) Downloaded 5 times

[Hippo.69]

Hmmm, I have detected another bug in pslmake ... let us hope would be able to isolate it ... it probably is caused by the new bespoke ...
Unfortunately I am not able to replicate it. ... I do not have the predecessor in the beam ... and new run does not have the problem.OWWBSalvo_146_1bad.mc

I am going to run the computaton agian keeping all beam progress files ... (unfortunately the beam width is 1024).
(I just need entire beam of generation 145 ... let us hope the same error occurs again at generaton 146).

Oh there is no bug just the salvo is slower then presented (by 2 ticks)... defrag would cure the problem.

[TigerCub414]

*snip*

Hmmm, I have detected another bug in pslmake ... let us hope would be able to isolate it ... it probably is caused by the new bespoke ...
Unfortunately I am not able to replicate it. ... I do not have the predecessor in the beam ... and new run does not have the problem.OWWBSalvo_146_1bad.mc

Here is a simpler way to build the catalyst for the metacell's clock:

Code: Select all

x = 41, y = 27, rule = B3/S23
2b2ob2o$o2bob2o$2obo$3bo13b3o4b2o$3b2o18bo2bo$b2o20bo2bo$obo21b2o$bo$
15b3o2$b2o20b2o$b2o19bo2bo$22bobo$23bo2$5b2o$4bo2bo$4bo2bo$5b2o3$9b2o$
9bobo$10bo$38b3o$38bo$39bo!

[Hippo.69]

Oh double post… I will reuse it in near future…

So seems the orignal shema expecting oriented build around the "gen" path would not work as path to building main clocks crosses the gen path.
Fortunately we expect build by OGGCA's so this is not a big deal, just some connections and correponding SoD's should be modified ...

[Hippo.69]

Here is a simpler way to build the catalyst for the metacell's clock:

Code: Select all

x = 41, y = 27, rule = B3/S23
2b2ob2o$o2bob2o$2obo$3bo13b3o4b2o$3b2o18bo2bo$b2o20bo2bo$obo21b2o$bo$
15b3o2$b2o20b2o$b2o19bo2bo$22bobo$23bo2$5b2o$4bo2bo$4bo2bo$5b2o3$9b2o$
9bobo$10bo$38b3o$38bo$39bo!

Thanks, I am going to replace the bespoke and rerun again:)

If you/someone else know better bespoke for the first phase, I would gladly update it as well.

If you have recipes from other directions (other then adding an ott) … I would update their bespoke as well.

OK, your proposal is

Code: Select all

x = 43, y = 54, rule = DoubleB3S23
2.2C.2C$C2.C.2C$2C.C$3.C13.3C4.2A$3.2C18.A2.A$.2C20.A2.A$C.C21.2A$.C$
15.3C2$.2C20.2A$.2C19.A2.A$22.A.A$23.A2$5.2A$4.A2.A$4.A2.A$5.2A3$9.2A
$9.A.A$10.A$38.3A$38.A$39.A3$36.3B$36.B$37.B20$41.B$40.2B$40.B.B!

I would try given glider pairs from different directions ...

Code: Select all

x = 419, y = 220, rule = DoubleB3S23
274.C6.C$275.C6.C$273.3C4.3C22$297.C$298.C$296.3C7$394.C$393.C$393.3C
2$384.C$382.2C$383.2C9$370.C$369.C$369.3C51$2.2C.2C115.2C.2C85.2C.2C
70.2C.2C70.2C.2C$C2.C.2C113.C2.C.2C83.C2.C.2C68.C2.C.2C68.C2.C.2C18.A
$2C.C116.2C.C86.2C.C71.2C.C71.2C.C22.2A$3.C13.3C4.2A97.C13.3C73.C13.
3C58.C13.3C58.C13.3C5.2A$3.2C18.A2.A96.2C88.2C73.2C73.2C$.2C20.A2.A
94.2C88.2C73.2C73.2C$C.C21.2A94.C.C87.C.C72.C.C72.C.C25.2A$.C119.C89.
C74.C74.C25.A.A$15.3C117.3C87.3C72.3C72.3C8.A.A$387.A8.2A$.2C20.2A96.
2C88.2C73.2C73.2C32.A2.A$.2C19.A2.A95.2C88.2C73.2C73.2C32.A2.A$22.A.A
371.2A$23.A206.A$229.A.A$5.2A143.A72.3A2.A.A$4.A2.A141.A.A73.A3.A77.A
4.A$4.A2.A141.A2.A71.A81.A.A3.A.A$5.2A143.2A153.A2.A3.2A$155.A150.2A$
154.A.A$9.2A143.A.A$9.A.A143.A213.2A$10.A357.A.A$38.3A196.2A130.A$38.
A198.2A69.A$39.A98.2A167.A.A8.3B49.A$137.A2.A166.A.A8.B50.A.A$138.A.A
167.A10.B49.2A$36.3B100.A8.2A6.3B$36.B110.A2.A5.B$37.B109.A.A7.B$148.
A$305.3A$236.2A$147.2A81.3A2.A.A72.2A$146.2A88.A73.2A$148.A5$259.3B$
259.B$260.B$412.3B$412.B$413.B$323.B$322.2B$322.B.B$41.B119.B$40.2B
118.2B$40.B.B117.B.B11$264.B$263.2B$263.B.B$417.B$416.2B$89.2C118.2C
205.B.B$88.2C118.2C$90.C119.C11$85.C119.C$84.2C118.2C$84.C.C117.C.C6$
155.2C$146.3C5.C.C$148.C7.C$147.C23$133.2C$132.C.C$134.C!

... pslmake git ... defragUI branch update includes the bespoke changes. … seems 3loaf version is cheaper… in isolation.

BTW: I have got your creation of glider pair among others using

spliters_by_two_gliders.lua

... have you used it as well?

[TigerCub414]

If you/someone else know better bespoke for the first phase, I would gladly update it as well.

If you have recipes from other directions (other then adding an ott) … I would update their bespoke as well.

OK, your proposal is

Code: Select all

x = 43, y = 54, rule = DoubleB3S23
2.2C.2C$C2.C.2C$2C.C$3.C13.3C4.2A$3.2C18.A2.A$.2C20.A2.A$C.C21.2A$.C$
15.3C2$.2C20.2A$.2C19.A2.A$22.A.A$23.A2$5.2A$4.A2.A$4.A2.A$5.2A3$9.2A
$9.A.A$10.A$38.3A$38.A$39.A3$36.3B$36.B$37.B20$41.B$40.2B$40.B.B!

I would try given glider pairs from different directions ...

Code: Select all

x = 419, y = 220, rule = DoubleB3S23
274.C6.C$275.C6.C$273.3C4.3C22$297.C$298.C$296.3C7$394.C$393.C$393.3C
2$384.C$382.2C$383.2C9$370.C$369.C$369.3C51$2.2C.2C115.2C.2C85.2C.2C
70.2C.2C70.2C.2C$C2.C.2C113.C2.C.2C83.C2.C.2C68.C2.C.2C68.C2.C.2C18.A
$2C.C116.2C.C86.2C.C71.2C.C71.2C.C22.2A$3.C13.3C4.2A97.C13.3C73.C13.
3C58.C13.3C58.C13.3C5.2A$3.2C18.A2.A96.2C88.2C73.2C73.2C$.2C20.A2.A
94.2C88.2C73.2C73.2C$C.C21.2A94.C.C87.C.C72.C.C72.C.C25.2A$.C119.C89.
C74.C74.C25.A.A$15.3C117.3C87.3C72.3C72.3C8.A.A$387.A8.2A$.2C20.2A96.
2C88.2C73.2C73.2C32.A2.A$.2C19.A2.A95.2C88.2C73.2C73.2C32.A2.A$22.A.A
371.2A$23.A206.A$229.A.A$5.2A143.A72.3A2.A.A$4.A2.A141.A.A73.A3.A77.A
4.A$4.A2.A141.A2.A71.A81.A.A3.A.A$5.2A143.2A153.A2.A3.2A$155.A150.2A$
154.A.A$9.2A143.A.A$9.A.A143.A213.2A$10.A357.A.A$38.3A196.2A130.A$38.
A198.2A69.A$39.A98.2A167.A.A8.3B49.A$137.A2.A166.A.A8.B50.A.A$138.A.A
167.A10.B49.2A$36.3B100.A8.2A6.3B$36.B110.A2.A5.B$37.B109.A.A7.B$148.
A$305.3A$236.2A$147.2A81.3A2.A.A72.2A$146.2A88.A73.2A$148.A5$259.3B$
259.B$260.B$412.3B$412.B$413.B$323.B$322.2B$322.B.B$41.B119.B$40.2B
118.2B$40.B.B117.B.B11$264.B$263.2B$263.B.B$417.B$416.2B$89.2C118.2C
205.B.B$88.2C118.2C$90.C119.C11$85.C119.C$84.2C118.2C$84.C.C117.C.C6$
155.2C$146.3C5.C.C$148.C7.C$147.C23$133.2C$132.C.C$134.C!

... pslmake git ... defragUI branch update includes the bespoke changes.

BTW: I have got your creation of glider pair among others using

spliters_by_two_gliders.lua

... have you used it as well?

The catalyst can be constructed in three stages, like this:

Code: Select all

x = 202, y = 43, rule = B3/S23
10bo$9bobo$10b2o$5bo10b3o$4bobo$4bobo$5bo5b2o$11bobo69b2ob2o75b2ob2o$
12bo68bo2bob2o73bo2bob2o$bo79b2obo76b2obo$obo81bo79bo13b3o4b2o$obo81b
2o78b2o18bo2bo$bo160b2o20bo2bo$161bobo21b2o$81b2o2b2o2b3o70bo$24b3o53b
obo2bobo88b3o$24bo50b3o3bo4bo$25bo66b2o68b2o20b2o$92b2o68b2o19bo2bo$
73b2o108bobo$73b2o7bo101bo$82bo$82bo83b2o$95b2o68bo2bo$95b2o68bo2bo$
166b2o2$81b2o11b2o$81bobo9bobo74b2o$82bobo9bo75bobo$83bo87bo$199b3o$
199bo$200bo7$99b2o$99bobo$99bo!

Also, yes, I used spliters_by_two_turners.lua to make the glider pairs. It’s a very useful script, although I think it, along with show_turner.lua, could be optimised (show_turners.lua creates the pattern 1 cell at a time, which takes several minutes. I’m thinking of changing it to paste the patterns faster.

[Hippo.69]

The catalyst can be constructed in three stages, like this:

Code: Select all

x = 202, y = 43, rule = B3/S23
10bo$9bobo$10b2o$5bo10b3o$4bobo$4bobo$5bo5b2o$11bobo69b2ob2o75b2ob2o$
12bo68bo2bob2o73bo2bob2o$bo79b2obo76b2obo$obo81bo79bo13b3o4b2o$obo81b
2o78b2o18bo2bo$bo160b2o20bo2bo$161bobo21b2o$81b2o2b2o2b3o70bo$24b3o53b
obo2bobo88b3o$24bo50b3o3bo4bo$25bo66b2o68b2o20b2o$92b2o68b2o19bo2bo$
73b2o108bobo$73b2o7bo101bo$82bo$82bo83b2o$95b2o68bo2bo$95b2o68bo2bo$
166b2o2$81b2o11b2o$81bobo9bobo74b2o$82bobo9bo75bobo$83bo87bo$199b3o$
199bo$200bo7$99b2o$99bobo$99bo!

Also, yes, I used spliters_by_two_turners.lua to make the glider pairs. It’s a very useful script, although I think it, along with show_turner.lua, could be optimised (show_turners.lua creates the pattern 1 cell at a time, which takes several minutes. I’m thinking of changing it to paste the patterns faster.

Thanks twice ... am going to update the entire bespoke sequence ... the experiment (on the entire required pattern) testing the improvement by the previous phase is still running.

I am glad the tool is used, let me know if you make show turners faster to update the repo.

Reduction to the second step:

Code: Select all

x = 12, y = 16, rule = B3/S23
4b2ob2o$2bo2bob2o$2b2obo$5bo$5b2o4$bo5b2o$obo3bo2bo$bo4bo2bo$7b2o2$9b
3o$9bo$10bo!

Perfect just in time before I have started processing the 2nd step.

Hmm the cleanup is rather expensive for the flipped version ... do you have an alternative for that case?
OK I need to have an ott180 ready before start of the cleanup ... I bet this is not optimal ...

Code: Select all

x = 73, y = 72, rule = B3/S23
3o$11bo$11bo$11bo3$7b2o$7b2o$14bo$14bo$14bo7b2o$21bo2bo6b2o$21bo2bo6b
2o$22b2o4bo$28b5o$32bo$30bo$23bo6b2o$17b2o3bobo$17bobo3bo$17bo34$56b2o
$56bobo$56bo13$70b2o$70bobo$70bo!

OK bespokes locally updated, another experment is started ... (making synced gliders more compact saved 37 gliders, stage3 (Tigercup's) reduction saved another 72 gliders, reduction of phases 1 an 2 saved another 167 gliders ... replacement of synchronized pair by 3 loaf version is worse by 37 gliders ... maybe just an unlucky context ... but I would return to Tigerscub bespoke anyways).

This is probably cheaper:

Code: Select all

x = 73, y = 73, rule = B3/S23
2o$2o$7bo$7bo$7bo7b2o$14bo2bo6b2o$14bo2bo6b2o$15b2o4bo$21b5o$25bo$23bo
$16bo6b2o$10b2o3bobo$3b3o4bobo3bo$10bo34$47b2o$47bobo$47bo13$58b2o$57b
2o$59bo5$71b2o$70b2o$72bo!

Alternatively, it seems like the reaction in the first step is compatible with having a sneaky blinker in this position:

Code: Select all

x = 52, y = 51, rule = B3/S23
2o$2o17bo$7bo11bo$7bo11bo$7bo7b2o$14bo2bo6b2o$14bo2bo6b2o$15b2o4bo$21b
5o$25bo$23bo$16bo6b2o$10b2o3bobo$10bobo3bo$10bo34$49b2o$49bobo$49bo!

Thanks, I would try both alternatives, I am not sure how expensive the "sneaky blinker" actually is. Then I add the winner of the experiment to bespokes. ... sneaky is cheaper ... 64 rather to 66 gliders.

Bespokes on DefragUI branch of pslmake upated again.

[EvinZL]

Reduction to the second step:

Code: Select all

x = 12, y = 16, rule = B3/S23
4b2ob2o$2bo2bob2o$2b2obo$5bo$5b2o4$bo5b2o$obo3bo2bo$bo4bo2bo$7b2o2$9b
3o$9bo$10bo!

Hmm the cleanup is rather expensive for the flipped version ... do you have an alternative for that case?
OK I need to have an ott180 ready before start of the cleanup ... I bet this is not optimal ...

Code: Select all

x = 73, y = 72, rule = B3/S23
3o$11bo$11bo$11bo3$7b2o$7b2o$14bo$14bo$14bo7b2o$21bo2bo6b2o$21bo2bo6b
2o$22b2o4bo$28b5o$32bo$30bo$23bo6b2o$17b2o3bobo$17bobo3bo$17bo34$56b2o
$56bobo$56bo13$70b2o$70bobo$70bo!

This is probably cheaper:

Code: Select all

x = 73, y = 73, rule = B3/S23
2o$2o$7bo$7bo$7bo7b2o$14bo2bo6b2o$14bo2bo6b2o$15b2o4bo$21b5o$25bo$23bo
$16bo6b2o$10b2o3bobo$3b3o4bobo3bo$10bo34$47b2o$47bobo$47bo13$58b2o$57b
2o$59bo5$71b2o$70b2o$72bo!

Alternatively, it seems like the reaction in the first step is compatible with having a sneaky blinker in this position:

Code: Select all

x = 52, y = 51, rule = B3/S23
2o$2o17bo$7bo11bo$7bo11bo$7bo7b2o$14bo2bo6b2o$14bo2bo6b2o$15b2o4bo$21b
5o$25bo$23bo$16bo6b2o$10b2o3bobo$10bobo3bo$10bo34$49b2o$49bobo$49bo!

A search is not finding a good cleanup with slow gliders only

EDIT to avoid forgetting it: this may be useful

Code: Select all

x = 9, y = 16, rule = B3/S23
7bo$6bo$6b3o3$2o$bo$bobo3bo$2b2o2bobo$7b2o2$4b2o$5bo$5bob2o$2b2obo2bo$
2b2ob2o!

[Hippo.69]

The start of oriented construction is currently limited by constructon of unoriented NNNW, where the oriented fast salvo collides (different ways dependng on the child being build). Easiest solution is to wait longer (encoding of the states would be much shorter then the waiting time).
A) Trivial solution is to just wait, but I bet we would not finish the oriented construction in time.
B) We could modify NWWW construction to not leave intermediates on the 4 input paths and make (hardly maintainable) waits on input streams to avoid the collisions.
C) We could replan the open kernel glider path to be almost DNA length longer to open the oriented construction long after the shell is finshed.
This would allow very small gap in the gen and definitely have the biggest chance to finish the construction in time.

I would probably use A) to find reasonably good layout of constrction targets, and during the rebuild of the shell constrction I could switch to C).

OK here is first successfull oriented WWWW build (a bit restricted build through the shell):

0e0pcells.mc

OWWWW

(1.42 MiB) Downloaded 3 times

Oops does not work on SE neighbour (different SoD should be taken into account) the start of build through the shell is much more complicated that way. (Of course we could create an additional oriented target by shell build ... and destroy unneeded during the oriented build ... I am not sure what would be cheaper). ... or I could modify the SoD for unoriented "SSSS" to leave the one required lane open.

OK, much cheaper way would be to create new target by a collision using shell snark.

OK version allocating using shell snark works well (in all directions):

0e0pcells.mc

OWWWW target creatioin uses snark

(1.25 MiB) Downloaded 3 times

OK, I have decided positions of oriented targets. I would not need targets at NNWW or NW, they will be created during oriented construction using OTTs at NNNW and WW similarly as target for ONNNN. I would use natural pslmake origins of NN and SSSW constructions which are "median" targets. There will be rather long push in WW, but the centrall clock is definitely the bottleneck of the construction anyways.
There will be push in NNNE as well, but total push in NNNE plus SSSW cannot be reduced so it is fine. On NWWW I can use trick from NNNN instead of rather long sideway move. And on SEEE I can create target from the construction lane.

So current plan is
1) to clean the shell construction to make oriented targets at their desired places and remove other debrie.
I would still continue with the current design. This would not be final version anyways as timing of kernel openning should be determined ... (considering state transition table encodding ... and delaying it full DNA loop if necessary).

2) do oriented build to see if we are in DNA length limits or not

[TigerCub414]

I have an idea about how to simplify the central clock - the pulse divider can be made with p8 circuitry instead of p1, like this:

Code: Select all

x = 117, y = 114, rule = B3/S23
39b2o$39bo$18b2o17bobo$11b2o5b2o17b2o$11b2o3$13b2o27b2o$13b2o27b2o$7b
2o$7b2o$48b2o$o47b2o$3o22bo18b2o$3bo21b2o17b2o$2b2o20bobo3$49b2o$49b2o
14$2b2o$2b2o$26bo$13bo10b3o$13bo10bobo$7b2o15bo$7b2o$3b2o48bo$3b2o49b
2o$44b2o7b2o$44b2o$9b2o27b2o$9b2o27b2o3$40b2o$15b2o16b2o5b2o$16bo16b2o
$13b3o$13bo19$73b2o$73bobo$75bo$75b2o$77bo$75b3o$74bo$74b2o18$115bo$
114bobo$114bobo$115bo2$100b3o$103bo$99bo3bo$98bobo2bo6bo$96bo2bobo7bob
o$96bo3bo9bo$96bo$97b3o2$108bo3bo$107b2o3b2o$107b2o3b2o$107bo5bo!

The figure 8 should be much easier to construct than the AK-94 catalyst. There are multiple figure 8 placements that work - for example, these are all equivalent:

Code: Select all

x = 180, y = 18, rule = B3/S23
14bo3b2o34bo3b2o34bo3b2o34bo3b2o34bo3b2o$15b2ob2o35b2ob2o35b2ob2o35b2o
b2o35b2ob2o$14b2o27b2o9b2o38b2o38b2o38b2o$2b2ob2o34bob2o$o2bob2o33bo
43bo40bo$2obo39bo39bobo38b3o38b3o$3bo35b2obo39bo3bo36bob3o40bo$3b2o34b
2o40bo3bo36bo3bo37bo3bo$b2o2bobo7bo39bo24bo3bo10bo25bo3bo9bo27bobo2bo
6bo$o2bo2b2o6bobo37bobo22bo3bo10bobo23b3obo9bobo24bo2bobo7bobo$b2o12bo
39bo24bobo12bo25b3o11bo25bo3bo9bo$81bo40bo38bo$162b3o2$12b2o3b2o34bo3b
o35bo3bo35bo3bo35bo3bo$13bo3bo34b2o3b2o33b2o3b2o33b2o3b2o33b2o3b2o$10b
3o5b3o31b2o3b2o33b2o3b2o33b2o3b2o33b2o3b2o$10bo9bo31bo5bo33bo5bo33bo5b
o33bo5bo!

[Hippo.69]

I have an idea about how to simplify the central clock - the pulse divider can be made with p8 circuitry instead of p1, like this:

Code: Select all

x = 117, y = 114, rule = B3/S23
39b2o$39bo$18b2o17bobo$11b2o5b2o17b2o$11b2o3$13b2o27b2o$13b2o27b2o$7b
2o$7b2o$48b2o$o47b2o$3o22bo18b2o$3bo21b2o17b2o$2b2o20bobo3$49b2o$49b2o
14$2b2o$2b2o$26bo$13bo10b3o$13bo10bobo$7b2o15bo$7b2o$3b2o48bo$3b2o49b
2o$44b2o7b2o$44b2o$9b2o27b2o$9b2o27b2o3$40b2o$15b2o16b2o5b2o$16bo16b2o
$13b3o$13bo19$73b2o$73bobo$75bo$75b2o$77bo$75b3o$74bo$74b2o18$115bo$
114bobo$114bobo$115bo2$100b3o$103bo$99bo3bo$98bobo2bo6bo$96bo2bobo7bob
o$96bo3bo9bo$96bo$97b3o2$108bo3bo$107b2o3b2o$107b2o3b2o$107bo5bo!

The figure 8 should be much easier to construct than the AK-94 catalyst. There are multiple figure 8 placements that work - for example, these are all equivalent:

Code: Select all

x = 180, y = 18, rule = B3/S23
14bo3b2o34bo3b2o34bo3b2o34bo3b2o34bo3b2o$15b2ob2o35b2ob2o35b2ob2o35b2o
b2o35b2ob2o$14b2o27b2o9b2o38b2o38b2o38b2o$2b2ob2o34bob2o$o2bob2o33bo
43bo40bo$2obo39bo39bobo38b3o38b3o$3bo35b2obo39bo3bo36bob3o40bo$3b2o34b
2o40bo3bo36bo3bo37bo3bo$b2o2bobo7bo39bo24bo3bo10bo25bo3bo9bo27bobo2bo
6bo$o2bo2b2o6bobo37bobo22bo3bo10bobo23b3obo9bobo24bo2bobo7bobo$b2o12bo
39bo24bobo12bo25b3o11bo25bo3bo9bo$81bo40bo38bo$162b3o2$12b2o3b2o34bo3b
o35bo3bo35bo3bo35bo3bo$13bo3bo34b2o3b2o33b2o3b2o33b2o3b2o33b2o3b2o$10b
3o5b3o31b2o3b2o33b2o3b2o33b2o3b2o33b2o3b2o$10bo9bo31bo5bo33bo5bo33bo5b
o33bo5bo!

Thanks for the suggestion.

This looks like a significant shortening of the construction salvo. I would take it in mind if complexity would become the problem.
The only reason I am not including it immediately is that the SoD should be recomputed as well. (And actually I am still working on the shell modification to produce targets for oriented construction on correct places.)

OK, we have to replan this portion:

Code: Select all

x = 100, y = 127, rule = B3/S23
33bo$32bobo$32bobo$33bo2$47b2o$46bo2bo$47b2o2$43bo$42bobo$42bobo$43bo
3$56b2o$55bo2bo$56b2o$71b2o$52bo18b2o$51bobo$51bobo$52bo2$66b2o$65bo2b
o$66b2o2$62bo$61bobo8bo$61bobo7bobo$62bo8bobo$54b2ob2o13bo$52bo2bob2o$
52b2obo$55bo$55b2o$53b2o2bobo7bo$52bo2bo2b2o6bobo$53b2o12bo4$64b2o3b2o
$65bo3bo$62b3o5b3o$62bo9bo3$70b2o$70b2o4$74b2o$74b2o63$7bo$7b2o$6bobo!

Different portion of crystal could be destroyed ... just the timing of p256 gun destroyal would be changed by shifting longboats.

OK, this looks cheap ...

Code: Select all

x = 47, y = 47, rule = LifeHistory14
23.5yN2A9yN$23.4yNA2yNA8yN$23.5yN2A8yN$23.13yN$23.yNA11yN$23.AyNA10yN
$23.AyNA11yN$23.yNA12yN$24.16yN$27.11yN2AyN$27.10yNA2yNAyN$28.10yN2A
2yN$30.12yN$32.2yNA9yN$32.yNAyNA8yNAyN$32.yNAyNA7yNAyNAyN$32.2yNA8yNA
yNA$32.12yNA2yN$32.14yN$32.14yN$30.2A3.9yN$28.A.2A4.7yN$19.3K5.A8.3yN
A3yN$30.A4.3yNAyNA3yN$26.2A.A9.A$26.2A3$37.A3.A$36.2A3.2A$36.2A3.2A$
36.A5.A13$.A$.2A$A.A!

One should be sure to have correct mod8 glider so the previous turn could become more expensive, but definitely cheaper then the original solution...

.... OK the SE part of central clock was replanned, SoD updated (and debugged) ... the salvo creating the pattern will be recomputed ... at its time ... git updated.

We should be carefull with the finish of the figure eight ... to use correct p8 glider ... but the complication is worth the saved gliders ...

... currently shell is rebuild on SSSS-WWWW, SSSE-NWWW and EEEE-NNNN diagonals, the optimization on the last diagonal is in progress (debugging interruption of EEEE OGGCA recipe by SSSE OGGCA recipe with 2 anchors for quick repostioning ... one of them during split glider pair travel for allocation close the orineted targets) ... critical point is around generation 86090000 ... (still the version where splitters are used for alocation of NNNN and EEEE with targets far from optimal positions ... rebuild of the start of the shell would significantly speed up the EEEE-NNNN diagonal and a lot of SSSS-WWWW portion would be easier as well ... for a cost of a bit more complicated synchronization)

Ufff, allocation completed, NNNW built, small work on NN, EE and SEEE remains to complete shell (with oriented targets).

[Hippo.69]

So finally shell construction with targets on desired places for the oriented build. And the oriented construction can start ...

0e0pcells.mc

targets for oriented build included

(736.41 KiB) Downloaded 2 times

I am happy I added bespoke specification parameter to pslmake ... I had to create alternative to avoid obstacles and it is less efficient then original, but it would be prefered choice ... now I can let standard bespokes intact and just use the alternative when needed.

[Hippo.69]

Oops I have just realized my oriented construction idea would not work.

I have planned to build by huge OGGCA on input lane ... and for NW neighbour there is actually just part of the input lane.
We should bend once before long OGGCA ....

I have planned to build everything except SSSS and half of SSSW using this OGGCA then bend twice to finish SSSW and SSSS.

The positions of oriented targets are in rather good places, But I have planned fast pull for clock allocation from NWWW while building the monstrosity in its SE part.
Build in perpendicullar direction would not help.

So what are the options now?

Bend twice early to finish SSSS and SSSW ... and build extra snark on SSSS WWWW diagonal, destroy he original 2 bends and build OGGCA near EEEE-NNNN diagonal ... to use the original direction of slow salvas? That looks like big waste of time to wait for creation of OGGCA on east. I am afraid the budget would not suffice...

Maybe we could just replace the second band as the SSSS-WWWW diagonal would be finished ... and destroy the first bends at the very end.

Actually it would be probably cheaper not to build the original OGGCA at all and start with the double bended.
Original plan was to have first optimized to NE direction while the other to SE, but building just one would probably be cheaper.

I would probably build snarks on positions the distant target is already built, so snarkmaker variant not making the target would be better then one destroying target afterwards…

I would probably shift SS, WW, NN, EE targets such that it can be used as speboe after first bend and allow to build SS snark by one of the OGGCA's (after another turn in either direction).

OK, start with double bend near SSSS and then changing second band direction looks reasonable.
... oops I have almost made the same misteke second time ... to make OGGCA from perpendicullar glider in the input stream ... which is missing on NW neighbor . ... so how to make target for OGGCA close to EEEE around EEEE-NNNN diagonal? Should I prepare it during the shell build?

I am still thinking about good enough plan to build the oriented portion ... something like this:
Seems first OGGCA could be after double bend to from SSSE->almost SSSS->a bit to SSSW -> SSSS such that most of OSSSS would be built on its "better side" and just the DNA fill snark would be build by its "worse side" ... the OGGCA would build WWWW and SSSW before building SSSS.

The other OGGCA should be at NEEE working on SS-NEEE diagonal building ONNNN first, ONNNE second by its "better side" and than OEEEE by its "worse side". Reason: NEEE blocks the diagonals EEEE-NNNN required for the NNNN construction. Luckily NEEE does not block EEEE construction diagonals.

Thereafter it would build NN and EE on the better side, and SEEE on the worst. It should create ott's on NNNW and NN and use synchronized long pull trick to create targets on NNWW and NW using them. Then ONNWW and ONW should be constructed and maybe ott and long pull creating target on NWWW.

Then ONWWW construction starting with long pull to clock NW postion, then NW construction. SW construction finishes the task. and we can destroy the OGGCA and both snarks to let the gliders fill the DNA loop.

OGGCA stop/destruction should be well timed and seems we could use snarkmaker without SoD for the task .. probably OGGCA would be destroyed much later then the snarks. (Escaping gliders from the stop would be used for snark destructions while the OGGCA destruction salvo would be headed to OGGCA)

I probably should build target for 2nd OGGCA at NEEE (with copies on NNNW, SWWW and SSSE to be just destroyed by O construction).
I probably should reposition SS (WW, NN and EE) target as well to allow constructions on SSSE, SS, WW, NWWW diagonal with the 2nd OGGCA (after the bend).