ConwayLife.com

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

Encoding
1. Take a pattern 2. Turn each row into a binary number: 3. Join them into 1 line: 4. On the end of each line and start of the string, append "2" to distinguish different rows: 5. Turn it into decimal: Example 2: Decoding
Pretty straightforward:
1. Take a code: 2. Turn it to Base-3 3. Put the rows, removing the first "2" splitting on each '2' and 4. Turn 2D array to pattern/RLE I don't know if this is useful or anything, just wanted to post.
Any improvements?

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: Then the glider becomes and hence The copperhead would become

Macbi wrote: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.

toroidalet wrote:

Macbi wrote: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.

Saka wrote: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.

Apple Bottom wrote: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".

Macbi wrote: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:
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.

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.