# A Hamiltonian circuit for Rubik's Cube!



## cuBerBruce (Feb 21, 2012)

I have found a Hamiltonian circuit for the quarter-turn metric Cayley graph of Rubik's Cube! In fact, it only uses turns of five of the six outer layers of the cube.

In more basic terms, this is a sequence of quarter moves that would (in theory) put a Rubik's cube through all of its 43,252,003,274,489,856,000 positions without repeating any of them, and then one final move restores the cube to the starting position. Note that if we have any legally scrambled Rubik's Cube position as the starting point, then applying the sequence would result in the cube being solved at some point within the sequence.

Additional information can be found at my web site: http://bruce.cubing.net/index.html


----------



## cmhardw (Feb 21, 2012)

Congratulations Bruce! This is a fascinating and amazing result! I downloaded the file, and I can't wait to check it out and attempt to understand it


----------



## Julian (Feb 21, 2012)

Wow! I thought this result would be way off in the future. Great job!


----------



## cubernya (Feb 21, 2012)

Now everytime somebody asks you how to solve it, just give them this.


----------



## aronpm (Feb 21, 2012)

Wow, this is awesome Bruce 



theZcuber said:


> Now everytime somebody asks you how to solve it, just give them this.


Yeah, that sounds plausible.


----------



## Brest (Feb 21, 2012)

Awesome Bruce, impressive as always!


----------



## Owen (Feb 21, 2012)

Yay! I hate B moves!


----------



## Specs112 (Feb 21, 2012)

Bruce should be president.


----------



## A Leman (Feb 21, 2012)

This is awesome! It must have taken you a long time and a pile of discrete math and number theory books to figure this out. Very impressive!!!


----------



## qqwref (Feb 21, 2012)

Awesome job! This is a crazy result, and I look forward to seeing how you actually found it.

PS: I, for one, would like to see how fast Feliks can execute it.


----------



## cuBerBruce (Feb 21, 2012)

Sahid Velji said:


> Bruce, were you the one to post a Hamiltonian circuit for the 2x2 as well?


 
Yes, I was also the one who posted the 2x2x2 Hamiltonian circuit (after someone else posted a Hamiltonian circuit of the 2x2x2 <U, R> subgroup). I thought I better post my 2x2x2 result at that time before someone else figured out a way to connect up the 126 cosets. I had actually developed that solution in July of 2010.

It was back in late 2007 that I decided to make it a goal of mine to solve the Rubik's Cube Hamiltonian circuit problem. So this was no overnight solution. I solved the <U, R> subgroup Hamiltonian problem in 2008. I was not successful in arriving at a Hamiltonian circuit for the <U, R, F> subgroup. On Nov. 1, 2011, it finally dawned on me to consider the <U, R, D> subgroup rather than <U, R, F>. This turned out to be much easier for me to solve, and then <U, R, D, L> (only 132 cosets to deal with) was fairly easy to solve as well. This left only 2048 cosets for the final phase. While this had the same sort of difficulty as the <U, R, F> subgroup, the <U, R, F> subgroup problem had over 2.3 million cosets to deal with; over 1000 times more than 2048. By sometime in December I had determined _how_ to finish the solution. It was just a matter of working out the details. On February 1, 2012, I had the problem essentially solved. I still had some work to take the details that had been worked out and put them into a form that describes the Hamiltonian circuit in the actual order that the sub-parts are executed.


----------



## Cielo (Feb 21, 2012)

Congratulations!

P.S: I noticed a typo in your explanation :"The problem of _connnecting_ up the 2048 cosets".


----------



## Lucas Garron (Feb 21, 2012)

Ooh, this is awesome. I've been looking forward to it ever since your previous results suggested it should be feasible. It looked too scary for me, so congratulations for getting a full solution! 

- You only use quarter turns, right? That gets rid of the ambiguities around RR vs. R2
- The 7MB zip expands to 236MB (you might want to mention that on the site, too?). Any idea of the actual Kolmogorov complexity of your solution? Can it fit into a MB? Way less?
- It might be kind of cute to write an algorithm that prints out a given (short) subsequence on demand. Sort of to make a point that this algorithm is constructive and we *can* write out any part we want.
- Generalizing this: What puzzles have a Hamiltonian path? Is it obvious whether Pyraminx should have one? Megaminx? Square-1?


