Prototype / demo for a (weighted) collision search program

For scripts to aid with computation or simulation in cellular automata.
User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » February 26th, 2014, 4:30 pm

oblique wrote:Hmm. Choosing initial targets is easy. Just put them in a file together (my program should be able to load rle, gencol results and the traditional ***.*** notation without problems - just leave empty lines between to rle or ***.*** patterns).
Sorry, I didn't really finish the thought. One important detail is that List 1 and List 2 objects can only be built in certain specific columns close to the block trails. You can build any of them anywhere you want, as long as it's sufficiently far away -- but for some objects you might have to go out a fair distance from the trails to get a free choice of location.

The idea is to run some rephasers, then a backrake, then some other number of rephasers, and then a forerake, to hit exactly the right lanes. You might need several rephasers between the rakes, so at a guess, you might not have absolutely free choice of List 1 or List 2 until around 1000-1500 cells from the trails.

So... is it worth worrying about including (x,y) locations as part of these List 1 / List 2 targets?
oblique wrote:I didn't quite get which orientations of - say - the pi mess should be included ...
The messy explosions were included in the lists only to make the collision sequences easier to recognize -- it probably won't be useful to build them very often. I suppose some of the pi explosions might come in handy to absorb extra gliders, up toward the top of the spaceship, but you're very likely to end up with period-doubling effects that are too annoying to be worth the trouble.

Gliders on the same color squares will build List 1, and gliders on different color squares will produce List 2. But I'm not sure that's easy for everyone to translate into useful information... Basically you're in List 1 if you can adjust the timing and crash two gliders together and get a pi explosion (or a pond, eater, interchange, or anything that's just beehives, like a honeyfarm). If you see traffic lights or single blinkers, glider kickbacks, or B-heptominos, you're in List 2. Blocks are less conclusive, but you can generally tell where you are by testing a few glider collisions with adjacent timings.

Here are all the workable orientations for left-side construction, in order, with List 1 in the top row:

Code: Select all

