Having repeatedly shot myself in the foot by mishandling the symmetry reduction of coset spaces, I finally sat down, laid out the math and put together a set of notes on the matter. These notes follow.

Coset Spaces

Solving Rubik's cube either manually or by computer usually involves dealing with coset spaces. A group may be partitioned into cosets of a subgroup of the group:

     g * SUB          where g is an element of the parent group and 
	              SUB is a subgroup of the parent group

I recently bought a new computer and wanted to put it through its paces. I dusted off my RUF three face coset solver and spruced it up a bit. Since I now have three iMacs in my household connected on an airport network, I rewrote the program using a server–client model. With this I can have all three computers working on a problem in parallel with as many as 14 cores. With these tools I have extended the enumeration of the three face group out to twenty q–turns:

Three Face Enumerator Client

Fixed cubies in subgroup: UF, UR, UB, UL, DF, DR, FR, FL, BR.
92,897,280 cosets of size 1,837,080

Server Status:
Three Face Group Enumerator
Sequential coset iteration
Enumeration to depth: 20

Snapshot: Friday, February 22, 2013 9:28:02 PM Central Standard Time

 Depth             Reduced             Elements
   0                     1                    1 
   1                     1                    6 
   2                     4                   27 
   3                    12                  120 
   4                    51                  534 
   5                   213                2,376 
   6                   914               10,560 
   7                 4,038               46,920 
   8                17,639              208,296 
   9                78,234              923,586 
  10               344,175            4,091,739 
  11             1,524,115           18,115,506 
  12             6,722,358           80,156,049 
  13            29,739,437          354,422,371 
  14           131,158,304        1,565,753,405 
  15           578,971,538        6,908,670,589 
  16         2,546,820,524       30,422,422,304 
  17        11,174,670,698      133,437,351,006 
  18        48,528,827,222      579,929,251,620 
  19       205,901,170,504    2,459,821,160,421 
  20       814,027,054,726    9,731,195,124,049 

 Sum     1,082,927,104,708   12,943,737,711,485 

92,897,280 of 92,897,280 cosets solved

I have written a GUI NxNxN cube program to which I just added a 2x2x2 cube auto solve function. To test the performance of the solution algorithm I wanted try it on the 14 q-turn antipodes. So I did the depth-wise expansion of the group, found the 276 antipodes and reduced them with M^† symmetry. In the context of the fixed DBL cubie 2x2x2 model, that is the <R U F> group model, M^† symmetry classes are formed by ( c * m' * q * m ) where q is a group element, m ranges over the cubic symmetry group and c is the whole cube rotation needed to place the conjugate back in the group.

How many 26q* maneuvers are there?

Well, obviously we can't say for sure, as it hasn't yet been proved that the 3 known 26q* positions (which are symmetrically equivalent to each other) are the only 26q* positions. In another thread, Herbert Kociemba mentioned that there are "many" such maneuvers, but he did not attempt to generate them all (for the known 26q* positions).

I note that 26q* refers to a maneuver that is 26 quarter turns long and that is known to be optimal in the quarter turn metric. It may also refer to a position that requires a minimum of 26 quarter turns to solve. 26q (without the asterisk) refers to any maneuver 26 quarter turns long, but isn't necessarily optimal for the position it solves.

The multi-chained approach used in kumi na tano allows to use multiple search chains at the same time. The main advantage is that the best chain can be choosen depending on the instance to be solved, rather than hard-coded into the search algorithm.

For example, the first of the following two 5x5 instances has its leftmost column solved, while second has solved four tiles in top-right corner.

[1]
  1 17  9 10 18    18  3 16  4  5
  6  0  2  3  8    11  7 17  9 10
 11  5 22  7  4    19  2 23  0 21
 16 15 20 23 13     6 20 14 12  1
 21 19 12 14 24    13  8 15 22 24

We cah use multi-chained approach here. The following two partitioning schemes:

I have solved sub-optimally 1,000,000 random instances of 5x5 sliding tile puzzle in STM metric (single-tile moves). The actual running time was about 18,5 hours. The minimum, maximum and average solution length were 73, 171 and 124.48 moves respectively. About 52% of 1,000,000 solutions were in range [118; 132]. There were only 32 instances with (suboptimal) solution length less than 81 (range [73; 80]). Only one instance was solved in 171 moves.