• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.

Announcing: New 4x4x4 Brute Force Solver

Status
Not open for further replies.
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.

Hmmmm. Yes, I see your point now. I was hoping that something along these lines would not crop up.

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.

And turning it on or off in certain situations is plenty tricky. I was having fits with the "collapsing the noose" implementation. This is when you find a TFS hit of distance N at depth D, then you find another line of distance N-1. Do you turn off the higher distance database right away? Or do you let the iteration finish out, and then turn it off? There could be interesting gold nuggets in there that are just one move longer. Or, as you have seen, you can get hundreds of solutions that are basically every permutation of a means to enter the database at the optimal distance.

In an aggressive mining mode, you can even turn off the optimal distance TFS, if you want to search for something only better than what you have just found, and you don't care for the (possibly hundreds) of solutions of equal length pouring out of the thing. The configuration possibilities require a great deal of thought.

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.

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

That is a fair number of solutions! Now I really hope I purged the PV bug for good! (I am pretty sure I did, I rewrote like 300 lines of code yesterday.)

And now a little sneak peek at tomorrow's version:


now_in_color.jpg

I made a couple of changes, as you can see.

The first one is pretty apparent: I added color.

The second new feature is the ability to parse a 1-line text file to input a scramble, and the interface could not be easier.
Name the text file "scramble.txt" and just put your move sequence in there. Make sure it is in the same directory as the program.
Next, at the "enter scramble" prompt, just type the lower-case letter "i," and it will load it and start searching right away.

Trying the spoiler thingee to show how easy it is to get a pre-loaded entry into the program:
file_input.jpg
This is "just a start" for now. Eventually I have an entire text file of scrambles process automatically, but I am not there yet.

And... whenever a new "best line of play" outdoes any of the others, or if it is the first solution found, I have it appear in yellow. :)

And something you guys will probably hate me for now, but will like later once I do some leaf node pruning: I went ahead and implemented Iteration Jumping. It just seemed like a waste to rescan all of those positions constantly when they were already probed at prior iterations. If you have the 5-TFS loaded, it will jump in 2-ply increments. If you have 6-TFS, for now, I have it jump in 3-ply increments.

I may change it back if enough people start throwing stones my way.
 
Last edited:
That is a fair number of solutions!

Remember this version did not reset the solution count. The first solution of this scramble was counted as #170.

And something you guys will probably hate me for now, but will like later once I do some leaf node pruning: I went ahead and implemented Iteration Jumping. It just seemed like a waste to rescan all of those positions constantly when they were already probed at prior iterations. If you have the 5-TFS loaded, it will jump in 2-ply increments. If you have 6-TFS, for now, I have it jump in 3-ply increments.

I may change it back if enough people start throwing stones my way.

Please ... please ... please ... Make iteration jumping an optional feature only, and certainly don't even consider making it the default behavior.

It appears it would take me days to finish a depth 13 search for O-Perm (with the 5-TFS database). It would probably take months to complete a depth 14 search to get the 13-move solutions! This makes no sense at all to enforce upon the user!

OK, I guess it would do a depth 8+5 search in this case, not a depth 14 search, but the problem will still exist for any case where the optimal solutions aren't hit using the maximum TFS depth.
 
Last edited:
It appears it would take me days to finish a depth 13 search for O-Perm (with the 5-TFS database). It would probably take months to complete a depth 14 search to get the 13-move solutions! This makes no sense at all to enforce upon the user!

Days? Are you being serious?

I started this one like 20 minutes ago,

months.jpg


Already cruising through the 8th ply. I added an extra move onto the end of an algo just to test to see if maybe it was out of range of the 4-TFS database. You can see it hit it, then improved with a 3-TFS solution.

I have the software set to use one variable, SEARCH_EXTENSIONS, so I guess I'll add an on/off switch for you. I'll make the default option OFF.

Edit: Why don't you send me some scrambles and I can run them here for you?
 
Last edited:
Switch l' with l and vice versa. Older version had a bug. The U, F, and R solutions were always correct. The signs of the D, B, and L solutions always had to be switched with regard to having the ' or not.

see.jpg
 
Last edited:
O.k. I see.

