# Solving Corners Last On Large Cubes



## unsolved (Mar 18, 2016)

I have just recently been experimenting with solving the 5x5x5 via reduction: centers, tredges, corners last. I notice some of these corners are much longer to solve than I anticipated. The shortest solution for any such arrangement seems to be 8 moves.







R2 B L2 B' R2 B L2 B' 

*Question 1:* Are there any cases where fewer than 8 moves can solve a large cube if only the corners are incorrect?
*Question 2:* Is there a "known longest" corners-only-unsolved position (and what is its solution)?
*Question 3:* Given any sufficiently scrambled cube, isn't the longest solution to solve all of the corners first only 11 moves?
*Question 4:* Would it be wiser to solve the cube in the order: corners, tredges, centers... if the objective was to build a method that has the fewest moves to solve on average?


----------



## Lucas Garron (Mar 18, 2016)

unsolved said:


> if the objective was to build a method that has the fewest moves to solve on average?



If this is your objective, you should use a two-phase algorithm for the 3x3x3 stage.


----------



## Chree (Mar 19, 2016)

1. The shortest "Corners Only" alg I know of is Niklas (and all of its mirrored/inversed iterations): R U' L' U R' U' L (7 moves).

2. There are lots of different types of "corners only" algs. But if you're asking for an area where they're commonly used today, then what you're asking for are Corner Commutators. They're ubiquitous in advanced FMC and BLD methods. The longest commutators used in BH/3-Style for BLD (which cycles 3 corners at a time) are 12 moves. I may defer to an FMC or BLD expert to talk about if there are known cases which cycle more than 3 corners. I don't think anyone uses any method to solve all 8 corners in one shot... I just can't fathom how that could be broken down into easy to recognize cases that preserve the rest of the cube. https://www.speedsolving.com/wiki/index.php/Commutators http://www.speedcubing.com/chris/bhcorners.html

3. If you think of "corners only" solutions to be the equivalent of solving a 2x2, in which case God's Number is 11, then yes... 11. But once again, on big cubes, preserving the corners to the end would be an enormous pain without a proper method. And I don't think one exists. 

4. I don't think a method like that has been explored because 'direct solving' on big cubes, efficient though it could be, is not very conducive to speedsolving. Recognition is atrocious and algs are not friendly to muscle memory, so speedsolving is out. However, using center commutators is very easy. Then maybe something like Freeslice for edges could also be efficient, and then corner commutators. But my gut is telling me that would not be very efficient.

I'm not sure what kind of answer you're looking for here, because what's "wiser" could be subjective. The method you describe sounds interesting from an FMC perspective, but from a speedsolving perspective, just painful. As a speedsolver, I would say it's wiser to use a method more akin to Reduction: Solve the centers, Pair the tredges (placement is arbitrary), and then just solve the whole thing like a normal 3x3. Reduction winds up being fairly efficient, and I'd actually really like to see if anyone knows of an already existing method that is even more so.

Have you spent any time checking out any more common methods for solving big cubes? K4 and Cage has some elements of what you're describing, though maybe not in the same order you listed them here. They also might not be as "direct" as what you're hoping for.


----------



## sqAree (Mar 19, 2016)

Chree said:


> 1. The shortest "Corners Only" alg I know of is Niklas (and all of its mirrored/inversed iterations): R U' L' U R' U' L (7 moves).



Actually the AUF is missing so it comes down to 8 moves.


----------



## unsolved (Mar 19, 2016)

Thanks for the elaborations; very informative.



Chree said:


> 1. The shortest "Corners Only" alg I know of is Niklas (and all of its mirrored/inversed iterations): R U' L' U R' U' L (7 moves).



That's very close to what I was referring to, but the "tredges" are not fully solved. They're in the right orientation but not the correct position. See below:

R U' L' U R' U' 




Chree said:


> 2. There are lots of different types of "corners only" algs. But if you're asking for an area where they're commonly used today, then what you're asking for are Corner Commutators. They're ubiquitous in advanced FMC and BLD methods. The longest commutators used in BH/3-Style for BLD (which cycles 3 corners at a time) are 12 moves. I may defer to an FMC or BLD expert to talk about if there are known cases which cycle more than 3 corners. I don't think anyone uses any method to solve all 8 corners in one shot... I just can't fathom how that could be broken down into easy to recognize cases that preserve the rest of the cube. https://www.speedsolving.com/wiki/index.php/Commutators http://www.speedcubing.com/chris/bhcorners.html



I was thinking of something along these lines:

U2 R U' F' D' R' U' R' B D' F2 L F' U' B' L' F' L' D B'

I thought somewhere I saw a 22-move with just two opposite corners twisted on an otherwise completely solved cube. I will continue hunting.
But is there a shorter solution to the corner position shown above? That one consists of 20 moves.



Chree said:


> 3. If you think of "corners only" solutions to be the equivalent of solving a 2x2, in which case God's Number is 11, then yes... 11. But once again, on big cubes, preserving the corners to the end would be an enormous pain without a proper method. And I don't think one exists.



Yes, I'm thinking about having my own solving program switch to solve *corners *first, so it would kind of be like a 2x2 solve, only I need a *center *reference on the 5x5x5. It turns out that solving with respect to the center does not change the distance; it's still at a max of 11. Thanks for verifying.



Chree said:


> 4. I don't think a method like that has been explored because 'direct solving' on big cubes, efficient though it could be, is not very conducive to speedsolving. Recognition is atrocious and algs are not friendly to muscle memory, so speedsolving is out. However, using center commutators is very easy. Then maybe something like Freeslice for edges could also be efficient, and then corner commutators. But my gut is telling me that would not be very efficient.



Ahhhh, ok, that makes sense now. It's easier to execute some well known algs fast rather than use time to derive a shorter solution with such a narrow scope of applicability.



Chree said:


> I'm not sure what kind of answer you're looking for here, because what's "wiser" could be subjective. The method you describe sounds interesting from an FMC perspective, but from a speedsolving perspective, just painful. As a speedsolver, I would say it's wiser to use a method more akin to Reduction: Solve the centers, Pair the tredges (placement is arbitrary), and then just solve the whole thing like a normal 3x3. Reduction winds up being fairly efficient, and I'd actually really like to see if anyone knows of an already existing method that is even more so.



