0

I have implemented Thistlethwaite's algorithm however, it is far too slow as it is only using graph traversal over many Rubik's cube states. I am currently unsure of how look-up tables are implemented so any help on how I could do so would be greatly appreciated.

SD8
  • 1

1 Answers1

1

In case it's still relevant, the idea is to get indices based on cube states and store the distance (number of moves it takes) to reach the next group from the given state.

For example - G0->G1 only looks at edge orientations. This means, that if you only consider the orientation of an edge at a given position, there are 2^11 possible states (2 ways each of the 11 edges can be oriented, because the orientation of the 12th edge is "forced" in place by the other 11 edges, so the orientation can be assumed).

For G0->G1, it's easy to generate these indices because you can assign each edge position to a bit in a 11-bit integer, and convert it to decimal.

For a state which satisfies G1, the index would be 0 (00000000000) and for a state with all edges oriented badly, the index would be 2047 (11111111111) which gives unique index for each state from 0 to 2047.

Using this logic, run your IDDFS from a solved cube only using the available moves of the group until all permutations were visited. for G0->G1 it should be done in 7 depths.

Itay Sadeh
  • 11
  • 1