----------



## cuBerBruce (Feb 21, 2012)

Lucas Garron said:


> - You only use quarter turns, right? That gets rid of the ambiguities around RR vs. R2


Yes, the solution only uses quarter-turns (both clockwise and counterclockwise), but it may use the same quarter-turn more than once consecutively. Of course you can't use the same turn four times in succession, as that would result in repeating a state. As I said, it's a Hamiltonian circuit for the QTM Cayley graph.

A half-turn on an actual cube would have the cube pass through another state midway, so limiting to quarter-turns assures that no state is passed through without being counted as a reached state.



Lucas Garron said:


> - The 7MB zip expands to 236MB (you might want to mention that on the site, too?). Any idea of the actual Kolmogorov complexity of your solution? Can it fit into a MB? Way less?


I was thinking good lossless compressors tend to compress fairly close to the amount of actual information. But perhaps this isn't so much the case with highly compressible information, so I don't really know. (By the way, Lucas, are there limits to how much space I can use?)



Lucas Garron said:


> - It might be kind of cute to write an algorithm that prints out a given (short) subsequence on demand. Sort of to make a point that this algorithm is constructive and we *can* write out any part we want.


I'll have to think about this. I also want to calculate the distribution of the 10 different moves that are used.



Lucas Garron said:


> - Generalizing this: What puzzles have a Hamiltonian path? Is it obvious whether Pyraminx should have one? Megaminx? Square-1?


As mentioned on Jaap's Puzzle Page, there is a mathematical conjecture (so it's not proven) that all Cayley graphs have a Hamiltonian circuit. Cubes larger than 3x3x3 generally have indistinguishable pieces (if not stickered as supercubes) so the positions don't form a group, so I believe the conjecture would not apply to those puzzles. Square-1 positions also do not form a group. For puzzles that are not a group, it may tend to be much harder (even if possible) to find a Hamiltonian circuit, since you then can't make use of group properties.

And thanks for pointing out the typo, Cielo. I'll fix that.


----------



## Cubenovice (Feb 21, 2012)

Congratulations!

I guess this is a good time to rename God's algorithm: 

*Bruce's Algorithm*

Now that this one is out of the way: what is there still to be discovered about the 3x3x3?


----------



## Stefan (Feb 21, 2012)

cuBerBruce said:


> I was thinking good lossless compressors tend to compress fairly close to the amount of actual information.


 
NanoZip 0.09 alpha with "cm" setting got it to 2,754,024 bytes, that's 38.8% of your zip's size. But shouldn't a full representation of your construction method/algorithm be even much smaller? (I'm not that familiar with Kolmogorov complexity, don't know what exactly is allowed and how it's counted)


----------



## ASH (Feb 21, 2012)

Ok, I admit I suck at group theory (took the last course 4 years ago).
So, what do I get wrong:

- If there exists an element of the cube group which generates all elements (of the cube group) this means the group is cyclic, e.g. Cubegroup=<a>, a the proposed element
- All cyclic groups are ablian, which means that for all elements a,b \in Cubegroup: a°b=b°a holds (° is the group's operation)
- This means that 0=a°b-b°a=[a,b] (Commutator)

Which concludes that all commutators do nothing, which is obviously false.

So, tell me why I suck, pls!


----------



## Stefan (Feb 21, 2012)

ASH said:


> So, what do I get wrong


 
The topic of this thread.

This is about a loooong algorithm which *during* its execution visits all cube states. You're thinking of what happens when you repeat an algorithm and look at the cube only *after* each execution. The cube group isn't cyclic.


----------



## ASH (Feb 21, 2012)

You're right Stefan.

I was anyway doubting that I beat you in group theory! 

At least I've been right about what I thought it was about.


----------



## cuBerBruce (Feb 21, 2012)

Oops! I had an error in the file x.txt within the .zip archive. The sequence for x had two moves missing from the beginning. I figure I must have typed "x=" while in replace mode instead of insert mode and not realized that. The correct .zip archive is now on the site. The sequence x contains 73483059 moves.


----------



## cubernya (Feb 21, 2012)

Cubenovice said:


> Congratulations!
> 
> I guess this is a good time to rename God's algorithm:
> 
> ...


 Except this is Devil's algorithm, not God's algorithm


----------



## ben1996123 (Feb 21, 2012)

qqwref said:


> I, for one, would like to see how fast Feliks can execute it.



43,252,003,274,489,856,000/9 = 4,805,778,141,609,984,000 seconds \( \approx \) 152,390,225,190 years \( \approx \) 11.123 universe ages (assuming the universe is 13.7 billion years old) at 9tps


----------



## cuBerBruce (Feb 21, 2012)

Stefan said:


> NanoZip 0.09 alpha with "cm" setting got it to 2,754,024 bytes, that's 38.8% of your zip's size. But shouldn't a full representation of your construction method/algorithm be even much smaller? (I'm not that familiar with Kolmogorov complexity, don't know what exactly is allowed and how it's counted)



