Human-readable alternative to base64-encoded MAP rulestrings?

[confocaloid]

There is some prior art for expressing sets of fixed-orientation 3x3 subconditions in a human-readable form:

I was thinking more of something along the lines of extending the notation used for isotropic non-totalistic rules.

For example, if I wanted a non-isotropic rule including certain variations of B2a, they could be picked from a set of possible rotations:

Code: Select all

x = 38, y = 11, rule = LifeHistory
3D3.D3.3D2.3D2.D.D2.3D2.3D2.3D$D.D3.D5.D4.D2.D.D2.D4.D6.D$D.D3.D3.3D
2.3D2.3D2.3D2.3D4.D$D.D3.D3.D6.D4.D4.D2.D.D4.D$3D3.D3.3D2.3D4.D2.3D2.
3D4.D4$2EB2.B2E2.2BE2.3B2.3B2.3B2.3B2.E2B$BCB2.BCB2.BCE2.BCE2.BCB2.BC
B2.ECB2.ECB$3B2.3B2.3B2.2BE2.B2E2.2EB2.E2B2.3B!

One possible notation using this system would be B2a(0246)/S2a(1357), which would only allow for birth on the displayed B2a conditions marked as 0, 2, 4 and 6, and survival on those marked 1, 3, 5 and 7. Like with non-totalistic rules, a - to negate unwanted orientations could also be used.

This notation probably isn't optimal when it comes to the lengths of rulestrings, but at least it could be interpreted a bit easier, and understanding what a rulestring symbolises at a glance is what i'm really after.

One possible notation using this system would be B2a(0246)/S2a(1357), which would only allow for birth on the displayed B2a conditions marked as 0, 2, 4 and 6, and survival on those marked 1, 3, 5 and 7. Like with non-totalistic rules, a - to negate unwanted orientations could also be used.

I have several ideas for this.

