Welcome to the Speedsolving.com, home of the web's largest puzzle community! You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

OptClock is a new program to optimally solve the Rubik's Clock. It can solve any position in seconds on my machine, and it can also generate and solve thousands of random positions in a row, and then display statistics. I came up with the algorithm and wrote the original C++ program, and Ben Whitmore (ben1996123) added a GUI.

So far we've sub-optimally solved millions of scrambles and haven't been able to find a depth 12 position. The average optimal depth seems to be about 9.4.

So far we've sub-optimally solved millions of scrambles and haven't been able to find a depth 12 position. The average optimal depth seems to be about 9.4.

I programmed an optimal clock solver last summer. I'll check, If I can find it anywhere. But If I remember correctly, it was a bit slower than OptClock. I also solved a bunch of random scramble and got the same result, no position required more than 11 moves.

By the way, I can't get the gui or the stats to run. I downloaded the 4 dlls (libgcc_s_dw2-1.dll, libstdc++-6.dll, QtCore4.dll and QtGui4.dll). Now when I start the gui, ,nothing happens. And the stats crashes, after I enter the searching depth, but no error message. otpclock.exe works however.

I am surprised that there is no God's number or full statistics for the number of positions for each distances for this puzzle.
Maybe this is because the high number of possible postions? How many positions there are? (I probably could calculate it, I'm just too lazy...)

I am surprised that there is no God's number or full statistics for the number of positions for each distances for this puzzle.
Maybe this is because the high number of possible postions? How many positions there are? (I probably could calculate it, I'm just too lazy...)

No, it's 12^14 = 1.28 * 10^15. There are 9+9 = 18 little clocks, and the 4 corner clocks on the front are mechanically linked with the 4 corner clocks on the back. So only 14 clocks are free. Any position of these clocks is possible.

If you want to solve the solved state optimally, it finds the basic solution instantly (0+0), but then takes 1.2 seconds to assure, that there is no shorter solution.

No, it's 12^14 = 1.28 * 10^15. There are 9+9 = 18 little clocks, and the 4 corner clocks on the front are mechanically linked with the 4 corner clocks on the back. So only 14 clocks are free. Any position of these clocks is possible.

So the number of positions is quite high? However the number of symmetries should be very high, too. There should be 16 rotation/mirror symmetries, 2 time inversion symmetries and the 14 free clocks must take some value twice. My intuition tells me, one should be able to exploit this fact in another symmetry. (I could be wrong)

One more: Turning a wheel can be viewed as an element in the Z/12Z group. There are isomorphisms of this group to itself, that are: multiplying every element by a number, that is co-prime to 12. (1, 5, 7, 11 are the only ones I think). Having thought about that, time inversion is just multiplication by 11.

Putting all these together yields: 16*4=64. Assuming the number of symmetry-invariant positions is very small, the remaining interesting positions add up to: ~2*10^13. Did I miss some symmetries?

Also, when reducing the number of states for every single clock, can we find out some god's numbers there?

No, it's 12^14 = 1.28 * 10^15. There are 9+9 = 18 little clocks, and the 4 corner clocks on the front are mechanically linked with the 4 corner clocks on the back. So only 14 clocks are free. Any position of these clocks is possible.

If you want to solve the solved state optimally, it finds the basic solution instantly (0+0), but then takes 1.2 seconds to assure, that there is no shorter solution.

That's not really a bug, just a result of how this particular algorithm works. It will loop through the 12^8 possible phase 1 positions no matter what, although it discards all of them immediately.

Do you remember what your algorithm was to find optimal solutions?

Oh yeah, and I ran 50 million scrambles with upper bound of 11, but could not find any 12s

If I remember correctly, it was very straightforward. I just had a prune table for the cross.
Solved one cross with the 15 possible moves, then solved the cross + edges on the other side with the other 15 moves. And I used the fact, that moves are commutative.
My algorithm wasn't a 2-phase solver. The first solution I found, was the optimal one.

The more I thing about my solver, the more slower it gets. A few hours ago, I thought, that it solved 11 move solutions in half a minute. At the moment I think, that it took up to 5 minutes.
I will search for my code and test it. I didn't optimize it in any way. I thought about a clock solver today, and I have quite a lot of improvements and ideas. Maybe I'll improve my program in the next days.