x = 964, y = 84, rule = B3/S23
7bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24b
o24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo
24bo24bo24bo24bo$6bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo
24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo
24bo24bo24bo24bo24bo24bo24bo24bo24bo$6b3o22b3o22b3o22b3o22b3o22b3o22b
3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b
3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b
3o22b3o22b3o22b3o22b3o2$5bo74bo24bo49bo649bo49bo24bo74bo$o75bo$2b2o23b
2o24bo47bo50bo$b2o24bobo22b2o23b3o23b2o23b2o24bo$3bo23bo24bobo22bo24b
2o24bobo22b2o23b3o23b2o23b2o24bo$78bo25bo23bo24bobo22bo24b2o24bobo22b
2o23b3o23b2o23b2o24bo$179bo25bo23bo24bobo22bo24b2o24bobo22b2o23b3o23b
2o23b2o24bo$280bo25bo23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo
$381bo25bo23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo$482bo25bo
23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo47bo50bo24bo$583bo25b
o23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo98bo$684bo25bo23bo
24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo$785bo25bo23bo24bobo22bo
24b2o24bobo22b2o$886bo25bo23bo24bobo36$38b2o24b2o510b2o$38b2o24b2o510b
2o6$7bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24b
o24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo
24bo24bo24bo24bo24bo$6bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo
24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo
24bo24bo24bo24bo24bo24bo24bo24bo24bo24bo$6b3o22b3o22b3o22b3o22b3o22b3o
22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o
22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o22b3o
22b3o22b3o22b3o22b3o22b3o2$o4bo449bo49bo449bo$2b2o23b2o24bo$b2o24bobo
22b2o23b3o23b2o23b2o24bo$3bo23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o
23b2o24bo$78bo25bo23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo98b
o$179bo25bo23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo47bo$280bo
25bo23bo24bobo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo$381bo25bo23bo24b
obo22bo24b2o24bobo22b2o23b3o23b2o23b2o24bo$482bo25bo23bo24bobo22bo24b
2o24bobo22b2o23b3o23b2o23b2o24bo$583bo25bo23bo24bobo22bo24b2o24bobo22b
2o23b3o23b2o23b2o24bo98bo$684bo25bo23bo24bobo22bo24b2o24bobo22b2o23b3o
23b2o23b2o24bo$785bo25bo23bo24bobo22bo24b2o24bobo22b2o$886bo25bo23bo
24bobo5$374b2o$374b2o542b2o$918b2o!
#C or if you prefer LifeHistory with labels...
x = 971, y = 100, rule = LifeHistory
2.D3.D.D2.2D2.2D62.3D2.D20.3D2.D42.D3.D.3D2.2D2.2D633.D3.D.3D2.2D2.2D
37.3D2.D20.3D2.D65.D3.D.D2.2D2.2D$2.2D.2D.D.D3.D64.D2.D.D20.D2.D.D42.
2D.2D.D3.D3.D635.2D.2D.D3.D3.D39.D2.D.D20.D2.D.D65.2D.2D.D.D3.D$2.D.D
.D.D2.D3.D63.3D2.D20.3D2.D42.D.D.D.2D3.D3.D634.D.D.D.2D3.D3.D38.3D2.D
20.3D2.D65.D.D.D.D2.D3.D$2.D3.D.D3.D3.D62.D4.D20.D4.D42.D3.D.D5.D3.D
633.D3.D.D5.D3.D37.D4.D20.D4.D65.D3.D.D3.D3.D$2.D3.D.D.2D2.2D63.D4.D
20.D4.D42.D3.D.3D.2D2.2D634.D3.D.3D.2D2.2D38.D4.D20.D4.D65.D3.D.D.2D
2.2D6$10.A24.C24.C24.A24.A24.C24.A24.C24.C24.C24.C24.C24.C24.C24.C24.
C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.A
24.C24.A24.A24.C24.C24.A$9.A24.C24.C24.A24.A24.C24.A24.C24.C24.C24.C
24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C
24.C24.C24.C24.C24.A24.C24.A24.A24.C24.C24.A$9.3A22.3C22.3C22.3A22.3A
22.3C22.3A22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.
3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C
22.3A22.3C22.3A22.3A22.3C22.3C22.3A2$8.A74.A24.A49.A649.A49.A24.A74.A
$3.A75.A$5.2A23.2C24.C47.A50.A$4.2A24.C.C22.2C23.3A23.2A23.2C24.A$6.A
23.C24.C.C22.A24.2A24.C.C22.2A23.3C23.2C23.2C24.C$81.A25.A23.C24.A.A
22.C24.2C24.C.C22.2C23.3C23.2C23.2C24.C$182.C25.C23.C24.C.C22.C24.2C
24.C.C22.2C23.3C23.2C23.2C24.C$283.C25.C23.C24.C.C22.C24.2C24.C.C22.
2C23.3C23.2C23.2C24.C$384.C25.C23.C24.C.C22.C24.2C24.C.C22.2C23.3C23.
2C23.2C24.C$485.C25.C23.C24.C.C22.C24.2C24.C.C22.2C23.3C23.2C23.2C24.
C47.A50.A24.A$586.C25.C23.C24.C.C22.C24.2C24.C.C22.2C23.3C23.2A23.2C
24.A98.A$687.C25.C23.C24.C.C22.C24.2A24.C.C22.2A23.3A23.2C23.2C24.A$
788.C25.A23.C24.A.A22.A24.2C24.C.C22.2A$889.A25.C23.C24.A.A36$41.2A
24.2A510.2A$41.2A24.2A510.2A6$10.A24.C24.C24.C24.C24.C24.C24.C24.C24.
C24.C24.C24.C24.C24.C24.C24.C24.C24.A24.C24.A24.C24.C24.C24.C24.C24.C
24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.A$9.A24.C24.C24.C24.C
24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.A24.C24.A24.C
24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.C24.A$
9.3A22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C
22.3C22.3C22.3C22.3C22.3A22.3C22.3A22.3C22.3C22.3C22.3C22.3C22.3C22.
3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3C22.3A2$3.A4.A449.
A49.A449.A$5.2A23.2C24.C$4.2A24.C.C22.2C23.3C23.2C23.2C24.C$6.A23.C
24.C.C22.C24.2C24.C.C22.2C23.3C23.2C23.2C24.C$81.C25.C23.C24.C.C22.C
24.2C24.C.C22.2C23.3C23.2C23.2C24.C98.A$182.C25.C23.C24.C.C22.C24.2C
24.C.C22.2C23.3C23.2C23.2C24.A47.A$283.C25.C23.C24.C.C22.C24.2C24.C.C
22.2A23.3C23.2A23.2C24.C$384.C25.C23.C24.A.A22.C24.2A24.C.C22.2C23.3C
23.2C23.2C24.C$485.C25.A23.C24.C.C22.C24.2C24.C.C22.2C23.3C23.2C23.2C
24.C$586.C25.C23.C24.C.C22.C24.2C24.C.C22.2C23.3C23.2C23.2C24.C98.A$
687.C25.C23.C24.C.C22.C24.2C24.C.C22.2C23.3C23.2C23.2C24.A$788.C25.C
23.C24.C.C22.C24.2C24.C.C22.2A$889.C25.C23.C24.A.A5$377.2A$377.2A542.
2A$921.2A2$D3.D.D2.2D2.2D366.3D.D8.3D62.3D46.3D65.3D.D8.3D318.D2.D.3D
38.D3.D.D2.2D2.2D$2D.2D.D.D3.D369.D2.D4.D2.D65.D2.D45.D2.D65.D2.D4.D
2.D321.D.D2.D2.D37.2D.2D.D.D3.D$D.D.D.D2.D3.D368.D2.D3.3D.D.2D62.3D
46.3D66.D2.D3.3D.D.2D318.2D3.3D38.D.D.D.D2.D3.D$D3.D.D3.D3.D367.D2.D
4.D2.D2.D62.D2.D45.D2.D65.D2.D4.D2.D2.D318.D.D2.D2.D37.D3.D.D3.D3.D$D
3.D.D.2D2.2D368.D2.3D6.3D62.3D46.3D66.D2.3D6.3D318.D2.D.3D38.D3.D.D.
2D2.2D!

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 26th, 2014, 4:51 pm

dvgrn wrote:You might need several rephasers between the rakes, so at a guess, you might not have absolutely free choice of List 1 or List 2 until around 1000-1500 cells from the trails.

So... is it worth worrying about including (x,y) locations as part of these List 1 / List 2 targets?
That depends of the needs of your ship.

If you have to move that far anyway (to buy some time for the front of the ship or so) they might be worth the trouble.

My current search approach is not very well suited for that kind of complexity. It tracks the lane offset and the movement of the construction site. That's about it (up to now). No notion of distance from the trails.
dvgrn wrote:Here are all the workable orientations for left-side construction
Left-side construction: that means you would have to x-flip them for right-side, right? All the spine versions I've seen where symetrical, as far as I recall.
(BTW: my example assumes a north travelling ship and construction on the right, by se shooting 1RL0 back rakes, but changing that assumptions is no mayor issue, of course).
Last edited by oblique on February 27th, 2014, 1:28 am, edited 1 time in total.

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » February 26th, 2014, 7:54 pm

oblique wrote:Left-side construction: that means you would have to x-flip them for right-side, right? All the spine versions I've seen where symetrical, as far as I recall.
Yeah, don't worry about left vs. right, just take the mirror image of the List 1+2 RLE for right-side constructions. The standard lane-0 backrakes on both sides come from the Herschels' second natural gliders, so there's no difference from sscs's point of view.

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 27th, 2014, 1:46 pm

dvgrn wrote: Here are all the workable orientations for left-side construction, in order, with List 1 in the top row:
I've hand-imported those patterns (minus duplicates).

Could you please verify the result?

(Should be one rle for each pattern - x-mirrored, of course 8) ...)
Sometimes I was not too sure where one pattern ended and the next began ...
Last edited by oblique on February 27th, 2014, 5:46 pm, edited 4 times in total.

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 27th, 2014, 1:54 pm

I updated my search program to a version which dumps surplus reactions to disk for later use and started a search based on the starting targets linked above.