Well, I could have done more to make the representation I had more compact, if that's what you mean. The x.txt file is pure sequence of individual moves, for example. But I left it that way so subsequence ranges used in the misc.txt and RubiksCubeHamilton.txt would directly correspond with the sequence as given. Also, I wanted to announce this at the MIT Spring 2012, and didn't really have the time to work on making it more compact.

I will try to come up with an updated version of the specification in the near future, or at least try to provide more information about the relationship between the q_shortcut.txt and q.txt files so that the subsequences for q and Q can be more easily related to the actual sequences.



Cubenovice said:


> Congratulations!
> 
> I guess this is a good time to rename God's algorithm:
> 
> ...


 


theZcuber said:


> Except this is Devil's algorithm, not God's algorithm


I think Cubenovice was just sort of trying to compliment me. That post reminded me about the movie _Bruce Almighty_.


----------



## stannic (Feb 21, 2012)

Congratulations on the successful completion of this work!

BTW, how the whole sequence affects six face centers?


----------



## Cubenovice (Feb 21, 2012)

theZcuber said:


> Except this is Devil's algorithm, not God's algorithm



pff semantics....

For me Gods alg is one single alg that solves every (legit) cube state.
Bruce achieved just that


----------



## cmhardw (Feb 21, 2012)

stannic said:


> Congratulations on the successful completion of this work!
> 
> BTW, how the whole sequence affects six face centers?


 
Oh wow, I'd also be curious about this.

Bruce, do you think this result shows that such a Hamiltonian cycle might exist for the supercube 3x3x3 as well? Is this question possibly solvable in a reasonable amount of time and effort, or is the complexity of that problem larger than is reasonable?


----------



## Stefan (Feb 21, 2012)

cuBerBruce said:


> Well, I could have done more to make the representation I had more compact, if that's what you mean.


 
What I meant was to not measure the computed move sequences, but to measure the program code that computed them, as that's a representation as well. Surely that is or could be much shorter?


----------



## cuBerBruce (Feb 21, 2012)

stannic said:


> BTW, how the whole sequence affects six face centers?


 


cmhardw said:


> Oh wow, I'd also be curious about this.
> 
> Bruce, do you think this result shows that such a Hamiltonian cycle might exist for the supercube 3x3x3 as well? Is this question possibly solvable in a reasonable amount of time and effort, or is the complexity of that problem larger than is reasonable?


 
Obviously the B center is unaffected. I also know that the F center ends up in its original orientation. When I finish calculating the distribution counts for the other turns, this will be a trivial calculation. Every F turn can be matched with a corresponding F' turn except for 12 F turns (due to making use of the identity (U' R' U F)6 twice).

Of course, I was not trying to create a supercube Hamiltonian circuit, so I didn't care about tracking the orientations of the center pieces. It's not immediately clear to me if the result can easily be extended to generate a supercube Hamiltonian circuit.


----------



## qqwref (Feb 22, 2012)

Cubenovice said:


> For me Gods alg is one single alg that solves every (legit) cube state.
> Bruce achieved just that


That's Devil's alg, you've just got your terms confused. God's alg is an alg (well, a collection of algs) that can solve any cube state optimally.

I feel like finding a Hamiltonian circuit for supercube positions would be significantly harder than this problem.


----------



