In this paper we present a method of solving Rubik's cube in 36 quarter turns. The proof have many common facts with other methods presented on the forum. In able to prove our claim we have used the corner and edge permutation analysis done for the first time by Bruce Norskog.

We call the group of corner edge permutations of the cube for CEP and cube group for C. Let N be the normal subgroup that fixes cubies. Then we have a homomorphism hom:C->C/N=CEP such that hom(g)="permtutation of cubies done by g". Let a be the unique antipode in CEP. Every element in CEP can be written as x*a. Where x is an element requiring at most 18 quarter turns according to Norskog's analysis. There are 220 elements at distance 17 and 1 element at distance 18. So we could say that all elements of CEP except 220+1 elements can be written as x'*a where x' is an element requiring at most 16 quarter turns.

A permutation is generally defined as a bijection on a non-empty set.

Given a permutation on a set W, a partial permutation is a bijection from one subset W_X of W to another subset W_Y of W.  W_X and W_Y are the domain and range, respectively, of the partial permutation.  Because a partial permutation is a bijection, W_X and W_Y must contain the same number of elements (or must be of the same cardinality, if they are infinite).  Note that a partial permutation is defined only in the context of a specific and previously defined permutation.  Generally speaking, a partial permutation is not a permutation, and indeed a partial permutation is a permutation only if its domain and range are the same set.

In this paper we prove that Rubiks cube can be solved in at most 28 face turns. The proof uses exactly the same method as Michael Reid used in 1995. The only difference is that we show how to avoid the positions at distance 29. The proof was based on the fact that it takes 12 face turns max to take an arbitrary element of the Rubiks cube group into the group H=< U,D,L2,F2,B2,R2 >. And at most 18 face turns to take an element of H to the identity.

The above method can also be formulated in following way:

Given an arbitrary element g in the cube group we multiply it by an element B^-1 from the right such that gB^-1 is in the group H and the length of B^-1 is at most 12 face turns. Then we multiply gB^-1 by an element A^-1 from the right such that gB^-1A^-1=id --> g=AB. And the length of A is at most 18 face turns.

I have computed optimal solutions for following subgroups of the cube:

Group that fixes cubies


Distance        Nr of pos       Unique wrt M    Unique wrt M + inv

0q              1               1               1
2q              0               0               0			
4q              0               0               0
6q              0               0               0
8q              0               0               0
10q             0               0               0
12q             441             11              8
14q             3944            87              52
16q             32110           708             396

I reported this to the most visible Square One guy I could find on the web (Jaap Scherphius), and he sent me here. Yes, I have spent the last year or so computing God's Algorithm for Square One, in the center-flip-count domain, taking advantage of all top/bottom rotational degeneracies available. The table calculation itself is finished, but I am not finished analyzing it yet. I can report that the maximum number of flips required to get back to START is 13, with many shapes (not just square-square) contributing to that number.

The main stumbling block to reporting results at the moment is that I discovered a unexpected position-counting problem, where the shape degeneracy interferes with the 16-fold starting position degeneracy, and which requires me to do a recount on the tables. I will post the results back here in a few days when the recount is finished.

Silviu recently posted a result where he provides move sequences to solve all positions of the corners with an even corner permutation in 22 quarter turns or less without any net effect on the edges. This, combined with a result by Tomas Rokicki that the edges can be solved in 18 quarter turns or less, allowed Silviu to conclude that Rubik's cube can always be solved in 18+22 = 40 quarter turns or less. I have used a C++ program to verify Silviu's sequences do not exceed 22 quarter turns; and combined with applying "M-symmetry" and inverses to those sequences, correctly solve all even permutation and orientation possibilities for the corners with no net effect on the edges.

Looking at Rokicki's analysis further, one can see that there are relatively few positions in the edges-only case that require more than 16 quarter turns. For the cases of 16 or less quarter turns, the edges can be solved, and then the corners can be solved with Silviu's sequences, in no more than 38 quarter turns. Showing that the other cases in the edges-only analysis of more than 16 quarter turns can be solved in 38 quarter turns or less (including corners) would therefore mean that all positions of Rubik's cube can be solved in 38 quarter turns or less.

Recently it has been discovered that the cube restricted to edges can be solved in at most 18 quarter turns. This calculation can be
found at http://www.cubeman.org .This means that given an arbitrary cube in the whole cube group one can solve the edges in at most 18 quarter turns. Once the edges are solved there are 44089920 possibilities for the corners. We prove that each of this configurations can be solved in at most 22 quarter turns. A list of all this configurations expressed in the generators can be found at: http://www.efd.lth.se/~f01sr/ under the link "Data file" (txt document). This list contains only representatives up to M-symmetry+inverse.

Your sysadmin was rather adventurous last night. Both Apache and php were upgraded. One of more interesting things admins see is clever hacking attempts. Someone managed to get an executable into the /tmp directory of the server via wget. The program then proceeded to spawn copies of itself in memory. I'm pretty sure it was an attack on drupal so a drupal upgrade may be in the cards. How they managed to run wget on my machine without a login I don't understand. I'll be watching the processes on the server closely...

Let me know if anything is broken.