Seams to work like a charm - the program is running for hours without requiring any more memory then it did at start-up (+/- some kB for target-patterns which are freed after being used).

I found some reactions, which I coined "wrong edge shooters":

Like:

Code: Select all

x = 11, y = 20, rule = LifeHistory
7.A$8.2A$7.2A3$6.2A$5.A2.A$5.A2.A$6.2A3$4.A3.3A$4.A$4.A2$3A3.3A2$4.A$
4.A$4.A!
or

Code: Select all

x = 14, y = 11, rule = LifeHistory
8.A$9.2A$8.2A3$A$A7.A$A7.A$8.A$12.2A$12.2A!
The best so far is:

Code: Select all

.......*...........
........**.........
.......**..........
...................
...................
......**...........
.....*..*..........
.....*..*........**
......**.........**
...................
...................
....*...***.....**.
....*...........**.
....*..............
...................
***...***..........
...................
....*..............
....*..............
....*..............
 
And here is my best close-but-no-cigar edge shooting reaction (firing on the correct edge but leaving an traffic light where it should not be):

Code: Select all

*......................
.**....................
**.....................
.......................
.......................
................**.....
................**.....
.....................**
.....................**
.......................
.......................
..................*....
.................*.*...
.................**....
.......................
.......................
.......................
.......................
....***...***..........
.......................
........*..............
........*..............
........*..............
The search is currently at depth 17 and has used almost 2GB of my harddrive ... and still not much main memory.

User avatar
codeholic
Moderator
Posts: 1147
Joined: September 13th, 2011, 8:23 am
Location: Hamburg, Germany

Re: Prototype / demo for a (weighted) collision search program

Post by codeholic » February 27th, 2014, 3:49 pm

Have you found any clean *WSS seeds?
Ivan Fomichev

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 27th, 2014, 5:43 pm

codeholic wrote:Have you found any clean *WSS seeds?
Not yet, at least. In fact I haven't found any usable ones at all (some minor ash wouldn't hurt, if it stays of the path of the ship - would it?)

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » February 27th, 2014, 7:09 pm

oblique wrote:
codeholic wrote:Have you found any clean *WSS seeds?
Not yet, at least. In fact I haven't found any usable ones at all (some minor ash wouldn't hurt, if it stays of the path of the ship - would it?)
No, out-of-the-way ash isn't a problem. Even the wrong-way edge shooters would technically be usable, assuming all the intermediate targets stay out of the way of the spaceship. We're building with slow salvos, so the timing can be trivially adjusted so that the seed construction gliders all slip through the spaceship stream.

But the final trigger glider can't be adjusted -- and naturally the examples you posted are all unlucky in different ways:

Code: Select all

x = 258, y = 201, rule = B3/S23
bo131bo$2bo131bo$3o129b3o89$61bo131bo$62bo131bo$60b3o129b3o32$119b2o$
118bo2bo121b3o$118bo2bo8b2o119b3o$119b2o9b2o$256b2o$122bo133b2o$122bo
6b2o$116b3o3bo6b2o2$114bo5bo$114bo5bo$114bo5bo2$116b3o18$119b2o$118bo
2bo121b3o$118bo2bo8b2o119b3o$119b2o9b2o$256b2o$122bo133b2o$122bo6b2o$
116b3o3bo6b2o2$114bo5bo$114bo5bo$114bo5bo2$116b3o13$121bo131bo$122bo
131bo$120b3o129b3o3$119b2o$118bo2bo121b3o$118bo2bo8b2o119b3o$119b2o9b
2o$256b2o$122bo133b2o$122bo6b2o$116b3o3bo6b2o2$114bo5bo$114bo5bo$114bo
5bo2$116b3o!
If there are more wrong-edge shooters, it might be worth having a look to see if any of the trigger gliders happen to slip through the upship stream.

These would mostly only be useful for building singleton *WSSes, though. If the upship stream is part of a helix or any other kind of convoy, it's probably not worth trying to deal with the timing problems, because other streams farther to the right would hit the intermediate construction targets -- never mind any leftover junk. This was all explained to me by codeholic a while back...
oblique wrote:And here is my best close-but-no-cigar edge shooting reaction (firing on the correct edge but leaving an traffic light where it should not be):
Well... the traffic light isn't necessarily a problem, but something else is.

The traffic light would get in the way if we were working on new reactions for a 17c/45 Caterpillar spaceship, where each newly constructed *WSS passes through the actual past construction points of higher *WSSes in the same stream, so if there's any leftover ash, the next ship will hit it unless it's cleaned up really fast.

EDIT: Waitaminute, no, that doesn't seem to be true. Depending on the helix you were building, you could get away with leaving junk in the lane when the seed is triggered, just like in 31c/240 -- right? And there's no difference at the slow-salvo seed construction stage either; the only difference is that at 17c/45, you can't build forward glider streams that catch up to the front of the spaceship -- you really need *WSSes.

But 31c/240 is slow! In 31c/240 upship streams, *WSSes pass through the future construction points of lower *WSSes in the same stream. And this is a serious problem for this seed -- it's not actually anywhere near being an edge-shooter:

Code: Select all

x = 164, y = 292, rule = LifeHistory
22.A$23.A$21.3A89$82.A$83.A$81.3A32$157.2A$157.2A$162.2A$162.2A3$159.
A$158.A.A$158.2A3$160.2C$146.A5.A7.2C$146.A5.A$146.A5.A2$148.3A15$
157.2A$157.2A$162.2A$162.2A3$159.A$158.A.A$158.2A3$160.2C$146.A5.A7.
2C$146.A5.A$146.A5.A2$148.3A10$142.A$143.A$141.3A3$157.2A$157.2A$162.
2A$162.2A3$159.A$158.A.A$158.2A4$146.A5.A$146.A5.A$146.A5.A2$148.3A
28$120.2A$121.2A$120.A27$60.2A$61.2A$60.A27$2A$.2A$A!
In the above pattern I've added a forerake stream that moves the traffic light out of the way. There's another lane placement that would clean it up completely.

