A while ago, I wrote:In terms of further rule families, the next one I intend to implement is outer-totalistic rules up to range 5.
Higher-range outer-totalistic (HROT) rules are implemented as of
v4.63 (in apgsearch) and
ll2.0.17 (in lifelib).
The syntax is
rXbXXX...XsXXX...X[z]where the range can be either 2, 3, 4, or 5, and the 'b' and 's' must each be followed by exactly r(r+1) hexadecimal characters. For instance, the LtL rule r2b4t4s10t19 has the outer-totalistic rulestring r2b000008s03ff00, where:
- 000008 = 0000 0000 0000 0000 0000 1000 because we have birth only on 4 neighbours, and the 4th-from-last bit is 1 (the others are 0).
- 03ff00 = 0000 0011 1111 1111 0000 0000 because we have survival from 9 to 18 neighbours, and those bits are 1.
IMPORTANT: the middle cell is
included in LtL (for consistency with Kellie Evans' original notation), but
excluded in HROT (for consistency with the usual outer-totalistic B/S notation).
If you want survival on zero neighbours, stick a 'z' on the end of the rule. For instance, if we were allowed r1 (which we're not, because that pointlessly duplicates the outer-totalistic rulespace), then B3/S02456 would have the rulestring r1b04s3az:
- 04 = 0000 0100 because we have birth only on 3 neighbours, and the 3rd-from-last bit is 1 (the others are 0).
- 3a = 0011 1010 because we have survival on 2, 4, 5 and 6 neighbours.
- z because we have survival on zero neighbours.
A maximum range of 5 is supported (in which case each of the birth and survival conditions have exactly 30 hex chars), because due to extremely technical reasons* the
HROT code can't support neighbourhoods of area greater than 127.
* The easiest way to explain it is that PSHUFB allows me to index into a lookup table of at most 16 bytes, and I can (with some effort) use that as a 128-bit lookup table. I have separate 'birth' and 'survival' lookup tables, PSHUFB each of them, and combine the results using the result of PCMPEQB-ing the centre cell with zero. This extracts the relevant
byte; to extract the specific
bit, I PSHUFB a 'powers of 2' lookup table and take the bitwise AND with the vector of bytes.
Also, I haven't combined this with Generations yet (it's 3:58 am here and I want to have food and sleep soon!), but the changes to do so would be utterly trivial.