Discussions on the mathematics of the cube

Drupal database problem

Folks, I'm in the middle of fighting with the drupal database. While trying to add the ability to contact the admin I managed to mess up the database in some way. As a result I'm reverting the database back to 5 am this morning and anything added after that won't show up.

I'm going to add in the ability for anonymous users to read all the posts and comments but they won't be able to post. A new drupal is in the cards but the problem is transferring all the info from the old drupal to the new is rather difficult.

I'm going to try to add in the lost posts later tonight. Sorry for the trouble everyone, but I'm still learning the idiosyncrasies of drupal. Turning on the menu module was the cause of the trouble and I won't be touching that particular part again :-/

Thirty-One QTM Moves Suffice

As of last Tuesday, with 1200 QTM cosets solved, all at a distance of 25 except two at 24, I've been able to show that 31 moves suffices in the QTM to solve every cube position.

Surprised by the dearth of 26s (none found out of more than 20 trillion positions solved), I decided to take a cue from Radu (and others) and explore the symmetrical positions. In the past few days I've run about 500 cosets with 16-way, 8-way, and 4-way symmetry and have not found any distance-26 positions other than the one that is known.

This is in contrast to the face turn metric, where distance-20 positions pop up much more frequently.

100,000 cubes optimally solved

Using my brandnew Core i7 920 CPU machine (Vista 64 bit with 6 GB of RAM) I solved 100,000 random cubes optimally with a rate of about 4-5 cubes / minute. So the computation took less than two weeks. I got the following results:
14f*:     18
15f*:    197
16f*:   2710
17f*:  26673
18f*:  67099
19f*:   3303
No 20f* cube was encountered. According to Toms results this indeed would be very unlikely and for 100000 cubes the probability should be less than 10-6. The 95% confidence interval for the probability of 18f* is about 0.671 ±0.003, for 17f* 0.267 ±0.003 for 19f* 0.033 ±0.001 and for 16f* 0.027 ±0.001.

Tripod Finish - optimal FTM analysis

I have used Cube Explorer to solve all "tripod finish" cube configurations. All positions were solved in no more than 15 face turns. I calculated an average distance of about 12.746 face turns per position.

A "tripod finish" configuration has all cubies solved except four corners and three edges that make a configuration resembling a tripod. For example, corners URF, UFL, UBR, and DFR along with edges UF, UR, and FR make up one representative tripod configuration. For the above tripod configuration (or any equivalent one), there are a total of 7776 possible legal arrangements of the cubies. These 7776 arrangements can be reduced by symmetry to 1317 cases.

Thirty-Two QTM Moves Suffice

I have modified my coset solver to work in the quarter turn metric, and
with 396 cosets solved, I can announce that every cube position can be
solved in 32 or fewer quarter turns.

I am running phase one to a depth of 19 and letting phase two complete
the coset; each run takes about 12 minutes and approximately 63% of
the runs yield an upper bound of 25; the other 37% yield an upper
bound of 26.

No coset I have run yet has required more than 26 moves to solve, and
the possible distance-26 positions that I have run through an optimal
solver have all yielded distances less than 26, so I do not have a

A Possible Approach to Generalize Dan Hoey's Syllables

The thread on this forum entitled "Non Trivial Identities" has had the most responses of any thread to date (39 responses so far).  The thread contains a great deal of useful information, including a detailed analysis of non-trivial identities of length 12q.  The thread may be found at http://cubezzz.homelinux.org/drupal/?q=node/view/114 (you have to login to see all the responses).

I tend to view the problem of analyzing identities more in terms of duplicate positions than in terms of identities, but you can of course easily transition from one view of the problem to the other.  In any case, the problem of finding a formula for the number of moves at each distance from Start is closely tied to the problem of finding duplicate positions and/or non-trivial identities.

There are approximately 700,000,000 distance-20 positions.

Inspired by Jerry Bryan's recent Cubelovers article, I decided to run a few large randomly-selected cosets such that optimal solutions were found for *all* positions (rather than just proving all positions were within 20, as I usually do). From this, I hoped to gain some insight into how long it would take to enumerate the entire cube space and find counts for every distance. I also hoped to get an estimate for the total count of 20s in the entire cube space.

I first wrote a program to select a random coset, and then set those cosets to running, specifying a maximum search ply of 18. This way

Some observations on the Rubik's Cube Group, its sub-groups and solution algorithms.

Some observations on the Rubik's Cube Group, its sub-groups and solution algorithms.

When approaching the problem of auto-solving Rubik's cube in my Virtual Rubik program I chose to proceed in a three step process by first solving a 2 x 2 x 2 block using turns of all six faces. Then using turns of the three faces not intersecting the solved block, the block is extended to a 3 x 2 x 2 block, leaving two faces unsolved. And finally the last two faces are solved using just turns of those two faces.

Enumerating all of 3x3x3 cube space - required performance characteristics

I've been playing around with what it would take to enumerate the entire cube space for the standard 3x3x3 cube, using a large number of computers working together.  I've come up with what I think is a reasonable approach, a bit past the bare edge of what might be possible with today's technology, but perhaps not too far past.  The assumption will be that we want to solve the problem in one year, with all the machines involved in the project fully dedicated to the problem for the whole year.

The following is not a compete description of my proposed approach, but rather is an analysis of the performance characteristics that would be required.  There is not much advantage in coming up with an approach that would require billions of years to compute.

First Post, General Puzzle Solving


A quick introduction: I'm Robert Smith, I'm 18, and I live in the US. I used to be quite into speedcubing, starting around 2003, but I have since moved into the more "theoretical" aspects of the cube. I also like mathematics, and, fortunately, programming. Anyway, that's that.

I have been writing a "general puzzle solver," whose goal is to be able to solve any (permutation) puzzle with (almost) any method. Quite quickly, we see there are definitely limits to this (e.g., we couldn't solve any scrambled 10x10x10 cube in a single phase). But, if some certain requirements are met, solving any puzzle should be an ability with this program.