## penfold1992 (Feb 22, 2012)

super cube wouldnt be much harder... you could just say "if the cube is almost solved with just the centers need twisting then apply one of the remaining 2 algs that will fix this" then just list the 180 turn and the two 90degree algs.


----------



## musicninja17 (Feb 22, 2012)

penfold1992 said:


> super cube wouldnt be much harder... you could just say "if the cube is almost solved with just the centers need twisting then apply one of the remaining 2 algs that will fix this" then just list the 180 turn and the two 90degree algs.


 
Thus removing the whole point of a circuit.


----------



## vcuber13 (Feb 22, 2012)

you both missed the point, a super cube has 12(?) times more combinations


----------



## vcuber13 (Feb 22, 2012)

i thought about it wrong and couldn't remember, and wouldn't it be 2048 (4^6/2)


----------



## Christopher Mowla (Feb 22, 2012)

vcuber13 said:


> i thought about it wrong and couldn't remember, and wouldn't it be 2048 (4^6/2)


Yes. For the nxnxn supercube, factor increase = number of solved positions of the regular nxnxn cube.

EDIT:

On topic. Congratulations Bruce! This is amazing.


----------



## cuBerBruce (Feb 22, 2012)

I've tallied up the distribution of the different moves in the Hamiltonian circuit I made. I hope I didn't make any errors. I would like to do a somewhat brute force tally by computer to check the values.


```
U:  10,898,125,406,064,467,088
U': 10,727,912,135,641,656,820
R:  10,901,458,532,532,248,688
R': 10,724,506,023,073,643,108
D:             588,588,720,174
D':            588,588,580,818
L:                     268,288
L':                    268,288
F:                       1,370
F':                      1,358
B:                           0
B':                          0
```

The net clockwise turns of each layer is 0 mod 4, so it indeed will preserve center orientations if my calculations are correct.


----------



## rokicki (Feb 23, 2012)

Congratulations on the accomplishment. You beat me to it (although I do not
know if my approach would have succeeded in any case). Your approach is
very nice. I am also interested in how concise a formulation of the cycle can
be made

Are there insights you've gained through this work that may help settle the
question in general? *That* would truly be a stunning achievement.


----------



## cuBerBruce (Feb 24, 2012)

rokicki said:


> Congratulations on the accomplishment. You beat me to it (although I do not
> know if my approach would have succeeded in any case). Your approach is
> very nice. I am also interested in how concise a formulation of the cycle can
> be made
> ...


 
My goal was basically to come up with a solution as easily as possible, not one that necessarily has a nice structure. Generally, the structure would have been nicer if I solved each hierarchical level by producing a sequence of complete Hamiltonian paths for the cosets connected end to end by non-subgroup moves. However, it seems so much easier to make Hamiltonian circuits for each coset and connect them together with what I think of as the "interrupt approach." You start traversing a Hamiltonian circuit or path for one coset, and part way through you interrupt that traversal to traverse another coset (or multiple cosets) and come back to the original Hamiltonian path/circuit at the point where you left off. You might do several such interrupts before finishing that Hamiltonian path/circuit. While this approach is much easier, it doesn't make for the most concise sort of solutions. Perhaps expressing the solution as an algorithm or actual program code as Stefan mentioned would make it appear more concise.

I'm not quite sure what you mean by the question in general. I'm guessing you might be referring to proving the conjecture that every Cayley graph has a Hamiltonian circuit. It seems easy to use a Hamiltonian circuit for a subgroup if the larger group is generated by adding a generator that commutes with a generator for the subgroup. But if you have to add a generator that doesn't commute with the subgroup generators, you may not have a way to traverse one other coset and return to the interrupted coset at the point where you left off (as is the case with <U,R,F> and subgroup <U,R>). In this case it might be hard to prove that you can make a Hamiltonian circuit for the larger group.


----------



## fw (Feb 24, 2012)

Hi Bruce,

nice result. I like it very much! So... No offense, but how do we know for sure that your approach is correct?  Brute-force-verifying your solution is not an option (right?) and you don't really give a proof that your way of generating it is not flawed (just a really rough sketch).

Flo


----------



## cuBerBruce (Feb 24, 2012)

fw said:


