# 3x3x3 Guimond-style Method



## Cride5 (Sep 14, 2009)

This is a method for solving the 3x3x3 cube using the same principles used in the 2x2x2 Guimond method. The idea is to do: *orientation*, followed by *separation*, followed by *permutation*. The method bares some similarities to the Orient-First method and the Human Thistlethwaite algorithm (particularly in the first steps), but there are also a lot of differences. It uses less algorithms, and uses steps which cubers may already be familiar with, including Edge Orientation, Guimond (steps 1 and 2), PLL, and CF/Roux edge permutation.

I'm not sure how appropriate this method would be as a fewest-moves one, since it breaks down the solve into many distinct steps. Possibly, by combining the steps better move counts could be achieved. Because recognition for most steps is fairly straight forward, and the algs can be made quite finger friendly (ie, with M-slice moves), the method may have some potential for speed solving. However, even if not used for any competitive purpose, it can be a fun way to practice many sub-steps including ZZ-style EO, Guimond, PLL etc.

The method broadly goes as follows:

 Edge Orientation
 Corner Orientation
 Mid-Edge Grouping
 Corner Separation
 U/D Edge Separation
 Solve E-Slice
 U-Layer PLL
 D-Layer PLL 


Method Detail

 *Edge Orientation*
This is exactly the same as the first step of ZZ, but without placement of the line. A fairly detailed outline of how to do this can be found here.


 *Corner Orientation*
This is exactly the same as the first step of Guimond, but with the restriction of not using any F/B moves. Ensuring there are no F/B moves can be achieved by doing an E-slice quarter turn when ever an alg would require an F/B move. Its also possible to go for an Ortega-style corner orientation, by placing four oriented U/D corners in the D-layer, then using an OCLL alg to orient the U-layer corners.


 *Mid-edge Grouping*
The goal of this step is to place all the E-slice edges into the E-slice (but not necessarily solved). The basic technique in this step swaps the two E-slice edges (FL and BL) with the two U/D layer edges UR and DR using:
*R E2 R'*
*L E2 L'* (mirrored)
To set up for the swap alg, R2/L2/F2/B2 moves can be used to position the mid-slice edges in FL/BL and theh same moves plus U/D can be used to position the mid layer edges in the UR and DR. 

Where there are an odd number of U/D layer edges in the E-slice, it will be necessary to swap an even number of mid-edges with an odd number of U/D edges (or visa-versa).


 *Corner Separation*
This is exactly the same as Guimond corner separation. Because only R2, L2, F2, B2, U and D moves are used, all previous work done on the cube is preserved.


 *Edge Separation*
This is a very short/easy step. The basic technique for this step is to swap UF and DF using:
*M' U2 M*
It is also possible to swap four opposite edges at a time using:
*M' E2 M'*
Finally, all four edges can be swapped using:
*M2 S2*


 *Solve E-Slice*
This step is again fairly easy and can be completed using R2/E-slice moves (in a similar manner to the final step of Roux). However, if the E-slice looks like an N-Perm, T-Perm or its solved apart from a single bar which needs to be twisted by 180 degrees, then you have 'parity', which can be solved using:
*R2 U2 R2 U2 R2* (the same as SQ-1 parity)

EDIT: qqwref pointed out that when E-Slice parity occurs, one of the U/D layers will be solvable with PLL. Ensuring the solvable U/D layer is positioned in D when mid-layer parity is executed will avoid parity occurring in step 7..



 *U and D layer PLL*
This will usually be the same PLL cases as expected, however there is again the possibility of parity (which will occur 50% of the time). It's caused by the U and D layer permutations requiring an odd number of swaps to solve individually. It can be fixed by using:
*M2 U2 M2*


Method Variants
As it stands, the method has a LOT of (simple) sub-steps which can be combined by adding algorithms. For example, the separation steps 4 and 5 combined together would have about 164 cases (less if not counting mirrors/inverses) and have fairly straightforward recognition.

The final three permutation steps could be combined in different ways. For example, new PBL algs which preserve edge separation could be used to solve the corners, and then all edges edges could be solved in one step which would require roughly about 4^3 = 64 algs. 



Example Solves

