Padding -- you mean padding the bitstring with zeroes in step 4? That's just to ensure it's the right length for easy, unambiguous conversion to octal digits.shouldsee wrote:Thank you for this informative scheme and I think you deserve its name (lol).
The only unnatural part to me is the padding.
There's not much that can be done about the different numbers of subconditions that the various B/S conditions have, unfortunately. B7 (or S7) only has two, while B4 (or S4) has 13, that's just the way it is in Alan's scheme. And of course he didn't pull his scheme from thin air either: these really are the numbers of different configurations that can exist for a given neighbor count.The problem as I view it is that different B/S principal number have a different number of sub-neighborhoods, asking each neighborhood to be expanded differently.
That said, with these "Apple Bottom numbers", the non-integer part that encodes the non-totalistic subconditions is largely opaque. It's still true that tools working with these numbers need to know about the different numbers of subconditions that exist for different B/S conditions, but:
- Using 14 bits for each individial B/S condition would make the resulting numbers quite a bit longer (as strings);
- I've already implemented it this way, and I'm lazy and don't want to change things; and
- Perfect is the enemy of good.
For those I'd say it'd be most natural to use a 128-digit hexadecimal number that encodes said 512 bits. (In fact I don't think there's ANY notation for these rules yet, certainly nothing generally understood and agreed on.)It would also be great if the scheme allow a easy transfer towards non-istropic non-totalistic rules (aka the most general form of 2d Moore rules, which would obviously be sufficiently described with a 2^9=512 bit string ).
I'm not sure how you'd extend either rule integers or "Apple Bottom numbers" to cover these non-isotropic rules.