David Bell's engineless caterpillar idea revisited

[simsim314]

That's not obvious to me. The only conclusion I can make up from it is that the whole spaceship's velocity should be less than c/4.

Well the Head moves with c/2 (as it built from *WSS). The spaceship can move with whatever speed it wants the Heads will still move at c/2, and gliders it shoots are c/4, so after short while the glider will be behind the head.

Even the regular caterpillar has "loop" logic in it, so glider from one head can kill another. But this is timing sensitive, which means each period will require subtle adjustments to it.

Another such loop is present in slow salvo techniques we have today. The new block is created by colliding glider with *WSS. The *WSS was generated by glider from Head1 (after long built by slow salvo) but the new block is generated by glider from Head2 (at the beginning of the line of salvos). This means that this mechanism is also period sensitive.

[codeholic]

The spaceship can move with whatever speed it wants the Heads will still move at c/2, and gliders it shoots are c/4, so after short while the glider will be behind the head.

There is no requirement that a glider should shoot down the same spaceships that triggered the seed it came from.

[simsim314]

There is no requirement that a glider should shoot down the same spaceships that triggered the seed it came from

Definitely! But when we make the caterloop slower we increase the distance between the reading heads (this is the speed adjustment mechanism). When we take this idea to extreme, just to sense the consequences, say million generations between Head1 and Head2 this gives us a sense of the reflecting glider seeds distance.

[codeholic]

I'm sorry, probably there is some essential misunderstanding. Head1 in your terminology is the foremost part of the tape-reading spaceship stream, that moves its tape forward, right?

[simsim314]

I'm sorry, probably there is some essential misunderstanding

I tried to be clear but let me try to be more clear. We agree that glider emited from reading Head can't delete the Head itself (because the glider very soon will be behind the Head). That means we have Head1 the deleted and Head2 the deleter. Because we have different deleted and deleter, we depend on the distance between them, to adjust the timing.

Now our mechanism is speed adjustable. We adjust the speed by making the distance between the reading heads larger. Say if we want speed 59/1000 we just place each head a bit further away. Now if we want 59/100000 we will have the heads very large distance apart, this is how we adjust the speed.

If we agree that two heads are very large distance apart for some caterloops, and that we need two heads to delete a head, we must have a glider to be reflected from very far away to have contant between two heads by a glider, as for many generations there will be no signal in between the deleter and deleted.

EDIT In simple words the simple fact we have DELETED and DELETER means the glider that passes between them will be proportional to the distance between them.

[codeholic]

We agree that glider emited from reading Head can't delete the Head itself (because the glider very soon will be behind the Head).

No, I don't agree with that!

If tape-reader shoots a glider forward, and a salvo seed it triggers shoots gliders forward too (but in laterally opposite direction), it can shoot itself, given the whole spaceship's velocity is slower than c/4, despite the fact that *WSS are faster than a glider, because

There is no requirement that a glider should shoot down the same spaceships that triggered the seed it came from.

[simsim314]

Reading Head I mean the constellation of 5-7 *WSS that shoots a glider once per SL. Not the whole mechanism. The mechanism is built out of large amount of reading heads.

glider emitted from reading Head can't delete the Head itself (because the glider very soon will be behind the Head).

Means:

glider can't shoot down the same spaceships.

I was saying exactly that, in other words. The spaceships constellation that reads SL once, I call reading Head. The whole mechanism is built out of numerous Reading Heads, that go at constant distance one from other, and convert SLs into gliders while moving SLs.
---

Lets be clear: I don't argue the mechanism can work, I argue the distance for the seeds will increase as the speed goes down. I also argue that the mechanism is speed sensitive, and will need modification for every particular speed.

The glider can shoot some other reading Head and definitely the self destruct mechanism can work.

[HartmutHolzwart]

If you just want a glider consrtuctible p8 blinker puffer that is destroyed by a 2c/3 fuse, there must be something better than this:

Code: Select all

x = 26, y = 57, rule = B3/S23
3$18bo$11b3o3b3o$5bo5bo2bo2bob2o$4b3o4bo6b3o$4bob2o3bo3bo2b3o$5b3o4bo
5b2o$5b3o5bo$5b3o$5b2o10bo$10b3o3b3o$16bob2o$17b3o$17b3o$10b3o4b3o$17b
2o3$10b3o4$10b3o4$10b3o4$10b3o4$10b3o4$10b3o4$10b3o2$10bobo$10b3o$9bo
3bo$9b2ob2o2$9b2ob2o$10bobo$10bobo2$9b2ob2o!

Here is a classic recipe for building the blinker puffer:

Code: Select all

x = 51, y = 54, rule = B3/S23
5$43bobo$43b2o$44bo5$27bo$10bo17b2o$8bobo16b2o$9b2o$44bo$43bo$43b3o$
18b2o2b2o$19b2obobo$18bo3bo14$25b2o$26b2o$25bo6$42b3o$42bo2bo$42bo$42b
o3bo$42bo$43bobo!

[simsim314]

If you just want a glider consrtuctible p8 blinker puufer that is destroyed by a 2c/3 fuse

Yes great it's a good start, thx Hartmut. Of course we need to clean the recipe etc. but now we know it's possible to make fuses as close to c/2 as we want.

[simsim314]