The results that I _might _achieve with the program would probably not be worth it for the human speedsolvers. I'm hunting for a fast FMC-type solution for the program. Currently the more time I invest, the lower the movecount drops, but the corners-last approach is not bearing fruit. I'd need to pre-compute all 88,179,840 corner positions and perform a lookup on the result. With the tredges + centers already solved, this would take a great deal of time.



Chree said:


> Have you spent any time checking out any more common methods for solving big cubes? K4 and Cage has some elements of what you're describing, though maybe not in the same order you listed them here. They also might not be as "direct" as what you're hoping for.



This will pretty much evolve into a Cage-solving method. I have a very quick way to deal with the cage once it is set up.

Thanks again, I'll re-read the links you posted.


----------



## Ranzha (Mar 19, 2016)

Since outer-layer turns on the 5x5x5 reduces the puzzle to a 3x3x3, then God's number for the 3x3x3 of 20 moves can be applied. So the 22-move algorithm you described must be sub-optimal.

Also, your 20-move alg is easily proven to be sub-optimal:


----------



## unsolved (Mar 19, 2016)

Ranzha said:


> Since outer-layer turns on the 5x5x5 reduces the puzzle to a 3x3x3, then God's number for the 3x3x3 of 20 moves can be applied. So the 22-move algorithm you described must be sub-optimal.
> 
> Also, your 20-move alg is easily proven to be sub-optimal:
> https://www.youtube.com/watch?v=CBBr8q-T-x0



The larger cubes can create corner and edge scenarios that can't be created on the 3x3x3 though. Correct? Case in point: the single "dedge" flip on the 4x4x4:

2R2 D2 2R' F2 2R F2 D2 2R D2 2L' F2 2L F2 D2 2R2


I was trying to look for a way to create this corner position in fewer moves for the 4x4x4:

U2 F2 U' L' U2 L F U R' U2 R Uw F' U2 F Uw' F Fw' R U2 Fw' U2 Fw' U2 Fw' U2 Fw2 R' Fw z' 2R2 D2 2R' F2 2R F2 D2 2R D2 2L' F2 2L F2 D2 2R2 y'x

*Edit: Here it is, and you can see why this is probably not possible on the 3x3x3:*

r2 2F2 U2 b2 D' r2 U2 b2 U f2 R2 D2 B2 l2 U


My question is: Can this corner orientation be created on the 3x3x3? My supposition at this point is that it can't. If it can, I'd like to see the 3x3x3 solution. If it can't, I'd like to see the fewest moves to the 4x4x4 solution.


----------



## shadowslice e (Mar 19, 2016)

unsolved said:


> The larger cubes can create corner and edge scenarios that can't be created on the 3x3x3 though. Correct? Case in point: the single "dedge" flip on the 4x4x4:
> 
> 2R2 D2 2R' F2 2R F2 D2 2R D2 2L' F2 2L F2 D2 2R2



If we're talking about 5x5, all 3x3 states that come up after reduction (once OLL parity which does not represent a 3x3 stage and can easily be recognised as such) can be solved exactly like a 3x3 as the 5x5 can be viewed as a 3x3 when it comes to the middle slice edge and the corners. This is why you can't get PLL parity on a 5x5 and OLL parity is an error in the wings rather than a single tredge flip.

In addition, all CO states possible on big cubes can be directly created on a 3x3 or 2x2.

However, even layered cubes are slightly different as they don't have edges which directly correspond to 3x3 edges and can therefore have 2-swaps.



> I was trying to look for a way to create this corner position in fewer moves for the 4x4x4:
> 
> U2 F2 U' L' U2 L F U R' U2 R Uw F' U2 F Uw' F Fw' R U2 Fw' U2 Fw' U2 Fw' U2 Fw2 R' Fw z' 2R2 D2 2R' F2 2R F2 D2 2R D2 2L' F2 2L F2 D2 2R2 y'x
> 
> ...



I think when it comes to big cubes, you can essentially have 3 sets of pieces: (corners and middle edges), (wings) and (centres).

You are correct that the above position cannot be created on a 3x3 though the same pattern cannot be replicated (ie opposite corner swap with no other pieces affected) on any odd layered cube (such as 5x5, 7x7 etc) as you cannot create PLL parity on these either.

To summarise, you can get things like the above on even layered cubes as the are no middle edges but you can't get them on odd layered cubes.


----------



## cuBerBruce (Mar 19, 2016)

In the block turn metric, there are 6-move maneuvers, but I don't think the OP meant to allow that metric.

For example (SiGN notation):
U2 2-4r2 2-4f2 D2 2-4r2 2-4f2 (same algorithm to scramble or solve)

Using only single-layer turns, I can't think of any positions having only corners unsolved that take less than 8 turns.


----------



## Christopher Mowla (Mar 19, 2016)

unsolved said:


> *Edit: Here it is, and you can see why this is probably not possible on the 3x3x3:*
> 
> r2 2F2 U2 b2 D' r2 U2 b2 U f2 R2 D2 B2 l2 U
> 
> ...


I won't go into trying to explain (again) what the laws of the cube are, but Clément Gallet recently found some pretty brief algorithms for this case and the adjacent case *in your preferred move metric*. I added these to the 4x4x4 parity algorithms wiki about a month ago.

Adjacent (17 moves):
F2 R2 B' D' B R2 F' U 2F2 F' L2 2F2 2L2 L2 2F2 2L2 U'

Diagonal (18 moves)
2R2 F2 L' U2 L2 2L2 F2 R' D2 R2 U2 B2 R D2 B2 R2 2R2 U2


May I also say that:

I added an 11 dedge flip section to the 4x4x4 parity algorithms wiki page. All algs currently in that section, apart from the last alg, is a result of Herbert Kociemba's work in your thread. I found 3 other directly related algorithms based on his alg. 
Clément also found a 20 move (in your metric) "pure" 3 dedge flip in the last layer algorithm
R2 2B' U' L2 2F2 L2 2F2 U 2B U 2F' U2 2F m2 2F m2 U R2 
And he found, a 21 move 3 dedge flip + PLL parity alg (well, this is just one of many possible cases):
2U2 2F' U' 2F2 l2 U2 2F' U2 B2 l2 2F2 U' 2F 2U2 l2 B2 l2 