> Hi Bruce,
> 
> nice result. I like it very much! So... No offense, but how do we know for sure that your approach is correct?  Brute-force-verifying your solution is not an option (right?) and you don't really give a proof that your way of generating it is not flawed (just a really rough sketch).
> 
> Flo


 
I certainly expect that some people would question the validity of my result. So I am hoping that someone will actually do an indpendent verification of it.

I would certainly agree that a totally brute force verification is not an option. However, I think it is possible to verify (with a computer) that the Hamiltonian paths used at each of the subgroup levels are valid, and that the cycle defined at the top level in fact traverses each of 2048 cosets of the <U,R,D,L> subgroup. In that manner, the Hamiltonian circuit should be verifiable.

I rely on the fact that if I have a sequence s that traverses all element of a subgroup of G called H, then I can start at some arbitrary element of g of G and do the sequence s, and I will traverse all of the elements of the coset gH. I also make use of the fact that if a sequence s is a Hamiltonian path for a group G, then the inverse sequence of s is also a Hamiltonian path for G. I think these concepts are quite elementary results in group theory.


----------



## Stefan (Mar 21, 2012)

cuBerBruce said:


> I will try to come up with an updated version of the specification in the near future, or at least try to provide more information about the relationship between the q_shortcut.txt and q.txt files so that the subsequences for q and Q can be more easily related to the actual sequences.



I assume you mean q and q? It's called that in both files.

I'm trying to verify the length and the move distribution, and this is where I'm stuck right now. With indexes using q_shortcut.txt but the actual moves in q.txt, I need to know how to match them and it's not obvious to me.


----------



## cuBerBruce (Mar 21, 2012)

Although the q_shortcut file contains "q=", it does not really define the true sequence for q. Each "u" (lower case) in the shortcut file would really need to be replaced by a sequence. To determine that sequence (for each u), you would have to execute the corresponding moves from the q.txt until you reach the same state that you would reach if you just applied the move U at that point instead. (You should then find that the next moves in both files will be the same until the next "u" in q_shortcut.txt; and so on.) These "u" sequences generally are not the same length. The indices in RubiksCubeHamilton.txt are such that each "u" (or other symbol such as "x") is counted as a single "move" (that is, takes up exactly one index position).

I've created a file that provides a mapping between positions in the shortcut sequence to positions in the longer sequence (for each position following a "u" in the shortcut file). I can email this to people who want it.

Q is the inverse sequence of q. I didn't provide files for Q because it should be straightforward to generate these from the q.txt and q_shortcut.txt files (just reverse the order, using the inverse symbol of each symbol in the sequence).


----------



## Stefan (Mar 22, 2012)

cuBerBruce said:


> To determine that sequence (for each u), you would have to execute the corresponding moves from the q.txt *until you reach the same state* that you would reach if you just applied the move U at that point instead.



Ah yes, I could have seen that. Forgot that you don't visit a state twice...



cuBerBruce said:


> Q is the inverse sequence of q.



Ok, I've seen it in readme.txt now. I had only checked the definitions in the definition files. Why did you define T/Q/X in readme.txt instead of in misc.txt like the other inverses?


----------



## cuBerBruce (Mar 22, 2012)

Stefan said:


> Why did you define T/Q/X in readme.txt instead of in misc.txt like the other inverses?


Yes, the definitions for T/Q/X should have been included in the misc.txt file. I'll plan to update the misc.txt file.


----------



## CarlBrannen (Jul 6, 2012)

Of course the vast majority of initial conditions will be solved long before the algorithm indicates: Since the algorithm has thousands of moves, it has to, on average cover all the states thousands of times.

I.e. I'm assuming that the Hamiltonian circuit works in that if we call the algorithm A, then A raised to the J power is not equal to A for any J less than the number of cube positions. But the number of (not different) positions you've actually traversed in doing this is MxA^N where M is the number of 1/4 turns in the algorithm.


----------



## cuBerBruce (Jul 6, 2012)

CarlBrannen said:


