Script request thread

[dvgrn]

I have some (admittedly relatively ugly) ideas for encoding vertical gaps. Because "yy" is also unused, a vertical gap could be represented by "zyy" followed by something similar to whatever is used for "yz". Or, "yy" could mean a long horizontal gap and "yz" could mean a vertical gap. I will admit that either option would make decoding slightly harder, though.

Yeah, I guess the worst problem might be deciding on a canonical form, considering that patterns containing multiple blank lines have already been recorded by Catagolue -- e.g., trans-queen-bee-shuttle (three z's) and many others.

Would have to only start encoding vertical gaps after the first 38 z's have gone by, I suppose, to be perfectly safe... but probably after a quick search of current Catagolue contents we could pick a reasonable number that's smaller than 38.

This little problem definitely pushes me back toward voting for the simple greedy linear encoding algorithm, since our "reasonable number" would have to be a fairly contrived choice to match existing uses, not anything obvious or elegant.

[Apple Bottom]

@Apple Bottom, is what you said at the top of that thread still true, that

...a quick check of my files reveals that there are not currently any objects on Catagolue containing either yz or yy (though there are two containing yx, an xp412 in B358/S23 and the ship-pulling xq190 in B38/S23 (one variant, anyway).

If so, it seems as if it's not technically too late to support ridiculously large sparse patterns in a way that's completely backwards compatible -- practically speaking. If no apgcode has been officially recorded yet that contains a "yz", then we could still agree to update encoders and decoders everywhere, to allow variable-length base-36 encodings of long strings of 0s.

Yes, this is still true to the best of my knowledge. Using data freshly grabbed this morning just for this, covering 936 different rules I know have been investigated:

Code: Select all

sqlite> select distinct code, rule from census where code like "%yx%";
xp412_y7444y04bp3zzwezgg8gyrgg08oz32011yr1211zyxezzyeojq4y0444|b358s23
xq18_1a4zyx665|b2ce3aiys12-ckn3r
xq18_335zyxe95|b2ce3aiys12-ckn3r
xq190_33y1g88gzy133433zyeskszzyjcmm8zyx352|b38s23
xq190_sm3fk8cszw11zyecscwgzyi303w4zyj4s8zyx352|b38s23
sqlite> select distinct code, rule from census where code like "%yy%";
sqlite> select distinct code, rule from census where code like "%yz%";
sqlite>

That said I added greedy apgcodes for a number of previously-unencodable patterns to the LifeWiki a while ago, using the modification of biggiemac's encoder script that I posted above; these might.

OTOH they should be easy to find; they all use Template:LinkCatagolue and pass format=extended. I've added a tracking category, so they could easily be fixed up if necessary.

TL;DR
I guess for the moment my vote is for the simple greedy algorithm, but my mind might not be entirely made up yet. If someone can suggest a backwards-compatible apgext format that also allows logarithmic compression of vertical gaps, I might find that to be pretty much irresistible.

Might even volunteer to write revised encoders and decoders for the format, but I won't promise anything yet...!

I'm still leaning towards greedy codes, too; the fact that they strictly extend apgcodes (in their current form) and that existing decoders should require no modification are killer features IMO.

I also still think there's better ways of passing large patterns around, namely RLE, Macrocell and possible other future file formats.

Finally, I think that one of the purposes of apgcodes is allowing people to unambiguously talk about patterns -- and while it's perfectly reasonable to say e.g. "xp5_idiidiz01w1 is a known oscillator", nobody would do the same if the code were a million characters, or even a thousand. Large, extremely sparse patterns might get short codes, but are most large patterns really that sparse? (Sure, some are, but are these really the norm?)

THAT SAID, I think there is one more purpose that apgcodes serve: they provide the machinery to unambiguously compare patterns. Given two RLE files, it's not a trivial task to figure out whether they contain the same pattern or not. Two (canonical) apgcodes, however, will be definition encode the same object if and only if the codes themselves are identical. And this is a use where it won't matter whether the code is short enough to be used, remembered or quoted by human users.

On the subject of encoding vertical gaps:

Would have to only start encoding vertical gaps after the first 38 z's have gone by, I suppose, to be perfectly safe... but probably after a quick search of current Catagolue contents we could pick a reasonable number that's smaller than 38.

This little problem definitely pushes me back toward voting for the simple greedy linear encoding algorithm, since our "reasonable number" would have to be a fairly contrived choice to match existing uses, not anything obvious or elegant.

Keep in mind that Catagolue only properly encodes patterns up to 40x40 right now, and that there's at most eight strips of height 5 in a pattern -- so the maximum number of consecutive z's you can have in a code on Catagolue right now is 7.

A few codes with seven consecutive z's exist:

Code: Select all

sqlite> select distinct code, rule from census where code like "%zzzzzzz%";
xp160_3vy9v3zzzzzzzovy9vo|b3s2-i34q
xp160_voy9ovzzzzzzzv3y93v|b3s2-i34q
xq11_6917zzzzzzzyeci2e|b2c34e6cs2-i3-jn5e
xq12_4fzzzzzzzyv896|b2ik367s127
xq12_f2zzzzzzzyw5041|b2ik367s127
xq52_cjoo7zzzzzzzyt4a1a6|b36ce7-es23-y
xq74_okb7zzzzzzzyb25534jv|b3s23-e4e
sqlite>

The ships are just improperly unseparated, I think, but the xp160's in b3s2-i34q are genuine. In any case, since 8 consecutive z's are not currently possible on Catagolue, this would be a reasonable cut-off. (And it would not be completely arbitrary, either, insofar as that it derives from the specification of "classic" apgcodes rather than just the objects that happen to have been recorded on Catagolue at an arbitrary point in time.)

[dvgrn]

I guess for the moment my vote is for the simple greedy algorithm, but my mind might not be entirely made up yet. If someone can suggest a backwards-compatible apgext format that also allows logarithmic compression of vertical gaps, I might find that to be pretty much irresistible.

Might even volunteer to write revised encoders and decoders for the format, but I won't promise anything yet...!

I'm still leaning towards greedy codes, too; the fact that they strictly extend apgcodes (in their current form) and that existing decoders should require no modification are killer features IMO.
...
THAT SAID, I think there is one more purpose that apgcodes serve: they provide the machinery to unambiguously compare patterns. Given two RLE files, it's not a trivial task to figure out whether they contain the same pattern or not. Two (canonical) apgcodes, however, will be definition encode the same object if and only if the codes themselves are identical. And this is a use where it won't matter whether the code is short enough to be used, remembered or quoted by human users.

There will always be somewhat arbitrary limits on what kinds of patterns an extended apgcode can be found for. The first problem pattern that occurs to me would be a two-rectifier glider loop with a million-cell diagonal separation. Even with the bijoscar call upgraded to a million ticks as in the current greedy-algorithm script, it won't be possible to find a period, and therefore the script won't even be able to try to generate the large hash table needed to figure out which phase is the canonical one.

It doesn't seem to me that that's a show-stopper, though. There is a unique small canonical apgext code for that pattern -- it just might take some extra time and/or a modified encoder script to find it. But once the code is found, it will be usable (if anyone needs a unique fingerprint of a particular silly-slow glider loop for some reason).

Besides the phase issue, I think it really shouldn't be too time-consuming to generate different orientations of very large sparse patterns. Any pattern with a reasonable-sized apgcode will resolve to a reasonably short list of cell coordinates, and those can be sorted and subtracted from each other and so on, fairly efficiently, without having to do anything horrible like populate and transform a full 2D grid of bits the size of the bounding box. Will probably want to use bigints, in whatever language the encoder/decoder is written in... so there's a maybe little overhead there in some cases, but probably not really noticeable.

So I don't know, maybe an apgext format that's backwards-compatible to classic apgcode would be a good idea after all, to allow for logarithmic compression of blank space both horizontally and vertically. Seems to me that once a spec is written, it really won't be difficult to implement -- and for nearly all cases it won't make any difference at all.

On the subject of encoding vertical gaps:

Would have to only start encoding vertical gaps after the first 38 z's have gone by, I suppose...

Keep in mind that Catagolue only properly encodes patterns up to 40x40 right now, and that there's at most eight strips of height 5 in a pattern -- so the maximum number of consecutive z's you can have in a code on Catagolue right now is 7... In any case, since 8 consecutive z's are not currently possible on Catagolue, this would be a reasonable cut-off. (And it would not be completely arbitrary, either, insofar as that it derives from the specification of "classic" apgcodes rather than just the objects that happen to have been recorded on Catagolue at an arbitrary point in time.)

Ah, right, wasn't thinking well last night. A cutoff of eight z's seems better somehow -- not sure why.

The idea of being able to unambiguously fingerprint Sparse Life structures kind of pushes me back in the other direction. On the other hand, a lot of Sparse Life patterns are infinite-growth or quadratic-growth constructions that don't become periodic in approximately forever, so you can't really pick a canonical apgcode phase anyway.

... So it seems that my vote is still for the current simple greedy algorithm. Anyone else have a good reason for a different vote?

[Scorbie]

This seems to imply that it doesn't hurt to introduce new characters, does it? How about adding ~ or - or . to delimit repeated 0s or zs? Edit: At least an underscore can be used.

[muzik]

How about a script that shows the bare minimum non-totalistic rule in which a set pattern works in an identical way to a set rule?


For example, if i had a copperhead in B3/S23 and ran the script, the rule would change to B3-ceky/S23-cik.

[Apple Bottom]

How about a script that shows the bare minimum non-totalistic rule in which a set pattern works in an identical way to a set rule?

For example, if i had a copperhead in B3/S23 and ran the script, the rule would change to B3-ceky/S23-cik.

That's basically Jason Summers's Oscillizer, except for adapted to a) spaceships and b) non-totalistic rules.

