## Prime numbers and Rubik cube

Submitted by mdlazreg on Fri, 03/07/2008 - 20:32.For example in the following list:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

only 2, 5, 7, 11, 13, 17 and 19 are prime numbers.

Now if we look at the Rubik cube's positions, we can also count them, something like:

U D F B L R U' D' F' B' L' R' UU UD UF UB UL UR UU' UD' UF' UB' UL' UR'....

Similar to the prime number concept we can come up with the prime cube position concept. So in the above list UU' is not a prime position.

In prime numbers theory, the following theorem has been proved:

P(x)~x/ln(x) where P(x) is the prime numbers counting function.

## 2 questions

Submitted by mdlazreg on Thu, 02/21/2008 - 02:02.I am asking for help to understand the second phase of the 2-phases algorithm. I do understand the first phase.

My question is once we bring the scrambled cube to a position in the G1 =

__subgroup, how is this position taken to the Identity?__

Kociemba says the following in his website:

In phase 2 the algorithm restores the cube in the subgroup G1, using only moves of this subgroup. It restores the permutation of the 8 corners, the permutation of the 8 edges of the U-face and D-face and the permutation of the 4 UD-slice edges. The heuristic function h2(a,b,c) only estimates the number of moves that are necessary to reach the goal state, because there are too many different elements in G1.

Kociemba says the following in his website:

In phase 2 the algorithm restores the cube in the subgroup G1, using only moves of this subgroup. It restores the permutation of the 8 corners, the permutation of the 8 edges of the U-face and D-face and the permutation of the 4 UD-slice edges. The heuristic function h2(a,b,c) only estimates the number of moves that are necessary to reach the goal state, because there are too many different elements in G1.

## Some "F2L" computer analyses

Submitted by Bruce Norskog on Tue, 02/19/2008 - 22:18.I have done some "restricted" God's algorithm calculations for solving two layers of Rubik's Cube, given that the four edges of the face layer are already solved. I say it's a "restricted" calculation because it only considers certain moves or sequences of moves. For convenience, I will consider the two layers to be solved are the bottom layer (generally referred to as the D layer), and the layer above that (typically referred to by speedcubers as the E layer).

Given that four edges of the D layer are taken to be solved,
the remaining four edges being considered (those that belong in the E layer)
must be distributed among 8 possible edge locations.
So the number of configurations for those four edges is
8*7*6*5*(2^{4}) = 26880 (including orientations).
The four corner cubies being considered (those that belong in the D layer)
have 8*7*6*5*(3^{4}) = 136080 configurations (including orientations).
This makes for a total of 26880*136080 = 3,657,830,400 configurations.

## Efficient test for equivalence of bandaged 4x4x4s ?

Submitted by Andreas Nortmann on Sun, 01/27/2008 - 09:40.I tried to write a program to generate all valuable bandagings of a 4x4x4. Here valuable means:

1. No single gluing can be added without restricting at least one turn which was possible before.

2. From every set of equivalent bandagings, which are transformable into each other by turning and/or generating symmetries, at most one is in the final list.

3. No bandagings which could be realized by a 2x2x2 or a 3x3x3.

Only the 108 bondings between the surface cubies are considered.

## New hex-axes search 2x faster than triple-axes search

Submitted by rokicki on Tue, 01/22/2008 - 16:00.This option searches along three axes at once, instead of just one.

How much does Triple Search help? For random cubes, when searching for a length

20 solution, it helps tremendously. I implemented my own Kociemba solver with

single-axis search, triple-axis search, and a new "six-axis" search, and compared

the amount of time needed to find length 20 or better solutions for 3,000 random

cubes. This program was single-threaded (Kociemba's cube explorer is multi-threaded),

runs only from the command line, and is brand new code (so it has not been heavily

## Pattern Sub-Groups

Submitted by B MacKenzie on Sat, 01/12/2008 - 22:10.I've been fooling around with symmetric Rubik cube patterns: "Cross" patterns, involving corners only; "Check" patterns, involving edges only; and "Dots" patterns, involving edges and corners.

By rotating the eight corners a quarter turn about one of the cube axes a cube state with a cross on four faces is produced. A second such state may be produced by rotating about a different cube axes:

R U B R U R D R U' D B' U' B' D' B' R' D' B' R B D R B R F R B' F D' B' D' F' D' R' F' D'

By recursively forming binary products from these two generators a group of 24 cube states is produced composed of all the different pure cross patterns plus the identity element. This Cross group is composed of five conjugate classes:

## Hexadecimal Sudo-Kube puzzle

Submitted by crepeau on Sat, 01/12/2008 - 01:27.I have constructed the following puzzle based on a 4x4x4 Eastsheen cube. It is labelled with hexadecimal digits 0,1,2,...,9,A,B,C,D,E,F on each face of each cubbie (I have turned the labels at an angle of 45 degrees to avoid having positional information due to label orientations). The goal of the puzzle is to have each label eaxctly once per face and once per row (in all 3 dimensions). This is the only constraint that must be satisfied. It seems possible that a single puzzle has more than one valid solved configuration, but I have not fund more than one so far. I wrote a computer program which generates the instance to be solved "randomly" and outputs the labelling of a scrambled puzzle. This last step is necessary to avoid knowing the solved configuration which would reduce the puzzle to returning each cubbie to its correct place... The puzzle is really difficult because the solved configuration is not known !!!

## Hexadecimal Sudo-Kube puzzle

Submitted by crepeau on Wed, 01/09/2008 - 13:18.I have constructed the following puzzle based on a 4x4x4 Eastsheen cube. It is labelled with hexadecimal digits 0,1,2,...,9,A,B,C,D,E,F on each face of each cubbie (I have turned the labels at an angle of 45 degrees to avoid having positional information due to label orientations). The goal of the puzzle is to have each label eaxctly once per face and once per row (in all 3 dimensions). This is the only constraint that must be satisfied. It seems possible that a single puzzle has more than one valid solved configuration, but I have not fund more than one so far. I wrote a computer program which generates the instance to be solved "randomly" and outputs the labelling of a scrambled puzzle. This last step is necessary to avoid knowing the solved configuration which would reduce the puzzle to returning each cubbie to its correct place... The puzzle is really difficult because the solved configuration is not known !!!

## Using GAP to produce solutions to Pentultimate

Submitted by DougCube on Tue, 12/11/2007 - 16:14.You can play with this puzzle here (it doesn't physically exist yet):

http://users.skynet.be/gelatinbrain/Applets/Magic%20Polyhedra/dodeca_f6.htm

## Independent proof of 26-move upper bound for half-turn metric

Submitted by rokicki on Thu, 12/06/2007 - 13:34.run on my personal machines on a bunch of the H cosets, starting with

the most symmetrical ones and moving down to the less symmetrical ones.

My H-coset solver uses the Kociemba two-phase algorithm, but for all

19B elements of an H-coset in parallel, rather than for a single cube

position. (It's just the Kociemba two-phase algorithm augmented with

a 19B-element bit table, roughly.)

As of today, I have completed 4,748 such cosets, using a depth of at

least 16 for phase 1 and proving that each element of most of these