> Of course the vast majority of initial conditions will be solved long before the algorithm indicates: Since the algorithm has thousands of moves, it has to, on average cover all the states thousands of times.
> 
> I.e. I'm assuming that the Hamiltonian circuit works in that if we call the algorithm A, then A raised to the J power is not equal to A for any J less than the number of cube positions. But the number of (not different) positions you've actually traversed in doing this is MxA^N where M is the number of 1/4 turns in the algorithm.



You seem to be confused about something. The Hamiltonian circuit contains exactly 43,252,003,274,489,856,000 quarter turns. Performing it once will sequence the cube through each of the possible states exactly once until ending up at the initial position again when finished. Repeating it will result in going through the same sequence of 43,252,003,274,489,856,000 positions a 2nd time in the same order.

You seem to be of the impression that the Hamiltonian circuit I've described is some shorter algorithm simply repeated a certain number of times. That's simply not the case at all.


----------



## CarlBrannen (Jul 6, 2012)

Thanks for explaining that to me. Now I'm more impressed! It's like a knight's tour of the chessboard (but far longer).

Now I'm wondering if what I was thinking of can exist. That is, is there an algorithm A which raised to the 43 zillionth power is unity and for no smaller power. That could be a lot easier to memorize than the Devil's algorithm (but would take much longer to cycle the cube).


----------



## cuBerBruce (Jul 6, 2012)

CarlBrannen said:


> Thanks for explaining that to me. Now I'm more impressed! It's like a knight's tour of the chessboard (but far longer).
> 
> Now I'm wondering if what I was thinking of can exist. That is, is there an algorithm A which raised to the 43 zillionth power is unity and for no smaller power. That could be a lot easier to memorize than the Devil's algorithm (but would take much longer to cycle the cube).



Yeah, the knight's tour problem is one of the more famous Hamiltonian circuit problems.

Didn't you read the Calculating "The Devil's Algorithm" thread?

It's been discussed there and many other places that you will always get back to the initial state after no more than 2520 repetitions of any algorithm (1260 repetitions if the algorithm is restricted to face turns only).

I also note that my Hamiltonian circuit certainly does make use of repetition, but it's a quite a bit more complicated than simply repeating a certain fixed sequence over and over. It also makes use of "interrupts" which I regard as one of the key techniques used to make solving the problem relatively "easy."


----------



## Swordsman Kirby (Jul 7, 2012)

CarlBrannen said:


> Now I'm wondering if what I was thinking of can exist. That is, is there an algorithm A which raised to the 43 zillionth power is unity and for no smaller power. That could be a lot easier to memorize than the Devil's algorithm (but would take much longer to cycle the cube).





cuBerBruce said:


> It's been discussed there and many other places that you will always get back to the initial state after no more than 2520 repetitions of any algorithm (1260 repetitions if the algorithm is restricted to face turns only).



How about: "every cyclic group is abelian, but the Rubik's Cube group is not"?


----------



## Nils (Aug 22, 2012)

Why is the maximum order of an element 2520 in the case you also use middle layer turns, while in the usual Rubik's Cube group (face turns only) the maximum order of an element is 1260? I don't really see why adding middle layer turns double the maximum order?

Or is it because in the face + middle layer turning case, configurations that are equal under octahedral rotation symmetry are not considered to be the same? While in the face turning case you have no multiple configurations that are the same under octahedral rotation symmetry simply because the face pieces are fixed?

Or do you also consider x, y and z as group elements?


_____
Nils


----------



## cuBerBruce (Aug 22, 2012)

Nils said:


> Why is the maximum order of an element 2520 in the case you also use middle layer turns, while in the usual Rubik's Cube group (face turns only) the maximum order of an element is 1260? I don't really see why adding middle layer turns double the maximum order?



When you allow middle layer turns, you allow centers to move (with respect to the layers you are referring to as U, F, etc.). When centers are allowed to move, the parity constraint of the cube becomes that the total parity of corners, edges, and centers must be even. The constraint that the corner parity must match the edge parity becomes removed! This allows a corner position of order 45 to be combined with an edge position of order 56. This provides an order 2520 position. For example, U R' U2 L' F S.



Nils said:


> Or do you also consider x, y and z as group elements?



If you consider x, y, and z as group elements, you end up with a group 24 times larger than the normal Rubik's cube group. But you don't have to use these cube rotations. The above example (U R' U2 L' F S) is an element of the cube group that uses the DB edge as the reference, <U, E, L, R, F, S>. This group is the same size as the normal (fixed centers) cube group, but still has an order 2520 element.


