Right/Front Rubik's Group

One of the assignments I gave out this term was to "solve" the "RF" subgroup of the Rubik's cube, which is to say to describe an algorithm to get any position which could be reached by turning only the "right" and "front" sides. This turned out to be a lot harder than I expected - mostly because most of the possible permutations of the corners cannot be reached.

So here's my analysis.

There are 6 corners that move, which are in a pattern like this:

  C - C - C      1 - 2 - 3
  |   |   |      |   |   |
  C - C - C      4 - 5 - 6
and 7 edges, in a pattern like this:
    E   E           a   b
   / \ / \         / \ / \
  E   E   E       c   d   e
   \ / \ /         \ / \ /         
    E   E           f   g
As in the larger cube, the generators R and F cycle 4 edges and 4 corners, which is an odd permuation. Therefore, just as in the larger cube, starting from the "solved" configuration which has parity (even,even) for (corners,edges), after an odd number of R and F quarter turns we must be at an (odd,odd) parity, and after an even number of quarter turns we must be at an (even,even) parity.

Except for this constraint, the approach I use, like that of the larger cube, is to try to solve 4 things essentially independently, and to look for move sequence "operators" which will accomplish some without affecting the others. These four things to worry about are

 (1) the positions of the 7 edges,
 (2) the orientations of the 7 edges,
 (3) the positions of the 6 corners, and
 (4) the orientiations of the 6 corners.
The first thing to notice is that the (2) is trivial: the edges cannot be "twisted" in place. As they loop over and back on the two sides, the RF moves keep them in the same orientation. Thus (2) is done for us.

For the rest, the technique is to look at some commutators, and study what the cyclic permutations are when they're done over and over. Then one builds up more and more complicated "operators" from those building blocks.

The basic commutators I found are

 A =  R F  R' F'
 B =  R F' R' F
These are very similar: both disturb 3 edges, and 4 corners. It turns out then that doing them either 3 or 4 times does something interesting.
        Edges           Corners
      ------------    ---------------------------
 A3 :  unchanged      (12)(56) pairs swapped 
 B3 :  unchanged      (13)(25) pairs swapped 
 A4 :  (adg) cycle    (1)(2)(5)(6) twist in place
 B4 :  (adb) cycle    (1)(2)(5)(6) twist in place
The only other "building block" I need is
  C = R2 F2
which has the interesting property that
       Edges           Corners
    --------------    ------------------
 C3 :  (af)(bg) swap     unchanged
It follows from this last that by variations we can build up enough power to put the edges wherever we like, without disturbing the corners. A bit of building up commutators of C3 gives
 D = C3 F C3 F' : (af)(cd) swap
 E = C3 R C3 R' : (de)(bg) swap
 X = D E C = (cde) cycle
 Y = F D E C F' = (afe) cycle
 Z = R D E C R' = (cbg) cycle
These operators are enough to solve the edges without disturbing the corners at all - or at least that's what I've found in practice. I'm still unclear on a real proof of this, though, nor am I entirely confident that every edge permuation can be reached.

The reason for my uncertainty is that try as I might, I couldn't find _any_ 3-cycles of the corners! This came as a complete surprise, and to really convince myself this was right I did a brute-force computer search on the corner permutations. What I found is that of the 720 = 6! possibilities, only 120 = 5! are actually possible.

The full computer printout is here: RF_corners_out.txt. (And for you C programmers, the code is here and here).

Again, in practice I found that the various pair-swap operators were enough to solve the corners, particularly when combined with (D F), which swaps (15)(24). This "keeping the same face" pair swap, when combined with the A3-type pair swaps, can be used to "twist" the corners as need be.

That's as far as I've got on this - in practice I've found it much harder than I expected, and indeed much harder - and with longer operator sequences - than the full Rubik's cube itself.

Jim Mahoney
Last modified: Thu Mar 30 03:49:36 EST 2000