1. For the sake of easy understanding I'd avoid numbers -- which would require a publisher master list to interpret, as dvgrn points out --, and perhaps use compass directions instead, to wit:
   

   Code: Select all

   nw n ne
   w  -  e
   sw s se
   

   "B1(n,w)" is more easily understood than "B1e(1,2)" or so.
   
   In cases like B1, this would also do away with the distinct subconditions that are separately encoded in Alan Hensel's notation, but it would be difficult to ALWAYS do this; you'd generally still want to keep them separate.
   
   Figuring out how to match the possible orientations of a given isotropic subcondition with the compass direction might also be difficult / non-intuitive in general, so when doing this one would probably end up publishing lists again anyway, making this notation semi-mnemonic at best. (Kinda like Alan Hensel's, actually; I can never remember what exactly "4q", "4z" and all those mean without looking them up.)
2. It might actually be better to assign a single letter to each direction, and then directly specify which bits have to be set to satisfy a certain Bx or Sx condition. For example:
   

   Code: Select all

   l  n  r
   w  -  e
   v  s  h
   

   "l(eft)" and "r(ight)" for "nw" and "ne" are probably self-explanatory; I turned to Swedish for "v(änster)" and "h(öger)" for "sw" and "se".
   
   One could try and find other mnemonics in English as well. "c(lockwise)" is tempting; unfortunately "w(iddershins)" clashes with "w(est)"...
   
   In any case, any non-isotropic subcondition could then be expressed by putting together the respective letters. For instance, birth on 3 cells, those being either l, n and r, or alternatively l, e and v, could be expressed as "B3(lnr,lev)". Each non-isotropic subcondition would be represented by one group (which could be in any order, just like with Hensel's isotropic subconditions), and groups would be separated by commas, say.
   
   Negation still works: "B3(-lnr,lev)" is easily understood to mean birth on three live neighbors, UNLESS those neighbors are either l, n and r, or alternatively l, e and v.
   
   It would be possible to do away with the outer-totalistic B/S conditions in this notation and just write e.g. "B(w,e,l,lnr,lev,-nswe)" or so, but I think that's less readable overall. There's a lot of possible configurations that could be present (or negated), and parsing a long rulestring would be easier for humans if it's a organized according to overall neighbor count.
3. One could also stipulate that in this notation, for non-isotropic subconditions for 5 to 8 neighbors, the letters indicate dead cells rather than live ones. "B7(n,w)" is much shorter than "B7(lrwevsh,lnrevsh)", and should be intuitive and easy to understand.
4. Finally, since (as I noted) the labels for the compass directions are essentially arbitrary again, it might actually make sense to use numbers for those after all:
   

   Code: Select all

   1  2  3
   4  -  5
   6  7  8
   

   ...and write "B1(2,4)" instead of "B1(n,w)", and "B3(-123,156)" instead of "B3(-lnr,lev)", and so on. I think this is not quite as intuitive when you're not familiar with the notation at all -- it doesn't really get more intuitive than "B1(n,w)" --, but I think this would be a good alternative if noone can come up with good one-letter mnemonics for the diagonal compass directions. Remembering that the directions are 1 to 8, in order, is pretty easy.
   
   One possible downside is that people might interpret the digit groups as numbers. OTOH that might not actually be downside, since there's probably value in mentally associating e.g. "nw,w,ne" with the number 123, and so on.

All in all I prefer the third option, using "v(änster)" and "h(öger)" from Swedish for the southern diagonal compass directions. Alternatively I could get behind the fourth option, using the digits 1-8 for the compass directions.

Thoughts?

EDIT: referring back to your example:

Code: Select all

x = 38, y = 11, rule = LifeHistory
3D3.D3.3D2.3D2.D.D2.3D2.3D2.3D$D.D3.D5.D4.D2.D.D2.D4.D6.D$D.D3.D3.3D
2.3D2.3D2.3D2.3D4.D$D.D3.D3.D6.D4.D4.D2.D.D4.D$3D3.D3.3D2.3D4.D2.3D2.
3D4.D4$2EB2.B2E2.2BE2.3B2.3B2.3B2.3B2.E2B$BCB2.BCB2.BCE2.BCE2.BCB2.BC
B2.ECB2.ECB$3B2.3B2.3B2.2BE2.B2E2.2EB2.E2B2.3B!

using the "Swedish style" notation, these would be, in order: B2(ln), B2(nr), B2(re), B2(eh), B2(hs), B2(sv), B2(vw) and B2(wl), all very intuitive, self-explanatory, and easy to both create and understand once you know about "v(änster)" and "h(öger)".

I'd also like to christen this notation "Swedish notation" (in line with e.g. Polish notation).

EDIT 2: here's a write-up on the wiki (in my Incubator).

[b-engine]

Next i'll probably try to make a script for defining custom MAP rules, which is my ultimate goal when i started creating these scripts.

I invented a notation for MAP rules, which is used in the following script for defining custom MAP rules:

Code: Select all

import base64
letter_to_number = {
    'z': 0,
    'u': 128,
    'd': 2,
    'l': 32,
    'r': 8,
    'h': 40,
    'v': 130,
    'w': 42,
    'c': 162,
    'q': 138,
    'n': 168,
    'f': 160,
    'g': 136,
    'i': 10,
    'j': 34,
    'a': 170,
    'Z': 0,
    'U': 256,
    'D': 1,
    'L': 4,
    'R': 64,
    'H': 68,
    'V': 257,
    'W': 69,
    'C': 261,
    'Q': 321,
    'N': 324,
    'F': 260,
    'G': 320,
    'I': 65,
    'J': 5,
    'A': 325}
    
def customap(rulestring):
    bits = bytearray(64)
    n = 0
    n_base = 0
    for char in rulestring:
        if char in ['b', 'B']:
            n = n_base = 0
            char_ = False
        elif char in ['/', ',']:
            if char_:
                bits[n // 8] |= (0x80 >> (n % 8))
                n = n_base
            char_ = False
        elif char in ['/', 's', 'S']:
            n = n_base = 16
        else:
            char_ = True
            n += letter_to_number[char]
    if char_:
        bits[n // 8] |= (0x80 >> (n % 8))
        n = n_base
    return "MAP" + base64.b64encode(bits).decode('ascii').strip("=")

if __name__ == "__main__":
    rstr = input('Type a rulestring: ')
    print(customap(rstr))
else:
    import golly
    rstr = golly.getstring("Type a rulestring, using the notation documented at conwaylife.com/wiki/User:iddi01/Anisotropic_rule_notation: ")
    golly.setrule(customap(rstr))
    try:
        f = open(golly.getdir('rules') + "mapstrings.txt", 'r+')
        f.read()
    except FileNotFoundError:
        f = open(golly.getdir('rules') + "mapstrings.txt", 'w')
    f.write(rstr + " = " + customap(rstr) + '\n')
    f.close()

Note: this script currently does not correct non-canonical rulestrings. Make sure you type the rulestring strictly in the format BxX,xX/SxX,xX or you might get a weird unintended rule.

Whenever you set a rule using the script, the rulestring you typed and the corresponding MAP string is saved in mapstrings.txt in Golly's rule folder. That way, you can reuse a rule without having to type the rulestring again.

Example of what it generates:
A rule which emulates W110 at the upper and lower edge of a pattern and is chaotic within it (BzR,uZ,uU,uR,G,zL,dZ,dL,dD,J/S):

Code: Select all

x = 1, y = 1, rule = MAPPgAAAAAAAACAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAA
o!

Also, any suggestions on improving the notation?

[hotdogPi]

Unfortunately, there isn't really a compressed way to do it, since base64 is already almost as compressed as you can get, and it's 86 characters. Staying with ASCII, using the 95 printable characters only brings this down from 86 to 78 characters, and all possibilities are used so it can't be compressed further.

[confocaloid]

Unfortunately, there isn't really a compressed way to do it, since base64 is already almost as compressed as you can get, and it's 86 characters. [...]

Yes it's likely to be a failure in the ultimate compression department.
However, for example Swedish notation seems like a win in readability - it's enough to remember eight letters for directions, and using digits for the number of alive neighbours provides a useful kind of redundancy.

Weighted-neighbourhood HROT is another example of a rulestring notation that can be very long, but the rulestrings are fairly readable.

[Haycat2009]

See my idea and solution in my incubator page - is it a good idea? User:Haycat2009/Incubator/Durnak notation
So for example, B3/S236i where S6i only works vertically would be B3/S236iu, Determination but photons only work vertically would be B2audbx3i/S12.

(Not Durnak-Cole notation)

[confocaloid]

[...] So for example, B3/S236i where S6i only works vertically would be B3/S236iu, Determination but photons only work vertically would be B2audbx3i/S12. [...]

The first overall impression is that there are too many letters to remember, and too many special cases to distinguish. Compare and contrast with always using just 8 letters, one letter for each possible direction.

Is it possible to make a compact table for that notation that fits on a single page, and can be used in a straightforward way to encode and decode rulestrings? How far can you compress the explanation of the rulestring notation, while still keeping it unambiguous and easily human-readable?

[Haycat2009]

[...] So for example, B3/S236i where S6i only works vertically would be B3/S236iu, Determination but photons only work vertically would be B2audbx3i/S12. [...]

The first overall impression is that there are too many letters to remember, and too many special cases to distinguish. Compare and contrast with always using just 8 letters, one letter for each possible direction.

Is it possible to make a compact table for that notation that fits on a single page, and can be used in a straightforward way to encode and decode rulestrings? How far can you compress the explanation of the rulestring notation, while still keeping it unambiguous and easily human-readable?

Hensel notation has the exact same issues and nobody complains.

[confocaloid]

Hensel notation has the exact same issues and nobody complains.

Hensel notation does have some of the same issues. Specifically there are 13 letters to be remembered, along with the definedness and meaning of each letter for each number of alive neighbours from 1 through 4. (5, 6, 7 don't have to be remembered because those follow from 3, 2, 1 respectively. 0 and 8 never have any letters.)

Your notation seems to add more letters on top of that. Thus it becomes harder to learn. That might be partially compensated, if the notation is supposed to be used mostly by people who already learned Hensel notation.
However, I think you still need to explain (probably by showing specific 3x3 arrangements) what you mean by "heavy part", what you mean by "pointing down/down and right", and so on.

What I'm trying to say is that the rulestrings might be relatively short, but a good human-readable explanation of how would one read and write such rulestrings would be fairly long, when you include further details that are necessary to avoid ambiguities.

[Haycat2009]

Hensel notation has the exact same issues and nobody complains.

Your notation seems to add more letters on top of that. Thus it becomes harder to learn. That might be partially compensated, if the notation is supposed to be used mostly by people who already learned Hensel notation.

Well, it is meant to be stacked with Hensel notation, much as Hensel notation is meant to be stacked with B/S notation. Thus this is a safe assumption to make.