If anybody has any algos that have solves that are not merely the moves played back in reverse with the prime mark logically negated, feel free to post a bunch of them here. I want to really test this principal variation code thoroughly.

Thanks!
 
Days? Are you being serious?

Yes. It's taken about a day just to go through { U, U' U2, u, u' u2 } as the first move at depth 13 (8+5). (First generation Core i7 processor.) That means it will take something on the order 6 days to go all the way through depth 13 if I let it continue. Of course, after it finishes r2 (halfway through), it will have found essentially every solution mod symmetries for that position (O-perm) - so no point in going farther than that. Actually I think I'll stop it and try today's version.

Regardless of how fast you can make your program or how fast the hardware you use, it is known that there are positions requiring at least 32 moves. So making the program faster will just result in people attempting to find solutions to deeper and deeper positions.
 
Yes. It's taken about a day just to go through { U, U' U2, u, u' u2 } as the first move at depth 13 (8+5). (First generation Core i7 processor.) That means it will take something on the order 6 days to go all the way through depth 13 if I let it continue. Of course, after it finishes r2 (halfway through), it will have found essentially every solution mod symmetries for that position (O-perm) - so no point in going farther than that. Actually I think I'll stop it and try today's version.

Regardless of how fast you can make your program or how fast the hardware you use, it is known that there are positions requiring at least 32 moves. So making the program faster will just result in people attempting to find solutions to deeper and deeper positions.

I will be posting the new version, without search extensions enabled, in a few minutes. In the meantime, do you have a "scramble" for this position?

http://alg.garron.us/?alg=f2_u-_r2_Uw2_S-_r2_S_D_S-_r_S_y_Uw_d_r2_u_f2&cube=4x4x4&notation=WCA

I just want to test a few algos and see if the PV is 100% working.

I tried to turn it into a scramble and got r2 u' b2 d' u' U' b f' r' b' f D' b f' r2 b' f u' U' r2 u f2 but that does not seem to be right. I do not have a rotation option or "wide" option in my program, so I need to convert it.

And here it is, online:

http://lightningcloudcomputing.com/OO_4x4x4.zip

Tomorrow's version, delivered a little early.

tomorrow.jpg
 
Last edited:
I will be posting the new version, without search extensions enabled, in a few minutes. In the meantime, do you have a "scramble" for this position?

http://alg.garron.us/?alg=f2_u-_r2_Uw2_S-_r2_S_D_S-_r_S_y_Uw_d_r2_u_f2&cube=4x4x4¬ation=WCA

I just want to test a few algos and see if the PV is 100% working.

I tried to turn it into a scramble and got r2 u' b2 d' u' U' b f' r' b' f D' b f' r2 b' f u' U' r2 u f2 but that does not seem to be right. I do not have a rotation option or "wide" option in my program, so I need to convert it.

I think this is what you want:

f2 u' r2 U2 u2 D f' b r' f b' D' f' b r2 f b' U2 u2 r2 u f2

Is suggest copy/paste. Those f followed by ' can look like just an f.
 
Last edited:
I think this is what you want:

f2 u' r2 U2 u2 D f' b r' f b' D' f' b r2 f b' U2 u2 r2 u f2

Is suggest copy/paste. Those f followed by ' can look like just an f.

Which was my prime motivation for building the "read scramble.txt file" feature.
It was like 10-12 lines of code too. I just read the file, "faked" it being like
one of your null-terminated list so as to resemble a "string," then passed it
into the move parsing procedure. Simplest code I ever wrote.

And speaking of primes, I almost found the world's largest twin prime on my machine today. 1026738 x 10^200701 + 1 is prime, but its counterpart at -1 is not. Bummer!

solved_22_move_scramble.jpg


UPDATE: Looks like this 22 move scramble has a 13-turn solution!

...and...
I have a question for you guys. I was testing the scramble:

R B r2 U2 r2 U u U u r2 u2 B' R' (entered as 13 moves) on OO_4x4x4 with just the 4-TFS loaded in order to test out the smaller databases. I wanted to create positions with longer scramble entries than "solves" to make sure the optimal PV is just not spitting out the reversed scramble.

The program spit out a 12-turn solution with the 4-TFS:

