Cycle Structures

Now that we understand orientation, we can notate cube states in terms of permutation and orientation of pieces rather than just permutation of stickers. This will make the way in which the Qter Architecture Solver works easier to think about. Lets see how we can represent the algorithm.

Next, lets trace where the pieces go. Instead of using numbers to represent the pieces in the cycle notation, we can simply use their names.

Note that I’m writing down the one-cycle of the UFR corner because we will see that it twists in place. If you would like, you can manually verify the tracing of the pieces. Next, we need to examine changes of orientation.

I’m going to notate orientation by writing the amount of orientation that a piece acquires above it.

The process of translating a cube state into cycles of pieces including orientation is known as blind tracing because when blind solvers memorize a puzzle, they memorize this representation. Using this representation, we can actually calculate the order of the algorithm. In the intro, we claimed that the algorithm repeats after performing it times, but now we can prove it.

First, we have to consider how many iterations it takes for each cycle to return to solved. To find this, we have to consider both the length of the cycle and the overall orientation accrued by each piece over the length of the cycle. Lets consider the first cycle first. It has length one, meaning the piece stays in its solved location, however the piece returns with some orientation added, so it takes three iterations overall for that piece to return to solved.

Next, let’s consider the cycle of edges. They have a cycle of seven and don’t accrue orientation at all, so it simply takes 7 iterations for the edges to return to solved.

Finally, let’s consider the cycle of corners. It has length 5, so all pieces return to their solved locations after 5 iterations, but you can see that they accrue some amount of orientation.

How can we calculate how much orientation? Since each piece will move through each location in the cycle, it will move through each addition of orientation, meaning that all pieces will accrue the same orientation, and that orientation will be the sum of all orientation changes, looping around after three. The cycle has three orientation changes, , , and , and summing them gives which loops around to . You can see in the above example that all corners in the cycle have orientation.

It will take three traversals through the cycle for the orientation of the pieces to return to zero, so the cycle resolves itself after 15 iterations.

Now, the entire cycle resolves itself once all individual cycles resolve themselves. To calculate when, we can simply take the LCM:

This also clarifies what pieces we have to select as parameters for “solved-goto”. We need a representative piece from every cycle that isn’t redundant. We don’t need to care about the 3 cycle because it is always solved whenever the 15 cycle is. We can pick any representatives from the 7 and 15 cycles, for example FDR and FR. Using those, the QAT program

.registers {
  A ← 3x3 (R U)
}
label:
solved-goto A label

.registers {
  A ← 3x3 (R U)
}
label:
solved-goto A label

…compiles to the Q program

Puzzles
A: 3x3
1 | solved-goto FDR FR 1

Puzzles
A: 3x3
1 | solved-goto FDR FR 1