----------



## CubeRoots (Sep 4, 2012)

Could someone tell me what B is in terms of U R L D and F?


----------



## ben1996123 (Sep 4, 2012)

CubeRoots said:


> Could someone tell me what B is in terms of U R L D and F?



D' = 
R2 U F2 U L2 U B2 U R2
L U L' U R U2 R2 F R F'
R' U2 R
U L' U' L2 U L'
y' U' R U' R' U2 R U' R'
U' F R U R' U' R' F' L F R F' L'
U R2 U R U R' U' R' U' R' U R' U

so you could inverse and rotate that if you want.

F' D F' D F D F D F' D' F' D2 F' U L D' L' U' L D F D F' D' L' F D F D' F2 D F D' F L F' L2 F L F' R' F2 R D R' D' R2 F2 R' F' L F' L' R2 F' U2 F' L2 F' D2 F' R2


----------



## vcuber13 (Sep 4, 2012)

i think Chris' signature has something like that


yup:
D = R L F2 B2 L' R' U R L B2 F2 L' R'


----------



## Stefan (Sep 4, 2012)

You can easily do that yourself, doesn't even take a minute:


----------



## CubeRoots (Sep 4, 2012)

Stefan said:


> You can easily do that yourself, doesn't even take a minute:



not if you don't have the software!

but thankyou though


----------



## Stefan (Sep 4, 2012)

Getting the software doesn't take a minute, either 

And it's quite useful, so I highly recommend having it.


----------



## CubeRoots (Sep 4, 2012)

Stefan said:


> Getting the software doesn't take a minute, either
> 
> And it's quite useful, so I highly recommend having it.



I am on it now


----------



## elrog (Feb 28, 2013)

This is great and very impressive, but I dare you to come up with one that goes through every possible position the cube can be assembled into.  Knowing Bruce, hes already done this and just hasn't told anyone.


----------



## JasonK (Feb 28, 2013)

elrog said:


> This is great and very impressive, but I dare you to come up with one that goes through every possible position the cube can be assembled into.  Knowing Bruce, hes already done this and just hasn't told anyone.



Surely that's impossible? You can't get to unsolvable states by doing moves on a solvable cube.


----------



## qqwref (Feb 28, 2013)

(Devil's Alg) [twist corner clockwise] (Devil's Alg) [twist corner clockwise]
(Devil's Alg) [flip edge]
(Devil's Alg) [twist corner clockwise] (Devil's Alg) [twist corner clockwise]
(Devil's Alg) [swap two edges]
(Devil's Alg) [twist corner clockwise] (Devil's Alg) [twist corner clockwise]
(Devil's Alg) [flip edge]
(Devil's Alg) [twist corner clockwise] (Devil's Alg) [twist corner clockwise]
(Devil's Alg)


----------



## cuBerBruce (Feb 28, 2013)

qqwref said:


> (Devil's Alg) [twist corner clockwise] (Devil's Alg) [twist corner clockwise]
> (Devil's Alg) [flip edge]
> (Devil's Alg) [twist corner clockwise] (Devil's Alg) [twist corner clockwise]
> (Devil's Alg) [swap two edges]
> ...



For a Hamiltonian circuit, the "(Devil's Alg)" would have to be a Hamiltonian circuit leaving out the final quarter-turn. Also (for the above to become a Hamiltonian circuit), you would also require a simultaneous clockwise corner twist and edge swap at the end to get back to the "legal" coset (and the solved state, if that's your starting position). I realize elrog may not have been clear if he meant a Hamiltonian circuit or just a (not necessarily minimal) sequence that visits all illegal cube group states.

My solution:
Let's say the illegal moves are to be limited to:
P = Flip edge at UF
T = Twist corner at UFR clockwise
C = Swap the corners at positions ULF, UFR

Further, let's let H = standard Hamiltonian circuit of quarter-turn moves, leaving out the final move, assuming that move would have been D.

Then, a Hamiltonian circuit for the illegal cube group could be made as:

HTHTHPHCHTHCHTHCHPHTHTHC


----------

