Browse Source

Fix prevent_OLL()

Daniel Walton 2 years ago
3 changed files with 38 additions and 11 deletions
  1. +24
  2. +5
  3. +9

+ 24
- 11
misc/TODO.txt View File

@@ -51,17 +51,15 @@
2017-12-22 07:38:36,659 INFO: 4x4x4-step70-tsai-phase3: IDA found match 8 steps in, f_cost 14 (8 + 6)
2017-12-22 07:38:36,659 INFO: 4x4x4-step70-tsai-phase3: IDA threshold 13, explored 74412 branches, took 0:01:04.261351 (0:01:28.678691 total)

- the edges and centers tables are ready and in ~/lego/rubiks-cube-lookup-tables-4x4x4/
- the main table is building now to 8-deep, restricting the moves makes the seq
about 1 step longer so 7-deep wasn't going to be enough

- tsai phase3 takes a while in large part due to calculating symmetry states. We could rebuild the table one move less
but skip doing might be a net win and the lookup table would be smaller.

- cpu-normal phase1 stages all centers but I often see "it leads to OLL" scrolling by. We could
LOW - cpu-normal phase1 stages all centers but I often see "it leads to OLL" scrolling by. We could
build parity specific tables to help with this.

- If we did EO as part of phase2 (solving the centers) would it reduce the number of moves to pair edges?
- My guess is no, we are already at an avg of 25.82 steps for pairing edges which is pretty darn
good considering all of the centers are solved.

- Add "cube.cpu_mode = 'tsai'" to and run this overnight
time ./utils/ --test-cubes utils/test_cubes.json.small --size 4x4x4

@@ -98,7 +96,12 @@ time ./utils/ --test-cubes utils/test_cubes.json.small --size 4x4x4


Once fixed comment out the prevent_OLL() call in
The fake_555 centers solver would have to know its 6x6x6 parent and check
the parent for OLL.

Once fixed comment out the prevent_OLL() call in I think this
would shave about 10 moves off of 6x6x6 solutions...that would put us at
sub-200 moves on average.

- Something to explore...stage the centers and then solve them via bidir IDA.
Today we reduce the centers to 5x5x5 and use that solver but it ends up
@@ -116,16 +119,26 @@ time ./utils/ --test-cubes utils/test_cubes.json.small --size 4x4x4

Solving L and F (in turn solve R and B) would be (8!/(4!*4!))^8 or
576,480,100,000,000 but with two 24,010,000 prune tables for a ratio
of 0.000 000 041 6493128
of 0.000 000 041 might be doable.


step80 LFRB appears to be hanging on this one:
- step10 is slow for this that table 1 move deeper


- step80...we spend 40+ moves in this phase
- we solve LR and then FB prune to speed up step80...can we avoid this
- build the main table out to 6-deep
- build a bunch of 24 million entry prune tables
- test with this cube




+ 5
- 0
rubikscubennnsolver/ View File

@@ -2966,6 +2966,11 @@ class RubiksCube(object):
Solving OLL at the end takes 26 moves, preventing it takes 10

# OLL only applies for even cubes
if self.is_odd():
return False

orbits_with_oll_parity = self.center_solution_leads_to_oll_parity()
steps = None

+ 9
- 0
usr/bin/ View File

@@ -325,6 +325,15 @@ try:

# compress a solution
cube = RubiksCube555(solved_5x5x5, args.order, args.colormap)
cube.solution = "Rw' Lw x F2 Rw Lw' x' F' Uw Dw' y' B' Uw Dw' y' B Uw Dw' y' B Uw Dw' y' B' Uw Dw' y' F'".split()