Skip to main content
added 140 characters in body
Source Link
Evil
  • 9.5k
  • 11
  • 32
  • 53

Kociemba wrote very nice algorithm, which is the fastest working algorithm returning optimal or almost optimal solution very efficiently.

If you want to derive your own system, try in steps:
0) invent notation for the cube, do not try to optimize it.

  1. try BFS or something like A* (this one will be harder, with heuristics).
  2. try some kind of memoization, and state precomputation.
  3. if something is not efficient step back to 0 and change type of notation.

Why should you not optimize your notation?
Because a few bytes overhead is nothing in compare to smooth transitions between states.

Honestly, pure BFS will do the job, but without any help or reductions it will be very slow. You can make encoding relative to color and put your reference point (one corner or the cross), it will decrease hashing time.
To check your approach just take several thousands of permuted cubes, count turns per cube and time it took per cube to solve.
If you are interested in AI, solving cube is doable, but guaranteed least moves will take some time.

There is Rubik Group but language induced solvers in contrary to graph or group solvers are not common, so there might be some hidden treasure there. Look at Kociemba algorithm, he does not use Rubik Cube group per se, but changes it so he has smaller number of instances.

Kociemba wrote very nice algorithm, which is the fastest working algorithm returning optimal or almost optimal solution very efficiently.

If you want to derive your own system, try in steps:
0) invent notation for the cube, do not try to optimize it.

  1. try BFS or something like A* (this one will be harder, with heuristics).
  2. try some kind of memoization, and state precomputation.
  3. if something is not efficient step back to 0 and change type of notation.

Honestly, pure BFS will do the job, but without any help or reductions it will be very slow. You can make encoding relative to color and put your reference point (one corner or the cross), it will decrease hashing time.
To check your approach just take several thousands of permuted cubes, count turns per cube and time it took per cube to solve.
If you are interested in AI, solving cube is doable, but guaranteed least moves will take some time.

There is Rubik Group but language induced solvers in contrary to graph or group solvers are not common, so there might be some hidden treasure there. Look at Kociemba algorithm, he does not use Rubik Cube group per se, but changes it so he has smaller number of instances.

Kociemba wrote very nice algorithm, which is the fastest working algorithm returning optimal or almost optimal solution very efficiently.

If you want to derive your own system, try in steps:
0) invent notation for the cube, do not try to optimize it.

  1. try BFS or something like A* (this one will be harder, with heuristics).
  2. try some kind of memoization, and state precomputation.
  3. if something is not efficient step back to 0 and change type of notation.

Why should you not optimize your notation?
Because a few bytes overhead is nothing in compare to smooth transitions between states.

Honestly, pure BFS will do the job, but without any help or reductions it will be very slow. You can make encoding relative to color and put your reference point (one corner or the cross), it will decrease hashing time.
To check your approach just take several thousands of permuted cubes, count turns per cube and time it took per cube to solve.
If you are interested in AI, solving cube is doable, but guaranteed least moves will take some time.

There is Rubik Group but language induced solvers in contrary to graph or group solvers are not common, so there might be some hidden treasure there. Look at Kociemba algorithm, he does not use Rubik Cube group per se, but changes it so he has smaller number of instances.

Source Link
Evil
  • 9.5k
  • 11
  • 32
  • 53

Kociemba wrote very nice algorithm, which is the fastest working algorithm returning optimal or almost optimal solution very efficiently.

If you want to derive your own system, try in steps:
0) invent notation for the cube, do not try to optimize it.

  1. try BFS or something like A* (this one will be harder, with heuristics).
  2. try some kind of memoization, and state precomputation.
  3. if something is not efficient step back to 0 and change type of notation.

Honestly, pure BFS will do the job, but without any help or reductions it will be very slow. You can make encoding relative to color and put your reference point (one corner or the cross), it will decrease hashing time.
To check your approach just take several thousands of permuted cubes, count turns per cube and time it took per cube to solve.
If you are interested in AI, solving cube is doable, but guaranteed least moves will take some time.

There is Rubik Group but language induced solvers in contrary to graph or group solvers are not common, so there might be some hidden treasure there. Look at Kociemba algorithm, he does not use Rubik Cube group per se, but changes it so he has smaller number of instances.