If you want to implement this, that might be a good starting point. Oscillizer's source code (in C) is available on that page as well.

[dvgrn]

How about a script that shows the bare minimum non-totalistic rule in which a set pattern works in an identical way to a set rule?

For example, if i had a copperhead in B3/S23 and ran the script, the rule would change to B3-ceky/S23-cik.

Should the script also notice if there's a totalistic neighborhood that isn't actually used? The script gets a little more complicated if you have to deal with this version of the copperhead, for example:

Code: Select all

x = 8, y = 12, rule = B38/S2378
b2o2b2o$3b2o$3b2o$obo2bobo$o6bo2$o6bo$b2o2b2o$2b4o2$3b2o$3b2o!

Isn't there already a script somewhere that makes a report of all non-totalistic neighborhoods that are actually used by a given pattern? I have a very vague memory of maybe seeing something like that.

[Rhombic]

I'm pretty sure the script either already exists or there's a way around it that I haven't thought about, but here it goes:

a script to list all the different 2-spaceship collisions for a given spaceship (ideally from selection or apgcode)
I was thinking about using these listings for the non-glider spaceships in non-totalistic rules

[Caenbe]

Isn't there already a script somewhere that makes a report of all non-totalistic neighborhoods that are actually used by a given pattern? I have a very vague memory of maybe seeing something like that.