However, it would actually be okay to leave something like the traffic light behind in the upship lane -- the upship stream is complete at that point, so there won't be any more *WSSes coming up on that lane. There might be nearby upship streams to the right, so leftover junk (or even a spark) sticking out any distance to the right is not so good... but if we're just building a few singleton *WSSes to reflect forward glider streams and build the front end that way, then a cheap seed that leaves a little junk in the lane might be just fine.

[Somebody please explain to me if I'm wrong about any of this...!]

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » February 27th, 2014, 7:20 pm

oblique wrote:I've hand-imported those patterns (minus duplicates).

Could you please verify the result?
You just have one LOM blockade split the wrong way. Replace your lines 43 to 47 with:

Code: Select all

x = 23, y = 10, rule = B3/S23
21b2o$21b2o3$b2o17b2o$b2o17b2o3$2o$2o!
Other than that, you don't seem to be missing anything.

It's wonderful to see actual results coming out of sscs*, even if they aren't quite useful results yet. It will be good to be on the lookout also for seeds that would work in Caterpillar's little brother, too -- it looks to me as if these slow-salvo seed constructions could shorten the Caterpillar by quite a lot.

* I take it you aren't too keen on my suggestion about calling the search program "NewGlue", after Paul Chapman's unpublished alpha search utility? It is kind of an odd name, I admit...

User avatar
codeholic
Moderator
Posts: 1147
Joined: September 13th, 2011, 8:23 am
Location: Hamburg, Germany

Re: Prototype / demo for a (weighted) collision search program

Post by codeholic » February 27th, 2014, 8:15 pm

oblique wrote:
codeholic wrote:Have you found any clean *WSS seeds?
Not yet, at least. In fact I haven't found any usable ones at all (some minor ash wouldn't hurt, if it stays of the path of the ship - would it?)
Just in case, I didn't mean edge shooters, I meant just any clean *WSS seeds. In particular, clean MWSS and HWSS seeds might be useful for the cleanup.
Ivan Fomichev

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 28th, 2014, 1:38 am

codeholic wrote:
oblique wrote:
codeholic wrote:Have you found any clean *WSS seeds?
Not yet, at least. In fact I haven't found any usable ones at all (some minor ash wouldn't hurt, if it stays of the path of the ship - would it?)
Just in case, I didn't mean edge shooters, I meant just any clean *WSS seeds. In particular, clean MWSS and HWSS seeds might be useful for the cleanup.
oops.

Guess I have to include lateral ships in the next search ...

(my current parameters explicitly look for UP ships)

User avatar
codeholic
Moderator
Posts: 1147
Joined: September 13th, 2011, 8:23 am
Location: Hamburg, Germany

Re: Prototype / demo for a (weighted) collision search program

Post by codeholic » February 28th, 2014, 2:27 am

Does it matter? Can't you just mirror the synthesis by the diagonal axis?
Ivan Fomichev

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » February 28th, 2014, 8:35 am

codeholic wrote:Does it matter? Can't you just mirror the synthesis by the diagonal axis?
Yes, unless you're starting from a cheap seed from a two-glider collision that isn't mirror-symmetric. That's probably a good reason to start searches mostly from blocks, ponds, honeyfarms, traffic lights, and blinkers.

For some other targets like the LOM and half-blockade, it wouldn't be terribly expensive to construct an initial target in the "wrong" orientation -- you just wouldn't be finding a minimum-weight *WSS recipe for that orientation.

Maybe the best thing would be to run a separate search for horizontal *WSS at some point -- keep the code the same, looking for upships only, but use mirror-image initial targets.
oblique wrote:The search is currently at depth 17 and has used almost 2GB of my harddrive ... and still not much main memory.
Is that a weighted depth of 17, or 17 gliders? 17 gliders seems unlikely if you're looking at the full search tree, but maybe the mod-31 limitation is pruning off more branches than I'm expecting. If it's a weighted depth, are you using this table for the weights (lane 9 costs 1, lane 18 costs 2, etc.)? Or have you adjusted it to account for multiple rakes?

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 28th, 2014, 1:40 pm

dvgrn wrote:
codeholic wrote:Does it matter? Can't you just mirror the synthesis by the diagonal axis?
Yes, unless you're starting from a cheap seed from a two-glider collision that isn't mirror-symmetric. That's probably a good reason to start searches mostly from blocks, ponds, honeyfarms, traffic lights, and blinkers.
That's not quite all.

There are at least the following differences between a given seed and it's diagonally mirrored sister:

1) Size.

While a width of 35 might be perfectly OK, a height of 35 is probably not.

2) Reachability.

The 31c/240 ship has only 31 lanes to hit a target/the seed with. Beyond something like a bounding box of mere 13x10 this would mean you would have to shoot your bullet *thru* the bbox of one copy of the seed to hit the upper right corner of the next one (which might be possible or not, depending on the pattern).

3) As you mentioned: cost.

My search engine is ordered by cost. It will consider rather long sequences of easy to fire glider salvos before it even tries to fire a glider on the same lane twice (which is the worst case when considering the rephasers you need). So maybe you could hit a given seed on lane 5 perfectly cheap after you build it, but with the mirror it is a completly new story.
dvgrn wrote: Maybe the best thing would be to run a separate search for horizontal *WSS at some point -- keep the code the same, looking for upships only, but use mirror-image initial targets.
No need for that. My program already checks for any type of known spaceship escaping the reaction. They are used to either track them as "emitted" or to discard the reaction ("prune"). There is an parameter for telling the program which ships to keep and which to discard. This parameter has allways been an array ;)

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » February 28th, 2014, 2:50 pm

oblique wrote:There are at least the following differences between a given seed and it's diagonally mirrored sister:
1) Size.
...
2) Reachability.
...
3) As you mentioned: cost.
No arguments there. But I think there will be quite a bit of interest in even relatively inefficient *WSS seeds, if they can be built with relatively few gliders. Seeds that aren't worth building as part of a 31c/240 spaceship might be just what's needed for Caterpillar's little brother, or maybe some future oblique spaceship.