In addition, there are no odd permutation "corners only" positions on the odd nxnxn cube (which includes a 2 corner swap only). So you only have to consider 88,179,840 corner only positions for the even nxnxn cube, but 44,089,920 for the odd nxnxn cube.

EDIT:
And the two corner swap position you asked about is not referred to as a "corner orientation", but a "corner permutation". Corner orientation is a term used to describe how corners are _twisted_, not how they are moved around.


----------



## unsolved (Mar 19, 2016)

shadowslice e said:


> You are correct that the above position cannot be created on a 3x3 though the same pattern cannot be replicated (ie opposite corner swap with no other pieces affected) on any odd layered cube (such as 5x5, 7x7 etc) as you cannot create PLL parity on these either.





Christopher Mowla said:


> In addition, there are no odd permutation "corners only" positions on the odd nxnxn cube (which includes a 2 corner swap only). So you only have to consider 88,179,840 corner only positions for the even nxnxn cube, but 44,089,920 for the odd nxnxn cube.



Thank you both. I'm working on determining what the longest "corners only" position is on the 5x5x5. If they're as long as some of these 4x4x4 positions,
my program will have to discover another means of dealing with them.



cuBerBruce said:


> In the block turn metric, there are 6-move maneuvers, but I don't think the OP meant to allow that metric.
> 
> For example (SiGN notation):
> U2 2-4r2 2-4f2 D2 2-4r2 2-4f2 (same algorithm to scramble or solve)
> ...



I'm doing a full-width search out to depth 8 on the 5x5x5. If all of the tredges and centers are solved, I'm capturing the sequence.
Depth 7 already completed (93,510,461,296 nodes cumulative, including the 1 node @ depth 0) and there are 0 corner positions, for certain.

Depth 8 has found only 400 so far (2.1 trillion and counting). That's a pretty sparse distribution.
My supposition at this point is that there will be some very deep corners-only positions for the 5x5x5.



Spoiler



