Base-3 Pattern Integers

[Saka]

Something strange I thought of.
What if we trenary-ized patterns to make a "pattern integer"?
So like this:

Encoding
1. Take a pattern

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!

2. Turn each row into a binary number:

Code: Select all

010
100
111

3. Join them into 1 line:

Code: Select all

010100111

4. On the end of each line and start of the string, append "2" to distinguish different rows:

Code: Select all

201021002111

5. Turn it into decimal:

Code: Select all

379147

Example 2:

Code: Select all

x = 10, y = 13, rule = B3/S23
4b2o$3b4o2$2b6o$3b4o2$2b2o2b2o$2obo2bob2o$3bo2bo3$4b2o$4b2o!
!

Code: Select all

200001100002
00011110002
00000000002
00111111002
00011110002
00000000002
00110011002
11010010112
00010010002
00000000002
00000000002
00001100002
0000110000

Code: Select all

113094238779136186224404200800208066204840200024442844228088088284862

Decoding
Pretty straightforward:
1. Take a code:

Code: Select all

379147

2. Turn it to Base-3

Code: Select all

201021002111

3. Put the rows, removing the first "2" splitting on each '2' and

Code: Select all

010
100
111

4. Turn 2D array to pattern/RLE

Code: Select all

x = 3, y = 3, rule = B3/S23
bo$o$3o!

I don't know if this is useful or anything, just wanted to post.
Any improvements?

[Macbi]

It seems like the idea is to convert a life pattern to a decimal number as efficiently as possible. So how about this: Starting in the centre of the pattern and working out in a spiral pattern write 0 or 1 depending on whether the cell is alive or dead. Then there is no need to encode newlines, and so we can just use binary rather than base 3. Lets suppose the spiral goes in this direction:

Code: Select all

6789
501
432

Then the glider

Code: Select all

010
100
111

becomes

Code: Select all

10111100

and hence

Code: Select all

188

The copperhead would become

Code: Select all

8769010869333004479652076648183998230970886464518

[toroidalet]

Starting in the centre of the pattern and working out in a spiral pattern write 0 or 1 depending on whether the cell is alive or dead.

Where would the center be determined if the bounding box is even? (Presumably rounding, I suggest rounding to the SW). Rounding may result in an extra area of 0s, but it may be fine.

[Macbi]

Starting in the centre of the pattern and working out in a spiral pattern write 0 or 1 depending on whether the cell is alive or dead.

Where would the center be determined if the bounding box is even? (Presumably rounding, I suggest rounding to the SW). Rounding may result in an extra area of 0s, but it may be fine.

You can put it anywhere, but I would choose the place where the resulting number was smallest. Which means that when the bounding box is even you want to round to move the centre in the direction of the side that will get hit by the spiral last.

[Apple Bottom]

Something strange I thought of.
What if we trenary-ized patterns to make a "pattern integer"?

[...]

I don't know if this is useful or anything, just wanted to post.
Any improvements?

Interesting idea -- conceptually similar to apgcodes, but more primitive (which can be a good thing when simplicity is desired, of course). I think I prefer apgcodes, especially since they're shorter, but it's good to have variety.

[Macbi]

I think I prefer apgcodes, especially since they're shorter, but it's good to have variety.

That's just because they use more characters. If you want them to be really short use my method (or Saka's method) and then convert to Base62. For example you could encode a glider just by "1t", and the copperhead by "3xa5uGVEmO2E2YQkUr3RbVzW1ifA".

[Apple Bottom]

That's just because they use more characters. If you want them to be really short use my method and then convert to Base62.

Not just that; apgcodes also encode runs of zeros in an efficient manner to avoid overly long codes, and avoid representing empty strips (see e.g. the queen bee shuttle example on the wiki).

And your scheme is neat, but it would contain a lot of zeros for patterns with a low squareness. Switching to base62 wouldn't help with that.

Also, while distinguishing case is obviously going to shorten codes, doing so has the potential to sow confusion and cause subtle problems in practice when people talk about patterns, so I -- like Calcyman, in all likelihood believe that the trade-off isn't worth it and that using only lower-case is the better choice.

Of course there's no reason one couldn't do that with your scheme. But once you start doing things like encoding zeroes, and sticking to the same characters apgcodes use, and defining the canonical encoding of a pattern, then at some you gotta ask yourself if you're not just recreating apgcodes (or something very similar anyway).

It's also important to ask yourself what you hope to achieve anyway -- what problem you're trying to solve. apgcodes did solve some problems; they unambiguously identify patterns (unlike e.g. RLE files), they don't rely on external sources for said identification (unlikely e.g. Mark Niemiec's or Heinrich Koenig's object IDs), they are short (for small objects anyway), they can be encoded and decoded easily (unlike Heinrich Koenig's SOF representation), and they can be used in URLs etc. and written out by people without any real chance of corruption, due to the lack of special characters or upper-vs.-lower-case confusion (as above). That they also tell you some basic properties of the pattern (such as "xq4_something is a spaceship of period 4") is just the icing on the cake.

Coming up with novel ways to represent patterns is a good intellectual exercise, of course, and can be fun. But unless and until you can say "these are real problems that haven't been solved, and my new representation solves them (ideally, but not necessarily, while retaining whatever other desirable properties previous representations had)", they're just that -- an intellectual exercise, a game to play, not something one should take serious.

After all:

standards.png (23.74 KiB) Viewed 4051 times

Coming up with a new proposed standard isn't bad per se -- but it should be motivated by real defects and flaws in existing standards.

[Macbi]

Yeah, apgcodes are actually very close to optimal for small patterns. In particular the apgcode for the copperhead is actually shorter than the example I gave above, despite using fewer characters (because the copperhead isn't square).

For huge patterns like the caterpillar you can probably get the best compression by treating the pattern as a black and white image and using a standard lossless compression format.