Browse Source

Fix prevent_OLL()

master
Daniel Walton 2 years ago
parent
commit
5cbe20f28b
3 changed files with 38 additions and 11 deletions
  1. +24
    -11
      misc/TODO.txt
  2. +5
    -0
      rubikscubennnsolver/__init__.py
  3. +9
    -0
      usr/bin/rubiks-cube-solver.py

+ 24
- 11
misc/TODO.txt View File

@@ -51,17 +51,15 @@ https://alg.cubing.net/?puzzle=4x4x4&setup=R2-_U_L2-_F2-_R2-_F2-_D-_F2-_R2-_U2-_
2017-12-22 07:38:36,659 LookupTable.py INFO: 4x4x4-step70-tsai-phase3: IDA found match 8 steps in, f_cost 14 (8 + 6)
2017-12-22 07:38:36,659 LookupTable.py INFO: 4x4x4-step70-tsai-phase3: IDA threshold 13, explored 74412 branches, took 0:01:04.261351 (0:01:28.678691 total)

UPDATE
- 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 sym...it 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 test.py and run this overnight
time ./utils/test.py --test-cubes utils/test_cubes.json.small --size 4x4x4

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

./usr/bin/rubiks-cube-solver.py --state FBDDDFFUDRFBBLFLLURLDLLUFBLRFDUFLBLLFBFLRRBBFDRRDUBUFRBUBRDLUBFDRLBBRLRUFLBRBDUDFFFDBLUDBBLRDFUUDLBBBRRDRUDLBLDFRUDLLFFUUBFBUUFDLRUDUDBRRBBUFFDRRRDBULRRURULFDBRRULDDRUUULBLLFDFRRFDURFFLDUUBRUFDRFUBLDFULFBFDDUDLBLLRBL

Once fixed comment out the prevent_OLL() call in __init__.py
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 __init__.py. 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.py --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 6493128...it might be doable.


=====
7x7x7
=====

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

./usr/bin/rubiks-cube-solver.py --state LLDBLFDRRFDUBFLLLFLLDFLDUBRULFLFDRDRUBBUDBFLFRUBFLDBFRDRFLLRBDUUFRFURDDDBRRLDUDUBLRLLBUDRUDBUUUUBUUDLDFRURFFUFURRRDLBRFLLUFUULRUBRRURULFUBUURLDBRBDBFRLULLFLDLFRRDLRBFDBBFDDUDRBBUUFLBFBLRDDDBRFLBURFDDRBDRBRLURFUDDUFBBFBFLLRFFLLRDFDBBFBRFDLLURUFDDFLFDFBDFFUBDBRBUDDDBLFBLBRBRURFLBBULLDFURUBBLURFU


- 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

./usr/bin/rubiks-cube-solver.py --state LLDBLFDRRFDUBFLLLFLLDFLDUBRULFLFDRDRUBBUDBFLFRUBFLDBFRDRFLLRBDUUFRFURDDDBRRLDUDUBLRLLBUDRUDBUUUUBUUDLDFRURFFUFURRRDLBRFLLUFUULRUBRRURULFUBUURLDBRBDBFRLULLFLDLFRRDLRBFDBBFDDUDRBBUUFLBFBLRDDDBRFLBURFDDRBDRBRLURFUDDUFBBFBFLLRFFLLRDFDBBFBRFDLLURUFDDFLFDFBDFFUBDBRBUDDDBLFBLBRBRURFLBBULLDFURUBBLURFU

LLDBLFDRRFDUBFLLLFLLDFLDUBRULFLFDRDRUBBUDBFLFRUBFLDBFRDRFLLRBDUUFRFURDDDBRRLDUDUBLRLLBUDRUDBUUUUBUUDLDFRURFFUFURRRDLBRFLLUFUULRUBRRURULFUBUURLDBRBDBFRLULLFLDLFRRDLRBFDBBFDDUDRBBUUFLBFBLRDDDBRFLBURFDDRBDRBRLURFUDDUFBBFBFLLRFFLLRDFDBBFBRFDLLURUFDDFLFDFBDFFUBDBRBUDDDBLFBLBRBRURFLBBULLDFURUBBLURFU


=====

+ 5
- 0
rubikscubennnsolver/__init__.py 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/rubiks-cube-solver.py View File

@@ -325,6 +325,15 @@ try:
sys.exit(0)
'''

# 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()
cube.compress_solution()
cube.print_solution()
sys.exit(0)
'''

cube.sanity_check()
cube.print_cube()
cube.www_header()

Loading…
Cancel
Save