R U R' D' R U' R' D 
R U R' D R U' R' D' 
R U R' D2 R U' R' D2 
R U L' U' R' U L U' 
R U L U' R' U L' U' 
R U L2 U' R' U L2 U' 
R U' R' D' R U R' D
R U' R' D R U R' D' 
R U' R' D2 R U R' D2 
R U' L' U R' U' L U
R U' L U R' U' L' U 
R U' L2 U R' U' L2 U
R U2 R' D' R U2 R' D
R U2 R' D R U2 R' D' 
R U2 R' D2 R U2 R' D2 
R D' R' U R D R' U' 
R D' R' U' R D R' U
R D' R' U2 R D R' U2 
R D' L' D R' D' L D
R D' L D R' D' L' D
R D' L2 D R' D' L2 D
R D R' U R D' R' U' 
R D R' U' R D' R' U
R D R' U2 R D' R' U2 
R D L' D' R' D L D' 
R D L D' R' D L' D' 
R D L2 D' R' D L2 D' 
R D2 R' U R D2 R' U' 
R D2 R' U' R D2 R' U
R D2 R' U2 R D2 R' U2 
R F R' B' R F' R' B
R F R' B R F' R' B' 
R F R' B2 R F' R' B2 
R F L' F' R' F L F' 
R F L F' R' F L' F' 
R F L2 F' R' F L2 F' 
R F' R' B' R F R' B
R F' R' B R F R' B' 
R F' R' B2 R F R' B2 
R F' L' F R' F' L F
R F' L F R' F' L' F 
R F' L2 F R' F' L2 F
R F2 R' B' R F2 R' B
R F2 R' B R F2 R' B' 
R F2 R' B2 R F2 R' B2 
R B' R' F R B R' F' 
R B' R' F' R B R' F
R B' R' F2 R B R' F2 
R B' L' B R' B' L B
R B' L B R' B' L' B
R B' L2 B R' B' L2 B
R B R' F R B' R' F' 
R B R' F' R B' R' F
R B R' F2 R B' R' F2 
R B L' B' R' B L B' 
R B L B' R' B L' B' 
R B L2 B' R' B L2 B' 
R B2 R' F R B2 R' F' 
R B2 R' F' R B2 R' F
R B2 R' F2 R B2 R' F2 
R' U R D' R' U' R D
R' U R D R' U' R D' 
R' U R D2 R' U' R D2 
R' U L' U' R U L U' 
R' U L U' R U L' U' 
R' U L2 U' R U L2 U' 
R' U' R D' R' U R D
R' U' R D R' U R D' 
R' U' R D2 R' U R D2 
R' U' L' U R U' L U
R' U' L U R U' L' U
R' U' L2 U R U' L2 U
R' U2 R D' R' U2 R D
R' U2 R D R' U2 R D' 
R' U2 R D2 R' U2 R D2 
R' D' R U R' D R U' 
R' D' R U' R' D R U
R' D' R U2 R' D R U2 
R' D' L' D R D' L D
R' D' L D R D' L' D
R' D' L2 D R D' L2 D
R' D R U R' D' R U' 
R' D R U' R' D' R U
R' D R U2 R' D' R U2 
R' D L' D' R D L D' 
R' D L D' R D L' D' 
R' D L2 D' R D L2 D' 
R' D2 R U R' D2 R U' 
R' D2 R U' R' D2 R U
R' D2 R U2 R' D2 R U2 
R' F R B' R' F' R B
R' F R B R' F' R B' 
R' F R B2 R' F' R B2 
R' F L' F' R F L F' 
R' F L F' R F L' F' 
R' F L2 F' R F L2 F' 
R' F' R B' R' F R B
R' F' R B R' F R B' 
R' F' R B2 R' F R B2 
R' F' L' F R F' L F
R' F' L F R F' L' F
R' F' L2 F R F' L2 F
R' F2 R B' R' F2 R B
R' F2 R B R' F2 R B' 
R' F2 R B2 R' F2 R B2 
R' B' R F R' B R F' 
R' B' R F' R' B R F
R' B' R F2 R' B R F2 
R' B' L' B R B' L B
R' B' L B R B' L' B
R' B' L2 B R B' L2 B
R' B R F R' B' R F' 
R' B R F' R' B' R F
R' B R F2 R' B' R F2 
R' B L' B' R B L B' 
R' B L B' R B L' B' 
R' B L2 B' R B L2 B' 
R' B2 R F R' B2 R F' 
R' B2 R F' R' B2 R F
R' B2 R F2 R' B2 R F2 
R2 U L' U' R2 U L U' 
R2 U L U' R2 U L' U' 
R2 U L2 U' R2 U L2 U' 
R2 U' L' U R2 U' L U
R2 U' L U R2 U' L' U
R2 U' L2 U R2 U' L2 U
R2 D' L' D R2 D' L D 
R2 D' L D R2 D' L' D 
R2 D' L2 D R2 D' L2 D
R2 D L' D' R2 D L D' 
R2 D L D' R2 D L' D' 
R2 D L2 D' R2 D L2 D' 
R2 F L' F' R2 F L F' 
R2 F L F' R2 F L' F' 
R2 F L2 F' R2 F L2 F' 
R2 F' L' F R2 F' L F
R2 F' L F R2 F' L' F
R2 F' L2 F R2 F' L2 F
R2 B' L' B R2 B' L B
R2 B' L B R2 B' L' B
R2 B' L2 B R2 B' L2 B
R2 B L' B' R2 B L B' 
R2 B L B' R2 B L' B' 
R2 B L2 B' R2 B L2 B' 
L' U R U' L U R' U' 
L' U R' U' L U R U' 
L' U R2 U' L U R2 U' 
L' U L D' L' U' L D
L' U L D L' U' L D' 
L' U L D2 L' U' L D2 
L' U' R U L U' R' U
L' U' R' U L U' R U
L' U' R2 U L U' R2 U
L' U' L D' L' U L D
L' U' L D L' U L D' 
L' U' L D2 L' U L D2 
L' U2 L D' L' U2 L D
L' U2 L D L' U2 L D' 
L' U2 L D2 L' U2 L D2 
L' D' R D L D' R' D
L' D' R' D L D' R D
L' D' R2 D L D' R2 D 
L' D' L U L' D L U' 
L' D' L U' L' D L U 
L' D' L U2 L' D L U2 
L' D R D' L D R' D' 
L' D R' D' L D R D' 
L' D R2 D' L D R2 D' 
L' D L U L' D' L U' 
L' D L U' L' D' L U 
L' D L U2 L' D' L U2 
L' D2 L U L' D2 L U' 
L' D2 L U' L' D2 L U 
L' D2 L U2 L' D2 L U2 
L' F R F' L F R' F' 
L' F R' F' L F R F' 
L' F R2 F' L F R2 F' 
L' F L B' L' F' L B 
L' F L B L' F' L B' 
L' F L B2 L' F' L B2 
L' F' R F L F' R' F 
L' F' R' F L F' R F 
L' F' R2 F L F' R2 F 
L' F' L B' L' F L B 
L' F' L B L' F L B' 
L' F' L B2 L' F L B2 
L' F2 L B' L' F2 L B 
L' F2 L B L' F2 L B' 
L' F2 L B2 L' F2 L B2 
L' B' R B L B' R' B 
L' B' R' B L B' R B 
L' B' R2 B L B' R2 B 
L' B' L F L' B L F' 
L' B' L F' L' B L F 
L' B' L F2 L' B L F2 
L' B R B' L B R' B' 
L' B R' B' L B R B' 
L' B R2 B' L B R2 B' 
L' B L F L' B' L F' 
L' B L F' L' B' L F 
L' B L F2 L' B' L F2 
L' B2 L F L' B2 L F' 
L' B2 L F' L' B2 L F 
L' B2 L F2 L' B2 L F2 
L U R U' L' U R' U' 
L U R' U' L' U R U' 
L U R2 U' L' U R2 U' 
L U L' D' L U' L' D 
L U L' D L U' L' D' 
L U L' D2 L U' L' D2 
L U' R U L' U' R' U 
L U' R' U L' U' R U 
L U' R2 U L' U' R2 U 
L U' L' D' L U L' D 
L U' L' D L U L' D' 
L U' L' D2 L U L' D2 
L U2 L' D' L U2 L' D 
L U2 L' D L U2 L' D' 
L U2 L' D2 L U2 L' D2 
L D' R D L' D' R' D 
L D' R' D L' D' R D 
L D' R2 D L' D' R2 D 
L D' L' U L D L' U' 
L D' L' U' L D L' U 
L D' L' U2 L D L' U2 
L D R D' L' D R' D' 
L D R' D' L' D R D' 
L D R2 D' L' D R2 D' 
L D L' U L D' L' U' 
L D L' U' L D' L' U 
L D L' U2 L D' L' U2 
L D2 L' U L D2 L' U' 
L D2 L' U' L D2 L' U 
L D2 L' U2 L D2 L' U2 
L F R F' L' F R' F' 
L F R' F' L' F R F' 
L F R2 F' L' F R2 F' 
L F L' B' L F' L' B 
L F L' B L F' L' B' 
L F L' B2 L F' L' B2 
L F' R F L' F' R' F 
L F' R' F L' F' R F 
L F' R2 F L' F' R2 F 
L F' L' B' L F L' B 
L F' L' B L F L' B' 
L F' L' B2 L F L' B2 
L F2 L' B' L F2 L' B 
L F2 L' B L F2 L' B' 
L F2 L' B2 L F2 L' B2 
L B' R B L' B' R' B 
L B' R' B L' B' R B 
L B' R2 B L' B' R2 B 
L B' L' F L B L' F' 
L B' L' F' L B L' F 
L B' L' F2 L B L' F2 
L B R B' L' B R' B' 
L B R' B' L' B R B' 
L B R2 B' L' B R2 B' 
L B L' F L B' L' F' 
L B L' F' L B' L' F 
L B L' F2 L B' L' F2 
L B2 L' F L B2 L' F' 
L B2 L' F' L B2 L' F 
L B2 L' F2 L B2 L' F2 
L2 U R U' L2 U R' U' 
L2 U R' U' L2 U R U' 
L2 U R2 U' L2 U R2 U' 
L2 U' R U L2 U' R' U 
L2 U' R' U L2 U' R U 
L2 U' R2 U L2 U' R2 U 
L2 D' R D L2 D' R' D 
L2 D' R' D L2 D' R D 
L2 D' R2 D L2 D' R2 D 
L2 D R D' L2 D R' D' 
L2 D R' D' L2 D R D' 
L2 D R2 D' L2 D R2 D' 
L2 F R F' L2 F R' F' 
L2 F R' F' L2 F R F' 
L2 F R2 F' L2 F R2 F' 
L2 F' R F L2 F' R' F 
L2 F' R' F L2 F' R F 
L2 F' R2 F L2 F' R2 F 
L2 B' R B L2 B' R' B 
L2 B' R' B L2 B' R B 
L2 B' R2 B L2 B' R2 B 
L2 B R B' L2 B R' B' 
L2 B R' B' L2 B R B' 
L2 B R2 B' L2 B R2 B' 
U R U' L' U R' U' L 
U R D2 R' U' R D2 R' 
U R' U' L2 U R U' L2 
U R' D R U' R' D' R 
U R' D2 R U' R' D2 R 
U R2 U' L' U R2 U' L 
U L' U' R2 U L U' R2 
U L' D L U' L' D' L 
U L' D2 L U' L' D2 L 
U L U' R' U L' U' R 
U L D2 L' U' L D2 L' 
U L2 U' R' U L2 U' R 
U F U' B U F' U' B' 
U F U' B2 U F' U' B2 
U F D' F' U' F D F' 
U F D F' U' F D' F' 
U F' U' B' U F U' B 
U F' U' B U F U' B' 
U F' U' B2 U F U' B2 
U F' D' F U' F' D F 
U F' D2 F U' F' D2 F 
U F2 U' B' U F2 U' B 
U F2 U' B U F2 U' B' 
U F2 U' B2 U F2 U' B2 
U B' U' F U B U' F' 
U B' U' F' U B U' F 
U B' U' F2 U B U' F2 
U B' D' B U' B' D B 
U B' D2 B U' B' D2 B 
U B U' F U B' U' F' 
U B U' F2 U B' U' F2 
U B D' B' U' B D B' 
U B D B' U' B D' B' 
U B2 U' F U B2 U' F' 
U B2 U' F' U B2 U' F 
U B2 U' F2 U B2 U' F2 
U' R U L2 U' R' U L2 
U' R D' R' U R D R' 
U' R D2 R' U R D2 R' 
U' R' U L U' R U L' 
U' R' D2 R U R' D2 R 
U' R2 U L U' R2 U L' 
U' L' U R U' L U R' 
U' L' D2 L U L' D2 L 
U' L U R2 U' L' U R2 
U' L D' L' U L D L' 
U' L D2 L' U L D2 L' 
U' L2 U R U' L2 U R' 
U' F U B' U' F' U B 
U' F U B U' F' U B' 
U' F U B2 U' F' U B2 
U' F D F' U F D' F' 
U' F D2 F' U F D2 F' 
U' F' U B' U' F U B 
U' F' U B2 U' F U B2 
U' F' D' F U F' D F 
U' F' D F U F' D' F 
U' F2 U B' U' F2 U B 
U' F2 U B U' F2 U B' 
U' F2 U B2 U' F2 U B2 
U' B' U F' U' B U F 
U' B' U F2 U' B U F2 
U' B' D' B U B' D B 
U' B' D B U B' D' B 
U' B U F U' B' U F' 
U' B U F' U' B' U F 
U' B U F2 U' B' U F2 
U' B D B' U B D' B' 
U' B D2 B' U B D2 B' 
U' B2 U F U' B2 U F' 
U' B2 U F' U' B2 U F 
U' B2 U F2 U' B2 U F2 
U2 R D' R' U2 R D R' 
U2 R D R' U2 R D' R' 
U2 R D2 R' U2 R D2 R' 
U2 R' D' R U2 R' D R 
U2 R' D R U2 R' D' R 
U2 R' D2 R U2 R' D2 R 
U2 L' D' L U2 L' D L 
U2 L' D L U2 L' D' L 
U2 L' D2 L U2 L' D2 L 
U2 L D' L' U2 L D L' 
U2 L D L' U2 L D' L' 
U2 L D2 L' U2 L D2 L' 
U2 F D' F' U2 F D F' 
U2 F' D F U2 F' D' F 
U2 B' D B U2 B' D' B 
U2 B D' B' U2 B D B' 
D' R U' R' D R U R' 
D' R U2 R' D R U2 R' 
D' R D L2 D' R' D L2 
D' R' U2 R D R' U2 R 
D' R' D L D' R D L' 
D' R2 D L D' R2 D L' 
D' L' U2 L D L' U2 L 
D' L' D R D' L D R' 
D' L U' L' D L U L' 
D' L U2 L' D L U2 L' 
D' L D R2 D' L' D R2 
D' L2 D R D' L2 D R' 
D' F U F' D F U' F' 
D' F U2 F' D F U2 F' 
D' F D B' D' F' D B 
D' F D B D' F' D B' 
D' F D B2 D' F' D B2 
D' F' U F D F' U' F 
D' F' U' F D F' U F 
D' F' D B' D' F D B 
D' F' D B2 D' F D B2 
D' F2 D B' D' F2 D B 
D' F2 D B D' F2 D B' 
D' F2 D B2 D' F2 D B2