Here are some very preliminary results on slow salvo without oscillators (couldn't fit the last block):

Code: Select all

x = 11987, y = 11998, rule = B3/S23
2o$2o75$80b3o$80bo$81bo116$208b3o$208bo$209bo150$336b3o$336bo$337bo
126$464b3o$464bo$465bo124$592b3o$592bo$593bo119$720b3o$720bo$721bo134$
848b3o$848bo$849bo129$976b3o$976bo$977bo112$1104b3o$1104bo$1105bo116$
1232b3o$1232bo$1233bo125$1360b3o$1360bo$1361bo141$1488b3o$1488bo$1489b
o114$1616b3o$1616bo$1617bo142$1744b3o$1744bo$1745bo145$1872b3o$1872bo$
1873bo112$2000b3o$2000bo$2001bo132$2128b3o$2128bo$2129bo126$2256b3o$
2256bo$2257bo116$2384b3o$2384bo$2385bo138$2512b3o$2512bo$2513bo102$
2640b3o$2640bo$2641bo140$2768b3o$2768bo$2769bo103$2896b3o$2896bo$2897b
o116$3024b3o$3024bo$3025bo160$3152b3o$3152bo$3153bo123$3280b3o$3280bo$
3281bo138$3408b3o$3408bo$3409bo124$3536b3o$3536bo$3537bo114$3664b3o$
3664bo$3665bo122$3792b3o$3792bo$3793bo133$3920b3o$3920bo$3921bo140$
4048b3o$4048bo$4049bo119$4176b3o$4176bo$4177bo139$4304b3o$4304bo$4305b
o114$4432b3o$4432bo$4433bo132$4560b3o$4560bo$4561bo125$4688b3o$4688bo$
4689bo121$4816b3o$4816bo$4817bo98$4944b3o$4944bo$4945bo116$5072b3o$
5072bo$5073bo143$5200b3o$5200bo$5201bo115$5328b3o$5328bo$5329bo121$
5456b3o$5456bo$5457bo146$5584b3o$5584bo$5585bo118$5712b3o$5712bo$5713b
o140$5840b3o$5840bo$5841bo131$5968b3o$5968bo$5969bo125$6096b3o$6096bo$
6097bo110$6224b3o$6224bo$6225bo132$6352b3o$6352bo$6353bo125$6480b3o$
6480bo$6481bo121$6608b3o$6608bo$6609bo100$6736b3o$6736bo$6737bo116$
6864b3o$6864bo$6865bo160$6992b3o$6992bo$6993bo123$7120b3o$7120bo$7121b
o118$7248b3o$7248bo$7249bo135$7376b3o$7376bo$7377bo141$7504b3o$7504bo$
7505bo131$7632b3o$7632bo$7633bo108$7760b3o$7760bo$7761bo124$7888b3o$
7888bo$7889bo124$8016b3o$8016bo$8017bo123$8144b3o$8144bo$8145bo115$
8272b3o$8272bo$8273bo145$8400b3o$8400bo$8401bo103$8528b3o$8528bo$8529b
o123$8656b3o$8656bo$8657bo138$8784b3o$8784bo$8785bo125$8912b3o$8912bo$
8913bo115$9040b3o$9040bo$9041bo134$9168b3o$9168bo$9169bo138$9296b3o$
9296bo$9297bo131$9424b3o$9424bo$9425bo125$9552b3o$9552bo$9553bo110$
9680b3o$9680bo$9681bo132$9808b3o$9808bo$9809bo125$9936b3o$9936bo$9937b
o121$10064b3o$10064bo$10065bo100$10192b3o$10192bo$10193bo116$10320b3o$
10320bo$10321bo161$10448b3o$10448bo$10449bo126$10576b3o$10576bo$10577b
o115$10704b3o$10704bo$10705bo160$10832b3o$10832bo$10833bo115$10960b3o$
10960bo$10961bo131$11088b3o$11088bo$11089bo103$11216b3o$11216bo$11217b
o168$11344b3o$11344bo$11345bo126$11472b3o$11472bo$11473bo124$11600b3o$
11600bo$11601bo119$11728b3o$11728bo$11729bo134$11856b3o$11856bo$11857b
o129$11984b3o$11984bo$11985bo!

EDIT Here it's after some optimization:

Code: Select all

x = 7891, y = 7902, rule = B3/S23
2o$2o75$80b3o$80bo$81bo116$208b3o$208bo$209bo150$336b3o$336bo$337bo
126$464b3o$464bo$465bo124$592b3o$592bo$593bo119$720b3o$720bo$721bo134$
848b3o$848bo$849bo129$976b3o$976bo$977bo103$1104b3o$1104bo$1105bo137$
1232b3o$1232bo$1233bo117$1360b3o$1360bo$1361bo101$1488b3o$1488bo$1489b
o116$1616b3o$1616bo$1617bo160$1744b3o$1744bo$1745bo116$1872b3o$1872bo$
1873bo131$2000b3o$2000bo$2001bo115$2128b3o$2128bo$2129bo142$2256b3o$
2256bo$2257bo142$2384b3o$2384bo$2385bo135$2512b3o$2512bo$2513bo123$
2640b3o$2640bo$2641bo119$2768b3o$2768bo$2769bo134$2896b3o$2896bo$2897b
o129$3024b3o$3024bo$3025bo69$3152b3o$3152bo$3153bo124$3280b3o$3280bo$
3281bo124$3408b3o$3408bo$3409bo127$3536b3o$3536bo$3537bo123$3664b3o$
3664bo$3665bo114$3792b3o$3792bo$3793bo118$3920b3o$3920bo$3921bo116$
4048b3o$4048bo$4049bo151$4176b3o$4176bo$4177bo124$4304b3o$4304bo$4305b
o133$4432b3o$4432bo$4433bo127$4560b3o$4560bo$4561bo126$4688b3o$4688bo$
4689bo130$4816b3o$4816bo$4817bo135$4944b3o$4944bo$4945bo123$5072b3o$
5072bo$5073bo138$5200b3o$5200bo$5201bo118$5328b3o$5328bo$5329bo114$
5456b3o$5456bo$5457bo105$5584b3o$5584bo$5585bo115$5712b3o$5712bo$5713b
o132$5840b3o$5840bo$5841bo154$5968b3o$5968bo$5969bo115$6096b3o$6096bo$
6097bo132$6224b3o$6224bo$6225bo145$6352b3o$6352bo$6353bo116$6480b3o$
6480bo$6481bo160$6608b3o$6608bo$6609bo123$6736b3o$6736bo$6737bo133$
6864b3o$6864bo$6865bo127$6992b3o$6992bo$6993bo135$7120b3o$7120bo$7121b
o131$7248b3o$7248bo$7249bo121$7376b3o$7376bo$7377bo123$7504b3o$7504bo$
7505bo119$7632b3o$7632bo$7633bo134$7760b3o$7760bo$7761bo129$7888b3o$
7888bo$7889bo!

[dvgrn]

Here are some preliminary results on slow salvo without oscillators...

Have you seen the data from the original 'Glue', Paul Chapman's P1 block-move search from back in 2004? I'm pretty sure there are no oscillator intermediates in any of those recipes.

If you want to build other things besides blocks, one easy way to get usable recipes would be to progressively truncate each of those block-move recipes: before the last glider, the partial recipe must have built something P1. I did this trick for the newer P2 block-move table, and it gave me plenty of options for every orientation of every still life used in Spartan Herschel circuitry, except for the eaters, and quite a few two-object constellations as well.

Unfortunately it will take a little more sorting to find the good P1 stuff. The P2 Glue results are all atomic recipes, but the old P1 recipes were mostly composite. On the positive side, there's a probably-minimal P1 block-move recipe in that list for every (X,Y) offset in a fairly wide range, as shown by the index image:

Partial index image for P1 block move costs

P1-block-move-index-image.png (57.81 KiB) Viewed 22219 times

Truncating block moves wouldn't give you an exhaustive list of recipes, by any means, but on the other hand you wouldn't have to rewrite Glue. Not that a new Glue would be a bad thing by any means -- the original was a proof-of-concept built with a very old and cranky version of Smalltalk. Oblique's sscs search code comes pretty close to being a new Glue, but it hasn't been proven to be very customizable yet.

[simsim314]

Have you seen the data from the original 'Glue', Paul Chapman's P1 block-move search from back in 2004? I'm pretty sure there are no oscillator intermediates in any of those recipes.

Hi dvgrn, thx.

Actually the moving tables as I now discover have a real limitation. Take this recipe:

Code: Select all

x = 178, y = 153, rule = B3/S23
b2o$b2o2$bo$2o$obo4$16b2o$15b2o$17bo3$17b2o$17bobo$17bo10$25bo$24b2o5b
2o$24bobo3b2o$32bo46$94b2o$94bobo$94bo8$75b2o$75bobo$75bo4$99b3o$99bo
5b2o$100bo3b2o$106bo5$117b2o$117bobo$117bo5$117b3o$117bo$118bo42$176b
2o$175b2o$177bo!

Can you imagine using it around some SLs? The answer is maybe, depends. So there should be no single recipe per block move. Actually what we need is an array of recipes that might work, and compile script that will optimize the result, while trying few recipes and figuring out which is the best to use that doesn't destroy anything around it.

I've recently written something with this approach. I needed a new set of recipes for the move table, that will include all possible moves, with N gliders (currently 7), and then a compiler that will take all the possible routs and will find those that will at the least work with previous recipes. As you can see in the preliminary results, the compiler is working, but no optimization was made to make it more efficient, this might take more time - it was trying few recipes, and only made sure there was nothing messed up by applying it, it still doesn't optimize all the possible variations and taking the smallest possible.

EDIT By the way dvgrn, do you have some idea for blinkerless MWSS edge shooter which is better than this:

Code: Select all

x = 43, y = 69, rule = B3/S23
bo$2bo$3o21$32b2o$32b2o8$35b2o$35b2o4$4b2o$4b2o$33b2o$33b2o5$14b2o$9b
2o3b2o$9b2o29b2o$29bo9bo2bo$28bobo9b2o$28bobo$29bo6bo$35bobo$35bobo$
36bo3$35b2o$35b2o5$34b2o$33bo2bo$30bo3b2o$29bobo$29bobo$30bo!

For HWSS I got this:

Code: Select all

x = 17, y = 24, rule = B3/S23
14b2o$14b2o10$7b2o5b2o$7b2o4bo2bo$2bo11b2o$obo$b2o2$11b2o$10bo2bo$10bo
bo$11bo2$4b2o$4b2o!

[dvgrn]

By the way dvgrn, do you have some idea for blinkerless MWSS edge shooter which is better than this...

Hmm, I don't recall that an initial blinker was really a requirement for an MWSS edge-shooter. There are some workable edge-shooting recipes in oblique's search results, aren't there? I'll look again when I have some time. Unlike the 31c/240 project, you need edge shooters that don't block the output lane with leftover junk, correct?

I'm working on an exhaustive search of two-common-object constellations, looking for a few good glider splitters. So eventually it will probably be possible to replace the three-block splitters with something just a little bit cheaper, anyway (though without a database of minimal slow-salvo recipes for such constellations, it will be hard to know for sure.)

For HWSS I got this:

Code: Select all

x = 17, y = 24, rule = B3/S23
14b2o$14b2o10$7b2o5b2o$7b2o4bo2bo$2bo11b2o$obo$b2o2$11b2o$10bo2bo$10bo
bo$11bo2$4b2o$4b2o!

Glad to see that one is getting some use -- it has a really impressive sideways reach. I seem to recall the preliminary spark that touches the HWSS lane caused problems at p240, so couldn't be used in the Centipede.

[simsim314]

Hmm, I don't recall that an initial blinker was really a requirement for an MWSS edge-shooter

Well unfortunately all the recipes include at least one blinker, and that blinker can't be removed.

Here is a bit less terrible (9 SLs and not 12):

Code: Select all

x = 38, y = 58, rule = B3/S23
2bo$obo$b2o20$32b2o$32b2o8$35b2o$35b2o5$8b2o$2b2o4b2o23b2o$2b2o29b2o4$
15b2o$15b2o19b2o$26b2o7bobo$25bo2bo7bo$26bobo$27bo8$36b2o$36b2o!

though without a database of minimal slow-salvo recipes for such constellations, it will be hard to know for sure

I'm actually working on very extensive database for any B -> SL slow salvo with all the possible ways. This is part of my search (I just take all SLs and place them into results (not only those with block) + I don't filter anything from step to step, so it comes out as much brute force as it gets.

[simsim314]

I'm working on an exhaustive search of two-common-object constellations, looking for a few good glider splitters.

Great tip thx. Using this approach I've found how to optimize the whole thing to 6 SLs - which is acceptable price.

Code: Select all

x = 37, y = 32, rule = LifeHistory
.C$2.C$3C$26.C$25.C.C$26.2C8$10.2C$10.C.C$11.2C3$35.2C$25.2C7.C.C$24.
C2.C7.C$2C23.C.C$C.C23.C$.C7$35.2C$35.2C!

EDIT Also built this for just in case (8 SLs):

Code: Select all

x = 37, y = 52, rule = LifeHistory
.C$2.C$3C14$19.2C$18.C2.C$18.C2.C$19.2C5$24.2C$24.C.C$25.2C5$26.C$25.
C.C$25.C.C6.2C$26.C7.C.C$35.C3$5.C$4.C.C$5.2C25.2C$32.2C5$31.2C$30.C
2.C$27.C3.2C$26.C.C$26.C.C$27.C!

---

Here is a small script I've written to find many splitters using common objects (actually those that can be constructed under 7 gliders with slow salvo):

Code: Select all

import golly as g 

vals = g.parse("bo99bo99bo99bo99bo99bo99bo99b2o98b2o98b2o98b2o98b2o98b2o98b2o98b2o98b2o98b2o$obo97bobo97bobo97bobo97bobo97bobo97bobo97bobo97bobo97bobo97bo2bo96bo2bo96bo2bo96bo2bo97b2o98bobo97bobo$2o98bobo97bo2bo95bobo97bo2bo98b2o98bo98b2o97bobo99bo98bobo97bo2bo97b2o98bobo198b2o98bo$101bo99b2o96b2o99b2o398bo200bo99b2o199bo!")
gld = g.parse("3o$o$bo!")

g.new("")
g.setrule("S23/B3")
g.setalgo("HashLife")

g.putcells(vals)

rect = g.getrect()
result = []

stables = []

for i in xrange(-10, rect[2] + 10, 100):
	stables.append(g.getcells([i, -10, 20, 20]))

for i in xrange(0, len(stables)): 
	g.new("")
	g.putcells(stables[i])
	rect = g.getrect()
	g.new("")
	g.putcells(stables[i], -rect[0], -rect[1])
	stables[i] = g.getcells([0, 0, rect[2], rect[3]])

cpu = 0
min = cpu * 3
max = (cpu + 1) * 3

if len(stables) < max:
	max = len(stables)

#cellArray = [2,2,2,2,0,0,0,2,2,2,0,0,0,0,0,0]

for i in xrange(min, max):
	for j in xrange(0, len(stables)):
		for x in xrange(-10, 11):
			for y in xrange(0, 11):
				g.new(str(i) + "," + str(j) + "," + str(x) + "," + str(y))
				#g.setrule("S23/B3")
				
				g.putcells(stables[i])
				g.putcells(stables[j], x, y)
				cells = str(g.getcells(g.getrect()))
				g.run(1)
				
				if str(cells) != str(g.getcells(g.getrect())):
					continue 
				
				g.show(str(result))
				g.update()
				
				for k in xrange(-25, 26):
					g.new("")
					g.setstep(3)
					#g.setrule("LifeHistory")

					g.putcells(stables[i])
					g.putcells(stables[j], x, y)
					g.putcells(gld, 20 + k, 20)
					
					g.step()
					g.step()
					
					rect = g.getrect()
					
					if rect == []:
						continue 
						
					xmin = rect[0]
					ymin = rect[1]
					xmax = rect[0] + rect[2]
					ymax = rect[1] + rect[3]
					
					rect = g.getrect()
					
					if int(g.getpop()) == 10 and len(g.getcells([-80, -80, 160, 160])) == 0:
						result.append([i, j, x, y, k])

					#if xmin < -300 or ymin < -300 or  xmax > 300 or ymax > 300:
						

g.new("")
g.show(str(result))
d = 0 
for r in result:
	i = r[0]
	j = r[1]
	x = r[2]
	y = r[3]
	k = r[4]
	
	g.putcells(stables[i], d, 0)
	g.putcells(stables[j], x + d, y)
	g.putcells(gld, 20 + k + d, 20)
	
	d += 300

It's optimized to run on 6 cpu's. Just increase the cpu index, and run golly once more.

[dvgrn]

Using this approach I've found how to optimize the whole thing to 6 SLs - which is acceptable price.

6sL is quite an improvement -- and that's a very impressive splitter, too: for about 240 ticks I was thinking that that explosion couldn't possibly fade out into nothing but gliders.

Here is a small script I've written to find many splitters using common objects (actually those that can be constructed under 7 gliders with slow salvo)...

Thanks! I might try borrowing the glider collision test code to add to my constellation enumeration script. I'm interested in turners as well as splitters, though -- really any collision will be interesting if it has

if int(g.getpop()) > 0 and len(g.getcells([-80, -80, 160, 160])) == 0:

You might see a few spaceship outputs if you changed the code so it wouldn't just discard them -- who knows, maybe even an edge-shooter.

I'm also very curious about int(g.getpop())=15 or 20, though I doubt that that many clean gliders will show up very often from just two objects... One phase of an MWSS is population 15, but it looks like any other multiples of five will really be gliders.

It's optimized to run on 6 cpu's. Just increase the cpu index, and run golly once more.

Hmm, maybe it's worth writing a little Python library function to return the current highest running CPU number -- each script could write a 0.txt, 1.txt, etc., to a Users/{username}/AppData/Roaming/Golly/ subdirectory (i.e., Golly's default path for the OS), and delete it when the search is completed or cancelled.