There is such a script here, however it only handles semi-totalistic rules.

[Saka]

I would like a script that searches soups until it detects an expanding pattern.

[dvgrn]

I would like a script that searches soups until it detects an expanding pattern.

Seems like a very small change to the old apgsearch Python script would do that. Maybe you'd want to disable the report-to-Catagolue function, but you almost wouldn't have to. What am I missing? Do you want to do this kind of search in multistate rules, or something like that?

[Saka]

I would like a script that searches soups until it detects an expanding pattern.

Seems like a very small change to the old apgsearch Python script would do that. Maybe you'd want to disable the report-to-Catagolue function, but you almost wouldn't have to. What am I missing? Do you want to do this kind of search in multistate rules, or something like that?

I want it to be able to search in any kind of rule. All it does is keep soup searching until the soup expands (And therefore a moving object is found). This is useful when I make a new rule but gliders are not coming out and I want to find a glider and I know one exists.

[Gamedziner]

I want it to be able to search in any kind of rule. All it does is keep soup searching until the soup expands (And therefore a moving object is found). This is useful when I make a new rule but gliders are not coming out and I want to find a glider and I know one exists.

The problem with that is that many rules explode, producing patterns that have an infinite bounding box but are not ships.
Replicator(the rule) is an example of this.

[BlinkerSpawn]