----------



## Christopher Mowla (Mar 20, 2016)

unsolved said:


> I'm doing a full-width search out to depth 8 on the 5x5x5. If all of the tredges and centers are solved, I'm capturing the sequence.
> Depth 7 already completed (93,510,461,296 nodes cumulative, including the 1 node @ depth 0) and there are 0 corner positions, for certain.
> 
> Depth 8 has found only 400 so far (2.1 trillion and counting). That's a pretty sparse distribution.
> My supposition at this point is that there will be some very deep corners-only positions for the 5x5x5.


Why are you giving your computer unnecessary stress? The corner only positions on the 5x5x5 are identical to the corner only positions on the 3x3x3. If you want to do such an analysis, do it on the 3x3x3.

Have you ever solved a big cube with the *3x3x3* reduction method to know that this is true, or have you just solved the 4x4x4 and up by using a form of cage?


----------



## cuBerBruce (Mar 20, 2016)

unsolved said:


> Depth 8 has found only 400 so far



I count essentially 11 types of corner 3-cycles that have 8-move commutators. There are 48 symmetry variations of each type for 11*48 = 528 positions. Of the 11 types, 7 have two separate 8-move commutators. That makes a total of (11+7)*48 = 864 8-move maneuvers, if you're counting maneuvers rather than positions.


