## Kilominx can be solved in 34 moves

Submitted by Ben Whitmore on Sun, 02/11/2018 - 12:58.The ⟨U,R,F⟩ subgroup, while much smaller than G_0, is still pretty large, having 36 billion states. It's small enough that a full breadth-first search can be done if symmetry+antisymmetry reduction is used, but I will leave this for another time.

## 5x5 sliding puzzle can be solved in 205 moves

Submitted by Ben Whitmore on Fri, 01/26/2018 - 17:46.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24We can solve the puzzle in three steps. First solve 1,2,3,4,5,6,7, then solve 8,9,10,11,12,16,17,21,22, and finally solve the 8 puzzle in the bottom right corner. Step 1 requires 91 moves:

depth new total 0 18 18 1 6 24 2 13 37 3 27 64 4 54 118 5 117 235 6 231 466 7 443 909

## God's algorithm for the <2R, U> subset of the 4x4 cube

Submitted by Ben Whitmore on Wed, 01/24/2018 - 22:00.Depth New Total 0 1 1 1 6 7 2 18 25 3 54 79 4 162 241 5 486 727 6 1457 2184 7 4360 6544

## Do we have a 3x3x3 optimal solver for stm metric?

Submitted by cubex on Thu, 08/10/2017 - 06:46.Also is it true we don't know if using slice turns plus face turns could reduce God's Number from 20 to less than 20?

## More details about my new program

Submitted by Jerry Bryan on Thu, 06/08/2017 - 14:55.
**Introduction**

On 02/23/2016, I posted a message about a new program I had developed that had succeeded in enumerating the complete search space for the edges only group. It was not a new result because Tom Rokicki had solved the same problem back in 2004, but it was important to me because the problem served as a testbed for some new ideas I was developing to attack the problem of the full cube. I am now in the process of adapting the new program to include both edges and corners. In this message, I will include some additional detail about my new program that was not included in the first message.

## Pattern databases for the 5x5 sliding puzzle

Submitted by stannic on Sun, 04/02/2017 - 11:37.In 2002, Korf and Felner [1] used pattern databases to solve optimally 50 random instances of the 5x5 sliding puzzle. They used a static

## A cubic graph with cubic diameter

Submitted by stannic on Mon, 03/06/2017 - 03:53.The Fifteen puzzle is sometimes generalized to a sliding puzzle on an arbitrary simple connected graph *G* with *n* vertices in the following way. *n* − 1*n* − 1)*G*. At most one piece is placed on each vertex. One vertex of *G* is left unoccupied. A move consists in choosing a vertex *v* adjacent to the currently unoccupied vertex *v*_{0} and 'sliding' the piece at *v* along the edge (*v*; *v*_{0}). The aim is to restore the order so that piece numbered *i* occupies vertex numbered *i*, for *i* = 1 .. *n* − 1*G* is the

## Is there a way to evenly distribute face turns for 12 flip?

Submitted by cubex on Mon, 11/14/2016 - 22:10.R3 U2 B1 L3 F1 U3 B1 D1 F1 U1 D3 L1 D2 F3 R1 B3 D1 F3 U3 B3 U1 D3 24q

This process has 24 q turns, so I'm wondering could there be a 24 q turn process that evenly distributes the turns so that each side turns 4 q? The idea just seemed elegant to me, 6 faces each turning 4 q turns.

Mark

## Super Group Cosets of the Centers Subgroup

Submitted by B MacKenzie on Mon, 06/20/2016 - 06:52.Continuing my work with the 3x3x3 super group, I have written a coset solver for cosets of the pure center cubie subgroup. This subgroup is made up of the 2048 even parity center cubie configurations composed with the identity edge and corner configurations. The super group may be partitioned into cosets of the pure centers subgroup, g * [CTR] , where g is an element of the super group and [CTR] is the centers subgroup. The centers subgroup is a normal subgroup of the super group, g * [CTR] = [CTR] * g, and the standard cube group is the quotient group of the super group and the centers subgroup.

## Finally hitting depth 13 consistently with my 5x5x5 solver

Submitted by NoLongerUnsolve... on Fri, 06/17/2016 - 18:52.It finally occurred to me why my hash table was sometimes not finding the shortest solutions 100% of the time. When I upgraded my computer to one with 128 GB of RAM, I had enough to load more positions into RAM. The number of hash table entries exceeded 4.2 billion, which is more than 32 bits. I never adjusted all of my access code to use 64-bit indices which were now necessary. All I had to do was change the data type, and, lo and behold, it found a 13-move solution to this arrangement, which previously it was reporting required 14 moves!

A very happy day for me.