How can I force Golly to load a rule file from the clipboard?
Can I just use g.setrule([RULENAME]) even though the rule hasn't been saved anywhere?

[Saka]

I want it to be able to search in any kind of rule. All it does is keep soup searching until the soup expands (And therefore a moving object is found). This is useful when I make a new rule but gliders are not coming out and I want to find a glider and I know one exists.

The problem with that is that many rules explode, producing patterns that have an infinite bounding box but are not ships.
Replicator(the rule) is an example of this.

I'm using it for rules that tend to stabilize or dissolve into nothing, like day and night. It will search small 16x16 soups.

[Apple Bottom]

I'm using it for rules that tend to stabilize or dissolve into nothing, like day and night. It will search small 16x16 soups.

If you want to find new ships in Day & Night I'd honestly stick to using apgmera. It's much faster than any Golly script will be, even if you include the time spent on identifying and censusing patterns, uploading hauls and so on.

That said, since I've soup-searched Day & Night extensively, don't count on finding new ships by investigating random soups anytime soon. True, the next ship could always just be around the corner -- but in practice it's unlikely you'll find a new one this way anytime soon.

Side note: are you looking for NEW ships, or existing ones? For new ships searching soups ain't the best way to go about it anyway.

[Saka]

I'm using it for rules that tend to stabilize or dissolve into nothing, like day and night. It will search small 16x16 soups.

If you want to find new ships in Day & Night I'd honestly stick to using apgmera. It's much faster than any Golly script will be, even if you include the time spent on identifying and censusing patterns, uploading hauls and so on.

That said, since I've soup-searched Day & Night extensively, don't count on finding new ships by investigating random soups anytime soon. True, the next ship could always just be around the corner -- but in practice it's unlikely you'll find a new one this way anytime soon.

Side note: are you looking for NEW ships, or existing ones? For new ships searching soups ain't the best way to go about it anyway.

Basically I really like to make random non totalistic rules and I want to quickly soup search for some spaceships.

[Saka]

I would like to request a script to make a programmed metapixel display with custom frames (select frames, a frame is seperated by 3 cells)

[dvgrn]

I would like to request a script to make a programmed metapixel display with custom frames (select frames, a frame is seperated by 3 cells)

You mean, to make something like Patterns/Hashlife/hexadecimal.mc.gz, right? I think I have the code Brice Due wrote to generate that pattern -- and I ran it to change the movie frames for hexadecimal.mc.gz, so it was in working order at one point.

Will do some digging this weekend and see what I can find. You might have to make adjustments yourself if you specifically want your frames-with-3-cells-separation functionality, though -- I don't remember how that worked offhand. I just remember it was a bit arbitrary and mysterious, so it probably wasn't quite what you're asking for...!

[BlinkerSpawn]

REQUEST: An overlay script to give Golly viewing functionality similar to the TRACKBOX feature in LifeViewer.

[dvgrn]

REQUEST: An overlay script to give Golly viewing functionality similar to the TRACKBOX feature in LifeViewer.

We have that already, at least to some extent. Try this, for example --

Code: Select all