----------



## unsolved (Mar 20, 2016)

cuBerBruce said:


> I count essentially 11 types of corner 3-cycles that have 8-move commutators. There are 48 symmetry variations of each type for 11*48 = 528 positions. Of the 11 types, 7 have two separate 8-move commutators. That makes a total of (11+7)*48 = 864 8-move maneuvers, if you're counting maneuvers rather than positions.



The program has gone through 35 of the 45 moves through depth 8. The most recent count shows 496. That's roughly ~640 if they're evenly distributed. I'm only counting unique cube positions. If a different set of moves produces the same cube, it does not get counted thereafter. We'll have to see what the final tally shows.

*EDIT: Here are all of the various counts so far:*



DepthCumulative Node CountOnly Centers UnsolvedOnly Tredges UnsolvedOnly Corners Unsolved0100014600021,666000359,08600042,095,696366300574,331,4961,04484062,636,431,69620,4816280793,510,461,296140,9172,452083,316,682,338,6961,707,43132,7155289*4,172,450,898,004,695*(no data yet)*165,602*(no data yet)10*147,990,866,406,820,695*(no data yet)*1,722,997*(no data yet)

*By "only tredges unsolved" I mean if any middle edge or wing edge is not solved, while the rest of the cube is solved, I include it in the count.*



Christopher Mowla said:


> Why are you giving your computer unnecessary stress?



I've got 8 CPU cores. The Intel i7-5960X overclocked to 4.6 GHz outperforms every computer on the planet. It feels no pain.

I'm enumerating corners-only, tredge-only, and centers-only disturbed positions. The one with the fewest instances per depth is the worst to solve last. As it turns out, this will be the corners.

Theoretically, solving corners first, tredges next, and centers last should produce, on average, the lowest move counts per solve.


----------



## unsolved (Mar 21, 2016)

Christopher Mowla said:


> In addition, there are no odd permutation "corners only" positions on the odd nxnxn cube (which includes a 2 corner swap only). So you only have to consider 88,179,840 corner only positions for the even nxnxn cube, but 44,089,920 for the odd nxnxn cube.



But there are sequences with an odd number of moves that can create positions with only corners being unsolved, right? Or is this not what you meant.

Example:

R U' R D2 R' U R D2 R2


----------



## shadowslice e (Mar 21, 2016)

unsolved said:


> But there are sequences with an odd number of moves that can create positions with only corners being unsolved, right? Or is this not what you meant.
> 
> Example:
> 
> R U' R D2 R' U R D2 R2



He means on odd layered cubes you can't get a single 2-swap of corners in the way you demonstrated with a 4x4 above. These can only exist on even layered cubes due to PLL parity. (essentially, there must always be an even number of 2 swaps to have even "parity").


----------



## unsolved (Mar 21, 2016)

shadowslice e said:


> He means ...



Thanks!


----------



## qqwref (Mar 21, 2016)

unsolved said:


> I'm enumerating corners-only, tredge-only, and centers-only disturbed positions. The one with the fewest instances per depth is the worst to solve last. As it turns out, this will be the corners.
> 
> Theoretically, solving corners first, tredges next, and centers last should produce, on average, the lowest move counts per solve.


I'm not sure if this way of looking at things is right or not, but I do know it doesn't take all factors into account. When talking about what order to solve groups of pieces in, you also want to consider what kinds of moves and move sequences are allowed, and what are not, based on what you have already solved and must keep in place. The question to consider for each piece type is, how many moves do I lose due to having to respect the earlier steps?

Of course, usually this number can't be known for sure, but it is something that can be reasoned about. For instance, although there are 4-move centers only cases, they only affect six centers out of 48 (and in a very specific pattern, too), whereas you could otherwise do something like r U b and affect many centers at once in a few moves - giving a pattern that would require many more moves to solve if you know you can't disturb the edges or corners. So one could argue that the restriction of having all the edges and corners in place could potentially cost a lot of moves. With corners, on the other hand, you are looking at 11 moves to solve them first and maybe 18-20 to solve them last. Are those 7-9 moves worth that restriction in movement for the whole rest of the solve?

However - corners last should really never be considered. That's because they should always be solved while solving the middle edges. I'll explain.

There are really two fundamentally different types of edges, and lumping them together as a "tredge" can obscure some important points. I'll call them middles (the one in the center of each edge, which only shows up on odd-layered cubes) and wings (the rest). The two big distinctions are (a) middles have two possible orientations (and thus can be flipped) whereas wings only have one; and (b) like corners, _middles can only be moved using turns of the outer layer_ (relative to the fixed centers). The net effect is that middles can be treated like 3x3x3 edges.

This matters because, as any 3x3x3 solver knows, solving corners first and then edges, or edges first and then corners, is slower and takes more moves than just solving the whole cube directly. So if you think of the tredges as two separate steps - solve the middle, and, pair the tredges (i.e. get each middle next to its two corresponding wings) - then it immediately makes sense to combine the "solve the middle" step with solving the corners, in a 3x3x3 stage, like we do in reduction methods. Then really the three steps are solving the centers, pairing the tredges, and the 3x3x3 stage, and now it makes more sense to argue about how to order them. And of course, the 3x3x3 stage can be done in the same number of moves at any point in the solve, so you might as well do it last.


----------



## unsolved (Mar 21, 2016)