When you think scss is ready for a wider audience, maybe somebody could get a copy running with unweighted lanes and perhaps a bigger width -- though small widths still seem like a good idea, really.
oblique wrote:My search engine is ordered by cost. It will consider rather long sequences of easy to fire glider salvos before it even tries to fire a glider on the same lane twice (which is the worst case when considering the rephasers you need).
Technically the same lane might not be the worst case any more. The latest cost table says the worst thing is a lane offset of +7, which needs eleven rephasers. A lane offset of zero can be done with just six rephasers plus a different backrake.

Searches with the old simple cost table are still interesting, too, though. Which version are you using for your current search? I haven't gone looking through your code yet -- do you have lane costs as simple numbers in an array, or are you going to worry about how actual rakes follow one another, with different block-trail offsets for different rakes?

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 28th, 2014, 2:56 pm

dvgrn wrote:
oblique wrote:The search is currently at depth 17 and has used almost 2GB of my harddrive ... and still not much main memory.
Is that a weighted depth of 17, or 17 gliders? 17 gliders seems unlikely if you're looking at the full search tree, but maybe the mod-31 limitation is pruning off more branches than I'm expecting. If it's a weighted depth, are you using this table for the weights (lane 9 costs 1, lane 18 costs 2, etc.)? Or have you adjusted it to account for multiple rakes?
OK - maybe I have to explain how my stuff works. ;)

The search is ordered by COST (I sometimes said "depth" but that is not really true). I have not implemented other rakes then the 1RL0 type yet. When I will, I'll probably keep track of the relative "phase" of the trails towards my current target and use that to decide which lanes are cheaper then others.

Some technically notes at the start:
Context: 31c/240 upward moving ship to be build with rakes that rephase the ship by 9 cells downwards and fire se gliders on a fixed offset from the trails (1RL0 rakes).

Since we use se gliders, my programs counts lanes for 0..N where lane 0 will just hit the bottom left corner of the target, and lane N will just hit the top right corner. (total number of lanes = width + height + 8)

I choose this numbering for simplicity, but it mens that the "9 cells down" rephaser of your ship is seen as a "22 lanes up" rephaser by my program.

Here is one example of a small branch near the root of the tree:
Let's start with target 1 (the first of the list I posted yesterday). The program fires se gliders on all 23 possible lanes:

Code: Select all

MariaDB [gol]> select rId, initial_tId, lane, result_tId, result, cost from reaction where initial_tId = 1;
+-----+-------------+------+------------+------------+------+
| rId | initial_tId | lane | result_tId | result     | cost |
+-----+-------------+------+------------+------------+------+
|   1 |           1 |    0 |          0 | fly-by     |    0 |
|   2 |           1 |    1 |          0 | fly-by     |    0 |
|   3 |           1 |    2 |          0 | fly-by     |    0 |
|   4 |           1 |    3 |          0 | fly-by     |    0 |
|   5 |           1 |    4 |          0 | unfinished |    0 |
|   6 |           1 |    5 |         21 | stable     |    0 |
|   7 |           1 |    6 |         25 | stable     |    0 |
|   8 |           1 |    7 |         26 | stable     |    0 |
|   9 |           1 |    8 |          0 | unfinished |    0 |
|  10 |           1 |    9 |         27 | stable     |    0 |
|  11 |           1 |   10 |         21 | stable     |    0 |
|  12 |           1 |   11 |         21 | stable     |    0 |
|  13 |           1 |   12 |         29 | stable     |    0 |
|  14 |           1 |   13 |         31 | stable     |    0 |
|  15 |           1 |   14 |         33 | stable     |    0 |
|  16 |           1 |   15 |          0 | pruned     |    0 |
|  17 |           1 |   16 |         21 | stable     |    0 |
|  18 |           1 |   17 |          0 | unfinished |    0 |
|  19 |           1 |   18 |          0 | unfinished |    0 |
|  20 |           1 |   19 |          0 | fly-by     |    0 |
|  21 |           1 |   20 |          0 | fly-by     |    0 |
|  22 |           1 |   21 |          0 | fly-by     |    0 |
|  23 |           1 |   22 |          0 | fly-by     |    0 |
+-----+-------------+------+------------+------------+------+
23 rows in set (0.00 sec)
The cost is abritrarily set to "0" because I don't know the offset between trails and target yet.
Some of those 23 initial reactions are classified as "fly-by" (because the bullet does not hit any part of the pattern, just the bounding box), some as "unfinished" (= not stabilzed after 256 generations), "pruned" (to big or firing unwnated ships).
The rest is "stable", producing an resulting pattern as a new target.

Well. Actually some of those "new" targets are not really new (they have been in the starting set of targets) ... but nevermind.

Let's pick rId = 15, "hit target 1 with a bullet on lane 14, resulting in a stable target with ID 33" and look for reactions which start with the result_tId of this reaction.

Since the search I used in this example had only run up to a cost of 12 I found the following reactions in the database:

Code: Select all

MariaDB [gol]> select rId, initial_tId, lane, result_tId, result, cost from reaction where initial_tId = 33 order by rId;
+--------+-------------+------+------------+------------+------+
| rId    | initial_tId | lane | result_tId | result     | cost |
+--------+-------------+------+------------+------------+------+
|    563 |          33 |   25 |          0 | pruned     |    1 |
|    877 |          33 |   16 |        459 | stable     |    2 |
|   1374 |          33 |    7 |        760 | stable     |    3 |
|   2215 |          33 |   29 |       1348 | stable     |    4 |
|   3687 |          33 |   20 |       2364 | stable     |    5 |
|   6238 |          33 |   11 |       4176 | stable     |    6 |
|  10691 |          33 |    2 |          0 | fly-by     |    7 |-> requeued with lane=33
|  18630 |          33 |   33 |      17406 | stable     |    7 |
|  25850 |          33 |   24 |          0 | pruned     |    8 |
|  32447 |          33 |   15 |       5799 | stable     |    9 |
|  65574 |          33 |    6 |      44145 | stable     |   10 |
| 104903 |          33 |   28 |          0 | unfinished |   11 |
| 200150 |          33 |   19 |       2364 | stable     |   12 |
+--------+-------------+------+------------+------------+------+
13 rows in set (0.00 sec)
Note that the search is ordered by rId (the autoincrement primary key of table reaction), not explicitly by the cost.

