Rule integer: Difference between revisions
m Forgot to flip the directions in the description to match the new bit locations |
reword/relink, base64 |
||
| (14 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
{{Glossary}} | {{Glossary}} | ||
The '''rule integer''' of a given | The '''rule integer''' of a given [[Life-like rule]] is a single integer expressing its [[birth]] and [[survival]] conditions. | ||
The rule integer is computed by iterating over all B and S conditions, in order, writing down a one if a condition is present and a zero otherwise, and finally reversing the resulting string and interpreting it as a binary number. For instance, for [[Conway's Game of Life]] (B3/S23): | The rule integer is computed by iterating over all B and S conditions, in order, writing down a one if a condition is present and a zero otherwise, and finally reversing the resulting string and interpreting it as a binary number. For instance, for [[Conway's Game of Life]] (B3/S23), its rule integer is 6152 because: | ||
<tt> | |||
{| | |||
|- | |||
| B0 || B1 || B2 || B3 || B4 || B5 || B6 || B7 || B8 || S0 || S1 || S2 || S3 || S4 || S5 || S6 || S7 || S8 | |||
|- | |||
| 0 || 0 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 1 || 0 || 0 || 0 || 0 || 0 => 000100000001100000 => 000001100000001000b = 6152d | |||
|}</tt> | |||
Rule integers can also be constructed for [[hexagonal neighbourhood]] rules using similar methods. | |||
[[apgsearch]] 3.x (apgmera) uses a variant of rule integers to determine the circuitry needed to compute a given rule. | [[apgsearch]] 3.x (apgmera) uses a variant of rule integers to determine the circuitry needed to compute a given rule. | ||
== Non-totalistic rules == | ==Non-totalistic and non-isotropic rules== | ||
There is | There is not yet a generally accepted way of assigning rule integers or numbers to [[Non-totalistic rule|non-totalistic]] or [[Non-isotropic rule|non-isotropic]] rules. | ||
However, a candidate assignment is used by [[Chris Rowett]]'s [[LifeViewer]] and [[Golly]] 3.0 as a native rule type for [[Moore neighbourhood|Moore]], Hex and [[Von Neumann neighborhood|von Neumann]] neighborhoods. | |||
For the Moore neighborhood the format is as follows: <tt>rule = MAP{base64-encoded 512-bit binary string}</tt>, where the ''n''-th bit in the string gives the output state for a specific set of neighborhood conditions. | |||
Numbering the bits starting with 0, bit #0 (&B000000000) is the output state if all neighbors (and the center cell) are OFF, and bit #511 (&B111111111) is the output state if all neighbors (and the center cell) are ON. In between, look up the value of the various ON cells in a neighborhood in the following table: | Numbering the bits starting with 0, bit #0 (&B000000000) is the output state if all neighbors (and the center cell) are OFF, and bit #511 (&B111111111) is the output state if all neighbors (and the center cell) are ON. In between, look up the value of the various ON cells in a neighborhood in the following table: | ||
| Line 24: | Line 33: | ||
| 4 || 2 || 1 | | 4 || 2 || 1 | ||
|} | |} | ||
The output state is read directly from the 512-bit string, The position in the string is determined by the sum of the values of the ON cells. For example, zero-based bit#85 (=1+4+16+64) specifies what happens to an ON cell (16) if it has ON neighbors to the SE (1), SW (4), and NE (64). | The output state is read directly from the 512-bit string, The position in the string is determined by the sum of the values of the ON cells. For example, zero-based bit#85 (=1+4+16+64) specifies what happens to an ON cell (16) if it has ON neighbors to the SE (1), SW (4), and NE (64). | ||
For the Hex neighborhood the format is: <tt>rule = MAP{base64-encoded 128-bit binary string}</tt> and for the von Neumann neighborhood the format is: <tt>rule = MAP{base64-encoded 32-bit binary string}</tt>. | |||
Note the canonical form of MAP rule strings zeroes unused bits in the final [[base64]] character. | |||
== Megacell non-totalistic encoding == | == Megacell non-totalistic encoding == | ||
Adam P. Goucher's [[ | Adam P. Goucher's [[p1 megacell]] is a Life [[unit cell]] capable of simulating arbitrary non-totalistic rules. Its configuration includes a 512-bit rule integer encoded as a line of eaters in the west side of the south corner. This uses a different bit order, with the center cell as the most significant bit: | ||
{| border="1" style="border-collapse: collapse; text-align: center;" | {| border="1" style="border-collapse: collapse; text-align: center;" | ||
| Line 37: | Line 51: | ||
| 16 || 32 || 64 | | 16 || 32 || 64 | ||
|} | |} | ||
== Also see == | |||
* [[Rulestring]] | |||
Latest revision as of 08:26, 30 March 2023
The rule integer of a given Life-like rule is a single integer expressing its birth and survival conditions.
The rule integer is computed by iterating over all B and S conditions, in order, writing down a one if a condition is present and a zero otherwise, and finally reversing the resulting string and interpreting it as a binary number. For instance, for Conway's Game of Life (B3/S23), its rule integer is 6152 because:
| B0 | B1 | B2 | B3 | B4 | B5 | B6 | B7 | B8 | S0 | S1 | S2 | S3 | S4 | S5 | S6 | S7 | S8 |
| 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 => 000100000001100000 => 000001100000001000b = 6152d |
Rule integers can also be constructed for hexagonal neighbourhood rules using similar methods.
apgsearch 3.x (apgmera) uses a variant of rule integers to determine the circuitry needed to compute a given rule.
Non-totalistic and non-isotropic rules
There is not yet a generally accepted way of assigning rule integers or numbers to non-totalistic or non-isotropic rules.
However, a candidate assignment is used by Chris Rowett's LifeViewer and Golly 3.0 as a native rule type for Moore, Hex and von Neumann neighborhoods.
For the Moore neighborhood the format is as follows: rule = MAP{base64-encoded 512-bit binary string}, where the n-th bit in the string gives the output state for a specific set of neighborhood conditions.
Numbering the bits starting with 0, bit #0 (&B000000000) is the output state if all neighbors (and the center cell) are OFF, and bit #511 (&B111111111) is the output state if all neighbors (and the center cell) are ON. In between, look up the value of the various ON cells in a neighborhood in the following table:
| 256 | 128 | 64 |
| 32 | 16 | 8 |
| 4 | 2 | 1 |
The output state is read directly from the 512-bit string, The position in the string is determined by the sum of the values of the ON cells. For example, zero-based bit#85 (=1+4+16+64) specifies what happens to an ON cell (16) if it has ON neighbors to the SE (1), SW (4), and NE (64).
For the Hex neighborhood the format is: rule = MAP{base64-encoded 128-bit binary string} and for the von Neumann neighborhood the format is: rule = MAP{base64-encoded 32-bit binary string}.
Note the canonical form of MAP rule strings zeroes unused bits in the final base64 character.
Megacell non-totalistic encoding
Adam P. Goucher's p1 megacell is a Life unit cell capable of simulating arbitrary non-totalistic rules. Its configuration includes a 512-bit rule integer encoded as a line of eaters in the west side of the south corner. This uses a different bit order, with the center cell as the most significant bit:
| 4 | 2 | 1 |
| 8 | 256 | 128 |
| 16 | 32 | 64 |