R' 3F' 3R 2F B 2L L2 B 2U2 // 29 centers + 12 correct edge pieces
2R 2D' B' 2R2 U 2R2 B 2D 2R' // 30 centers + 16 edges
R' U' R2 2F2 R2 2F' U R // 29 centers + 20 edges
2F2 2L2 2F 2U' 2L2 2U 2F // 36 centers + 20 edges
F2 2L' U 2L U' F2 // 34 centers + 23 edges
F 2F R' 3F R 2B' B' // 37 centers + 23 edges
2B L' 2F' L' 2F L2 2B' // 40 centers + 23 edges
R' F 2L F 2L' F2 R // 42 centers + 23 edges
U2 2R' D 2R U2 2R' D' 2R // 42 centers + 25 edges
2B R' B 2R' B' R 2B' // 38 centers + 29 edges
R 2R2 2B' 2D' 2B 2D R' 2R2 // 42 centers + 29 edges
3F' 2R' F 2D' 3F 2D F' 2R // 45 centers + 29 edges
2F U' F 3R2 F2 3R2 F U 2F' // 45 centers + 31 edges
F 3R F' L' F 3R' F' L // 45 centers + 34 edges
2B R2 2B' 2R2 2B R2 2B' 2R2 // 48 centers + 34 edges
2R D' 2R' 2D' 2R D 2R' 2D // 50 centers + 34 edges
3F2 2U' F 2U 3F2 2U' F'2U // 52 centers + 34 edges + beating dead horse = off


----------



## qqwref (Mar 22, 2016)

So, 132 moves + parity + center 3-cycle + corners? Not very efficient for a computer solver; humans have even done shorter FMC solves. But it's definitely a good start.

In case you didn't read my post in detail and just angrily skimmed it, I'll point out here that solving pieces in any order is entirely possible, and with computing power and cleverness most of them can be more efficient than a human. My point was that some piece orders will be much more efficient than others, and if you want the best order, you can rule out corners last.


----------



## Christopher Mowla (Mar 22, 2016)

unsolved said:


> But there are sequences with an odd number of moves that can create positions with only corners being unsolved, right? Or is this not what you meant.
> 
> Example:
> 
> R U' R D2 R' U R D2 R2


Odd permutation is != to an odd number of "moves". Odd permutation ==odd number of *quarter turn* moves.

This sequence you showed consists of an _even_ number of quarter turn moves (12q). h moves, s moves and/or e moves (all of these terms are from Lucas's applet algorithm length counters) *are irrelevant* to determining if the permutation is odd or even.


@qqwref, I doubt he will understand your mention of reduction, because, by the signs I have seen in his responses since he's been a member here, and seeing his trivial big cube algorithm requests (asking for algorithms for positions which can be achieved from a direct translation of a 3x3x3 algorithm), I don't think he has ever solved a big cube with reduction before.


----------



## unsolved (Mar 22, 2016)

The program took 11.57 seconds to get that far before running out of precomputed algs to apply. That won't last long.

*EDIT: *The whole point of the computer solve was to show that trying to solve edges into their correct spots + centers simultaneously, perhaps the least efficient way to execute a solve, still produces a very high count of initially solved pieces after a very shallow move sequence was applied.* This is the exact opposite of what Gottlieb predicted*. The program never searched. It blindly applied a "sticker count" algorithm to determine which pre-computed set of moves led to the highest count of solved stickers, awarded +2 for an edge or wing, and +1 for a center. That's why the center counts go up and down (down when more edges are found as a result of the sacrifice).

Furthermore, you'll notice the longest sequence never exceeded 9 moves. It's still building all of those algs but it had enough computed for me to test it out. And that was a "1-pass" attempt. Since there's only ~41,000 tredges algs so far, I could search every possible instance paired up, the square of that number, in about 3 seconds. That will definitely give the highest count of solved edges possible in 2 turns, which can be greater than the 1-pass approach applied twice.

Solving corners first, tredges next, and centers last will cut down the movecount drastically. A caged cube can only be solved by moves that create cages, applied in reverse. By applying all of the cage algs to a solved cube, saving the solutions, hashing them, and then applying all of the cage algs to the unsolved cage while probing the hash table of the cages in RAM, the program will have a solving radius == to twice the deepest cage alg. I don't do this as of yet. When the program is finalized, it will have a 20-move horizon that can be probed in the time required to complete a search of only 10 moves.

*Solving centers-first in 51 moves (quick example)*

https://alg.cubing.net/?setup=B_D2_...2_//_centers_solved_in_51_moves&view=playback


----------



## ch_ts (Mar 22, 2016)

@unsolved: You're using the term "reduction" differently from everybody else in this forum. People use it to mean reducing a puzzle to a smaller puzzle (an easier puzzle than the original puzzle). Generally, large nxnxn cubes are reduced to 3x3x3, and then we can use 3x3x3 methods to finish it off. They could be reduced to puzzles other than 3x3x3 but it is generally more difficult. For example, a 4x4x4 cube can be reduced to other puzzles like 2x2x2 (or 3x3x4 or 3x3x2) and that could be called reduction. But what is usually done is people reduce it to 3x3x3 by solving the centers and pairing up the edges. This is what people here are calling reduction. The cube in my avatar is considered "reduced" because at this point it can be solved like a regular 3x3x3 cube (for simplicity, let's say we don't have orientation or permutation parities) using regular 3x3x3 moves (no inner layer turns) and regular 3x3x3 methods. Note that the dedges do not have to be solved into their places for it to be considered reduced. Now at this point, we know that it is at most 20 moves away from solved.

Add: Similarly for 5x5x5, the tredges do not have to be solved into their correct places. Then at that point, you'd be at most 20 moves away from solving the entire cube (tredges and corners). If using Kociemba's 2-phase algorithm, most likely under 25 moves would suffice.


----------



## qqwref (Mar 22, 2016)

unsolved said:


> ]The whole point of the computer solve was to show that trying to solve edges into their correct spots + centers simultaneously, perhaps the least efficient way to execute a solve, still produces a very high count of initially solved pieces after a very shallow move sequence was applied.* This is the exact opposite of what Gottlieb predicted*.


If you think this is the opposite of what I predicted, then either you misinterpreted my post or I explained my idea poorly, because I predicted nothing like this at all.


----------



## Christopher Mowla (Mar 22, 2016)

@unsolved,

How many moves would your solver take to complete this state? I basically used Bruce's 4x4x4 solver to solve the X centers, wing edges, and corners simultaneously of your example almost-complete solution. (I used the same generating sequence.)

Also, I did a reduction solve (this is what we mean by reduction), but didn't get a very good solution. (147 moves total with 3x3x3 solver assistance for the last part of the solution.)

