Discussions on the mathematics of the cube

even and odd cube positions

After calculating 14f* and 15f* being at bit out of range, I started calculations in the quarter turn metric and just for the heck of it I switched to edge cube positions as cosets. I am in the process of verifying 15q*, which will take about 24 hours on a total of 120 cores. In the process I noticed something strange in my output. For coset 0 I get:
0 11 1 0 0
0 12 1 121477 121477
0 13 1 0 0
0 14 1 2981152 2981152
0 15 1 0 0
so I only have positions for coset 0 at even depths (12 and 14) and none at odd depths (11, 13 and 15). I get the same for coset 1:
1 11 12 4284 51408

God's Algorithm out to 14f*

Here are the results for postions at exactly that distance:

 d   mod M + inv          mod M       positions
-- -------------- --------------- ----------------
 9      183339529       366611212      17596479795
10     2419418798      4838564147     232248063316
11    31909900767     63818720716    3063288809012
12   420569653153    841134600018   40374425656248
13  5538068321152  11076115427897  531653418284628
14 72805484795034 145610854487909 6989320578825358
I had the good fortune to run a few test calculations on a brand new Cray XT6m with over 4000 Opteron cores. As I have done in the past I tried my own program for rubiks cube calculation. Results looked promising and after some optimisations I was able to complete the calculation out to 14 moves in the full turn metric in a about nine days. If I had been able to use the entire machine alone it should have taken a bit over a day.

3-face subgroup of the 3x3x3 cube

Somewhat surprisingly I was unable to find any tables for the number of positions of various lengths in ascending order for this order 170659735142400 group w.r.t. three mutually orthogonal face generators such as U,F and R, i.e. This is seemingly beyond the reach of conventional software tools to solve, so I am appealing to the seemingly large number of contributors who have developed their own bespoke utilities. I'd be grateful if a table could be posted here. In particular is the diameter of the Cayley graph for this known?

free rubiks cubes

to get free cubes and more click on this banner
Cube Lagoon

All the Syllables, Corners Group, Quarter Turn Metric

My recent posting on |EndsWith| values for the corners of the 3x3x3 in the quarter turn metric was really secondary to another project I was working on.  Namely, I was working on determining all the syllables for the corners of the 3x3x3 in the quarter turn metric.  I discovered many more syllables than I was expecting.  As a part of determining why there were so many syllables, I discovered that the |EndsWith| values were much higher than I was expecting.  To a certain extent, one can think of the higher |EndsWith| values as being the "cause" of there being a larger number of syllables than expected.

EndsWith Values, Corners Group, Quarter Turn Metric

My calculations of God's algorithm have generally included an analysis of the distribution of EndsWith values.  My best God's algorithm results for the quarter turn metric are out to 13q. Tom Rokicki has since calculated out to 15q.  Out to 13q, it is the case that for the vast majority of positions x we have |EndsWith(x)| = 1.  Tom may be able to speak to the 14q and 15q cases, but I cannot.

Given the predominance of |EndsWith(x)| = 1 out to 13q, I have assumed that for the vast majority all of cube space it's probably the case that |EndsWith(x)| = 1.  I no longer believe that assumption is correct.  Which is to say, I now have an EndsWith distribution for the entirety of the corners group in the quarter turn metric.  Beyond a certain distance from Start in the corners group, there are no instances of |EndsWith(x)| = 1 whatsoever, and overall the |EndsWith(x)| = 1 cases are very much in the minority.  It now seems to me that the same is probably true for the complete cube group including corners and edges.  I suspect the reason we have not seen this effect for the complete cube group is simply that we have not yet been able to calculate out far enough from Start.

algorithm for generating permutations for the rubik cube

hi,

let's say I want to distribute permutation checking over say 10 computers.
so if there are a total of n permutations the first machine will check n/10.
the second will check from n/10 to 2n/10
third will check from 2n/10 to 3n/10.
and so forth.
the algorithm that generates permtuations needs to generate the ith permutation in O(1)
so that I can efficiently start each machine's work.
what algos for generating permtuations do you know that can do this ?

thanks

Second largest coset solved yet of actual Rubik's positions

After solving the trivial coset [All positions that have the same orientation as the START position] published here Largest coset solved yet of actual Rubik's positions
I went ahead and calculated the full distribution of the flipped coset [All positions that have the same orientation as Reid's position (The only known 26q*)].

Enjoy:
Depth         Trivial coset           Flipped coset
0                         1                       0
1                         4                       0
2                        10                       0

basic algorithms and schreier sims ?

hi, where can I find a comprehensive exposition with explanations and examples, the kind of stuff that you can really learn from ?
I'm trying to implement this for solving the cube, it's a hobby project of mine.

I've noticed that another approach(if I use some basic algos like http://www.ryanheise.com/cube/beginner.html ) would be to pattern match the cube and "hardcode" all the cases of ryan heise and this would also yield a solution.

I'm a begginer with the cube, I almost solved it in reality and would like to write code to solve it.

(I have already set up an opengl simulation and

UF and RBL generate the whole cube group

The two simple generators UF and RBL (without any rotations) generate the whole cube group.

It's surprising to me that these two very simple generators suffice.

It's easy to see no shorter set of generators (expressed in face turns) suffice because you need at least five faces.