Scramble: B2 D' L2 U B2 R2 B2 L2 D' B2 F D' B U B R' D' R F R2 
Solution:
Edge Orientation: *B' L R2 U F*
Corner Orientation: *L D R U' R'* 
Mid-Edge Grouping: *L2 U D2 R E2 R'*
Corner Separation: *F2 U' F2 U' F2*
Edge Separation: *M' E2 M'*
E-Slice Parity: *R2 U2 R2 U2 R2*
E-Slice Solve: *E L2 E' L2*
D-Layer PLL - R(a): *x2 y R U2 R' U2 R B' R' U' R U R B R2' U2*
U-Layer PLL - E: *x z R U' R' D R U R' u2 R' U R D R' U' R*
(62 moves STM)

Scramble:L2 F2 D' U R2 U' L2 U2 B2 U' B D L' F' D' U' R D B L U
Solution:
Edge Orientation:* B' D2 R F' *
Corner Orientation: *R d' F E' R y2*
Mid-Edge Grouping: *B2 R E2 R' y2*
Corner Separation: *D2 R2 U' L2*
Edge Separation: *S U2 S' D M U2 M'*
E-Slice Solve: *E R2 E' R2*
PLL Parity: *M2 U2 M2*
U-Layer PLL - A(b): *y2 R B' R F2 R' B R F2 R2 U'*
D-Layer PLL - R(a): *x2 R U2 R' U2 R B' R' U' R U R B R2' U*
(55 moves STM)


----------



## Cride5 (Sep 14, 2009)

*Combining steps 4 and 5: Number of cases*

I'm not sure if anyone can help me on this one, but I can only really give an estimate for the number of cases for combining steps 4 and 5, and here's my reasoning:

To count the number of cases first look at the number of edges and corners which need to be swapped:
Corners, 0 to 4 (5 cases)
Edges, 0 to 4 (5 cases)
So combined into one step that's 5*5 = 25 swap cases.

Now looking at the number of possible arrangements for each case (on one-layer only). Corners:
0 = 1 case
1 = 4 cases
2 = 6 cases
3 = 4 cases
5 = 1 case
= 16 cases
Edges = 16 cases (same reasoning as corners)

Now combined together in one layer that's 16*16 = 256. Because AUF is possible that reduces it to 64 cases (for each side).

Assuming both sides were independent the total number of cases would be 64*64. However since the number of edges/corners in one layer dictates the number in the other, its not as high as this.

... Here's where the reasoning breaks down: 
Because there are 25 distinct swap cases, the average number of cases for the other side, given the swap case is fixed is 64/25. 

So the total number of cases (estimated) = 64 * 64/25 ~= 164

I can't think of a way to count the number number of cases for the other side, other than just working it out for each of the 25 swap cases. If anyone can help please do :confused:


----------



## Spitfire97 (Oct 2, 2009)

I have practiced this and now average 45 seconds with it(since I suck at EO)
It would have to be practiced ALOT to become fast as fridrich or ZZ or Roux Or petrus.
JUst my opinion


----------



## Cride5 (Oct 2, 2009)

45 sec is not bad 

Never really properly practised this method for speed, but I'll give it a go...

stats:
number of times: 31/31
best time: 44.14
worst time: 2:08.19
best avg5: 53.76 (σ = 3.40)
best avg12: 57.46 (σ = 7.35)
times:
1:45.88, 2:08.19, 1:15.94, 1:17.41, 1:10.00, 1:03.79, 55.73, 1:13.78, 1:52.09, 1:21.82, 1:07.75, 1:36.22, 1:05.30, 1:14.50, 1:16.65, 59.84, 48.88, 1:08.84, 1:08.73, 44.14, 1:06.09, 51.63, 1:07.67, 1:13.50, 1:04.00, 52.24, 50.57, 1:03.45, 58.47, 44.36, 56.16 ... started really bad, but got sub 1 min fairly quickly.

I changed my technique a little for the last 3 steps. Instead of solving the middle first, I do the PLLs first to minimise the number of parity moves done. The procedure goes as follows:

