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 9tpsI, for one, would like to see how fast Feliks can execute it.
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.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)
I guess this is a good time to rename God's algorithm:
Now that this one is out of the way: what is there still to be discovered about the 3x3x3?
I think Cubenovice was just sort of trying to compliment me. That post reminded me about the movie Bruce Almighty.Except this is Devil's algorithm, not God's algorithm
Oh wow, I'd also be curious about this.Congratulations on the successful completion of this work!
BTW, how the whole sequence affects six face centers?
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?Well, I could have done more to make the representation I had more compact, if that's what you mean.
BTW, how the whole sequence affects six face centers?
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).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?
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.For me Gods alg is one single alg that solves every (legit) cube state.
Bruce achieved just that
Thus removing the whole point of a circuit.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.
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
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.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
Are there insights you've gained through this work that may help settle the
question in general? *That* would truly be a stunning achievement.
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.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).
I assume you mean q and q? It's called that in both files.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.