There's always the problem of files getting stranded if a script is interrupted and can't clean up after itself. Don't know if that would be much of a problem here, but I guess each script could write a current timestamp to its N.txt every few minutes, and new scripts looking for a number could delete any files that they find that are over an hour old (or whatever).

[simsim314]

I'm interested in turners as well as splitters

Well before the 10 I run 5, while searching for "edge shooters" for gliders. For example if we have some edge shooter that just shoots in "wrong" direction, we might add glider edge shooter (turning glider 180 degree) to fix it.

Beforehand, I've also run a script looking for *WSS (the min max < > 300 part which is marked), unfortunately I've found only 2 "almost" edge shooters from the script, but nothing that will really work.

Anyway I've cherry picked few that looked interesting from the single glider output:

Code: Select all

x = 700, y = 184, rule = LifeHistory
.C$C.C$C.C8.2C$.C8.C2.C$11.C.C$12.C4$185.C$184.C.C$184.2C2$447.C$183.
2C261.C.C$183.C.C260.2C$184.2C256.2C$442.C.C$443.2C2$13.3C$13.C$14.C
4$682.C$681.C.C$681.2C$208.3C$208.C$209.C2$453.3C$453.C224.C$454.C
222.C.C$677.C.C$678.C9$697.3C$697.C$698.C94$667.C$666.C.C$666.2C2$
458.C$457.C.C$457.C.C6.C199.2C$458.C6.C.C197.C.C$466.C197.C.C$665.C
10$177.C$176.C.C512.3C$176.C.C512.C$177.C514.C$183.2C$182.C2.C298.3C$
182.C2.C298.C$183.2C300.C13$191.3C$191.C$192.C!

