Browse Source

Fix prevent_OLL()

Daniel Walton 1 year 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-_
51 51
     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)
52 52
     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)
53 53
 
54
+    UPDATE
55
+        - the edges and centers tables are ready and in ~/lego/rubiks-cube-lookup-tables-4x4x4/
56
+        - the main table is building now to 8-deep, restricting the moves makes the seq
57
+          about 1 step longer so 7-deep wasn't going to be enough
54 58
 
55
-- tsai phase3 takes a while in large part due to calculating symmetry states.  We could rebuild the table one move less
56
-  but skip doing sym...it might be a net win and the lookup table would be smaller.
57 59
 
58
-- cpu-normal phase1 stages all centers but I often see "it leads to OLL" scrolling by. We could
60
+LOW - cpu-normal phase1 stages all centers but I often see "it leads to OLL" scrolling by. We could
59 61
   build parity specific tables to help with this.
60 62
 
61
-- If we did EO as part of phase2 (solving the centers) would it reduce the number of moves to pair edges?
62
-    - My guess is no, we are already at an avg of 25.82 steps for pairing edges which is pretty darn
63
-      good considering all of the centers are solved.
64
-
65 63
 - Add "cube.cpu_mode = 'tsai'" to test.py and run this overnight
66 64
 time ./utils/test.py --test-cubes utils/test_cubes.json.small --size 4x4x4
67 65
 
@@ -98,7 +96,12 @@ time ./utils/test.py --test-cubes utils/test_cubes.json.small --size 4x4x4
98 96
 
99 97
     ./usr/bin/rubiks-cube-solver.py --state FBDDDFFUDRFBBLFLLURLDLLUFBLRFDUFLBLLFBFLRRBBFDRRDUBUFRBUBRDLUBFDRLBBRLRUFLBRBDUDFFFDBLUDBBLRDFUUDLBBBRRDRUDLBLDFRUDLLFFUUBFBUUFDLRUDUDBRRBBUFFDRRRDBULRRURULFDBRRULDDRUUULBLLFDFRRFDURFFLDUUBRUFDRFUBLDFULFBFDDUDLBLLRBL
100 98
 
101
-    Once fixed comment out the prevent_OLL() call in __init__.py
99
+    The fake_555 centers solver would have to know its 6x6x6 parent and check
100
+    the parent for OLL.
101
+
102
+    Once fixed comment out the prevent_OLL() call in __init__.py. I think this
103
+    would shave about 10 moves off of 6x6x6 solutions...that would put us at
104
+    sub-200 moves on average.
102 105
 
103 106
 - Something to explore...stage the centers and then solve them via bidir IDA.
104 107
   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
116 119
 
117 120
   Solving L and F (in turn solve R and B) would be (8!/(4!*4!))^8 or
118 121
   576,480,100,000,000 but with two 24,010,000 prune tables for a ratio
119
-  of 0.000 000 041 6493128
122
+  of 0.000 000 041 6493128...it might be doable.
120 123
 
121 124
 
122 125
 =====
123 126
 7x7x7
124 127
 =====
125 128
 
126
-step80 LFRB appears to be hanging on this one:
129
+- step10 is slow for this one...build that table 1 move deeper
130
+
131
+./usr/bin/rubiks-cube-solver.py --state LLDBLFDRRFDUBFLLLFLLDFLDUBRULFLFDRDRUBBUDBFLFRUBFLDBFRDRFLLRBDUUFRFURDDDBRRLDUDUBLRLLBUDRUDBUUUUBUUDLDFRURFFUFURRRDLBRFLLUFUULRUBRRURULFUBUURLDBRBDBFRLULLFLDLFRRDLRBFDBBFDDUDRBBUUFLBFBLRDDDBRFLBURFDDRBDRBRLURFUDDUFBBFBFLLRFFLLRDFDBBFBRFDLLURUFDDFLFDFBDFFUBDBRBUDDDBLFBLBRBRURFLBBULLDFURUBBLURFU
132
+
133
+
134
+- step80...we spend 40+  moves in this phase
135
+    - we solve LR and then FB prune to speed up step80...can we avoid this
136
+    - build the main table out to 6-deep
137
+    - build a bunch of 24 million entry prune tables
138
+    - test with this cube
139
+
140
+./usr/bin/rubiks-cube-solver.py --state LLDBLFDRRFDUBFLLLFLLDFLDUBRULFLFDRDRUBBUDBFLFRUBFLDBFRDRFLLRBDUUFRFURDDDBRRLDUDUBLRLLBUDRUDBUUUUBUUDLDFRURFFUFURRRDLBRFLLUFUULRUBRRURULFUBUURLDBRBDBFRLULLFLDLFRRDLRBFDBBFDDUDRBBUUFLBFBLRDDDBRFLBURFDDRBDRBRLURFUDDUFBBFBFLLRFFLLRDFDBBFBRFDLLURUFDDFLFDFBDFFUBDBRBUDDDBLFBLBRBRURFLBBULLDFURUBBLURFU
127 141
 
128
-LLDBLFDRRFDUBFLLLFLLDFLDUBRULFLFDRDRUBBUDBFLFRUBFLDBFRDRFLLRBDUUFRFURDDDBRRLDUDUBLRLLBUDRUDBUUUUBUUDLDFRURFFUFURRRDLBRFLLUFUULRUBRRURULFUBUURLDBRBDBFRLULLFLDLFRRDLRBFDBBFDDUDRBBUUFLBFBLRDDDBRFLBURFDDRBDRBRLURFUDDUFBBFBFLLRFFLLRDFDBBFBRFDLLURUFDDFLFDFBDFFUBDBRBUDDDBLFBLBRBRURFLBBULLDFURUBBLURFU
129 142
 
130 143
 
131 144
 =====

+ 5
- 0
rubikscubennnsolver/__init__.py View File

@@ -2966,6 +2966,11 @@ class RubiksCube(object):
2966 2966
         """
2967 2967
         Solving OLL at the end takes 26 moves, preventing it takes 10
2968 2968
         """
2969
+
2970
+        # OLL only applies for even cubes
2971
+        if self.is_odd():
2972
+            return False
2973
+
2969 2974
         orbits_with_oll_parity = self.center_solution_leads_to_oll_parity()
2970 2975
         steps = None
2971 2976
 

+ 9
- 0
usr/bin/rubiks-cube-solver.py View File

@@ -325,6 +325,15 @@ try:
325 325
     sys.exit(0)
326 326
     '''
327 327
 
328
+    # compress a solution
329
+    '''
330
+    cube = RubiksCube555(solved_5x5x5, args.order, args.colormap)
331
+    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()
332
+    cube.compress_solution()
333
+    cube.print_solution()
334
+    sys.exit(0)
335
+    '''
336
+
328 337
     cube.sanity_check()
329 338
     cube.print_cube()
330 339
     cube.www_header()