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