# Acquiring a Letter System: part 1, Specifying



## leeo (Sep 7, 2015)

I programmed a parser for standard 3x3 moves that models the moves and returns the letter list that a BLD solver would read. I discovered that Speffz is a more common letter scheme than the counter-clockwise major system I acquired. Thus I needed to expand the program to accompany other letter systems. Now, the problem: how do I efficiently specify a letter system?

Here is what I came up with; this specifies Speffz:

```
ULB=AER UBR=BQN URF=CMJ UFL=DIF
        LFD=GLU LDB=HXS FRD=KPV RBD=OTW
        
        UB=AQ UR=BM UF=CI UL=DE LF=FL LD=GX
        LB=HR FR=JP FD=KU RB=NT RD=OV BD=SW
```
Each word specifies all the corners or edges on one sub-cubie. On the left before the "=" is the Singmaster name. 0n the right after the "=" the assigned letter matching the components of the Singmaster name. For instance, "ULB=AER" specifies all of the names for the stickers on the ULB corner cubie. ULB is "A"; "LBU" is "E"; "BUL" is "R". The other 45 names can be identified similarly.


----------



## bobthegiraffemonkey (Sep 7, 2015)

Aside from some dubious edge labels (typos presumably), that looks fine. I don't know Speffz so I can't check the example thoroughly, but the idea is clear enough anyway.


----------



## leeo (Sep 11, 2015)

We have not quite specified the letter system yet. The competitor uncovers the scrambled puzzle that must be in a random orientation and first needs to orient it into one of the 24 possible positions for reading. Since the poll does not have 24 options, I just selected the orientation for the white (or lightest) face.

A competitor with the same lettering system but different reading orientation would read an entirely different sequence of letters for the same scramble, since a lettering system is positional. Now, how to I unambiguously specify a reading orientation different from the scramble orientation?

How about: "@UF=XZ" stating that the entire cube is to be rotated (without applying moves) until the XZ edge is placed to the UF position. For example: "@UF=BD", for western-colored cubes scrambled according to WCF rules, the result would have blue up yellow front. Since WCF rules specify the scrambling colors for the U and F faces, the specification begins "@UF=". Some other examples: "@UF=FU" green up white front -- "@UF=UF" white up green front (read in scrambling orientation) -- "@UF=FL" green up orange front.

I came back to track whole-cube rotations off of the reading orientation similarly. As the whole-cube orientation changes from the reading orientation from slice or double-center moves, I just identify the edge that would be located at UF relative position from reading the center colors of the U and F faces. For instance, an M move changes the whole-cube orientation from the C_ reading position (unmodified) to the Q_ reading position (the UF relative edge position gets the BU absolute edge position cubie.)


----------