R F u2 R2 u2 R2 r2 u' -----> [inside 4-TFS] u' r2 F' R'

Usually that would make me nervous, since the u' @ ply-1 of the TFS should have not been the same move as the last play of the PV, then I realized that u2 is generated after u' in the move generator, so my heart rate went back to normal. I was also holding my breath, waiting for an 11-turn solution, which must be right around the corner. Expecting to see "u2" next, instead out came:

R F u2 R2 u2 R2 l2 u2 -----> [inside 3-TFS] l2 F' R' = 11 turns

The rest of the solutions that were coming out were all 11 turn solutions.

My question is, are there any faster solutions for this scramble?

I am hoping not, the program is still running and only finding 11 as best.
 
Last edited:
I have a question for you guys. I was testing the scramble:

R B r2 U2 r2 U u U u r2 u2 B' R' (entered as 13 moves) on OO_4x4x4 with just the 4-TFS loaded in order to test out the smaller databases. I wanted to create positions with longer scramble entries than "solves" to make sure the optimal PV is just not spitting out the reversed scramble.

The program spit out a 12-turn solution with the 4-TFS:

R F u2 R2 u2 R2 r2 u' -----> [inside 4-TFS] u' r2 F' R'

Usually that would make me nervous, since the u' @ ply-1 of the TFS should have not been the same move as the last play of the PV, then I realized that u2 is generated after u' in the move generator, so my heart rate went back to normal. I was also holding my breath, waiting for an 11-turn solution, which must be right around the corner. Expecting to see "u2" next, instead out came:

R F u2 R2 u2 R2 l2 u2 -----> [inside 3-TFS] l2 F' R' = 11 turns

The rest of the solutions that were coming out were all 11 turn solutions.

My question is, are there any faster solutions for this scramble?