x = 323, y = 327, rule = B3/S23
79b2o$79b2o7$87b2o$87b2o7$74b2o$73bo2bo13b2o$74b2o14bo2bo$90bo3bo$91b
3o$56bo$56b2o$55bobo30bobo$82b2o3bo3bo$81bo2bo7b2o$82b2o3bo5bo$87bo6bo
$88b2o4bo$94bo$90bo3bo$90bo3bo$91bobo$91b3o$73bobo$66b2o3b2obo$66b5ob
2o3b2o$66bob2obobo3b2o$67b2o4bob2o2bo$40b2o24b3o5bobobo$35bo4b2o24b3o
7bobo40b2o$33bo4bo21b2o57b2o$32bo5bo20b2o$33bo4bo21b2o$35bo25b3o$62bob
o$62bo2bo$65bo$63bobo61b2o$63b3o61b2o5$62b2o$61bo2bo$61b2o51b2o$62b5o
46bo2bo13b2o$66b2o46b2o14bo2bo$23bo39b2o2b2o61bo3bo$21b2o40bo2b2o63b3o
$22b2o40b3o29bo$65bo30b2o$42bo52bobo30bobo$41b3o78b2o3bo3bo$41bob2o10b
2o64bo2bo7b2o$44b3o7bob2o64b2o3bo5bo$44bo3b2o4bo2bob2o66bo6bo$45bo3bo
5bobobobo66b2o4bo$46b4o7bo3b2o71bo$35b3ob2o16b2ob2o68bo3bo$35b2ob3o17b
3o69bo3bo$36b5o18bo71bobo$36b2o93b3o$36bo76bobo$35bobo68b2o3b2obo$35b
2o69b5ob2o3b2o$17bo16bob3o67bob2obobo3b2o$16bobo16bo3bo67b2o4bob2o2bo$
16bobo15bo3bo41b2o24b3o5bobobo$17bo20b3o34bo4b2o24b3o7bobo$36b2o35bo4b
o21b2o$36b2ob2o31bo5bo20b2o$2o36bo34bo4bo21b2o$2o73bo25b3o$25bo76bobo$
24bobo75bo2bo$24bobo78bo$25bo77bobo$103b3o2$8b2o14bob2o$8b2o13bo4bo$
28bo$17b3o3bo6b2o70b2o$17bo2bo3bo7b2o67bo2bo$20bo4bo7bo67b2o$18bobo4b
2o5b2o68b5o$19bo7b5o74b2o$63bo39b2o2b2o$61b2o40bo2b2o$62b2o40b3o$105bo
$82bo$81b3o$81bob2o10b2o$84b3o7bob2o$84bo3b2o4bo2bob2o$85bo3bo5bobobob
o$86b4o7bo3b2o$75b3ob2o16b2ob2o$75b2ob3o17b3o$76b5o18bo$76b2o$76bo$75b
obo$75b2o$57bo16bob3o$56bobo16bo3bo$56bobo15bo3bo$57bo20b3o$76b2o$76b
2ob2o$40b2o36bo$40b2o$65bo$64bobo$64bobo$65bo3$48b2o14bob2o$48b2o13bo
4bo$68bo$57b3o3bo6b2o$57bo2bo3bo7b2o$60bo4bo7bo$58bobo4b2o5b2o$59bo7b
5o48$292b2o$292bobo$294bo4b2o$290b4ob2o2bo2bo$290bo2bobobobob2o$293bob
obobo$294b2obobo$298bo2$284b2o$285bo7b2o$285bobo5b2o$286b2o25bo$311b3o
$310bo$310b2o$285bo$284bobo$285bo32b2o$296b2o21bo$296bo22bob2o$297b3o
11b2o4b3o2bo$299bo11b2o3bo3b2o$316b4o$302b2o15bo$301bobo12b3o$301bo13b
o$300b2o14b5o$320bo$318bo$318b2o7$305bo$304bobo$305bo19$309b2o$309bo$
310b3o$312bo2$289b2o$289bo$290b3o$292bo15$276b2o$276bobo$278bo$278b2o
2$187bo$186bobo$187bo6$267b2o$267bo$268b3o$270bo5$195bo7bo$195b3o4bobo
$198bo4bo$197b2o2$249b2o$189b2o58bobo$189bo61bo$186b2obo61b2o$186bo2b
3o4b2o$187b2o3bo3b2o$189b4o$189bo15b2o$190b3o12bobo$193bo13bo$188b5o
14b2o$188bo24bo$190bo20b3o$189b2o19bo$210b2o$224bo$223bobo$224bo3$244b
2o$200b2o42bobo$199bobo5b2o37bo$199bo7b2o37b2o$198b2o2$212bo$208b2obob
o$207bobobobo$204bo2bobobobob2o$204b4ob2o2bo2bo$208bo4b2o$206bobo$206b
2o!
#C [[ STEP 5 AUTOSTART TRACKBOX 1/12 1/12 1/12 1/12  ]]

Copy this, and use Open From Clipboard (Ctrl+Shift+O) to open it in Golly 2.9b1. Run lifeviewer.lua and see what you get!

Notice that some more complicated script commands, along the lines of

#C [[ X -175 Y -175 ZOOM 2 STEP 9 AUTOSTART TRACKBOX 1/4 1/4 1/12 1/12 STOP 2800 ]]