*Step 6*. Check a layer for PLL
+ If possible do PLL, then on to step 7.
+ If not possible do x2 and check other layer for PLL
|--> If other layer possible do PLL
|--> If other layer not possible do M2 U2 M2, then PLL
*Step 7*. Check last layer for PLL (if not checked already)
+ If not possible do R2 U2 R2 U2 R2
Now do final PLL
*Step 8*. Solve middle layer

I prefer doing this because I find detecting parity on the outer layers easier than in the middle layer for some reason.


Even though the move count isn't too bad, I found that there are too many 'little' steps which each require their own inspection. A lot of the steps require inspection of both sides of the cube as well, which makes recognition quite slow.

Not a bad method for a bit of fun, but I deffo won't be swapping it for ZZ!


----------



## ErikJ (Oct 2, 2009)

you do know that Guimond was a CF method for 3x3 right?


----------



## Cride5 (Oct 2, 2009)

Yeah for sure, but it was pure CF - ie. completely solve the corners, followed by the edges. This method solves corners and edges simultaneously, by following the principal of orientation -> separation -> permutation. I called it Guimond-style (rather than Guimond) for this reason. Maybe it needs a proper name, but I'd hesitate to name it myself in case it has already been proposed elsewhere..


----------



## AvGalen (Oct 2, 2009)

How could you possibly suggest this method for FMC? Even your examples show that it requires more moves than CFOP and that is when counting in STM, not QTM. And CFOP is a bad method for FMC by itself!

Just doing the two PLL steps at the end will require AT LEAST 9+9 moves, but about 25 moves seems more realistic. That by itself is almost an entire FMC solve.

I agree that this method would be fun and useful to learn though.


----------



## Cride5 (Oct 2, 2009)

When I said: "_I'm not sure how appropriate this method would be as a fewest-moves one, since it breaks down the solve into many distinct steps._", I was in a round about way saying I didn't really see much potential for use in FM, mainly because of the division of the solve into many steps.

A good FM technique will generally have a low number of intuitive steps, and any steps involved should be easily blurred together. This method has many steps, which mostly can't really be easily combined, and as such it would probably be difficult to achieve low move counts with it.

I was not in any way suggesting this _should_ be used for FM, I was just providing a critical analysis of the method from the point of view of each possible application.


----------



## AvGalen (Oct 2, 2009)

Cride5 said:


> When I said: "_I'm not sure how appropriate this method would be as a fewest-moves one, since it breaks down the solve into many distinct steps._", I was in a round about way saying I didn't really see much potential for use in FM, mainly because of the division of the solve into many steps.
> 
> A good FM technique will generally have a low number of intuitive steps, and any steps involved should be easily blurred together. This method has many steps, which mostly can't really be easily combined, and as such it would probably be difficult to achieve low move counts with it.
> 
> I was not in any way suggesting this _should_ be used for FM, I was just providing a critical analysis of the method from the point of view of each possible application.


Ok, so you actually were sure that this method wouldn't be appropriate as a fewest-moves one. Glad we have that figured out

Another option for this system for the last 3 steps you could change it to a more square-1 like system:
* Top+Bottom layer corners (very much like final step of Ortega 2x2x2 as well)
* Top+Bottom layer edges (+parity) at once (or in smaller steps like a beginner square-1


----------



## Cride5 (Oct 2, 2009)

AvGalen said:


> Another option for this system for the last 3 steps you could change it to a more square-1 like system:
> * Top+Bottom layer corners (very much like final step of Ortega 2x2x2 as well)
> * Top+Bottom layer edges (+parity) at once (or in smaller steps like a beginner square-1



That's a pretty cool idea Av! 

So basically, you solve EO, then CO, then move U/D cubies out of the E-slice. Solve two adjacent E-slice cubies, and hold them on them with your left hand. From there, solving the corners is exactly like square-1 (and is quite efficient), but edges are not quite as straight forward (ie. can't be done using sq-1 algs).

A naive calculation for the number of algs it would take to complete the edges in one step would be 8! (about 40K), so it would need to be broken down into several sub-steps. Here are two possiblities:


 Use separation as described before to move edges into their correct layers, followed by EPLL both sides.


 Use Roux-style edge placement to place the UR/UL and DR/DL edges, followed by M-slice permutation. This would probably be more efficient, and use some tasty M-slice moves


----------