--

Yes the cpu issue is really annoying. I guess some small file, that just has the number of last run cpu, would really help, just not to increase the index manually 5 times, every time.

[dvgrn]

Quick clarification: I'm not entirely clear about the prohibition on P2 final junk, though I think I understand the problem with P2 intermediate targets.

For example, there's an extra beehive in the 8sL MWSS recipe from three messages up, which converts a blinker and a block into three ash objects -- not an improvement at all, except that the result isn't P2 any more. So this could maybe be a 7sL recipe, if the leftover blinker can be dealt with. (There's also a boat suppression option shown, which looks like an improvement on the beehive.)

Code: Select all

x = 107, y = 51, rule = B3/S23
bo69bo$2bo69bo$3o67b3o14$19b2o68b2o$18bo2bo66bo2bo$18bo2bo66bo2bo$19b
2o68b2o5$24b2o68b2o$24bobo67bobo$25b2o68b2o7$34b2o60bo7b2o$34bobo58bob
o6bobo$35bo59b2o8bo3$5bo21bo47bo21bo$4bobo21bo45bobo21bo$5b2o19b3o46b
2o19b3o2$34b2o68b2o$33bobo67bobo$33b2o68b2o3$26b2o68b2o$25bo2bo66bo2bo
$26bobo67bobo$27bo69bo!

Or it could be 6sL plus one glider, as shown, since those bottom three objects can be built from a loaf-and-ship constellation, borrowed from this P2 recipe:

Code: Select all

x = 173, y = 160, rule = B3/S23
2bo$obo$b2o5$22bo$20bobo$21b2o29$42bo$40bobo$41b2o18bo$62b2o$61b2o32$
82bo19bo$80bobo17bobo$81b2o18b2o25$121bo$122b2o$121b2o29$142bo$140bobo
$141b2o5$161bo$162b2o$161b2o3$168bo$168bo$168bo2$164b3o3b3o7$164b3o3b
3o2$168bo$168bo$168bo!

From what I understand, P2 recipes like this won't work in this engineless caterpillar project, because you want to be able to allow either even or odd distances between successive slow-salvo gliders. If you use them, you have to build even- and odd-period adjustable slow-salvo caterpillars with completely different recipes. Do I have that right?

Okay, but as for leftover blinkers that you just want to get rid of: it may be a little cheaper to just handle the cleanup in a period-independent way, instead of building extra still lifes to prevent the blinkers from forming. There are quite a few reactions like these, with different base collisions:

Code: Select all

#C the two period-independent "blinker detonator" reactions
x = 66, y = 8, rule = B3/S23
5bo49bo$6bo49bo$4b3o7bo39b3o$14bo48b3o$14bo$o$o6b2o40b3o5b2o$o6b2o48b
2o!

I suppose that means that P2 objects could also be allowed as intermediate targets in a few cases. They could be kept in a search as long as each new glider collision was tested at both even and odd parities, and the result was exactly the same. But that would expand the search tree enormously and only produce a tiny percentage of new recipes -- probably you'd only bother looking for those recipes if you wanted to show off.

[simsim314]

From what I understand, P2 recipes like this won't work in this engineless caterpillar project, because you want to be able to allow either even or odd distances between successive slow-salvo gliders.

The enginless is a bit non intuitive construction. The distance between the slow salvos will be 59 (at least this I've recipes for - but it's pretty adjustable). The distance between the SLs in the tape is 2*N - which allows any lane.

This is of course nice - but now consider how do we adjust the period. Say we have 59/800, and want 59/801 - the only thing we do is just evolving the "Reading Head" (the constellation of 5-7 *WSS which converts the SL -> G), by 801 ticks instead of 800.

That would be nice on paper, but in practice evolving something by even period, will give single parity. Now if we want periods of 4*N all the gliders will be in same internal state, shoot from each lane, in generations which is 4*N. That essentially means no parity at all, if we want to cover all possible periods.

Of course covering all possible periods has some more hidden issues, but the one with slow salvo is very clear. Either blinkerless slow salvos, or getting into a lot of special cases, or just let go of some periods, like building it for 2*N + 1 periods.

I chose to go for blinkerless slow salvos, as it looks pretty OK, and has the benefit to avoid special cases together with covering all periods. Obviously it has it's own price, but I figure the price is the lowest among other options.

So this could maybe be a 7sL recipe, if the leftover blinker can be dealt with. (There's also a boat suppression option shown, which looks like an improvement on the beehive.)

Thanks, looks very nice. The suppression is really a minor issue, as it costs only one slow salvo glider for clearing, and about 10-15 to placing SL in "tight" place (and 5-8 for placing it in reasonable clearance). Actually it's more important to have a bit more space between SLs, than the number of leftover SLs.

Okay, but as for leftover blinkers that you just want to get rid of: it may be a little cheaper to just handle the cleanup in a period-independent way, instead of building extra still lifes to prevent the blinkers from forming.

Well those interactions are pretty rare - so we need specially place extra SLs in correct position just to clear the blinker. It's the same as just placing the SL in the first place so blinkers wouldn't be born.

As for getting track for even+odd cases - just a waste of effort on my opinion, might work, wouldn't go there.

[simsim314]

Conducting a search for edge-shooters - with 3 SLs. Here is a preliminary (clear) result with 5 SL:

Code: Select all

x = 33, y = 35, rule = LifeHistory
26.2C$25.C2.C$26.C.C$27.C3$.C$2.C$3C12$21.2C$20.C2.C$21.2C$27.C$26.C.
C$25.C2.C$26.2C3$31.C$30.C.C$31.2C$25.2C$24.C.C$25.C!

Very nice 4 SLs HWSS edge shooter:

Code: Select all

x = 22, y = 18, rule = B3/S23
bo15b2o$2bo13bobo$3o13b2o2$20bo$19bobo$20b2o2$18bo$17bobo$17bo2bo$18b
2o4$14b2o$13bobo$14bo!

EDIT 4 SLs! for the MWSS edge shooter:

Code: Select all

x = 22, y = 25, rule = LifeHistory
20.2C$20.2C$.C$2.C$3C8$7.2C$7.C.C10.2C$8.C10.C.C$20.C7$18.C$17.C.C$
18.C!

This probably can be useful:

Code: Select all

x = 10, y = 33, rule = LifeHistory
4$4.2C2.C$5.3C$6.C11$5.C$4.C.C$3.C2.C$4.2C6$4.2C$4.C.C$5.2C!

EDIT Much cleaner and faster 4 SLs MWSS edge shooter:

Code: Select all

x = 25, y = 34, rule = LifeHistory
.C$2.C$3C10$23.C$22.C.C$18.2C2.C.C$17.C.C3.C$17.2C4$22.2C$21.C.C$22.C
9$22.2C$21.C.C$22.C!

And another one:

Code: Select all

x = 23, y = 33, rule = B3/S23
2bo$obo$b2o$18b2o$18bobo$19bo12$20bo$19bobo$20b2o4$21bo$20bobo$19bobo$
19b2o4$12b2o$11bo2bo$12b2o!

EDIT2 3Sl clean LWSS edge shooter:

Code: Select all

x = 23, y = 23, rule = LifeHistory
.C$2.C$3C10$16.2C$15.C.C$16.C6$10.2C8.2C$10.C.C6.C2.C$11.2C7.2C!

[chris_c]

I can see how these P1 recipes are going to work to build a *WSS in a particular column, but how are you going to make the timing correct? It seems to me like the only way to adjust the timing is to move the construction site 2 cells north or south which will make the constructed spaceship move by +/-4 cells. I don't see how that is going to give enough freedom without recipes for the same type of spaceship that have different timing mod 8.

In the 31c/240 spaceship it was easy because you could adjust the timing of each rake independently of the rest, but I don't think that applies here. Maybe I am missing something?

[simsim314]

how are you going to make the timing correct?

A bit about timing: You don't really need to to have anything mod 8. if two *WSS recipes are working at distance of N generations, they will continue working at distance N + 1 generations.

To demonstrate this idea, take a look at this pattern:

Code: Select all

x = 62, y = 720, rule = B3/S23
14b2o$13b3o$13b3o$13b3o$13b2obo$14b3o$15bo145$58bobo$61bo$57bo3bo$57bo
3bo$61bo$58bo2bo$59b3o81$12b2o$11b3o$11b3o$11b3o$11b2obo$12b3o$13bo54$
23bobo$22bo$22bo3bo$22bo$22bo2bo$22b3o8$b2o$3o$3o$2obo11bobo$b3o10bo$
2bo11bo3bo$14bo3bo$14bo$14bo2bo$14b3o146$59b2o$58b3o$58b3o$58b3o$58b2o
bo$59b3o$60bo80$13bobo$12bo$12bo3bo$12bo3bo$12bo$12bo2bo$12b3o55$23b2o
$23b3o$23b3o$22bob2o$22b3o$23bo7$2bobo$bo6b2o$bo3bobo2bo$bo5bobo$bo2bo
3bo$b3o26$8b2o$7bo2bo$7bobo$8bo57$8b2o$7bo2bo$7bobo$8bo!

The same recipe can be applied after 511 generations. No need to be 0 mod 2 or mod 8.

---

Saying that..You're absolutely right, for the G + *WSS -> SL part (the beginning of the chain of slow salvos). There I think using case to case approach. I just want to minimize all the places where period can have an influence, but obviously for very low periods the ship will grow - and this because of slow salvo birth issue.

I also consider to make negative helix for the tail, so no timing issues there as well (although, it will increase the size of the ship significantly - it will really decrease all the special cases, and for that time I'll have recipes for all *WSS slow salvo edge shooters, so it should be piece of cake in this sense, hopefully).

[dvgrn]

Yes the cpu issue is really annoying. I guess some small file, that just has the number of last run cpu, would really help, just not to increase the index manually 5 times, every time.

Here's some code that seems to work well. I suppose the quickest way to get six copies of the script running would be to put the script in Golly's root directory and temporarily rename it golly-start.py. Then just open instances of Golly one after another. Once six copies are running, script copies 7, 8, etc. will exit immediately because there are no more objects in the list. That seems like good behavior.

I made some minor changes to the script, and haven't tested them really thoroughly yet, so it might be safer just to copy the header lines and getCPUnum() subroutine into the original version of the script. And of course you also have to include "cpu = getCPUnum()" instead of "cpu=0".

I have my base step size set to 2 instead of 8, where it looks as if your code assumes 8 and won't work too well if it's something different. I changed a few lines below to fix that -- I think -- haven't run the new version long enough yet to confirm that it's still finding spaceships and splitters properly.

Code: Select all

import golly as g 
import os
from datetime import datetime

SCRIPTNAME = "splittersearch"
RESET_SECONDS = 999

def getCPUnum():
  num, in_use, now = 0, 1, datetime.utcnow()
  while in_use:
    fnpath=os.path.join(g.getdir("data"), SCRIPTNAME)
    fn=os.path.join(fnpath, str(num)+".dat")
    if os.path.isfile(fn):
      with open(fn,"r") as f: lastdate=f.readline().split(",")
      diff = datetime.utcnow() - datetime(*[int(i) for i in lastdate])
      if diff.total_seconds()<RESET_SECONDS: num+=1
      else: in_use = 0
    else: in_use = 0
    if in_use==0:
      if not os.path.exists(fnpath):
        os.makedirs(fnpath)
      with open(fn,"w") as f: f.write(str([now.year, now.month, now.day, now.hour, now.minute, now.second])[1:-1])
  return num

vals = g.parse("bo99bo99bo99bo99bo99bo99bo99b2o98b2o98b2o98b2o98b2o98b2o98b2o98b2o98b2o98b2o$obo97bobo97bobo97bobo97bobo97bobo97bobo97bobo97bobo97bobo97bo2bo96bo2bo96bo2bo96bo2bo97b2o98bobo97bobo$2o98bobo97bo2bo95bobo97bo2bo98b2o98bo98b2o97bobo99bo98bobo97bo2bo97b2o98bobo198b2o98bo$101bo99b2o96b2o99b2o398bo200bo99b2o199bo!")
gld = g.parse("3o$o$bo!")

g.new("")
g.setrule("S23/B3")
g.setalgo("HashLife")
g.setbase(2)
g.setstep(10)

g.putcells(vals)

rect = g.getrect()
result = []
stables = []

for i in xrange(-10, rect[2] + 10, 100):
   stables.append(g.getcells([i, -10, 20, 20]))

for i in xrange(0, len(stables)): 
   g.new("")
   g.putcells(stables[i])
   rect = g.getrect()
   g.new("")
   g.putcells(stables[i], -rect[0], -rect[1])
   stables[i] = g.getcells([0, 0, rect[2], rect[3]])

cpu = getCPUnum()
min = cpu * 3
max = (cpu + 1) * 3
if len(stables) < max: max = len(stables)

for i in xrange(min, max):
   for j in xrange(0, len(stables)):
      for x in xrange(-10, 11):
         for y in xrange(0, 11):
            g.new(str(i) + "," + str(j) + "," + str(x) + "," + str(y))
            
            g.putcells(stables[i])
            g.putcells(stables[j], x, y)
            cells = str(g.getcells(g.getrect()))
            g.run(1)
            
            if str(cells) != str(g.getcells(g.getrect())):
               continue 
            
            g.show(str(result))
            g.update()
            
            for k in xrange(-25, 26):
               g.new("")

               g.putcells(stables[i])
               g.putcells(stables[j], x, y)
               g.putcells(gld, 20 + k, 20)
               
               g.step()               
               rect = g.getrect()               
               if rect == []: continue 
                  
               xmin = rect[0]
               ymin = rect[1]
               xmax = rect[0] + rect[2]
               ymax = rect[1] + rect[3]
               
               # currently set to find any clean conversion to moving object(s):
               #  adjust ">0" to "=10" to find glider splitters,
               #   or appropriate values for other specific conversions
               # The following would find any spaceship output (clean or dirty)
               #if xmin < -300 or ymin < -300 or  xmax > 300 or ymax > 300:

               if int(g.getpop())>0 and len(g.getcells([-80, -80, 160, 160])) == 0:
                  result.append([i, j, x, y, k])

g.new("")
g.show(str(result))
d = 0 
for r in result:
   i,j,x,y,k = r   
   g.putcells(stables[i], d, 0)
   g.putcells(stables[j], x + d, y)
   g.putcells(gld, 20 + k + d, 20)
   
   d += 300

I set RESET_SECONDS = 999, so you have to start all six instances within 16 minutes or so. Otherwise new instances will start searching from the beginning again.

I think I'll adapt this to quickly start multi-core overnight runs of apgsearch as well.

[simsim314]

I suppose the quickest way to get six copies of the script running would be to put the script in Golly's root directory and temporarily rename it golly-start.py.

I didn't know about this feature of golly. One can do this in batch or external script - this will remove the problem of temporary renaming issues (the batch will do it automatically), and the need to open manually instances of golly.

I have my base step size set to 2 instead of 8

Definitely this will be an issue...this was just small script I wrote for myself in 10 minutes. The run time is about half hour (on 6 CPUs), in those cases I even don't worry about optimization, I just wait (my time spent on optimization will be much more than half hour).

I think I'll adapt this to quickly start multi-core overnight runs of apgsearch as well.

Glad it was helpful.

---

Meanwhile I was trying to build slow salvo recipes for the new 4 SLs edge shooters (here), and found out slow salvo has some serous limitation, for SLs placed tightly together and if the output *WSS is too close to the recipe.

So until my 8 gliders script for slow salvo is still in progress, I can't say for sure if the recipes are useful or not, but it seems the problem is a bit less "linear" than what I was expecting.

I also run a depth search for 3 SLs in 10x10, for VERY good edge shooters (I started to get too many 4 SLs recipes), but now I think maybe it wasn't such a good idea, as slow salvo can ruin pretty easily even not so bad edge shooter.

[dvgrn]

So until my 8 gliders script for slow salvo is still in progress, I can't say for sure if the recipes are useful or not, but it seems the problem is a bit less "linear" than what I was expecting.

I also run a depth search for 3 SLs in 10x10, for VERY good edge shooters (I started to get too many 4 SLs recipes), but now I think maybe it wasn't such a good idea, as slow salvo can ruin pretty easily even not so bad edge shooter.

I take it the main problem is finding recipes for individual still lifes in a constellation, where the intermediate targets don't get in the way of the output spaceship, and the construction sparks don't hit other already-constructed still lifes.

This was a fairly infuriating problem even for recipes found for the 31c/240 project, and I suspect it will be even more annoying for P1-only slow salvos. Generally a way can be found to complete the construction, but by the time you've found workarounds for all of the awkward little layout problems, you end up with a very expensive and clearly suboptimal recipe (arrgh).

The only way around that seems to be the method that oblique used in 'sscs': enumerate all valid slow salvos in order of cost until working edge-shooters start to show up. Seems as if it shouldn't be too difficult to adjust sscs code to leave out all the P2 initial targets and disallow P2 intermediates... but I wouldn't know for sure -- haven't dared to try hacking sscs myself yet.

The big problem seems to be that edge shooters are just far enough out on any search tree that keeping track of all the data is a challenge for your average home computer. A P1 search tree would go a lot deeper in terms of the number of gliders, but will probably start getting good edge-shooter results after examining about the same number of possibilities... maybe a factor of two or an order of magnitude more, I'm guessing.

There are definitely a lot of tricks that could be tried to get sscs to do its work more efficiently, but those are a good bit more complicated than the obvious P2->P1 hacks.