Discussions on the mathematics of the cube

Hexadecimal Sudo-Kube puzzle



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

I recently got started using GAP, and wrote a C++ program that generates legal scrambles in cyclic-notation for GAP, and some GAP code that gives solutions to them using the "PreimageRepresentative" function. On short scrmables, it can produce the reverse turns to solve it (likely optimal). But for a random scramble of say 500 turns it produces solutions over 14000 turns (in the analog of QTM or 'word-length' in the freegroup). This is not satisfactory to me because I can solve it by hand using less than 1000 turns doing centers-first.



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

Starting over Thanksgiving break, I decided to let my H-coset solver
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

Symmetry of Cayley Graphs of Subgroups of the Cube Group G

Normally, we think of Rubik's cube symmetry in terms of a particular position x.  The symmetry of x can be defined as Symm(x), where Symm(x) is the set all symmetries m in M such that xm=x, and where M is the group of 48 symmetries of the cube.  By the closure property, Symm(x) is a subgroup of M, and there are 98 possible such subgroups.  I wish to expand this definition of symmetry to encompass an entire subgroup of the Cube group G.

The primary motivation for the expanded definition is to provide a standard mechanism to deal with the symmetry of subgroups of the Cube group G such as H=<U,R>.  I'm probably going to make things more complicated than they need to be.  However, I don't recall seeing a general discussion of group symmetries before, neither on Cube-Lovers nor on this forum.

Optimal solver for QTM

I have written an optimal solver console program for the quarter turn metric in C which compiles under Linux and Windows. The target subgroup for the pruning table is the permutations of <U,D,R2,F2,L2,B2> which have an even corner parity, lets call it H'. I experimented with another type of pruning table which does not store the distance to H' for each coset element but the moves which reduce the distance to H'. Because there are 12 possible moves in QTM, a 16bit word is enough for each coset element - a move reduces the distance to H' by one or increases it by one. The table fits in about 583 MB of RAM.

4x4x4 Supercube Squares Group

At last, I have completed my God's algorithm calculation for the 4x4x4 supercube squares group, in the single-slice half-turns only metric. It was found to have 47,968,768 antipodes, many more elements than are in the entire 3x3x3 supercube squares group. (OK, it's only 11,992,192 antipodes after reducing the group by four cube orientations.) The analysis showed that the elements in the group can always be solved using no more than 20 half-turns, only one more half-turn than the number required if the four centers for each face are considered indistinguishable. (The 4x4x4 supercube differs from the usual 4x4x4 cube in that all 24 centers are considered to be distinguishable from one another.)

Supercube Squares Group

Before I finish and report the results of a huge analysis that I'm working on, I thought it only fitting that I first perform this much smaller analysis, an analysis of the 3x3x3 supercube squares group (using half-turns only). Since this group has a mere 5,308,416 elements, it wouldn't be surprising to me if others have already done this analysis. However, I did not find any such analysis searching on the internet. I know that Mark had noted the size of this group in a message in the "Cube-lovers" archives: http://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Mark_Longridge__Super_Groups.html as well as a God's algorithm calculation of the ordinary 3x3x3 squares group (a group 8 times smaller). Or at least he discussed the antipodes of that group: http://www.math.rwth-aachen.de/~Martin.Schoenert/Cube-Lovers/Mark_Longridge__SQUARE'S_GROUP_ANALYS IS.html

the new magic number is 26...

look at this new paper:

http://www.ccs.neu.edu/home/gene/papers/rubik.pdf

Algorithm for orientating flipped middle layer pieces

Does anyone know any algorithms for flipping incorrectly orientated middle layer edge pieces? I looked all over the internet but couldn't find any...
THANKS!!!

The 4x4x4 can be solved in 77 single-slice turns

Previously I announced that the 4x4x4 cube could be solved in 79 single-slice turns by solving it in five stages, in a manner similar to the Thistlethwaite 4-stage solution for the 3x3x3. (See The 4x4x4 can be solved in 79 moves (STM).) However, I have now realized my solution to the 2nd stage could have allowed the use of more basic turns than I used. I have realized that:
< U,u,D,d,L2,l2,R2,r2,F2,f,B2,b > = < U,u,D,d,L2,l,R2,r,F2,f,B2,b >
So with l and r replacing generators l2 and r2, you still can not reach any additional positions. As a result, I should have included the moves { l, l', r, r' } along with the other 24 allowed slice turns for that stage.