Discussions on the mathematics of the cube

Optimal solver for QTM

I have written an optimal solver console program for the quarter turn metric in C which compiles under Linux and Windows. The target subgroup for the pruning table is the permutations of <U,D,R2,F2,L2,B2> which have an even corner parity, lets call it H'. I experimented with another type of pruning table which does not store the distance to H' for each coset element but the moves which reduce the distance to H'. Because there are 12 possible moves in QTM, a 16bit word is enough for each coset element - a move reduces the distance to H' by one or increases it by one. The table fits in about 583 MB of RAM.

4x4x4 Supercube Squares Group

At last, I have completed my God's algorithm calculation for the 4x4x4 supercube squares group, in the single-slice half-turns only metric. It was found to have 47,968,768 antipodes, many more elements than are in the entire 3x3x3 supercube squares group. (OK, it's only 11,992,192 antipodes after reducing the group by four cube orientations.) The analysis showed that the elements in the group can always be solved using no more than 20 half-turns, only one more half-turn than the number required if the four centers for each face are considered indistinguishable. (The 4x4x4 supercube differs from the usual 4x4x4 cube in that all 24 centers are considered to be distinguishable from one another.)

Supercube Squares Group

Before I finish and report the results of a huge analysis that I'm working on, I thought it only fitting that I first perform this much smaller analysis, an analysis of the 3x3x3 supercube squares group (using half-turns only). Since this group has a mere 5,308,416 elements, it wouldn't be surprising to me if others have already done this analysis. However, I did not find any such analysis searching on the internet. I know that Mark had noted the size of this group in a message in the "Cube-lovers" archives: http://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Mark_Longridge__Super_Groups.html as well as a God's algorithm calculation of the ordinary 3x3x3 squares group (a group 8 times smaller). Or at least he discussed the antipodes of that group: http://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Mark_Longridge__SQUARE'S_GROUP_ANALYS IS.html

the new magic number is 26...

look at this new paper:


Algorithm for orientating flipped middle layer pieces

Does anyone know any algorithms for flipping incorrectly orientated middle layer edge pieces? I looked all over the internet but couldn't find any...

The 4x4x4 can be solved in 77 single-slice turns

Previously I announced that the 4x4x4 cube could be solved in 79 single-slice turns by solving it in five stages, in a manner similar to the Thistlethwaite 4-stage solution for the 3x3x3. (See The 4x4x4 can be solved in 79 moves (STM).) However, I have now realized my solution to the 2nd stage could have allowed the use of more basic turns than I used. I have realized that:
< U,u,D,d,L2,l2,R2,r2,F2,f,B2,b > = < U,u,D,d,L2,l,R2,r,F2,f,B2,b >
So with l and r replacing generators l2 and r2, you still can not reach any additional positions. As a result, I should have included the moves { l, l', r, r' } along with the other 24 allowed slice turns for that stage.

Rubik's cube can be solved in 34 quarter turns

I have proven that Rubik's cube can be solved in 34 quarter turns. The details can be found at:


UFR / UF Coset Space

Following up on an earlier thread I have explored the UFR/UF coset space. The number of UF cosets in the UFR group is given by:

(7 x 3) x (9 x 2) x (8 x 2) x 6 x 26 = 2,322,432

The first three factors are the number of ways the corner cubie position and the two edge cubie positions which are not on the UF faces may be configured. The factor of 6 is for the corner position permutation. Of the 720 corner position permutations on the UF faces achievable using the UFR face turns only 120 are achievable using the UF face turns. Thus the corner permutation may be one of six cosets. The flip of the seven UF edge cubies is constrained under the UF face turns, one cannot perform a double edge flip in this group. This gives rise to a factor of two to the sixth for the edge flip (flip parity determines the flip of the seventh edge cubie). As Bruce Norskrog pointed out in the earlier thread, the above number is the same as the order of the UFR group divided by the order of the UF group, so things check out.

Antisymmetry, Corners of the 3x3x3 Cube, quarter turn metric

Distance  Positions  Positions   Positions
 from                 reduced     reduced
 Start                  by           by
                      Symmetry    Symmetry

  0             1          1          1
  1            12          1          1
  2           114          5          5
  3           924         24         17
  4          6539        149         96
  5         39528        850        469
  6        199926       4257       2289
  7        806136      16937       8768
  8       2761740      57848      29603
  9       8656152     180787      91688
 10      22334112     466220     235710
 11      32420448     676786     342593
 12      18780864     392342     199610
 13       2166720      45600      23818
 14          6624        163        110

Total    88179840    1841970     934778

As I have written before, my programs have seldom worked with positions. They have nearly always worked with representative elements of M-conjugate classes. In the table above, the summary of representative elements is labeled "Positions Reduced by Symmetry". The goal of this approach is to obtain a 48 times speedup in processing time, and also to obtain a 48 times reduction in storage requirements.

Representation of edge permutations and move table

Stimulated by the last thread, where the representations of permutations and orientations was dealt I want to ask, what would be a good representation for the 12! edge permutations on the coordinate level, if the right multiplication of the edge permutation by any of the generators U,L.... should also be done with a MoveTable on the coordinate level like newcoordinate = MoveTable[oldcoodinate][generator].

This MoveTable would have 12!*18 4 Byte entries when we take the coordinate from 0..12!-1 and of course is far too big. Of course we could reduce this by 48 symmetries, but then we still would have a very large table.