B 3L F' 2D' U' 2B2 L' 2B' 2U' //first center
F2 2R F 2L2 B 2U' B2 R' 2U' F B 2U2 2F' R' 2F D' U' B' 2R F D2 2L2 2F D 2F' U' 2B' R 2B D2 3B F 2U F2 2U' 3F //2nd center
U' 2B U 2B' //3rd center
2R2 U 2R2 U 2R2 U' 2R2 //4th center
2L L' U 2L' L' U 2R B2 2R' //last 2 centers
R F L D 2B' D' U2 B U' L U F R' F' 2R' F2 D F2 D' F L2 F' R' D' R D 2R L' F B D' R2 B' R' D R D' R 2F' //pair wings
U' F' 3U B' U B 3D L 3U F U2 F' 3D B D' B' 3D2 F2 3D2 L' 3D2 R D' R' 3D2 // pair tredges
D R2 F2 D2 R U B U' F D' F2 L F' U2 R' U' F U2 x' y //3x3x3


----------



## unsolved (Mar 22, 2016)

Christopher Mowla said:


> @unsolved,
> 
> How many moves would your solver take to complete...



That depends. I can have it do a quick solve with respect to time (greater number of moves) or a long solve with respect to time, and get the fewest moves possible. I just set it up now on the long solve/lowest move count mode.

*Quick Solve Mode* (41 moves, but pretty fast)

https://alg.cubing.net/?puzzle=5x5x...2_2L_D-_B_3R2&title=no it ain't&view=playback

Error in new rotation code could not load other algs for center solves. Debugging that now.

*Deep Solve Mode* (22 moves, but 9+ hours of compute time)
D2 3R D 3R D B' 3R2 B2 3U' R 3U' R' 3U2 B' 3U' R' D R 3U R' D' R completes the cage. 

https://alg.cubing.net/?puzzle=5x5x...s_solved&view=playback&title=5x5x5 Deep Solve

The rest would be uninteresting but I can have it solve it completely if you want.


----------



## Christopher Mowla (Mar 22, 2016)

unsolved said:


> The rest would be uninteresting but I can have it solve it completely if you want.


Look at the total move count: 79 moves. The cube's state is very close to what your cube state was at 132 moves (but probably in a "much better shape" than the cube you showed at 132 moves). I was just curious to see if this could give you any ideas, but clearly it's fewer moves than your solver's current approach. (It took less than a second for Bruce's program to spit out that solution on my _ordinary_ laptop.)


----------



## unsolved (Apr 13, 2016)

Christopher Mowla said:


> I was just curious to see if this could give you any ideas, but clearly it's fewer moves than your solver's current approach. (It took less than a second for Bruce's program to spit out that solution on my _ordinary_ laptop.)



1. The 132-move example was a COUNTER-solve. That is, it is the OPPOSITE of the way my solver solves things. I *do not* try to solve tredges + centers first. I wanted to show Gottlieb that even the worst STRATEGIC solving method could TACTICALLY still produce extremely efficient counts of "centers being solved" using very few moves. There were 29 centers solved with just 7-9 moves, I forget the exact count. He was claiming that my approach wouldn't amount to much.

2. The 5x5x5 has *234,212,260,435,431,232,696,695 nodes* to search through *depth 14*. I completed that search in 9 hours 33 minutes. That works out to *6,822,378,690,225,203,399 per second*. The final 8 moves of the 22 shown were found in under one second.

3. Since you asked for the most expedient solve, including centers, I did a search. If this was done via pre-computed algs without concern for trying to maximize centers along the way, it could have taken a fraction of a second as well.

*EDIT: *I recomputed the centers algorithm code. I noticed some algs were "missing" after reviewing some of the solves. My pruning mechanism was "off by 1," overpruning some entries by forgetting to take into account the depth remaining is 1-based and not 0-based. Also added a new pruning mechanism that halts move generation whenever a cage is created and more moves remain in the search. Since the only way to create a unique cage at depth "d" requires it to be completed on the last move, creating a cage after "d - n" moves can only complete a cage by making back-to-back cage sequences that have already been computed. There is no point in accumulating such "algs" as they can be created in cascade. While this slows down the search rate, the pruning effect is tremendous. Depth 9 would take 4 days previously, and now depth 10 is completed after 1 day. (Note: This includes time to write the algs to disk, which is very slow compared to RAM operations, with the net effect of making the process somewhat slow).

*EDIT: Update April 12, 2016 with new numbers in bold:*


DepthCumulative Node CountOnly Centers UnsolvedOnly Tredges UnsolvedOnly Corners Unsolved0100014600021,666000359,08600042,095,696*432*300574,331,496*1,296*84062,636,431,696*39,192*6280793,510,461,296*255,072*2,452083,316,682,338,696*4,688,250*32,71552894,172,450,898,004,696*48,049,962*165,602(no data yet)10147,990,866,406,820,696*770,510,826*1,722,997(no data yet)115,249,024,392,428,376,696(no data yet)12,247,590(no data yet)

Each of the sequences that produces unsolved centers or unsolved tredges is being saved as an "alg." When applied in reverse, it restores the cube. It looks like I'll have the ability to store every tredge alg through depth 12. Some of the ones at depth 11 are a bit unusual. For example:

3R2 3F 2R2 2L2 D 2R2 2L2 3F2 D' 3F 3R2

And this one at depth 12:

R L 2U2 3U R' D2 R 2U2 3U' L' F2 R'

But you can see the power of having every such alg possible pre-computed and ready for testing. Instead of spawning nodes that do nothing to get towards the solve, I'll have about 120 million algs that effect tredges without disturbing the rest of the cube. I'll still need to manually encode a few algs for last layer stuff.

*EDIT*: Even more surprising is the number of centers that can be jostled around with just one alg. At depth 11, here is a case where 26 of the 48 unfixed centers are in motion:

2R 3U' 2F' 2R' 3U2 2L 3U 2F 3U 2L' 3U

While a very over-specific case, it is still obvious that even an inexact match of algs like this will have the capability to get a nice chunk of centers solved in one fell swoop. At present count, I have 1.2 billion center algs, not yet 10% of the way through depth 11. I am very curious to see how this will effect the final move count.


----------