My program did not find any solutions of length 10 or less. It hasn't checked distance-10 maneuvers starting with an F-B axis turn, but that's unnecessary due to the symmetry of the position. (I imagine your search completed by now, but you'll probably appreciate an independent confirmation is anyway.)
 
My program did not find any solutions of length 10 or less. It hasn't checked distance-10 maneuvers starting with an F-B axis turn, but that's unnecessary due to the symmetry of the position. (I imagine your search completed by now, but you'll probably appreciate an independent confirmation is anyway.)

Yes, thank you Bruce. So do you like the memory menu?
 
I think it's a bit "wordy." I might be happy with simply having a command line switch to override the default decision. But I like the ability to choose the depth. That way the user can experiment with what depth works best if the available memory is near the the threshold of what what is needed for a given depth. Also, the user might want to limit the memory used if running multiple copies.
 
@unsolved,
I didn't think of this before, but since you searched for the 2 2-cycle, R F u2 R2 u2 R2 l2 u2 l2 F' R', here is a list of the shortest solutions I could find (in single slice turn metric, at least) for the "worst" cases (all other 2 2-cycle cases have algorithms which have fewer moves than these cases, so I just picked out the longest ones for now).

l2 F D L F R2 D r2 D' R2 F' L' D' F' l2 (15)
r2 F D L F R2 D l2 D' R2 F' L' D' F' r2 (15)
F2 U' l' r' U F' L U' F l r F' U L' F' (15)
r2 U' B2 U' F L F' r2 F L' F' U B2 U r2 (15)
l2 U' B2 U' F L F' l2 F L' F' U B2 U l2 (15)
r2 U l r U' F R' U F' l' r' F U' R F' r2 (16)
R2 r' F' L R F r' F' R' F r2 F' L' F R2 (15)
r2 U F2 U B' R B r2 B' R' B U' F2 U' r2 (15)

They all work on the nxnxn, so I am guessing that it might be possible for shorter solutions to exist for the 4x4x4.
 
Last edited:
@unsolved,
I didn't think of this before, but since you searched for the 2 2-cycle, R F u2 R2 u2 R2 l2 u2 l2 F' R', here is a list of the shortest solutions I could find (in single slice turn metric, at least) for the "worst" cases (all other 2 2-cycle cases have algorithms which have fewer moves than these cases, so I just picked out the longest ones for now).

Thanks Chris, this is what I have been searching for. Are there any positions like this that can be solved with as few as 8 turns? I looked at all 506,489,884,416 leaf nodes @ depth 8 in my solver (507,090,491,478 if you do not have the NNP pruning mechanism which filters out sequences of No Net Progress) and if I coded my search for 3-layers-solved properly, I got a grand total of 0.

I have all of these cranking on my machine now, 1 with the 6-TFS database, the rest with 5-TFS. So far no solutions through depth 12 for any of them, starting depth 13 now.
 
Code:
  Found 18 moves to parse: Scramble = L U F L' U' L U L F' L2 U L U L' U' L U' L'



  3x3x3-F-perm


  Completed searching 0000000000001  nodes through DEPTHS 00-06:  LEAF NODES: 0000000000000  pruned
  TFS Database probes 0000000000000: 1-TFS probes 0000000000000: 2-TFS probes 0000000000000: 3-TFS probes 0000000000000
  TFS Database misses 0000000000001: 4-TFS probes 0000000000000: 5-TFS probes 0000000000000: 6-TFS probes 0000000000000

  Completed searching 0000000000036  nodes through DEPTHS 01-07:  LEAF NODES: 0000000000000  pruned
  TFS Database probes 0000000000449: 1-TFS probes 0000000000000: 2-TFS probes 0000000000000: 3-TFS probes 0000000000000
  TFS Database misses 0000000000476: 4-TFS probes 0000000000000: 5-TFS probes 0000000000026: 6-TFS probes 0000000000423

  Completed searching 0000000001026  nodes through DEPTHS 02-08:  LEAF NODES: 0000000000000  pruned
  TFS Database probes 0000000012608: 1-TFS probes 0000000000000: 2-TFS probes 0000000000000: 3-TFS probes 0000000000001
  TFS Database misses 0000000013457: 4-TFS probes 0000000000026: 5-TFS probes 0000000000724: 6-TFS probes 0000000011857

  Completed searching 0000000028836  nodes through DEPTHS 03-09:  LEAF NODES: 0000000000000  pruned
  TFS Database probes 0000000345417: 1-TFS probes 0000000000000: 2-TFS probes 0000000000000: 3-TFS probes 0000000000031
  TFS Database misses 0000000369351: 4-TFS probes 0000000000845: 5-TFS probes 0000000019487: 6-TFS probes 0000000325054

  Completed searching 0000000810648  nodes through DEPTHS 04-10:  LEAF NODES: 0000000000243  pruned
  TFS Database probes 0000009820846: 1-TFS probes 0000000000001: 2-TFS probes 0000000000065: 3-TFS probes 0000000000901
  TFS Database misses 0000010493547: 4-TFS probes 0000000022968: 5-TFS probes 0000000549175: 6-TFS probes 0000009247736

  Completed searching 0000022791456  nodes through DEPTHS 05-11:  LEAF NODES: 0000000006318  pruned
  TFS Database probes 0000275742675: 1-TFS probes 0000000000041: 2-TFS probes 0000000001697: 3-TFS probes 0000000025704
  TFS Database misses 0000294639627: 4-TFS probes 0000000644096: 5-TFS probes 0000015398462: 6-TFS probes 0000259672675

  Completed searching 0000640773504  nodes through DEPTHS 06-12:  LEAF NODES: 0000000178605  pruned
  TFS Database probes 0007751265664: 1-TFS probes 0000000001602: 2-TFS probes 0000000049005: 3-TFS probes 0000000725197
  TFS Database misses 0008282540120: 4-TFS probes 0000018154350: 5-TFS probes 0000432815535: 6-TFS probes 0007299519975

  Completed searching 0018015141312  nodes through DEPTHS 07-13:  LEAF NODES: 0000005022324  pruned
  TFS Database probes 0217932691727: 1-TFS probes 0000000046248: 2-TFS probes 0000001376598: 3-TFS probes 0000020418607
  TFS Database misses 0232869509950: 4-TFS probes 0000510423339: 5-TFS probes 0012167819428: 6-TFS probes 0205232607507

 →Solution [001] =  U  B2 L2 F  B2 U' F  R2 [inside 6-TFS] ---> B' D  F' R2 B  F'  @ 0016258098507 nodes with 0383864430139 6-TFS probes
  Solution [002] =  U' R  L' B2 R  D' L  B2 [inside 6-TFS] ---> R' U  L2 R' F2 L2  @ 0020869344258 nodes with 0434530203171 6-TFS probes
  Solution [003] =  U' F2 L2 F2 B' U  B' R2 [inside 6-TFS] ---> F  D' B  R2 B  F'  @ 0028103704626 nodes with 0514018495013 6-TFS probes
  Solution [004] =  U2 R  b' r' F' R  f2 D2 [inside 6-TFS] ---> f' L' r' R' f' r'  @ 0037295041680 nodes with 0615006622147 6-TFS probes
  Solution [005] =  U2 F  R' B  U2 F' L  F' [inside 6-TFS] ---> B2 D2 B2 L' B' F   @ 0043043091593 nodes with 0678163126931 6-TFS probes
  Solution [006] =  U2 F  R' B  U2 F' L  B2 [inside 6-TFS] ---> F' D2 B2 L' B' F   @ 0043043091603 nodes with 0678163127099 6-TFS probes
  Solution [007] =  U2 F  B' R  F2 D2 F2 B  [inside 6-TFS] ---> R' B  U2 F' L  B'  @ 0043346151619 nodes with 0681493331675 6-TFS probes
  Solution [008] =  U2 F  B' R' B2 D2 F' B2 [inside 6-TFS] ---> R  F' U2 B  L' F   @ 0043347082440 nodes with 0681503573627 6-TFS probes
  Solution [009] =  U2 B' R  F' U2 B  L' F2 [inside 6-TFS] ---> B  D2 F2 L  B' F   @ 0048167959503 nodes with 0734473686232 6-TFS probes
  Solution [010] =  U2 B' R  F' U2 B  L' B  [inside 6-TFS] ---> F2 D2 F2 L  B' F   @ 0048167959510 nodes with 0734473686270 6-TFS probes
  DEPTHS 08-14 MOVE (04/36)  u  D2 r  f' d  D2 B' U   NODES: 0051143357617 DATABASE ACTIVITY: 000001685125389786 probes

Solution [004] = U2 R b' r' F' R f2 D2 [inside 6-TFS] ---> f' L' r' R' f' r' @ 0037295041680 nodes with 0615006622147 6-TFS probes
^^ is wrong
 
Code:
  Found 18 moves to parse: Scramble = L U F L' U' L U L F' L2 U L U L' U' L U' L'

 Solution [004] =  U2 R  b' r' F' R  f2 D2 [inside 6-TFS] ---> f' L' r' R' f' r'  @ 0037295041680 nodes with 0615006622147 6-TFS probes 
^^ is wrong[/QUOTE]

And the others with L and B in the solution are correct? There was a bug where L, B, and D moves had the ' sign reversed (but I fixed it). What version of OO_4x4x4 is this?
 
Last edited:
Thanks Chris, this is what I have been searching for. Are there any positions like this that can be solved with as few as 8 turns?
In the K4 thread, I posted a PDF which has algorithms for all 58 cases (which includes mirror cases).

PLL parity requires 7 turns (r2 F2 U2 r2 U2 F2 r2), as you know, but the next magic number seems to be 9 turns (so no, I don't think any can be solved in 8 turns optimally):
r2 U' F2 U' r2 U F2 U r2 (9)
r2 U F2 U r2 U' F2 U' r2 (9)

To believe it or not, I thought the two cases above were bad cases, but when I found the algs above, I changed my mind!

I will now list a lot of last layer wing edge algorithms I found by hand or used Cube Explorer to find. Please do not feel pressured to find solutions to any of these cases. I listed them here for your convenience, as it's all of the shortest last layer algorithms for wing edges I have (besides those listed in the 2 2-cycle document above, 3-cycles, and those on the 4x4x4 parity algorithms page, although I did include two adjacent 4-cycle cases).

I have removed all rotations and rotated all algorithms to affect the last layer, for your convenience.

In this document, View attachment K4LL_OLL_PLL_CASES.pdf, I list all possible wing edge last layer cases which have all wing edges "oriented". I find that these cases, more often than not, require more moves than many cases which do not have all wing edges "oriented". So maybe this could be a good small subset of all 8! positions you can use to develop your solver.

A few years ago, I found short (but not necessarily optimal) algs for some of these cases. I list them by cycle type. I already posted a link to the 2 2-cycle algorithms, and therefore the algs for all "oriented" wings for 2 2-cycles is in that document.
A 3-cycle and a 2-cycle ({3,2}) (here are algs for all unique cases)
l2 r' D2 l F2 l F2 l' U l' F2 l F2 D2 U' l2 r (17) (my alg)
l2 r' D2 U' F2 l' F2 l U l F2 l' F2 l' D2 l2 r (17) (my alg)
r2 F2 U2 r2 U2 l' F2 l D2 r' D2 F' R' F' r' F R F r' (19) (my alg)
B2 U l r U' r F2 r' F2 U l' U2 r' U2 r' U' B2 (17) (my alg)
F2 l U' D2 r U2 R r' B r' U2 r U2 r B' R' U' D2 l' F2 (20) (my alg)
F2 r D b' R B' R b' R' B R' b' R2 b' R2 b' D' r' F2 (19) (my alg)

4-cycles ({4})
(here are algs for all unique cases)
l2 r2 U' F2 l F2 U2 r2 U2 l' U2 r2 B2 r B2 U' l2 r2 (18) (Found using Cube Explorer)
l2 r2 U l U2 B2 r2 B2 l' B2 r2 D2 r D2 B2 U l2 r2 (18) (Found using Cube Explorer)

2 3-cycles ({3,3}) (here are algs for all unique cases)
l2 r2 U r2 F2 r2 F2 U' l2 u2 r2 u2 (12) (my alg)
l2 r2 U' r2 F2 r2 F2 U l2 u2 r2 u2 (12) (my alg)
r2 U' r2 F2 r2 F2 U2 F2 r2 F2 r2 U' r2 (13) (Found using Cube Explorer)
F' R' d R U R' d' u' R U' R' u R F (14) (my alg)
R2 D' F2 f' U f U2 f' U F2 U' f U2 f' U' f D R2 (18) (my alg)
R2 r2 U2 R2 U' r U2 l r U' R2 U l' r' U2 r' U' R2 r2 (19) (my alg)
F L d' L' U' L d L' U F' L B u B' U' B u' B' U L' (20) (my alg)

3 2-cycles ({2,2,2}) (here are algs which represent half of the unique cases)
l2 r2 U r l2 U2 B2 r2 F2 r F2 l2 U2 l' U2 B2 U l2 r2 (19) (Found using Cube Explorer)
l2 r2 U F2 r l2 F2 U2 r2 D2 r D2 l2 F2 l' F2 U l2 r2 (19) (Found using Cube Explorer)
l2 r2 U B2 U2 r l2 U2 B2 r2 F2 r F2 l2 U2 l' U l2 r2 (19) (Found using Cube Explorer)

4 2-cycles ({2,2,2,2}) (here are algs which represent all cases, except of course, for cases equivalent to the 3x3x3 H and Z perms)
(F2 r2 F2 U' l2 r2 U) l2 r2 (U' r2 l2 U F2 r2 F2) (16) (my alg)
l2 r2 U' l' r U2 F2 l r F2 D2 F2 l2 F2 l2 D2 r2 U' l2 r2 (20) (found using cube explorer)

Lastly, here are some random algs for different cycle types of wing edges in which not all of them are "oriented" (again, one alg for each case listed. I do not include mirrors or inverses because that's redundant):
2 3-cycles ({3,3})
l r U' r2 F2 r2 U r2 U' F2 U l' r (13) (my alg)

4 2-cycles ({2,2,2,2})
(B2 r2 U2 F l' r U) r2 l2 (U' r' l F' U2 r2 B2) (16) (my alg)
(B2 r2 U2 F' l' r U') r2 l2 (U r' l F U2 r2 B2) (16) (my alg)

3-cycle and a 2 2-cycle ({3,2,2})
R2 U2 R u R U' R' u' d' R U R' d2 R' U R d' R' U R2 (20) (my alg)

4-cycles in 2 dedges (I omit the most 3 common parity cases, as they all have unquestionably optimal algs)
R B r U2 r2 U2 r' U2 r U2 r' U2 r2 U2 r B' R' (17) (someone found using Cube Explorer)
(l' U2 l2 r2 U) l r' U2 l U2 l2 U2 l U2 r (U' l2 r2 U2 l) (20) (my alg)

4-cycles in 3 dedges (Below are algs for all cases except 4, which I didn't have/make algs for)
l r2 U' F2 r' F2 r' F2 r' F2 r2 U r2 l' (14) (my alg)
r2 U' F2 U' r' U F2 U r2 F2 l' U2 l r U2 r' F2 (17) (my alg)
r2 U F2 U r' U' F2 U' r2 F2 l' U2 l r U2 r' F2 (17) (my alg)
l r2 U F2 r' F2 r' F2 r' F2 r2 U' l' r2 (14) (my alg)
r U2 r2 U' r' U2 r' U2 r2 U2 r' U' r2 U2 r' (15) (my alg)
r U2 r2 U r' U2 r' U2 r2 U2 r' U r2 U2 r' (15) (my alg)
r U2 r U' r' U2 r2 U2 r' U2 r' U' r' U2 r' (15) (my alg)
r U2 r U r' U2 r2 U2 r' U2 r' U r' U2 r' (15) (my alg)
r' F2 l U l2 F2 l F2 l2 F2 l F2 l' U' l' F2 r (17) (my alg)
R2 U' r U2 R2 r2 U r U2 r2 U2 r U2 r U r2 R2 U2 r' U R2 (21) (my alg)
r F' R' F r2 F2 r' F2 r' F2 r' F R F r' (15) (my alg)
r' F2 l U' l F2 l' F2 l2 F2 l' F2 l2 U l' F2 r (17) (my alg)
r' B' R B' r B2 r B2 r' B2 r2 B R' B r' B' R B2 R' B r2 (21) (my alg)
R' r' U R B2 U' r U2 r U2 r U2 r2 U' B2 R' U' R r (19) (my alg)
l' U2 l2 r' U l F2 l F2 l F2 l2 F2 U' r l2 U2 l (18) (my alg)
r U2 r R U' l U F2 U' r U F2 U' l' r' U R' U r U' r' U2 r' (23) (my alg)
F l U2 r U' r U2 r U2 r2 U2 r U' r' U2 l' F' (17) (my alg)

4-cycles in 4 dedges (I omit the "oriented" cases, as I have already posted them above. I don't have an alg listed for just 1 case)
F2 U r B R B' r2 B2 r' B2 r' B2 r' B' R' B' r' U' F2 (19) (my alg)
l r U' r U2 F2 r F2 U2 r' U2 l U2 r' U2 r U2 l' U l' r' (21) (found using cube explorer)
R' r' U B2 U r' U2 r' U2 r' U2 r U R U' r U R' B2 U' r R (22) (my alg)
l r U r U2 F2 r F2 U2 r' U2 l U2 r' U2 r U2 l' U' l' r' (21) (my alg)
F2 l' L F' D2 F r' F' D2 F L' l' F R' F r' F' R F' r l2 F2 (22) (my alg)
l2 r2 D' R2 r2 f R2 b' R2 b R2 D2 b D2 f' R2 b2 r2 R2 D r2 l2 (22) (my alg)
r B2 R U' l U F2 U' r U F2 U' l' r' U R' U r U' B2 r' (21) (my alg)
f2 b2 D' r F2 r F2 r F2 r F2 r D b2 f2 (15) (my alg)

I have all of these cranking on my machine now, 1 with the 6-TFS database, the rest with 5-TFS. So far no solutions through depth 12 for any of them, starting depth 13 now.
It would really be interesting to see if you can find shorter solutions!
 
Last edited:
And the others with L and B in the solution are correct? There was a bug where L, B, and D moves had the ' sign reversed (but I fixed it). What version of OO_4x4x4 is this?

It's the latest one linked in this thread (it's got colours and tells me I have 8 TB virtual RAM)

I tested most of them, but the only one that didn't seem to work was the one with inner slice turns
 
Last edited:
Status
Not open for further replies.
Back
Top