Note also that the program is starting with lane 25? Why??

Well:

Code: Select all

MariaDB [gol]> select offX, offY from reaction where initial_tId = 1 and result_tId = 33;
+------+------+
| offX | offY |
+------+------+
|   -3 |  -11 |
+------+------+
1 row in set (0.02 sec)
This means, there is an offset of (-3,-11) between the the starting target and the result.

And:

Code: Select all

MariaDB [gol]> select tId, combined_width, combined_height from target where tId  in (1, 33);
+-----+----------------+-----------------+
| tId | combined_width | combined_height |
+-----+----------------+-----------------+
|   1 |              9 |               7 |
|  33 |             24 |              26 |
+-----+----------------+-----------------+
2 rows in set (0.00 sec)
The primary target has size (9,7) and the result (24,26)

Furthermore:

Code: Select all

MariaDB [gol]> select * from bullets;
+-----+-------+-----+--------+--------+------------+---------+---------+------------------+-----------------+-------------+
| bId | name  | oId | base_x | base_y | reference  | lane_dx | lane_dy | lanes_per_height | lanes_per_width | extra_lanes |
+-----+-------+-----+--------+--------+------------+---------+---------+------------------+-----------------+-------------+
|   1 | gl-se |  10 |     -4 |      0 | BOTTOMLEFT |       0 |      -1 |                1 |               1 |           8 |
+-----+-------+-----+--------+--------+------------+---------+---------+------------------+-----------------+-------------+
1 row in set (0.00 sec)
The lane numbering is refering to lane=0 hits the bottom left corner (base_x and base_y are used to make it *just* hit that corner).
When going from lane n to lane n-1 we have to move the bullet by (0,-1) - i.e.: up.
And: there are lanes_per_height*height+lanes_per_width*width+extra_lanes lanes on which a glider can hit a pattern with a bounding box of width*height

sscs takes this into account:

Code: Select all

int tgt_adjust_lane (int _b, target *old, target *new)
{
  switch (reference)
...
      case bottomleft:
        return -(new->bottom - old->bottom)*b->lanes_per_height + (new->left - old->left)*b->lanes_per_width;
...
}
For a bullet referencing the bottom left corner the offset is calculated by using the offset between the bottom left corners of the targets, substraction dy and adding dx

Thus:
dx = -3, dy = 26-11 -7 = 8
=> adjust = -11

The old_lane was 14, being adjusted to 3.
So if the new lane has is at 25, this gives:
=> cost (old_lane, new_lane) = cost (3, 25) = COST [22] = 1
Last edited by oblique on March 2nd, 2014, 2:07 am, edited 1 time in total.

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » February 28th, 2014, 3:14 pm

oblique wrote:Context: 31c/240 upward moving ship to be build with rakes that rephase the ship by 9 cells downwards and fire se gliders on a fixed offset from the trails (1RL0 rakes).
I'm just a little worried about this one detail. To my way of thinking, a 1R0L rake will rephase the block trails by 9 cells upwards, or 22 cells downwards. Is this somehow the same thing as what you're saying?

Code: Select all

x = 576, y = 471, rule = LifeHistory
23.2C114.2C108.2C88.2C108.2C114.2C$23.2C114.2C108.2C88.2C108.2C114.2C
30$23.2C114.2C108.2C88.2C108.2C114.2C$23.2C114.2C108.2C88.2C108.2C
114.2C30$23.2C114.2C108.2C88.2C108.2C114.2C$23.2C114.2C108.2C88.2C
108.2C114.2C30$23.2C114.2C108.2C88.2C108.2C114.2C$23.2C114.2C108.2C
88.2C108.2C114.2C30$23.2C114.2C108.2C88.2C108.2C114.2C$23.2C114.2C
108.2C88.2C108.2C114.2C30$23.2C114.2C108.2C88.2C108.2C114.2C$23.2C
114.2C108.2C88.2C108.2C114.2C30$23.2C114.2C108.2C88.2C108.2C114.2C$
23.2C114.2C108.2C88.2C108.2C114.2C30$23.2C114.2C108.2C88.2C108.2C114.
2C$23.2C114.2C108.2C88.2C108.2C114.2C3$19.5A$17.2A3.A.A.4A$17.2A5.A5.
A535.A$19.A.4A2.2A2.2A528.3A.A.A$22.A3.A2.A.2A3.A525.4A.2A3.3A$14.A
12.2A3.2A2.A530.A2.5A$14.3A10.A.2A.2A2.A3.3A513.2A3.2A3.A3.A$13.A.3A
8.A2.7A513.3A3.A2.A.A5.A4.5A$10.2A5.2A7.A.7A516.A2.A6.3A11.A$13.A2.2A
.A6.A3.A518.A.2A2.3A3.A10.A.A$13.3A4.A9.A518.A.2A.A3.3A11.2A$13.3A4.
2A9.2A518.A.2A4.A$17.4A10.A524.A$17.3A9.A.A519.3A2.A$5.A11.2A11.A516.
A4.A$3.2A542.A4.A$4.2A542.A2.A2$23.2A540.2A$23.2A540.2A8$139.2A108.2A
88.2A108.2A$139.2A108.2A88.2A108.2A3$31.2A524.2A$31.2A524.2A2$544.A$
543.A$543.3A3$50.A$48.A.A$49.2A8$23.2A540.2A$23.2A540.2A8$139.2A108.
2A88.2A108.2A$139.2A108.2A88.2A108.2A3$31.2A524.2A$31.2A524.2A11$2A$A
.A$A4$23.2A540.2A$23.2A540.2A4$446.A$445.A$444.A2.A2$249.2A88.2A$249.
2A88.2A104.A5.2A$451.3A$137.A310.A3.2A$31.2A103.3A307.2A5.2A102.2A$
31.2A102.4A308.A4.2A103.2A$133.2A3.A.2A307.2A7.A$138.2A2.2A302.2A10.A
$132.A3.A.A2.A316.A$133.A4.A$134.2A.A$134.2A3$60.2A81.2A300.2A$60.A.A
80.2A300.2A$60.A6$23.2A114.2A308.2A114.2A$23.2A114.2A308.2A114.2A8$
249.2A88.2A76.A$249.2A88.2A75.A$416.3A2$31.2A98.2A324.2A98.2A$31.2A
98.2A44.A279.2A25.A72.2A$175.A.A305.A$176.2A71.2A232.3A$249.2A$336.A.
A$110.A140.A84.A.2A$108.A.A129.3A7.A.A13.A68.2A2.2A$109.2A9.2A117.A3.
A9.A10.2A.2A61.3A7.2A$120.A.A117.A2.A5.2A2.A2.2A6.A65.A8.2A$120.A119.
A2.A5.3A.2A.2A6.A3.A61.A.A6.A$242.A7.A2.A11.3A63.2A$243.2A3.2A.2A$
248.5A85.A$248.3A88.A$338.A3$23.2A114.2A108.2A88.2A108.2A114.2A$23.2A
114.2A108.2A88.2A108.2A114.2A2$488.A$489.2A$488.2A2$327.A$95.A.A229.A
.A$95.2A230.2A$96.A2$267.A$31.2A98.2A124.2A6.A.A63.2A124.2A98.2A$31.
2A98.2A124.2A7.2A63.2A124.2A98.2A5$180.2A$180.A.A$180.A10$23.2A114.2A
108.2A88.2A108.2A114.2A$23.2A114.2A108.2A88.2A108.2A114.2A12$31.2A
224.2A72.2A224.2A$31.2A224.2A72.2A224.2A17$23.2A114.2A108.2A88.2A108.
2A114.2A$23.2A114.2A108.2A88.2A108.2A114.2A12$31.2A224.2A72.2A224.2A$
31.2A224.2A72.2A224.2A17$23.2A114.2A108.2A88.2A108.2A114.2A$23.2A114.
2A108.2A88.2A108.2A97.A16.2A$549.2A$548.2A2$267.A$35.A.A229.A.A$35.2A
230.2A$36.A2$327.A$325.A.A$326.2A$31.2A224.2A72.2A224.2A$31.2A224.2A
72.2A224.2A!

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 28th, 2014, 3:25 pm