aren't correctly supported in the 2.9b1 lifeviewer.lua. Early days yet --!

[dvgrn]

I would like to request a script to make a programmed metapixel display with custom frames (select frames, a frame is seperated by 3 cells)

You mean, to make something like Patterns/Hashlife/hexadecimal.mc.gz, right? I think I have the code Brice Due wrote to generate that pattern -- and I ran it to change the movie frames for hexadecimal.mc.gz, so it was in working order at one point.

Found it, in a ten-year-old email... And wonder of wonders, it still works, at least for me. 16x10-cell frames are separated by 16 cells horizontally and 6 cells vertically (i.e., they're on a 32x16 grid). Here you go:

moviemaker.zip

moviemaker.py, plus two required base pattern files (movie pixel and 152 frames)

(13.86 KiB) Downloaded 283 times

When you run moviemaker.py, and you have both metapix.rle and tile152.rle in the same folder as the script, it will build you a custom 16x10-pixel movie pattern using the frames in tile152.rle and the base pixel pattern in metapix.rle.

movie.mc.gz

sample movie from moviemaker.py

(33.64 KiB) Downloaded 288 times

The 152 frames are a hard upper limit, unless you redesign the movie metapixel. However, since each pixel is programmed independently, trivial adjustments can be made to the script to create movies with more pixels. I'll leave that as an exercise for the reader.

Comments from Golly's Patterns/Hashlife/hexadecimal.mc.gz apply pretty well here. My Golly 2.7 got overloaded and decided to crash after I tried undoing a long run with movie.mc.gz. Your mileage may vary.

[This movie pattern] is a distant relative of Alan Hensel's Decimal Counter (see Guns/golly-ticker.rle), and a close relative of the 'META' patterns in Patterns/Hashlife: the tiles have the same base period, 35328 ticks, and share the same large-scale pixel machinery, with an adapted clock mechanism. The first pixel updates begin just before generation 6000.

This pattern should be run in hashing mode, with a step size of 8^4 or 8^5. For this pattern, it's particularly important that the 'Maximum memory for hashing' setting (File > Preferences, on the Control tab) does not exceed your available RAM. Using virtual memory and paging hash information to the hard drive will by far outweigh any speed advantages due to the larger hash table.

[drc]

Is it possible to make a script where you specify a pattern and it gives you all the rules in which said pattern evolves into a spaceship? For example, a t-tetromino would warrant:

Code: Select all

x = 2, y = 3, rule = B3/S2-i34q
o$2o$o!

Code: Select all

x = 2, y = 3, rule = B36/S2-e368
o$2o$o!

Code: Select all

x = 2, y = 3, rule = B368/S23-cej6
o$2o$o!

etc.

[BlinkerSpawn]

Is it possible to make a script where you specify a pattern and it gives you all the rules in which said pattern evolves into a spaceship? For example, a t-tetromino would warrant:

Code: Select all

x = 2, y = 3, rule = B3/S2-i34q
o$2o$o!

Code: Select all

x = 2, y = 3, rule = B36/S2-e368
o$2o$o!

Code: Select all

x = 2, y = 3, rule = B368/S23-cej6
o$2o$o!

etc.

Well, there's 2^102 total non-totalistic rules (2^98 if you disallow B012a) so an exhaustive search is out of reach and will continue to be so for quite some time.
However, there may be a way to create subsets of the search space that are reasonably diverse and yet of manageable size.

• Take Life.
• Add any of B5678/S5678* {2^8 choices}
• Take n transitions from B23456/S23456 and invert them (if they map to OFF turn them ON and vice versa) {45Cn choices}

This divides the search space into subsets that increase subgeometrically with n:

Code: Select all

n numRules
0 256
1 11520
2 253440
3 3632640
4 38142720
etc.

This should lend itself rather easily to scripting and division across multiple processors.
Your second pattern would show up under a search with n = 1, the first with n = 2, and the last with n = 3.

*I mean you could try it with B4 or S4 but I''m pretty sure that's a waste of time.

[twinb7]

It'd be cool to have a turing-machine rule generator script that allows you to see the evolution of the turing machine with the up-down direction being the time axis, as in normal Golly simulation of W110 or something.