> There are 43,252,003,274,489,856,000 ways to arrange a Rubik’s cube. If I could evaluate a million arrangements per second, it would take over 1.3 million years to evaluate all arrangements. So, inspecting every individual arrangement is out.
For people who like powers of 2, that's "only" 2^65.2
That's within the realm of computability in practical timespans, if you can make the code fast and have $$$$$ to spend on compute. (modern CPU cores can do billions of operations per second, and that's not even considering GPUs)
The approach presented in the article is obviously far more efficient, but I wonder if anyone's done a "full search" of all possible cube positions before. I don't think there's any reason to do that, but that hasn't stopped people before (see: pi calculation records).
I loved reading this, but I can't help but think that a "perfect scramble" would be one that can ONLY be solved in 20 moves, i.e no shortcuts can be applied to solve in less moves. I wonder how many of those exist?
I want to flip coins so randomly that I never see the same face twice in a row.
It actually looks somewhat regular instead of random in the end. Perhaps having only rule 6 and 3, no others, is interesting. Or 6, 3 and 1. Or only rule 3 and take solution with highest entropy
For all the Rubik's Cube enthusiasts here: here's a two-dimensional one in JavaScript - https://www.huehnken.de/games/circles/
Also a solution looking for a problem, maybe.
OP’s perfect scramble takes 18 moves to solve. Does that mean all Rubik’s Cube arrangements can be solved in 18 moves or less?
Its quite a pretty arrangement IMO. There is a mix of randomness and regularity in it.
I'll keep my Rubik's Cube in this position.
That’s a great reminder that what humans consider random and what is a truly random sets of states with high entropy are typically different things. In this case out of 43 quintillion combinations, there’s only 48 that fit the human imposed random criteria. In the case of passwords, websites typically ask for lots of additional constraints in what a password must have leading to dramatic reductions in the brute force effort required to find a password.
Par of why this is a strange goal is that two adjacent squares can be the same color, but not be in the correct relative position for an unscrambled cube. Rubik's cube is puzzle of cubelets, not squares
> There are 3 limitations:
> ...
> 2) I can place the first 11 edge pieces onto the cube any way I want. The orientation of the last edge piece is determined by the orientation of the first 11.
> 3) I need to track how many swaps I create by placing those pieces. An even number of swaps is solvable, and odd number is not.
Would it be equivalent to say, after placing the first 10 edge pieces, the position of the 11th is mandated, and then the orientation of the 12th is too? Or if (3) is broken might it be harder to fix than swapping the 11th and 12th?