Here is a checkbox I made in wireworld, for the "Create a checkbox!" question.
The problem is, we don't have a way to score answers like these.
Do we score these by pixels, like piet did, or in other ways?
\$\begingroup\$
\$\endgroup\$
16
5 Answers
\$\begingroup\$
\$\endgroup\$
1
There shouldn't be a general answer for all cellular automata.
People have pointed out that cellular automata are diverse. Some have only two states and square cells. Others have differently shaped cells with different rules and many possible states. This diversity means that we should not have one rule for all of them. Instead we should look at each one individually and decide how to score it.
-
\$\begingroup\$ I think this is the best approach. Let each CA have its own textual/binary encoding, and count the bytes of those. \$\endgroup\$– user45941Commented Feb 9, 2017 at 17:24
\$\begingroup\$
\$\endgroup\$
I know that golly allows you to copy and paste text into it, with spaces as empty cells, non-space as filled cells, and newline as ... newline. After pressing cmd/ctrl v, you click once, and the pattern is placed. Perhaps this could be used for the scoring system?
answered Feb 8, 2017 at 23:13
\$\begingroup\$
\$\endgroup\$
MCL Code
There is a Cellular automata emulator, which is widely used, called MCell.
This can emulate Cellular automata and create code for each, with the .mcl extension.
Maybe we might be able to use this.
\$\begingroup\$
\$\endgroup\$
10
The smallest bounding rectangle
If the program fits in a 16 by 16 rectangle of cells, then its score is 256 cells.
Worrying about how many bytes it'd take to store in a file isn't really a relevant plan unless there's a built-in way to convert a state into a file. If there is a built-in way to do that, then use the file size. As long as there's not, then the bounding rectangle should be used, because it represents the smallest grid that the base program could fit on, with the part outside the boundary all being the same infinite pattern, such as all live, or all dead.
-
1\$\begingroup\$ This only works for GoL, where each cell represents a single bit. The system isn't fair for other systems like VarLife, where each cell has a rule and a alive/dead state. \$\endgroup\$– user45941Commented Feb 9, 2017 at 2:50
-
\$\begingroup\$ Would this be the smallest bounding rectangle of the initial stare, or the smallest bounding rectangle for the program over the course of running it? \$\endgroup\$ Commented Feb 9, 2017 at 15:31
-
-
\$\begingroup\$ @Mego This isn't bytes. This is cells. If there's no built-in byte scoring system, we shouldn't attempt to score with bits or bytes. Just use cells in the same way that Piet uses codels/pixels. \$\endgroup\$– mbomb007Commented Feb 9, 2017 at 16:55
-
\$\begingroup\$ My point was, not all cells are created equal. In GoL, each cell holds one bit of information (alive/dead). In VarLife, each cell holds more than one bit of information (rule plus alive/dead). Scoring both of those types of cell equally is disingenuous - it's the same logic why we don't score by characters anymore (since UTF-16 is two bytes per character, while ASCII is one byte per character). \$\endgroup\$– user45941Commented Feb 9, 2017 at 16:57
-
\$\begingroup\$ @Mego Yet we score ASCII (7-bits) on equal ground with UTF-8. \$\endgroup\$– mbomb007Commented Feb 9, 2017 at 16:59
-
\$\begingroup\$ ASCII is represented as 1 byte, even if it doesn't use one of the bits. I'm not sure what you mean by "equal ground" - we directly compare the number of bytes, which is exactly equal to the number of characters in ASCII, but not necessarily so in UTF-8. \$\endgroup\$– user45941Commented Feb 9, 2017 at 17:01
-
\$\begingroup\$ You mean UTF-16? And I still disagree. GOL can be thought of like ASCII. It just uses less of the bits per cell, but can be scored the same. \$\endgroup\$– mbomb007Commented Feb 9, 2017 at 17:04
-
\$\begingroup\$ Let us continue this discussion in chat \$\endgroup\$– user45941Commented Feb 9, 2017 at 17:05
-
1\$\begingroup\$ @mbomb007 Comparing these to Piet might not be the best idea as there's currently no consensus on whether Piet programs should be counted by number of codels or bytes in the image. \$\endgroup\$ Commented Feb 9, 2017 at 18:35
\$\begingroup\$
\$\endgroup\$
ceil(Pixels/logbase(states,256)) + 3
This only works for gol variants on an infinite, square, grid. It takes no entropy to store an empty infinite grid. This is a fairly roundabout scoring system, so please feel free to downvote or critique.
Note that if the size is greater than a 256 by 256 box add 2 for each byte needed as representation of the size of one dimension.
Essentially we could easily create a file format where you take start with one byte detailing the number of bytes in which the dimensions are stored. Thus, each side can be up to 2^(2^128) squares long. Later two bytes (one for each side). Then convert the map to a binary integer (1=filled, 0 = empty) (and pad with 0's to make a multiple of 8 bits) to store in the rest of the file.
100)^k immediately before beginning a cycle through the program [i.e. on steps that are multiples of 24], it represents the integer k." I don't believe that format is among the default I/O methods. :P \$\endgroup\$