cube files
Indexed Cube Lovers Archive
Try Again on an computer code for a complete counting of God's Algorithm
Submitted by Jerry Bryan on Sun, 01/19/2025 - 21:44.
My most recent post on this topic was at http://forum.cubeman.org/?q=node/view/581 on 7/18/2020. That idea was a generalization of the original Shamir algorithm. The effort has been a failure in that it was far too slow. I also came up with sort of a Version 2.0 of the same idea. I was much faster, but still far too slow. For example, it counted a few hundred positions per second. I want to be able to get to about a million positions for second.
I now have a new concept for a Version 3 of a similar idea. I don't have any results yet. But I do have some of prototype code with some very preliminary time testing. It appears that I may be able to get about the order of magnitude of speed that I seek, perhaps not all the way to a million positions per second, but certainly many more than hundreds of positions per second.
It's a very simple idea. Suppose we have three sets of positions S, T, and U and we wish to form the product STU = Z. We reorganize the equation as S = ZU-1T-1 This is not so much different than what I have been doing for decades. It's based on creating positions in lexicographic order and not storing the created positions in memory. I call the algorithm a breadth first algorithm. But the breadth first algorithm has some problems. For example, it can't handle STU = Z. It can only can handle ST = Z. The new idea is a depth first algorithm instead of a breadth first algorithm, and it does story positions in memory.
A more complete description of the new idea may be found at jerrybryan.com/rubik_2025.pdf
I now have a new concept for a Version 3 of a similar idea. I don't have any results yet. But I do have some of prototype code with some very preliminary time testing. It appears that I may be able to get about the order of magnitude of speed that I seek, perhaps not all the way to a million positions per second, but certainly many more than hundreds of positions per second.
It's a very simple idea. Suppose we have three sets of positions S, T, and U and we wish to form the product STU = Z. We reorganize the equation as S = ZU-1T-1 This is not so much different than what I have been doing for decades. It's based on creating positions in lexicographic order and not storing the created positions in memory. I call the algorithm a breadth first algorithm. But the breadth first algorithm has some problems. For example, it can't handle STU = Z. It can only can handle ST = Z. The new idea is a depth first algorithm instead of a breadth first algorithm, and it does story positions in memory.
A more complete description of the new idea may be found at jerrybryan.com/rubik_2025.pdf
