Announcing: New 4x4x4 Brute Force Solver

[qqwref]

Yeah, there must be something wrong, because those two "solutions" just scramble my cube.

So, in one respect, I think I was correct. Search extensions for deeper searches can (potentially) find long-distance solutions faster than crawling one iteration at a time (from 0 to 1 to 2 to 3 .... to 12, in this case). Not every time, but clearly when the outer fringe of the last jump can reach the nominal depth of a deep search because of the databases.

As I already showed you, the gains are negligible... and they only apply when the optimal solution length is right on that edge (which I don't think it is here). If the optimal movecount is right on that edge, your jumping version takes a few percent less time (since the searches of 0, 1, ..., 11 moves are very small compared to the search for 12 moves), but if it's anywhere in between, your jumping version takes far longer.

 

[Jakube]

The code I gave you, deals only with things like U D U, R R, ... Not stuff like Uud'D'.

Look at my post here: http://www.speedsolving.com/forum/s...e-Force-Solver&p=965261&viewfull=1#post965261

My code for these three rules was quite ugly, so I only sent you the nice stuff.
If you want too add it, I might have the code anywhere.

But there's something else wrong. Like qqwerf said, these solutions doesn't solve this case.

 

[unsolved]

[table="width: 450, class: grid"]
[tr]
[td]n[/td]
[td]all
36*33^(n-1)[/td]
[td]canceling moves
(U d U = U2 d)[/td]
[td]cancel by rotation
(U u = d D)[/td]
[/tr]
[tr]
[td]0[/td]
[td]

1​

[/td]
[td]

1​

[/td]
[td]

1​

[/td]
[/tr]
[tr]
[td]1[/td]
[td]

36​

[/td]
[td]

36​

[/td]
[td]

36​

[/td]
[/tr]
[tr]
[td]2[/td]
[td]

1.188​

[/td]
[td]

1.026​

[/td]
[td]

999​

[/td]
[/tr]
[tr]
[td]3[/td]
[td]

39.204​

[/td]
[td]

28.836​

[/td]
[td]

27.288​

[/td]
[/tr]
[tr]
[td]4[/td]
[td]

1.293.732​

[/td]
[td]

810.891​

[/td]
[td]

746.562​

[/td]
[/tr]
[tr]
[td]5[/td]
[td]

42.693.156​

[/td]
[td]

22.803.120​

[/td]
[td]

20.421.648​

[/td]
[/tr]
[tr]
[td]6[/td]
[td]

1.408.874.148​

[/td]
[td]

641.245.896​

[/td]
[td]

558.627.948​

[/td]
[/tr]
[/table]

As it turns out, there is not much difference. 2nd column has a grow rate of ~28.12, 3rd has ~27.35. It only has an impact for searches with >> 6 moves.

I am not entirely convinced you can start parallel-rotation pruning, universally, at depths 2 and 3. There are certain cases, which are handled by the Axis Rotation/Move Group implementation in the move generator you suggested. But a move sequence such as U u2 d should be allowed to proceed to the next iteration. However, U u2 d D2 should be disallowed at depth == 4, since it is the same position as u d2 D'.

I am implementing a pre-emptive retroactive cascade check through the prior 4 plies at every depth == 3 about to make a 4th move. So at depth == 3, I look to see if the next move is a 4th parallel rotation. At depth == 4, I check depths 1-3 and the move I am about to make @ 4, at depth == 5 I check depths 2-4 and the move I am about to make @5, etc.

It just bothers me that my program thought it was doing an 18-ply search when the first 4 plies recreated the starting position!

But, on the other hand, that could mean, if the only bug was in the database text output and NOT the actual positions in the database, then the single dedge flip has a solution < 18 plies.

The following are the moves that get pruned if they are generated in cascade:

 U  u  d' D' 
 U  u  d' D  
 U  u  d' D2 
 U  u  d  D' 
 U  u  d  D  
 U  u  d  D2 
 U  u  d2 D' 
 U  u  d2 D  
 U  u  d2 D2 
 U  u' d' D' 
 U  u' d' D  
 U  u' d' D2 
 U  u' d  D' 
 U  u' d  D  
 U  u' d  D2 
 U  u' d2 D' 
 U  u' d2 D  
 U  u' d2 D2 
 U  u2 d' D' 
 U  u2 d' D  
 U  u2 d' D2 
 U  u2 d  D' 
 U  u2 d  D  
 U  u2 d  D2 
 U  u2 d2 D' 
 U  u2 d2 D  
 U  u2 d2 D2 
 U' u  d' D' 
 U' u  d' D  
 U' u  d' D2 
 U' u  d  D' 
 U' u  d  D  
 U' u  d  D2 
 U' u  d2 D' 
 U' u  d2 D  
 U' u  d2 D2 
 U' u' d' D' 
 U' u' d' D  
 U' u' d' D2 
 U' u' d  D' 
 U' u' d  D  
 U' u' d  D2 
 U' u' d2 D' 
 U' u' d2 D  
 U' u' d2 D2 
 U' u2 d' D' 
 U' u2 d' D  
 U' u2 d' D2 
 U' u2 d  D' 
 U' u2 d  D  
 U' u2 d  D2 
 U' u2 d2 D' 
 U' u2 d2 D  
 U' u2 d2 D2 
 U2 u  d' D' 
 U2 u  d' D  
 U2 u  d' D2 
 U2 u  d  D' 
 U2 u  d  D  
 U2 u  d  D2 
 U2 u  d2 D' 
 U2 u  d2 D  
 U2 u  d2 D2 
 U2 u' d' D' 
 U2 u' d' D  
 U2 u' d' D2 
 U2 u' d  D' 
 U2 u' d  D  
 U2 u' d  D2 
 U2 u' d2 D' 
 U2 u' d2 D  
 U2 u' d2 D2 
 U2 u2 d' D' 
 U2 u2 d' D  
 U2 u2 d' D2 
 U2 u2 d  D' 
 U2 u2 d  D  
 U2 u2 d  D2 
 U2 u2 d2 D' 
 U2 u2 d2 D  
 U2 u2 d2 D2 
 R  r  l' L' 
 R  r  l' L  
 R  r  l' L2 
 R  r  l  L' 
 R  r  l  L  
 R  r  l  L2 
 R  r  l2 L' 
 R  r  l2 L  
 R  r  l2 L2 
 R  r' l' L' 
 R  r' l' L  
 R  r' l' L2 
 R  r' l  L' 
 R  r' l  L  
 R  r' l  L2 
 R  r' l2 L' 
 R  r' l2 L  
 R  r' l2 L2 
 R  r2 l' L' 
 R  r2 l' L  
 R  r2 l' L2 
 R  r2 l  L' 
 R  r2 l  L  
 R  r2 l  L2 
 R  r2 l2 L' 
 R  r2 l2 L  
 R  r2 l2 L2 
 R' r  l' L' 
 R' r  l' L  
 R' r  l' L2 
 R' r  l  L' 
 R' r  l  L  
 R' r  l  L2 
 R' r  l2 L' 
 R' r  l2 L  
 R' r  l2 L2 
 R' r' l' L' 
 R' r' l' L  
 R' r' l' L2 
 R' r' l  L' 
 R' r' l  L  
 R' r' l  L2 
 R' r' l2 L' 
 R' r' l2 L  
 R' r' l2 L2 
 R' r2 l' L' 
 R' r2 l' L  
 R' r2 l' L2 
 R' r2 l  L' 
 R' r2 l  L  
 R' r2 l  L2 
 R' r2 l2 L' 
 R' r2 l2 L  
 R' r2 l2 L2 
 R2 r  l' L' 
 R2 r  l' L  
 R2 r  l' L2 
 R2 r  l  L' 
 R2 r  l  L  
 R2 r  l  L2 
 R2 r  l2 L' 
 R2 r  l2 L  
 R2 r  l2 L2 
 R2 r' l' L' 
 R2 r' l' L  
 R2 r' l' L2 
 R2 r' l  L' 
 R2 r' l  L  
 R2 r' l  L2 
 R2 r' l2 L' 
 R2 r' l2 L  
 R2 r' l2 L2 
 R2 r2 l' L' 
 R2 r2 l' L  
 R2 r2 l' L2 
 R2 r2 l  L' 
 R2 r2 l  L  
 R2 r2 l  L2 
 R2 r2 l2 L' 
 R2 r2 l2 L  
 R2 r2 l2 L2 
 F  f  b' B' 
 F  f  b' B  
 F  f  b' B2 
 F  f  b  B' 
 F  f  b  B  
 F  f  b  B2 
 F  f  b2 B' 
 F  f  b2 B  
 F  f  b2 B2 
 F  f' b' B' 
 F  f' b' B  
 F  f' b' B2 
 F  f' b  B' 
 F  f' b  B  
 F  f' b  B2 
 F  f' b2 B' 
 F  f' b2 B  
 F  f' b2 B2 
 F  f2 b' B' 
 F  f2 b' B  
 F  f2 b' B2 
 F  f2 b  B' 
 F  f2 b  B  
 F  f2 b  B2 
 F  f2 b2 B' 
 F  f2 b2 B  
 F  f2 b2 B2 
 F' f  b' B' 
 F' f  b' B  
 F' f  b' B2 
 F' f  b  B' 
 F' f  b  B  
 F' f  b  B2 
 F' f  b2 B' 
 F' f  b2 B  
 F' f  b2 B2 
 F' f' b' B' 
 F' f' b' B  
 F' f' b' B2 
 F' f' b  B' 
 F' f' b  B  
 F' f' b  B2 
 F' f' b2 B' 
 F' f' b2 B  
 F' f' b2 B2 
 F' f2 b' B' 
 F' f2 b' B  
 F' f2 b' B2 
 F' f2 b  B' 
 F' f2 b  B  
 F' f2 b  B2 
 F' f2 b2 B' 
 F' f2 b2 B  
 F' f2 b2 B2 
 F2 f  b' B' 
 F2 f  b' B  
 F2 f  b' B2 
 F2 f  b  B' 
 F2 f  b  B  
 F2 f  b  B2 
 F2 f  b2 B' 
 F2 f  b2 B  
 F2 f  b2 B2 
 F2 f' b' B' 
 F2 f' b' B  
 F2 f' b' B2 
 F2 f' b  B' 
 F2 f' b  B  
 F2 f' b  B2 
 F2 f' b2 B' 
 F2 f' b2 B  
 F2 f' b2 B2 
 F2 f2 b' B' 
 F2 f2 b' B  
 F2 f2 b' B2 
 F2 f2 b  B' 
 F2 f2 b  B  
 F2 f2 b  B2 
 F2 f2 b2 B' 
 F2 f2 b2 B  
 F2 f2 b2 B2

 

[cuBerBruce]

However, U u2 d D2 should be disallowed at depth == 4, since it is the same position as u d2 D'.

These are the same position as long as you consider that the orientation of the cube doesn't matter. I didn't think you were doing that so far, but I could be wrong. If you consider that the orientation of the cube doesn't matter, then you should consider the solved cube in any of 24 orientation is still a solved cube. You may be able to consider only one orientation as solved if you do 24 separate searches with each search using a different orientation of the initial cube or a different orientation of the solved cube, but this seems inefficient to me.

Relating to the above, consider the simple scramble U u d'. This scramble should have a 1-move solution.

It just bothers me that my program thought it was doing a 18-ply search when the first 4 plies recreated the starting position!

Again, it does as long as you're considering the orientation of the cube doesn't matter.

then the single dedge flip has a solution < 18 plies.

It does have a solution of less than 18 plies. There is a well-known maneuver that is 15 moves long: r2 B2 U2 l U2 r' U2 r U2 F2 r F2 l' B2 r2. Any reduction state of an odd parity of edge pieces (aka OLL parity) is known to require at least 13 block turns (and 13 is also minimal for this situation for both single-slice turns and outer block turns). A reduction state is where the center pieces are solved (all 4 of each color are on a single face, and in the proper arrangement with respect to each other for the cube's color scheme) and all dedges are paired up.

The following are the moves that get pruned if they are generated in cascade:

I note that you are simply listing all possible 81 combinations of all 4 layers being turned for each of the 3 axes.

 

[unsolved]

These are the same position as long as you consider that the orientation of the cube doesn't matter. I didn't think you were doing that so far, but I could be wrong.

I am trying to implement this now, and am testing it.

If you consider that the orientation of the cube doesn't matter, then you should consider the solved cube in any of 24 orientation is still a solved cube. You may be able to consider only one orientation as solved if you do 24 separate searches with each search using a different orientation of the initial cube or a different orientation of the solved cube, but this seems inefficient to me.

The supercomputer at work I feed each of the 24 possible orientations, each to a different CPU. The move generators generate the same moves, just on each possible orientation. The solution then gets "translated" to a cube with UFR orientation during a solve. I don't have access to this over the weekend though, and am having enough trouble with version control for the array and bitboard move generators.

Relating to the above, consider the simple scramble U u d'. This scramble should have a 1-move solution.

Yes, I wholeheartedly agree! And, of course, my program handles such a case.

It does have a solution of less than 18 plies. There is a well-known maneuver that is 15 moves long: r2 B2 U2 l U2 r' U2 r U2 F2 r F2 l' B2 r2.

Now that is interesting. According to my broken version, there are at least two different 14-ply nuggets out there waiting to be found. It tripped over an 18-ply solution after playing U u d' D' first, which is.... grrrrrrrr.... makes me so mad! Anyway, it printed out the wrong PV due to that lingering bug that I think I have all tracked down now (ha! famous last words!)

Anyway, I have search extensions turned off for now, I want to see what the cumulative effect is of pruning out the "UuD'd' junk." I should have a version ready for testing in a few minutes, once I try one last thing.

I note that you are simply listing all possible 81 combinations of all 4 layers being turned for each of the 3 axes.

Is that what it was? I just turned on the pruner and had it scan depth == 4 and print out any PV that met my code's criteria for elimination. This is my first leaf node pruning algorithm, I will finally show non-zero results in my pruning variable that I print out!

Now you can see the prune counts through 7 plies. And this sheds some light on the mysterious bugs regarding the principal variations that hit some of the TFS databases. There are 178,605 nodes that have been pruned through ply 6. That means there are 178,605 positions in the TFS databases with duplicate turns-from-solved distances. And, worst of all, I solved them in an order that would have the most bloated solution with the highest count go about generating an index corresponding to a smaller number of moves in a solution already placed in the database.

I need to re-implement the TFS solver using the new pruning technique to eliminate those entries. Or, more accurately, never have included them in the first place.

UPDATE:

So now I cut the 6-TFS database down to 12 GB after avoiding all of the no-net-gain positions. I also changed the compression scheme so it averages exactly 20.01 bytes per position, better than before. And while I was waiting for the thing to run, I messed up one of my own 4x4x4 solves pretty bad. So I give it to the new version to try and test.

Top = white, front = red, right = blue, bottom = yellow, back = orange, left = green. Hold the cube with top-front-right facing you, and the solutions work.
With search extensions on, it finds a 14-ply solution for me, and it works, no problem!

 

[unsolved]

New Version With "Enter Scramble" Code

Thanks to Bruce for sharing his "enter scramble" code, I now have a version where you can test your own scrambles:

http://lightningcloudcomputing.com/OO_4x4x4.zip

Please enter scrambles longer than 6 moves if you are able to load the entire 6-TFS database into RAM.

And, can someone test these solutions out on a cube? Mine is a mess right now

EDIT: Use the scramble shown by the input arrow, not the one re-printed onto the screen. Fixed the "reprint scramble entered" bug, so if you have version 1.1.8 or later, this is fixed.

Nodes: The count of 4x4x4 positions generated by the program as it searches.

Leaf Nodes Pruned: The number of nodes (positions) that were filtered out before going to the next level. This reduces the size of the game tree. Bruce's program has excellent leaf node pruning right now.

Depth XX-YY: XX is the distance from the parent position that the move generator has reached. YY is the deepest search completed using the RAM-based databases.

TFS = "turns from solution." This is a number from 1 to 6 currently, and it measures the distance a cube position is from a solved state.

TFS Database Probes: This is a count of how many times the database was queried for ANY distance to solve: 1, 2, 3, 4, 5 and 6 (if you have 12 GB of RAM to load the 6-TFS database).

1-TFS Probes, 2-TFS Probes... 6-TFS Probes: These are individual counts of database queries only within the respective turns-from-solution.

TFS Database Misses: The counts all of the times the database was queried and DID NOT find a database entry.

Database Activity: The sum of all probes, misses, and leaf node prunes

Solution (with arrow): The first solution at an improved solving distance. Other solutions of EQUAL distance will be shown. If the distance ever improves (gets less) then only the shortest distances will be reported from that point forward.

[Inside X-TFS] --->: Moves to the left of the bracket are from the move generator. Moves to the right of the arrow come from the RAM-database. "X" is the distance measure of the database that was probed.

 

[cuBerBruce]

I have tried running this program on my computer which has 12 GB RAM. It tries to create the TFS database, but apparently tries to allocate so much memory the computer becomes almost totally unresponsive except for some ability to move the mouse around some of the time. Trying to terminate the process from the Task Manager can take several minutes (no exaggeration) before the confirmation popup appears.

I will not try downloading another version of this program unless I have the ability to force what size TFS database to use, or have the ability to limit how much memory it will be allowed to allocate.

 

[unsolved]

I have tried running this program on my computer which has 12 GB RAM. It tries to create the TFS database, but apparently tries to allocate so much memory the computer becomes almost totally unresponsive except for some ability to move the mouse around some of the time. Trying to terminate the process from the Task Manager can take several minutes (no exaggeration) before the confirmation popup appears.

I will not try downloading another version of this program unless I have the ability to force what size TFS database to use, or have the ability to limit how much memory it will be allowed to allocate.

Here is a 5-TFS only version of the program. Requires 450 MB.

http://lightningcloudcomputing.com/4x4x4_5.zip

The program checks to see if the OS grants a request to "malloc()" memory. If you are using Virtual Memory and don't have actual RAM available, that can be a bad thing for any high performance piece of software.
I've run 2 instances of my 6-TFS on this machine at the same time with no problems, then loaded another copy of it, and it automatically switched to the 5-TFS load. There is also a 4-TFS only load if that fails.

I suggest a clean reboot and running it all alone if you have a machine with 16 GB or more. Who knows how much the OS is grabbing or what other background task might be stealing.

UPDATE: I am working on a new version with more options at startup for you Bruce:

I'll let you know when it is online.

 

[Carrot]

Solution to 4x4x4 cube Scramble = r2 U2 r2 u2 U2 r2 u2 L2 R2 

TOP                     FRONT                   RIGHT
---------------------   ---------------------   ---------------------
|~~~~|####|####|~~~~|   |&&&&|&&&&|&&&&|&&&&|   |XXXX|XXXX|XXXX|XXXX|
---------------------   ---------------------   ---------------------
|~~~~|####|####|~~~~|   |&&&&|OOOO|OOOO|&&&&|   |XXXX|XXXX|XXXX|XXXX|
---------------------   ---------------------   ---------------------
|~~~~|####|####|~~~~|   |&&&&|OOOO|OOOO|&&&&|   |XXXX|XXXX|XXXX|XXXX|
---------------------   ---------------------   ---------------------
|~~~~|####|####|~~~~|   |&&&&|OOOO|OOOO|&&&&|   |XXXX|XXXX|XXXX|XXXX|
---------------------   ---------------------   ---------------------


BOTTOM                  BACK                    LEFT
---------------------   ---------------------   ---------------------
|####|~~~~|~~~~|####|   |OOOO|OOOO|OOOO|OOOO|   |^^^^|^^^^|^^^^|^^^^|
---------------------   ---------------------   ---------------------
|####|~~~~|~~~~|####|   |OOOO|&&&&|&&&&|OOOO|   |^^^^|^^^^|^^^^|^^^^|
---------------------   ---------------------   ---------------------
|####|~~~~|~~~~|####|   |OOOO|&&&&|&&&&|OOOO|   |^^^^|^^^^|^^^^|^^^^|
---------------------   ---------------------   ---------------------
|####|~~~~|~~~~|####|   |OOOO|&&&&|&&&&|OOOO|   |^^^^|^^^^|^^^^|^^^^|
---------------------   ---------------------   ---------------------



Solution [001] =  u2 R2 l2 [inside 6-TFS] ---> L2 D2 d2 r2 D2 l2  @ 0000000004692 nodes with 0000000061918 6-TFS probes 
...
Solution [065] =  L2 d2 l2 [inside 6-TFS] ---> U2 l2 U2 l2 d2 R2  @ 0000000018795 nodes with 0000000212901 6-TFS probes   
** Search completed. **

****** PICTURE WAS MISSING!!!! AND SCRAMBLE!!!!! *****
→ u l f r d b u' l' f' r' d' b'

 TOP                     FRONT                   RIGHT
 ---------------------   ---------------------   ---------------------
 |####|####|####|####|   |OOOO|OOOO|OOOO|OOOO|   |XXXX|XXXX|XXXX|XXXX|
 ---------------------   ---------------------   ---------------------
 |####|OOOO|OOOO|####|   |OOOO|XXXX|~~~~|OOOO|   |XXXX|&&&&|XXXX|XXXX|
 ---------------------   ---------------------   ---------------------
 |####|####|^^^^|####|   |OOOO|XXXX|OOOO|OOOO|   |XXXX|~~~~|####|XXXX|
 ---------------------   ---------------------   ---------------------
 |####|####|####|####|   |OOOO|OOOO|OOOO|OOOO|   |XXXX|XXXX|XXXX|XXXX|
 ---------------------   ---------------------   ---------------------


 BOTTOM                  BACK                    LEFT
 ---------------------   ---------------------   ---------------------
 |~~~~|~~~~|~~~~|~~~~|   |&&&&|&&&&|&&&&|&&&&|   |^^^^|^^^^|^^^^|^^^^|
 ---------------------   ---------------------   ---------------------
 |~~~~|~~~~|XXXX|~~~~|   |&&&&|####|^^^^|&&&&|   |^^^^|^^^^|OOOO|^^^^|
 ---------------------   ---------------------   ---------------------
 |~~~~|&&&&|&&&&|~~~~|   |&&&&|&&&&|^^^^|&&&&|   |^^^^|~~~~|####|^^^^|
 ---------------------   ---------------------   ---------------------
 |~~~~|~~~~|~~~~|~~~~|   |&&&&|&&&&|&&&&|&&&&|   |^^^^|^^^^|^^^^|^^^^|
 ---------------------   ---------------------   ---------------------

Solution [066] =  d' l  d2 f  b' [inside 6-TFS] ---> d' u  l' f' u' b   @ 0000004416550 nodes with 0000058015996 6-TFS probes   
... 
Solution [073] =  b  d  r  b' l2 [inside 6-TFS] ---> f' d' f2 r' f' l2  @ 0000020149482 nodes with 0000230714530 6-TFS probes   
** Search completed. **

Worked for me

 

[unsolved]

Worked for me[/QUOTE]

Wow, did it really find 73 solutions?

 

[Carrot]

Wow, did it really find 73 solutions?

obviously it's 2 different cases.

but I have a few questions:
"However, due to the very large branching factor there
is a limit to its horizon of approximately 12 turns on a slow computer, 13 turns on a fairly fast system & 14
turns on a top-of-the-line computer. I have access to hardware at my office that can find 16-turn solutions."

How fast is it supposed to find those 12, 13 and 14 move solutions? like a day? xD



Whenever I input a sequence it will obviously load it and everything seems fine, just until I load the next scramble, because then it applies that AFTER the end of the previous scramble, but it still works. So I figured, I can just reset it by entering the solutions it found. which also works, and then I enter the new sequence, which also works. it does indeed find the solutions, but that's it, it just finds them, it doesn't actually output. and after this it refuses to output solutions (in both the prompt and the file)
I can obviously reset all these bugs by just re-opening, but given that takes 3:30 on average it is maybe not the best solution

 

[unsolved]

obviously it's 2 different cases.

This is what I get when I run it:

Solutions To Scramble = u l' f r d' b' u' l f' r' d b 

TOP                     FRONT                   RIGHT
---------------------   ---------------------   ---------------------
|####|####|####|####|   |OOOO|OOOO|OOOO|OOOO|   |XXXX|XXXX|XXXX|XXXX|
---------------------   ---------------------   ---------------------
|####|OOOO|OOOO|####|   |OOOO|XXXX|~~~~|OOOO|   |XXXX|&&&&|XXXX|XXXX|
---------------------   ---------------------   ---------------------
|####|####|^^^^|####|   |OOOO|XXXX|OOOO|OOOO|   |XXXX|~~~~|####|XXXX|
---------------------   ---------------------   ---------------------
|####|####|####|####|   |OOOO|OOOO|OOOO|OOOO|   |XXXX|XXXX|XXXX|XXXX|
---------------------   ---------------------   ---------------------


BOTTOM                  BACK                    LEFT
---------------------   ---------------------   ---------------------
|~~~~|~~~~|~~~~|~~~~|   |&&&&|&&&&|&&&&|&&&&|   |^^^^|^^^^|^^^^|^^^^|
---------------------   ---------------------   ---------------------
|~~~~|~~~~|XXXX|~~~~|   |&&&&|####|^^^^|&&&&|   |^^^^|^^^^|OOOO|^^^^|
---------------------   ---------------------   ---------------------
|~~~~|&&&&|&&&&|~~~~|   |&&&&|&&&&|^^^^|&&&&|   |^^^^|~~~~|####|^^^^|
---------------------   ---------------------   ---------------------
|~~~~|~~~~|~~~~|~~~~|   |&&&&|&&&&|&&&&|&&&&|   |^^^^|^^^^|^^^^|^^^^|
---------------------   ---------------------   ---------------------



Solution [001] =  d' l  d2 f  b' [inside 6-TFS] ---> d' u  l' f' u' b   @ 0000004416550 nodes with 0000057691095 6-TFS probes   
Solution [002] =  r2 l  f' l2 d2 [inside 6-TFS] ---> r  d' f  l  d' r   @ 0000011424132 nodes with 0000134693534 6-TFS probes   
Solution [003] =  r2 l2 f' l  d  [inside 6-TFS] ---> r  f  l' d' l2 r   @ 0000011445380 nodes with 0000134924652 6-TFS probes   
Solution [004] =  l  u  l2 d' l  [inside 6-TFS] ---> d  b  r  b' u' r'  @ 0000012466208 nodes with 0000146133299 6-TFS probes   
Solution [005] =  l  u  l2 b  r  [inside 6-TFS] ---> b' d' l  d  u' r'  @ 0000012466654 nodes with 0000146137179 6-TFS probes   
Solution [006] =  l  u  b  r  b' [inside 6-TFS] ---> l2 d' l  d  u' r'  @ 0000012475330 nodes with 0000146230770 6-TFS probes   
Solution [007] =  b' l' u2 l' f2 [inside 6-TFS] ---> u' l2 b2 f2 u' b'  @ 0000019799598 nodes with 0000226557067 6-TFS probes   
Solution [008] =  b  d  r  b' l2 [inside 6-TFS] ---> f' d' f2 r' f' l2  @ 0000020149482 nodes with 0000230389629 6-TFS probes   
** Search completed. **

but I have a few questions:
"However, due to the very large branching factor there
is a limit to its horizon of approximately 12 turns on a slow computer, 13 turns on a fairly fast system & 14
turns on a top-of-the-line computer. I have access to hardware at my office that can find 16-turn solutions."

How fast is it supposed to find those 12, 13 and 14 move solutions? like a day? xD

Well, it used to take the program about an hour to find an 8-ply solution, but it has made a fair amount of progress. If I ever figure out the corner orientation code (which is giving me fits!) the program will be able to reach about 5-7 plies deeper, getting close to 20 plies.

Whenever I input a sequence it will obviously load it and everything seems fine, just until I load the next scramble, because then it applies that AFTER the end of the previous scramble, but it still works. So I figured, I can just reset it by entering the solutions it found. which also works, and then I enter the new sequence, which also works. it does indeed find the solutions, but that's it, it just finds them, it doesn't actually output. and after this it refuses to output solutions (in both the prompt and the file)
I can obviously reset all these bugs by just re-opening, but given that takes 3:30 on average it is maybe not the best solution

Yeah, somewhere I am missing a re-initialization of the search parameters. All I need to do is add one line of code to fix this. Thanks for letting me know, I'll start on that now.

 

[Carrot]

.. above post..

Ohh ya I forgot: it reads the sequences you input correctly, but stores the moves wrong, so the scramble you see in the file was not the scramble it actually solved.

the original scramble it had to solve was: u l f r d b u' l' f' r' d' b'

 

[cuBerBruce]

If I ever figure out the corner orientation code (which is giving me fits!) the program will be able to reach about 5-7 plies deeper, getting close to 20 plies.

Corner pruning will allow pruning about 9-10 moves from solved. You are (in effect) pruning 6 moves from solved right now with your 6-TFS database. So with corner pruning you will only be getting about 4 moves deeper, not 5-7. Maybe deeper if you're also considering edge pairing combined with corner configuration.

 

[unsolved]

Ohh ya I forgot: it reads the sequences you input correctly, but stores the moves wrong, so the scramble you see in the file was not the scramble it actually solved.

the original scramble it had to solve was: u l f r d b u' l' f' r' d' b'

I think it only draws U' when the input is U, and U when the input is U'. I fixed that bug now (still did not upload it but will later on).

Also, I fixed the "keeps scrambling from the previous scramble" bug.

Thanks for your feedback, it has been very helpful!

Corner pruning will allow pruning about 9-10 moves from solved. You are (in effect) pruning 6 moves from solved right now with your 6-TFS database. So with corner pruning you will only be getting about 4 moves deeper, not 5-7. Maybe deeper if you're also considering edge pairing combined with corner configuration.

Yes, but the program will be able to prune 6 moves from whatever position it reaches. If the corner pruning extends 9-10, I am wondering if TFS would be purely additive and extend that to 15-16?

 

[qqwref]

I don't think the pruning is additive in this case. Given a position far from solved, your 6-TFS table tells you if it cannot be solved in les than 7 moves, and the corner pruning table tells you (maybe) if it cannot be solved in less than about 9-10 moves. You can only add the two if you want to apply every 6-move sequence to the position and then check THAT against the corner pruning table.

 

[unsolved]

I don't think the pruning is additive in this case. Given a position far from solved, your 6-TFS table tells you if it cannot be solved in les than 7 moves, and the corner pruning table tells you (maybe) if it cannot be solved in less than about 9-10 moves. You can only add the two if you want to apply every 6-move sequence to the position and then check THAT against the corner pruning table.

Very true.

But look at my node counts when I miss the TFS databases: they are huge.

Now, imagine Bruce's node counts for the same nominal depths (very small) and then speculate what would happen if you could apply the 6-TFS on top of that.

You would not "get deeper" by virtue of the two disjoint pruning methods acting as if they are the same type of mechanism, but you would get deeper via probing a much smaller tree! Even my slowest move generator (array-based laden with the 12 GB 6-TFS being probed heavily) can average 40,000,000 turns per second.

Some of Bruce's postings don't even have 40,000,000 nodes total! So that means if I pruned the leaf nodes as heavily, OO_4x4x4 would reach the same conclusion in less than one second. Of course this operates under the conjecture that there is 0-overhead for the leaf node pruner, which is not the case, but it would be minimal.

UPDATE: Version 1.2.1 now online

http://lightningcloudcomputing.com/OO_4x4x4.zip

The newest version of OO_4x4x4 has the following features:

1. The new Memory Menu (above) recommended by Bruce has been implemented and heavily tested. As you can see, the program differentiates from Bill Gate's absurd assumption that Virtual RAM is just as good as Physical RAM when it comes to trying to load a program under Windows. I now look at the Physical RAM that is available, and recommend options based on that. If you have less Physical RAM than any TFS database would need for a 100% loading factor, you don't even have the option to try and access it. You could always down-step though.

2. The Principal Variation bug was located, taken out back, and shot. Hopefully, it will remain dead. Please test this and let me know! It was a "conversion" issue that arose from (again, Bruce being a big help here) the fact that the moves were entered into the database in the order they were generated, and the position is being identified during a search. Well, the moves you made to create the position are really not of interest! What is of great help though, are the moves to make in order to solve the cube. The issue was complicated by the fact that any database also contains every smaller database within the same RAM cluster. So, when the 6-TFS database finds a solution with 5 moves, it would attempt to "convert" the 6th move and show it first in the PV, then convert the 5th move and show it second (which is normal when you flip the entire move order from scramble to solve), and so on. The problem is, in this case, there was no 6th move, it was a 5-move solution! This was also the case for a 4-mover inside 6-TFS, a 3-mover, etc., as well as 4-movers inside 5-TFS, 3-movers inside 5-TFS .... all the way down to 1 movers inside 2-TFS. This took a re-coding effort to fully purge.

3. The Enter Scramble bug seems to have gone away after some shotgun style coding. I am not 100% convinced it is gone for good. Test multiple scrambles of different sorts, and see if you get all correct solutions for everything OO_4x4x4 throws out there. Let me know if you find a bug, I will smack it silly if I can locate it.

So this is the most stable version so far. Thanks for all of the debugging help to all of those who have contributed.

P.S. I pronounce the nickname of the program as "Oh Oh 4 by 4 by 4" if anyone actually cares

 

[cuBerBruce]

Now, imagine Bruce's node counts for the same nominal depths (very small) and then speculate what would happen if you could apply the 6-TFS on top of that.

You need to understand that the pruning is based upon the solution length that is currently being sought. If I'm seeking a solution of length n, and I reach a node at depth n from the scramble position, then I merely need to check if that node represents a solved cube. Now I could look up that position in a "TFS" database if I have one, to see if that position that I've reached is within 6 moves from solved. The problem with this is that if the optimal solution is actually n + 6 moves, then I likely may have already pruned the branch containing the optimal solution too early, because my pruning decisions were been based upon finding a solution of length n, not for a length n + 6. If you don't want to miss a solution of length n + 6, your pruning decision must be based upon finding a solution of length n + 6. And if you base your pruning on finding of length n + 6, you will have less pruning at shorter depths from the scramble position than if your pruning had been based upon finding a solution of length n.

 

[unsolved]

You need to understand that the pruning is based upon the solution length that is currently being sought. If I'm seeking a solution of length n, and I reach a node at depth n from the scramble position, then I merely need to check if that node represents a solved cube.

And I do

My thinking was to prune for the sake of thinning out the tree, forgetting the fact a hypothetical TFS database exists. At depth 0 of the very first search, and for the root position only, apply the TFS check one time just to see if you are within a 6-ply radius of being done before you even start. If not, use the leaf node pruning mechanism to thin out the game tree for the remainder of all searches. Only apply the TFS query to the nodes that pass through your pruning check. Any such position, by definition, must require more than (terminal depth - current depth) moves to solve, since even the corner state with the rest of the cube in immaculate condition could not be solved in fewer than that number of moves.

You get the best of both worlds. You won't misevaluate any obvious quick solutions, and by thinning out the game tree, you make the TFS much more effective at finding truly lengthy solves.

 

[cuBerBruce]

My thinking was to prune for the sake of thinning out the tree, forgetting the fact a hypothetical TFS database exists. At depth 0 of the very first search, and for the root position only, apply the TFS check one time just to see if you are within a 6-ply radius of being done before you even start. If not, use the leaf node pruning mechanism to thin out the game tree for the remainder of all searches. Only apply the TFS query to the nodes that pass through your pruning check. Any such position, by definition, must require more than (terminal depth - current depth) moves to solve, since even the corner state with the rest of the cube in immaculate condition could not be solved in fewer than that number of moves.

Let's say you have a "TFS" database of depth 6. Let's say you are currently looking for a solution of length 14, having previously guaranteed no solution of length 13 exists. Then we know we don't have to check the TFS database until we've reached a depth of 8 moves from the scramble position. The TFS database will then tell us whether or not we can reach a solution of distance 14 from this search branch. But to be sure we haven't pruned away a good branch up to this point, we must have been making pruning decisions based upon a desired solution length of 14, not 8. This generally makes a big difference in how much pruning you can do.

For instance, let's say your best pruning table can only guarantee (at best) a position being at least 11 moves from solved. Then you will not be able to do any pruning at all until you're at least 4 moves from the scramble position. (Technically there may be tricks that might allow pruning at only 3 moves out in this case, but I'll ignore that for now.) At 4 moves out, if the pruning table tells you that you're at least 11 moves from solved, then you know you're not going to get a solution < 15 moves on this branch, and that is larger than your current goal of 14. So you might be able to get some pruning at 4 moves away from your scramble.

If we were doing pruning based upon a goal of 8 moves, we likely might find out right off that we're 9, 10, or 11 moves away from solved, and not have to generate any nodes at all. But this does not guarantee we're at least 15 moves from solved so we could be pruning away a good branch if we did this. Having the TFS database basically does us no good at all until we're out far enough from the scramble position to have a chance at hitting a database position.

You get the best of both worlds. You won't misevaluate any obvious quick solutions, and by thinning out the game tree, you make the TFS much more effective at finding truly lengthy solves.

You can look at the TFS database as being just another pruning table - "perfect" for when you're at position within its depth, and basically not useful beyond that. But it generally requires a lot of memory for what you get from it. Most solvers use a smaller pruning table for pruning at shallow depths without using up a huge amount of memory. This can get you close to the same pruning quality and save a lot of memory. This is why such TFS databases aren't generally used.

EDIT (appending):
I've been using the 5-TFS version to search for O-Perm solutions for about a day. I knew there existed a 13-move solution, so I knew it would not have to search deeper than that. The spoiler has my results so far.

Spoiler

 →Solution [170] =  u2 r2 U2 r2 b2 U' u2 b2 [inside 5-TFS] ---> r2 U  b2 U2 r2  @ 0083747294322 nodes with 1113921230625 5-TFS probes
  Solution [171] =  u2 r2 U2 r2 b2 U' r2 b2 [inside 5-TFS] ---> U  b2 U2 r2 u2  @ 0083747294664 nodes with 1113921234958 5-TFS probes
  Solution [172] =  u2 r2 U2 r2 b2 U' b2 r2 [inside 5-TFS] ---> U  b2 U2 r2 u2  @ 0083747295081 nodes with 1113921239047 5-TFS probes
  Solution [173] =  u2 r2 U2 r2 b2 D' r2 f2 [inside 5-TFS] ---> D  b2 U2 r2 u2  @ 0083747301051 nodes with 1113921299992 5-TFS probes
  Solution [174] =  u2 r2 U2 r2 b2 D' f2 r2 [inside 5-TFS] ---> D  b2 U2 r2 u2  @ 0083747301387 nodes with 1113921303658 5-TFS probes
  Solution [175] =  u2 r2 U2 f2 U  r2 u2 f2 [inside 5-TFS] ---> U' f2 r2 U2 r2  @ 0083754318918 nodes with 1113997133485 5-TFS probes
  Solution [176] =  u2 r2 U2 f2 U  r2 f2 U' [inside 5-TFS] ---> f2 r2 U2 r2 u2  @ 0083754319391 nodes with 1113997138019 5-TFS probes
  Solution [177] =  u2 r2 U2 f2 U  f2 r2 U' [inside 5-TFS] ---> f2 r2 U2 r2 u2  @ 0083754328850 nodes with 1113997242654 5-TFS probes
  Solution [178] =  u2 r2 U2 f2 D  r2 b2 D' [inside 5-TFS] ---> f2 r2 U2 r2 u2  @ 0083754544447 nodes with 1113999588875 5-TFS probes
  Solution [179] =  u2 r2 U2 f2 D  b2 r2 D' [inside 5-TFS] ---> f2 r2 U2 r2 u2  @ 0083754556171 nodes with 1113999720171 5-TFS probes
  Solution [180] =  u2 r2 u2 f2 U  r2 U2 f2 [inside 5-TFS] ---> U' f2 U2 r2 f2  @ 0083810148564 nodes with 1114600320056 5-TFS probes
  Solution [181] =  u2 r2 u2 f2 U  r2 D2 b2 [inside 5-TFS] ---> U' b2 D2 r2 f2  @ 0083810148810 nodes with 1114600322673 5-TFS probes
  Solution [182] =  u2 r2 u2 f2 U' f2 U2 r2 [inside 5-TFS] ---> U  f2 U2 r2 f2  @ 0083810184192 nodes with 1114600701781 5-TFS probes
  Solution [183] =  u2 r2 D2 l2 f2 U' l2 f2 [inside 5-TFS] ---> U  f2 D2 r2 u2  @ 0083900882406 nodes with 1115580379071 5-TFS probes
  Solution [184] =  u2 r2 D2 l2 f2 U' f2 l2 [inside 5-TFS] ---> U  f2 D2 r2 u2  @ 0083900882664 nodes with 1115580382325 5-TFS probes
  Solution [185] =  u2 r2 D2 l2 f2 D' l2 b2 [inside 5-TFS] ---> D  f2 D2 r2 u2  @ 0083900888799 nodes with 1115580448514 5-TFS probes
  Solution [186] =  u2 r2 D2 l2 f2 D' b2 l2 [inside 5-TFS] ---> D  f2 D2 r2 u2  @ 0083900889138 nodes with 1115580452852 5-TFS probes
  Solution [187] =  u2 r2 D2 b2 U  l2 b2 U' [inside 5-TFS] ---> b2 l2 D2 r2 u2  @ 0083908039331 nodes with 1115657726602 5-TFS probes
  Solution [188] =  u2 r2 D2 b2 U  b2 l2 U' [inside 5-TFS] ---> b2 l2 D2 r2 u2  @ 0083908048871 nodes with 1115657829165 5-TFS probes
  Solution [189] =  u2 r2 D2 b2 D  l2 f2 D' [inside 5-TFS] ---> b2 l2 D2 r2 u2  @ 0083908264219 nodes with 1115660138632 5-TFS probes
  Solution [190] =  u2 r2 D2 b2 D  f2 l2 D' [inside 5-TFS] ---> b2 l2 D2 r2 u2  @ 0083908271494 nodes with 1115660214473 5-TFS probes
  Solution [191] =  u2 r2 f2 U  r2 U2 f2 U' [inside 5-TFS] ---> f2 U2 r2 f2 u2  @ 0084105544976 nodes with 1117791755364 5-TFS probes
  Solution [192] =  u2 r2 f2 U  r2 D2 b2 U' [inside 5-TFS] ---> b2 D2 r2 f2 u2  @ 0084105551891 nodes with 1117791829576 5-TFS probes
  Solution [193] =  u2 r2 f2 U' f2 U2 u2 r2 [inside 5-TFS] ---> U  f2 U2 r2 f2  @ 0084106546434 nodes with 1117802579851 5-TFS probes
  Solution [194] =  u2 r2 f2 U' f2 U2 r2 U  [inside 5-TFS] ---> f2 U2 r2 f2 u2  @ 0084106546765 nodes with 1117802583769 5-TFS probes
  Solution [195] =  u2 r2 f2 U' f2 D2 l2 U  [inside 5-TFS] ---> b2 D2 r2 f2 u2  @ 0084106553680 nodes with 1117802660632 5-TFS probes
  Solution [196] =  u2 r2 f2 U2 r2 U  u2 f2 [inside 5-TFS] ---> U2 r2 U' r2 f2  @ 0084107006292 nodes with 1117807541810 5-TFS probes
  Solution [197] =  u2 r2 f2 U2 r2 U  f2 U2 [inside 5-TFS] ---> r2 U' r2 f2 u2  @ 0084107006955 nodes with 1117807548487 5-TFS probes
  Solution [198] =  u2 r2 f2 U2 r2 U' u2 r2 [inside 5-TFS] ---> U2 f2 U  r2 f2  @ 0084107007207 nodes with 1117807551312 5-TFS probes
  Solution [199] =  u2 r2 f2 U2 r2 U' r2 U2 [inside 5-TFS] ---> f2 U  r2 f2 u2  @ 0084107007540 nodes with 1117807554827 5-TFS probes
  Solution [200] =  u2 r2 f2 U2 r2 D' f2 U2 [inside 5-TFS] ---> l2 D  r2 f2 u2  @ 0084107014272 nodes with 1117807624558 5-TFS probes
  Solution [201] =  u2 r2 f2 U2 r2 D  r2 U2 [inside 5-TFS] ---> b2 D' r2 f2 u2  @ 0084107014614 nodes with 1117807628116 5-TFS probes
  Solution [202] =  u2 r2 f2 D' l2 U2 f2 D  [inside 5-TFS] ---> f2 U2 r2 f2 u2  @ 0084111395453 nodes with 1117854904425 5-TFS probes
  Solution [203] =  u2 r2 f2 D' l2 D2 b2 D  [inside 5-TFS] ---> b2 D2 r2 f2 u2  @ 0084111402368 nodes with 1117854981490 5-TFS probes
  Solution [204] =  u2 r2 f2 D  b2 U2 u2 r2 [inside 5-TFS] ---> D' f2 U2 r2 f2  @ 0084112205418 nodes with 1117863676903 5-TFS probes
  Solution [205] =  u2 r2 f2 D  b2 U2 r2 D' [inside 5-TFS] ---> f2 U2 r2 f2 u2  @ 0084112205758 nodes with 1117863680958 5-TFS probes
  Solution [206] =  u2 r2 f2 D  b2 D2 l2 D' [inside 5-TFS] ---> b2 D2 r2 f2 u2  @ 0084112212673 nodes with 1117863755903 5-TFS probes
  Solution [207] =  u2 r2 f2 D2 l2 U  b2 D2 [inside 5-TFS] ---> r2 U' r2 f2 u2  @ 0084112474548 nodes with 1117866578932 5-TFS probes
  Solution [208] =  u2 r2 f2 D2 l2 U' l2 D2 [inside 5-TFS] ---> f2 U  r2 f2 u2  @ 0084112475133 nodes with 1117866585636 5-TFS probes
  Solution [209] =  u2 r2 f2 D2 l2 D' b2 D2 [inside 5-TFS] ---> l2 D  r2 f2 u2  @ 0084112481865 nodes with 1117866655723 5-TFS probes
  Solution [210] =  u2 r2 f2 D2 l2 D  l2 D2 [inside 5-TFS] ---> b2 D' r2 f2 u2  @ 0084112482207 nodes with 1117866659746 5-TFS probes
  Solution [211] =  u2 l2 U2 l2 f2 U' u2 l2 [inside 5-TFS] ---> f2 U  f2 U2 l2  @ 0085217765070 nodes with 1129809640428 5-TFS probes
  Solution [212] =  u2 l2 U2 l2 f2 U' u2 f2 [inside 5-TFS] ---> l2 U  f2 U2 l2  @ 0085217765079 nodes with 1129809640582 5-TFS probes
  Solution [213] =  u2 l2 U2 l2 f2 U' l2 f2 [inside 5-TFS] ---> U  f2 U2 l2 u2  @ 0085217765502 nodes with 1129809645236 5-TFS probes
  Solution [214] =  u2 l2 U2 l2 f2 U' f2 l2 [inside 5-TFS] ---> U  f2 U2 l2 u2  @ 0085217765760 nodes with 1129809648592 5-TFS probes
  Solution [215] =  u2 l2 U2 l2 f2 D' l2 b2 [inside 5-TFS] ---> D  f2 U2 l2 u2  @ 0085217771895 nodes with 1129809713006 5-TFS probes
  Solution [216] =  u2 l2 U2 l2 f2 D' b2 l2 [inside 5-TFS] ---> D  f2 U2 l2 u2  @ 0085217772234 nodes with 1129809716896 5-TFS probes
  Solution [217] =  u2 l2 U2 b2 U  l2 u2 b2 [inside 5-TFS] ---> U' b2 l2 U2 l2  @ 0085224921954 nodes with 1129887027383 5-TFS probes
  Solution [218] =  u2 l2 U2 b2 U  l2 b2 U' [inside 5-TFS] ---> b2 l2 U2 l2 u2  @ 0085224922427 nodes with 1129887033344 5-TFS probes
  Solution [219] =  u2 l2 U2 b2 U  b2 l2 U' [inside 5-TFS] ---> b2 l2 U2 l2 u2  @ 0085224931967 nodes with 1129887138228 5-TFS probes
  Solution [220] =  u2 l2 U2 b2 D  l2 f2 D' [inside 5-TFS] ---> b2 l2 U2 l2 u2  @ 0085225147315 nodes with 1129889463734 5-TFS probes
  Solution [221] =  u2 l2 U2 b2 D  f2 l2 D' [inside 5-TFS] ---> b2 l2 U2 l2 u2  @ 0085225154590 nodes with 1129889542322 5-TFS probes
  Solution [222] =  u2 l2 u2 b2 U  l2 U2 b2 [inside 5-TFS] ---> U' b2 U2 l2 b2  @ 0085280751600 nodes with 1130490262796 5-TFS probes
  Solution [223] =  u2 l2 u2 b2 U  l2 D2 f2 [inside 5-TFS] ---> U' f2 D2 l2 b2  @ 0085280751840 nodes with 1130490264951 5-TFS probes
  Solution [224] =  u2 l2 u2 b2 U' b2 U2 l2 [inside 5-TFS] ---> U  b2 U2 l2 b2  @ 0085280787228 nodes with 1130490650817 5-TFS probes
  Solution [225] =  u2 l2 D2 r2 b2 U' r2 b2 [inside 5-TFS] ---> U  b2 D2 l2 u2  @ 0085367896656 nodes with 1131432103264 5-TFS probes
  Solution [226] =  u2 l2 D2 r2 b2 U' b2 r2 [inside 5-TFS] ---> U  b2 D2 l2 u2  @ 0085367897073 nodes with 1131432107167 5-TFS probes
  Solution [227] =  u2 l2 D2 r2 b2 D' r2 f2 [inside 5-TFS] ---> D  b2 D2 l2 u2  @ 0085367903043 nodes with 1131432171310 5-TFS probes
  Solution [228] =  u2 l2 D2 r2 b2 D' f2 r2 [inside 5-TFS] ---> D  b2 D2 l2 u2  @ 0085367903379 nodes with 1131432175499 5-TFS probes
  Solution [229] =  u2 l2 D2 f2 U  r2 f2 U' [inside 5-TFS] ---> f2 r2 D2 l2 u2  @ 0085374921383 nodes with 1131507934912 5-TFS probes
  Solution [230] =  u2 l2 D2 f2 U  f2 r2 U' [inside 5-TFS] ---> f2 r2 D2 l2 u2  @ 0085374930842 nodes with 1131508042038 5-TFS probes
  Solution [231] =  u2 l2 D2 f2 D  r2 b2 D' [inside 5-TFS] ---> f2 r2 D2 l2 u2  @ 0085375146439 nodes with 1131510379984 5-TFS probes
  Solution [232] =  u2 l2 D2 f2 D  b2 r2 D' [inside 5-TFS] ---> f2 r2 D2 l2 u2  @ 0085375158163 nodes with 1131510507608 5-TFS probes
  Solution [233] =  u2 l2 b2 U  l2 U2 b2 U' [inside 5-TFS] ---> b2 U2 l2 b2 u2  @ 0085576148012 nodes with 1133681479203 5-TFS probes
  Solution [234] =  u2 l2 b2 U  l2 D2 f2 U' [inside 5-TFS] ---> f2 D2 l2 b2 u2  @ 0085576154759 nodes with 1133681550673 5-TFS probes
  Solution [235] =  u2 l2 b2 U' b2 U2 u2 l2 [inside 5-TFS] ---> U  b2 U2 l2 b2  @ 0085577149389 nodes with 1133692283704 5-TFS probes
  Solution [236] =  u2 l2 b2 U' b2 U2 l2 U  [inside 5-TFS] ---> b2 U2 l2 b2 u2  @ 0085577149801 nodes with 1133692288053 5-TFS probes
  Solution [237] =  u2 l2 b2 U' b2 D2 r2 U  [inside 5-TFS] ---> f2 D2 l2 b2 u2  @ 0085577156548 nodes with 1133692364284 5-TFS probes
  Solution [238] =  u2 l2 b2 U2 l2 U  u2 b2 [inside 5-TFS] ---> U2 l2 U' l2 b2  @ 0085577609247 nodes with 1133697254688 5-TFS probes
  Solution [239] =  u2 l2 b2 U2 l2 U  b2 U2 [inside 5-TFS] ---> l2 U' l2 b2 u2  @ 0085577609991 nodes with 1133697262885 5-TFS probes
  Solution [240] =  u2 l2 b2 U2 l2 U' u2 l2 [inside 5-TFS] ---> U2 b2 U  l2 b2  @ 0085577610162 nodes with 1133697264536 5-TFS probes
  Solution [241] =  u2 l2 b2 U2 l2 U' l2 U2 [inside 5-TFS] ---> b2 U  l2 b2 u2  @ 0085577610576 nodes with 1133697268465 5-TFS probes
  Solution [242] =  u2 l2 b2 U2 l2 D' b2 U2 [inside 5-TFS] ---> r2 D  l2 b2 u2  @ 0085577617308 nodes with 1133697339323 5-TFS probes
  Solution [243] =  u2 l2 b2 U2 l2 D  l2 U2 [inside 5-TFS] ---> f2 D' l2 b2 u2  @ 0085577617650 nodes with 1133697342744 5-TFS probes
  Solution [244] =  u2 l2 b2 D' r2 U2 b2 D  [inside 5-TFS] ---> b2 U2 l2 b2 u2  @ 0085581866297 nodes with 1133743278786 5-TFS probes
  Solution [245] =  u2 l2 b2 D' r2 D2 f2 D  [inside 5-TFS] ---> f2 D2 l2 b2 u2  @ 0085581873044 nodes with 1133743352056 5-TFS probes
  Solution [246] =  u2 l2 b2 D  f2 U2 u2 l2 [inside 5-TFS] ---> D' b2 U2 l2 b2  @ 0085582676181 nodes with 1133752021712 5-TFS probes
  Solution [247] =  u2 l2 b2 D  f2 U2 l2 D' [inside 5-TFS] ---> b2 U2 l2 b2 u2  @ 0085582676602 nodes with 1133752025613 5-TFS probes
  Solution [248] =  u2 l2 b2 D  f2 D2 r2 D' [inside 5-TFS] ---> f2 D2 l2 b2 u2  @ 0085582683349 nodes with 1133752100673 5-TFS probes
  Solution [249] =  u2 l2 b2 D2 r2 U  f2 D2 [inside 5-TFS] ---> l2 U' l2 b2 u2  @ 0085582945224 nodes with 1133754937971 5-TFS probes
  Solution [250] =  u2 l2 b2 D2 r2 U' r2 D2 [inside 5-TFS] ---> b2 U  l2 b2 u2  @ 0085582945809 nodes with 1133754944784 5-TFS probes
  Solution [251] =  u2 l2 b2 D2 r2 D' f2 D2 [inside 5-TFS] ---> r2 D  l2 b2 u2  @ 0085582952541 nodes with 1133755017068 5-TFS probes
  Solution [252] =  u2 l2 b2 D2 r2 D  r2 D2 [inside 5-TFS] ---> f2 D' l2 b2 u2  @ 0085582952883 nodes with 1133755020714 5-TFS probes
  DEPTHS 08-13 MOVE (06/36)  u2 F' l2 B  L  U  D  f   NODES: 0087879251587 DATABASE ACTIVITY: 000002544721722703 probes