As of June 5, 2016, there are 3 different 5x5x5 solving programs that I know of: one is a robot that solves a physical 5x5x5 cube, one is a java program, and mine is written in C running under Windows 10. I know this forum caters specifically to those interested in "numbers" associated with the various cubes, and I do have some nodes-per-depth data that might be of interest to the group. As for those who might wish to submit test scrambles or other queries to the 5x5x5 programs, my guess is that this is outside of the domain of interest here. So as to not "step on any toes," I have a separate discussion board set up so as to not distract anyone from here. If you'd like more info about that, you can email me at edwardtrice at mail dot com.

I think almost everyone here is familiar with the Corner Distance data that is used for pruning brute force searches for the 3x3x3 cube. This database features using one cubie as a "reference point" about which to orient the cube, and the relative disposition of the other corners is determined after hunting for that fixed frame of reference.

I decided to create a database that:

A. requires no single point of reference
B. contains all 24 possible rotated states of the cube's corner arrangements
C. measures the distance the corners are from the solved state with respect to the fixed centers

Hi folks,

My upstream has changed my ip address so now the numeric ip is 69.165.220.244. All the links should work as before once all the dns changes have propagated.

To improve security I've removed ftp access from the forum. We'll use http instead of ftp. I've also moved the Thistlethwaite files over so they can be accessed by http as well.

Even though it's only confirmation of some rather ancient results, I would like to report that I have succeeded in replicating Tom Rokicki's 2004 results concerning the edges only cube in the face turn metric reduced by symmetry.  My goal was not really to solve that particular problem.  Rather, it was to use that problem as a way to prototype some ideas I have had for improving my previous programs that enumerate cube space.

The base speed of my program is that I am now able to enumerate about 1,000,000 positions per second per processor core when not reducing the problem by symmetry, and I am now able to enumerate about 150,000 symmetry representatives per second per processor core when reducing the problem by symmetry.

Bruce Norskog designed a five stage procedure to solve 4x4x4 positions, where the last stage is solving inside the squares subgroup. When I rewrote the code in Java to be used for the official WCA scrambler program, I found a few improvements on coordinate representation and symmetry reduction that I think is worth sharing.

Except for the last stage where centers need to be solved, every other stage needs to place 8 centers from a single axis (RL, FB or UD centers) in their correct faces (RL, FB or UD faces), in one of the 12 positions that can then be solved using only half turns. However, as pointed by Shuang Chen in his analysis, we don't need to store the exact colours of centers but only if two centers have the same or different colours. This reduces the number of center coordinates by 2.

Also, as opposed to the 3x3x3, 4x4x4 does not have fixed centers, which allows us to do more symmetry reduction. I'm representing a sym-coordinate as:
s1 * g * < H > * s1' * s2'
where g * < H > is a coset, s1 and s2 are symmetries from subgroups S1 and S2 of the group M of symmetries of the cube. s1 is the usual conjugated symmetry, and s2 correspond to a rotation of the cube, which is possible on the 4x4x4. Using carefully chosen subgroups S1 and S2 for each stage, more symmetry reduction is achieved. I will be using the Schoenflies symbols for subgroups of M in the following.

There was a router problem last night, possibly due to memory corruption. I disconnected and reset everything on the router and DSL modem and now it's working again.

Sorry about the outage. Just letting everyone know that the forum is still alive :)

Mark

I have replicated Shaung Chen's upper bound result of 57 moves in the OBTM (outer block turn metric), reproducing his numbers and calculating depth counts without symmetry reduction. His results are here: http://cubezzz.dyndns.org/drupal/?q=node/view/525

I have also calculated, with the same code, results in two other metrics: SST (single slice turn) and BT (block turn). The final results lower the upper bounds in these metrics to 56 and 53 (respectively).

The sequence of subsets chosen is identical to that used by Chen. The maximum distance for each stage, the sum, and the current lower bound is shown here:

I developed a slide-puzzle called WrapSlide that reminds of Rubik's Cube. I am interested in determining God's number for WrapSlide. I think my initial approach is too naive and may be I should leave it to the experts.

First let me describe WrapSlide:

The main puzzle is a 6x6 grid of colored tiles which are separated into four quadrants of 3x3 tiles. When it is unmixed all the tiles in a quadrant have the same colour. A move consists of sliding either the top, bottom, left or right two quadrants of tiles 1 to 5 units horizontally or vertically. Stated differently, a move consists of sliding either the top, bottom, left of right half (consisting of 3 rows or 3 columns) relative to the other half, thus giving 4x5 possible moves to choose from. As with Rubik's cube the puzzle is to return it to its unmixed state after it is scrambled. (For the unmixed state we don't care which color goes into which quadrant)

Breadth First Enumeration
2014-09-27 19:58:23.094 VoidCubeClient[508:5903]  0             1             1
2014-09-27 19:58:23.095 VoidCubeClient[508:5903]  1             1            12
2014-09-27 19:58:23.099 VoidCubeClient[508:5903]  2             5           114
2014-09-27 19:58:23.101 VoidCubeClient[508:5903]  3            17         1,068
2014-09-27 19:58:23.105 VoidCubeClient[508:5903]  4           130         9,951
2014-09-27 19:58:23.133 VoidCubeClient[508:5903]  5         1,018        92,592
2014-09-27 19:58:23.333 VoidCubeClient[508:5903]  6         9,204       860,852
2014-09-27 19:58:25.033 VoidCubeClient[508:5903]  7        83,789     7,991,856
2014-09-27 19:58:40.300 VoidCubeClient[508:5903]  8       774,323    74,114,319
2014-09-27 20:01:03.984 VoidCubeClient[508:5903]  9     7,159,250   686,774,712
2014-09-27 20:25:47.908 VoidCubeClient[508:5903] 10    66,273,224 6,360,091,030


Coset Enumeration

Void Cube Model 1.0
	Group: R, U, F, TR, TU, TF
	Coset Base Subgroup: Subgroup with solved corner cubies and the
	   UF and UR cubies in the solved position regardless of orientation.
	484,989,120 cosets of size 7,431,782,400
	Coset Symmetry Reduction: Oh+

Cosets solved since launch: 3,429,943
Average time per coset: 0:00:00.068

Server Status:
Void Cube Enumerator Server

Enumeration to depth: 13

Snapshot: Friday, October 3, 2014 at 6:56:34 PM Central Daylight Time

 Depth             Reduced             Elements
   0                     1                    1 
   1                     2                   12 
   2                    18                  114 
   3                    50                1,068 
   4                   447                9,951 
   5                 2,008               92,592 
   6                19,000              860,852 
   7               124,184            7,991,856 
   8             1,136,806           74,114,319 
   9             9,028,936          686,774,712 
  10            82,411,850        6,360,091,030 
  11           711,657,402       58,868,124,048 
  12         6,507,640,604      544,562,369,684 
  13        58,275,341,089    5,033,855,951,932 
  
 Sum        65,587,362,397    5,644,416,382,171 

484,989,120 of 484,989,120 cosets solved

Elapsed Time: 0:12:14:50

This work was performed using the <R, U, F, TR, TU, TF> group model. This model was discussed in a previous thread. It must be pointed out here that the <R, U, F, TR, TU, TF> metric is exactly the same as the <R, U, F, L, D, B> metric since TR = L , TU = D and TF = B on the void cube. It makes no difference if the left face is rotated holding the rest of the cube rigid or if the left face is held rigid and the rest of the cube is rotated in the opposite direction, the rearrangement of the cubies is the same. If a distinct state of the void cube is at say depth 13 in the <R, U, F, TR, TU, TF> metric it will be at depth 13 in the <R, U, F, L, D, B> metric.