dvgrn wrote:
oblique wrote:There are at least the following differences between a given seed and it's diagonally mirrored sister:
1) Size.
...
2) Reachability.
...
3) As you mentioned: cost.
No arguments there. But I think there will be quite a bit of interest in even relatively inefficient *WSS seeds, if they can be built with relatively few gliders. Seeds that aren't worth building as part of a 31c/240 spaceship might be just what's needed for Caterpillar's little brother, or maybe some future oblique spaceship.
They are not lost for those purposes. They are probably not found before the stars of the universe burn out, so.
(OK, east or south firing ones will be "pruned" currently. I could fix that at a small cost for the 31c/240 search - since there aren't that many seeds out there, the cost - some unpruned branches - would be tollereable).
dvgrn wrote: When you think scss is ready for a wider audience, maybe somebody could get a copy running with unweighted lanes and perhaps a bigger width -- though small widths still seem like a good idea, really.
"Unweighted" is easy to do: just set the COST-Parameter to 1 (normally it's an array, but if it's shorter then the number of possible lanes, it's just used over and over ...)

The problem is the exploding search space ...
dvgrn wrote:
oblique wrote:My search engine is ordered by cost. It will consider rather long sequences of easy to fire glider salvos before it even tries to fire a glider on the same lane twice (which is the worst case when considering the rephasers you need).
Technically the same lane might not be the worst case any more. The latest cost table says the worst thing is a lane offset of +7, which needs eleven rephasers. A lane offset of zero can be done with just six rephasers plus a different backrake.

Searches with the old simple cost table are still interesting, too, though. Which version are you using for your current search? I haven't gone looking through your code yet -- do you have lane costs as simple numbers in an array, or are you going to worry about how actual rakes follow one another, with different block-trail offsets for different rakes?
See my other post.

I will implement those other rakes soon (TM).
Last edited by oblique on February 28th, 2014, 3:30 pm, edited 1 time in total.

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 28th, 2014, 3:29 pm

dvgrn wrote:
oblique wrote:Context: 31c/240 upward moving ship to be build with rakes that rephase the ship by 9 cells downwards and fire se gliders on a fixed offset from the trails (1RL0 rakes).
I'm just a little worried about this one detail. To my way of thinking, a 1R0L rake will rephase the block trails by 9 cells upwards, or 22 cells downwards. Is this somehow the same thing as what you're saying?
No need to worry here, yet.

There are enough bugs and quirks left in the code, that I will certainly restart the search quite a few times still.

Just watched your pattern - you are right, the trails are moved upwards. Well I guess I've to change the COSTS = [22 % 31] parameter back to COSTS = [9 % 31]

[22 % 31] is lazy for COSTS [(i*22) mod 31] = i (for i = 0..30)

(stupidity deleted)

EDIT: I just noticed that I mixed the definition of [ x % p ] up completely. Corrected it.
EDIT: I just looked up your definition of lane numbering viewtopic.php?f=2&t=1274&start=200#p10768
dvgrn wrote:

Code: Select all

#C reference pattern for lanes 0, 7, 19, and 26
x = 30, y = 95, rule = LifeHistory
28.2A$28.2A30$28.2A$28.2A14$.3D3.3D$D3.D.D$4.D.D$3.D2.4D4.A$2.D3.D3.D
3.A.A$.D4.D3.D3.2A$5D2.3D3$2.D3.3D$.2D2.D3.D4.A$2.D2.D3.D4.A.A$2.D3.
4D4.2A$2.D6.D$2.D6.D$.3D2.3D$28.2A$28.2A2$3.5D$7.D$6.D$5.D8.A$4.D9.A.
A$3.D10.2A$3.D3$4.3D$3.D3.D6.A$3.D2.2D6.A.A$3.D.D.D6.2A$3.2D2.D$3.D3.
D$4.3D13$28.2A$28.2A!
You are numbering them in the same direction I am using in my current parameter set of sscs.
Last edited by oblique on March 1st, 2014, 3:49 am, edited 6 times in total.

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » February 28th, 2014, 3:44 pm

dvgrn wrote:* I take it you aren't too keen on my suggestion about calling the search program "NewGlue", after Paul Chapman's unpublished alpha search utility? It is kind of an odd name, I admit...
I allmost overlooked that footnote.

I'm not sure that the name would fit, since I never laid my hands on "Glue".

My approach is somewhat different, and I would never imply that sscs is in anyway "better" or even just based on it.

On the other hand: sscs is just a working title ...

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » March 4th, 2014, 5:32 pm

Somewhat improved new version:

+ fixed some irregularities with spurios ship and fly-by detection.
+ program can now continue a previously *completed* search.
(use with ./sscs --extend-by 3 my.cfg to continue search defined by my.cfg for 3 more COST-Levels)
+ included a config file demonstrating a non weighted search.

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » March 5th, 2014, 2:33 pm

codeholic wrote:Have you found any clean *WSS seeds?
Theese to are the first clean MWSS seeds I found (I found another two LWSS seeds, but no HWSS yet)
One is firing north, the other one west.

Code: Select all

.....*....
......**..
.....**...
..........
..........
........**
.......*.*
***....**.
..........
..........
..........
....***...
..........
..*.......
..*.......
..*.......

Code: Select all

*...............
.**..........**.
**..........*..*
............*..*
.............**.
................
................
................
................
.....**.....***.
....*.*.........
....**..........

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » March 6th, 2014, 1:10 pm

HartmutHolzwart wrote:could we nevertheless see those seeds?
An updated list of seeds I found so far.

Attached is a ZIP with 4 files (one for every direction).
Attachments
samples.zip
(20.9 KiB) Downloaded 332 times

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: Prototype / demo for a (weighted) collision search program

Post by dvgrn » March 6th, 2014, 2:21 pm

oblique wrote:
HartmutHolzwart wrote:could we nevertheless see those seeds?
An updated list of seeds I found so far.

Attached is a ZIP with 4 files (one for every direction).
At least a couple of these look like possible edge-shooter material. The first one below has a very nice offset and quick insertion reaction -- could possibly be used for building some difficult upship streams in a nonstandard order.

Code: Select all

x = 144, y = 95, rule = LifeHistory
42.C$41.3C$41.C.2C$42.3C$42.2C47$141.C$140.3C$140.C.2C$141.3C$141.2C
5$7.2D$7.2D$26.D$25.D.D$25.D.D$26.D3$116.2D$6.D109.2D$6.D118.D$6.D
118.D$27.A.A95.D.A.A$28.2A98.2A$28.A92.3D4.A$18.D$17.D.D6.A92.2A$17.D
.D6.A91.A2.A$17.ACA6.A2.3A86.A2.A$119.2A7.3A$15.2D$4.D10.2D109.A5.A$
4.D121.A5.A$4.D9.2A13.3A94.A5.A$13.A2.A$3D3.3D4.A.A112.3A$14.A$4.D
113.D$4.D113.D2A$4.D113.D2A2$11.D$11.D$11.D112.2D$124.2D!
These are from sample_w.pat, so I've illegally reflected them across Golly's X=Y line... making a horrible mess of the cost calculations, I know -- and unfortunately the first one may end up being too wide in this orientation, unless there's an easy way to place additional suppressing debris.

EDIT:Here are a few more seeds from the N and S collections where I'd like to see a full recipe. The first two are edge-shooters, if they're constructed without touching the ship lane. The third leaves some junk in the lane, which is not a problem for upship streams at 31c/240. It would be a problem for downship streams, but we don't seem to need those... so I'm just wondering how much it would cost to build the equivalent forward salvo for an upship stream.

Code: Select all

x = 197, y = 112, rule = LifeHistory
188.3D$194.2A$27.D160.2A3.A2.A$26.3D159.2A4.2A$26.D.2D$27.3D94.A59.A$
27.2D96.2A58.2A3.2A$124.2A58.2A3.A.A$190.A$134.2A$134.2A4$4.2C$4.2C3.
2D121.3A7.3A$8.D2.D$9.CD$8.A.A120.D6.D2.A$8.A.A120.D6.D.A.A$9.A121.D
6.DA2.A$140.2A$127.3D10.3D2$131.D6.D$128.2A.D6.D$128.2A.D6.D$19.2D$
19.2D$A49.A$.2A48.2A69.D24.D$2A6.2A40.2A70.D24.D$7.A.A4.3A105.D24.D$
7.2A125.2D$12.A47.2A2.D69.2D$12.A33.2D11.A.A2.D$12.A32.D.D11.2A3.D$
45.2D$60.3D3.3D$48.2D$48.2D14.D$64.D$53.2A9.D$52.A.A$52.2A$59.A$47.2D
10.A$47.2D10.A$62.D$55.3A3.D.D$61.D.D$62.D3$67.2D$66.D2.D$67.2D17$74.
2D$73.3D$73.2D.D$74.3D$75.D8$148.D.D$151.D$151.D$148.D2.D$149.3D18$
181.2D$181.3D$180.D.2D$180.3D$181.D!
The reaction on the far right is a compact wrong-edge shooter that might still be useful if we're just building singleton LWSSes using forward rakes.

oblique
Posts: 122
Joined: July 16th, 2013, 1:30 pm

Re: Prototype / demo for a (weighted) collision search program

Post by oblique » March 6th, 2014, 5:50 pm

dvgrn wrote: At least a couple of these look like possible edge-shooter material. The first one below has a very nice offset and quick insertion reaction -- could possibly be used for building some difficult upship streams in a nonstandard order.
OK - guess I have to rerun this search (I scrapped it because I had a serious bug in the calculation of ship positions) ...

As for messing up the COST-Table for the W bound ship: maybe we are lucky and it's not too expensive when mirrored.

Could you please try to verify my recipe posted here? If it doesn't work out I probably have seriously goofed somewhere (and would have to fix that first, before wandering thru a tree on the wrong branches).

Post Reply