# Intuitive 4x4 Method with Parity Avoidance



## dudefaceguy (Mar 24, 2019)

This is the method that I use to solve the 4x4 intuitively without using any memorized algorithms, and to easily avoid parity problems. It is based on the Sandwich method, and also shares several techniques with the Roux method. In fact, if you use this method on the 3x3 it is just Roux. I call it QTPI (cutie pie) Method, or Quarter Turn Parity Intuitive Method.

Here is a full demonstration solve with some explanation:






Here is a photo gallery of the method, with brief descriptions of the steps:



https://imgur.com/a/KQTCLCp


Here is a YouTube playlist showing short examples from steps 2-6:

https://www.youtube.com/playlist?list=PLxYYfdYl2gTjEI143CEwWfGd2uhOH0A2m

*Summary of the Method*

Solve two 1x3x4 blocks around opposite centers (similar to Roux)
Solve corners with a commutator
Extend one of the 1x3x4 blocks into a 2x3x4 block by solving one middle slice excluding the top layer
Use the unsolved slice to solve exactly 7 of the remaining 10 edge pieces
Solve the remaining 3 edge pieces and some center pieces with a commutator
Solve the remaining center pieces with 2 or 3 commutators
That's it! You should be able to do these steps intuitively without any more instruction (except maybe the corner parity explanation in step 2). The remainder of the guide is just clarification and some tips for better efficiency. Even though this method does not require you to learn any algorithms, I still refer to some algorithms in the explanation because it will be helpful to those who are familiar with them.

*Who is this method for?*

This method is for intermediate intuitive solvers who can already solve a 3x3, and want to start solving the 4x4 without memorizing algorithms.

This is not intended for complete beginners, since it assumes knowledge of concepts such as commutators and blockbuilding. But, you can still use it as a beginner if you want to learn about how the cube works. If you don't know about commutators, I suggest this video, as it goes over 4x4 commutators in particular: 4x4 Commutator Video

This is not really a speedsolving method, but perhaps it could be adapted for speedsolving, as it has a reasonably efficient move count.

My goals in making this method:

Completely intuitive - no memorized or written algorithms necessary.
Ability to solve parity problems at their source with a single quarter-turn.
Move efficiency.
Fun, which includes a varied set of problems and solving techniques that are different from a 3x3 solve.
I couldn't find any methods or tutorials designed with these goals in mind, so I made one myself.

*Detailed Explanation

Step 1: Blockbuilding* (~40-45 moves)

The goal is to end up with two 1x3x4 blocks around two opposite centers, similar to the Roux method. I usually build two opposite centers first, then hold the solved centers on L and R, and use the M slices to pair edges. But, you can really do whatever you want - user @dbeyer likes to build the perimeter of the blocks first and then drop in the centers.

In the advanced version explained below, you will instead build a 1x3x4 block and a 1x3x3 block.

*Step 2: Corners* (~9-17 moves)

If you know a set of corner algorithms such as CMLL, you can use them here and skip to the next step. But this method is for people who haven't memorized any algorithms, so I have developed a heuristic for solving last-layer corners efficiently using commutators.

First, determine corner parity like so:

Place one corner in its solved position so that it is correctly permuted.
Examine the other 3 corners. If exactly 2 are out of place and 1 is twisted in place or solved, the corners have odd parity. All other states have even parity.
Even-parity parity cases can be solved directly with commutators. If all 4 corners are incorrectly oriented, you can solve one corner with a conjugated 4-move commutator such as [F:[R,U]]. This will save 2 moves versus using an 8-move commutator.

Odd-parity cases cannot be solved directly with commutators, but every quarter-turn of any face changes corner parity between odd and even (180-degree turns like U2 count as 2 quarter turns and do not change parity). This gives us two basic options for solving odd parity cases:

Turn the top face one quarter-turn, then solve using two commutators.
Solve a different corner using an odd number of quarter-turns, then solve with one commutator.
Here's an example of converting corners from odd to even parity using the Niklas algorithm:





This heuristic will solve last-layer corners on any cubic puzzle. If you want to save some moves, you can use an advanced version that starts with 5 corners unsolved.



Spoiler: Advanced 5-corner solution, and a long explanation of parity



In this solution, you correct corners to even parity while solving the last edge of the second 1x3x4 block and any two corners at the same time. It's like Heise step 3 but without edges to guide you. This requires a more thorough understanding of parity, which will enable you to determine the parity state of any number or type of pieces.

Summary:

Step 1: Instead of solving two 1x3x4 blocks in step 1, leave out one corner/edge pair to make one 1x3x4 block and one 1x3x3 block.

Step 2a: Make the last edge needed to complete the second 1x3x4 block, and store it in the bottom layer.

Step 2b: Check corner parity

Step 2c: Solve two corners using either an odd or even number of quarter-turns, ensuring that corners will have even parity; insert the edge from step 3a into the solution such that it will be solved as well.

Step 2d: Solve the last 2 or 3 corners with a commutator.

If you know the Heise method for the 3x3, you will know that step 3 forces the last 3 corners to have even parity by solving all edges first. This makes it possible to solve the last 3 corners with a commutator. With the 4x4, this technique does not work because corner parity and edge parity are independent. If we wait to solve the corners until the end of the solve (as in Heise), we can end up with odd corner parity, which is also known as a form of PLL parity. Fixing this at the end of the solve can be done intuitively, but it requires discarding and re-solving large portions of the puzzle. So, we are instead going to solve corners now when it is easy to fix parity problems.

First, since we are solving intuitively, we have to understand what parity is. In group theory, parity refers to the number of swaps required to sort a particular permutation. If you can sort a permutation using an odd number of swaps, the permutation has odd parity, and if you can sort a permutation using an even number of swaps, the permutation has even parity. For some really interesting discussions of parity, I recommend the following resources:

Ryan Heise's parity explanation for the 3x3
https://www.ryanheise.com/cube/parity.html

The Parity of Permutations and the Futurama Theorem





A long parity essay about the 4x4
https://hlavolam.maweb.eu/parity-problem

Commutators are the secret weapon of the intuitive solver, but they cannot solve odd parity permutations, because they must always do an even number of swaps. So, we have to make sure that our last three corners have even parity before we can solve them with a commutator. We can determine corner parity by counting the number of swaps it will take to permute all of the corners. If you do blind solving, you already know how to do this. For our purposes here, we can use a simplified version. After a bit of practice, this can be done in a few seconds.

First, pick any incorrectly permuted corner (i.e. corners that are in the wrong place - corners twisted in place count as "solved" because we are only considering permutation, not orientation). Find its solved position; this is one swap. Now take note of the corner that is currently in this position and find its solved position; this is a second swap. Continue doing this until you come back to the original piece; this is one cycle. When counting swaps, don't count the starting piece itself, either at the beginning or the end of a cycle.

All of the corners may be in the same cycle, or they may be arranged in multiple separate cycles. Whatever the arrangement, the number of swaps it takes to solve a particular group of pieces will always equal the number of incorrectly permuted pieces minus the number of cycles. To express this as a formula, if p represents the number of pieces, c represents the number of cycles, and s represents the number of swaps needed to solve these pieces, then s=p-c. So in order to determine parity, we really only need to count the number of cycles, then subtract that number from the number of incorrectly permuted pieces. We can look at an easy example using four letters:

B C D A

Let's trace the swaps needed to put them in alphabetical order, starting with A. A belongs in B's spot, B belongs in C's spot, C belongs in D's spot, and D belongs in A's spot. All four letters are in the same cycle, and three swaps will sort all of the letters into their correct places. This arrangement has odd parity: 4 letters minus 1 cycle equals 3 swaps. Now look at this example:

C D A B

Here, the letters are arranged in two separate cycles, and we can sort them using only two swaps. This arrangement has even parity: 4 letters minus 2 cycles equals 2 swaps. Note that this example is the same as the previous example, except that the letters have all been rotated one spot to the left. This should help to illustrate how a quarter-turn switches pieces between odd and even parity.

We can apply exactly the same analysis to our corners quite easily. Count the number of corners that are out of place (don't count corners twisted in place), subtract the number of cycles it takes to permute them, and that number will tell you whether the corners have odd or even parity.

After we determine parity, our next goal is to solve two corners such that 3 corners remain unsolved with even parity. We can do this by solving 2 of our 5 unsolved corners using either an odd or an even number of quarter turns. 4-move commutators are very useful here. Remember that a 180 degree turn like U2 counts as two quarter turns. Once you have 3 corners unsolved and even parity, solve the last 3 corners with a single commutator.

You can solve the last edge of the second 1x3x4 block during step 2c in three different ways, listed here from easiest to most difficult:


Keep the edge in the bottom layer, solve all corners, then insert the edge afterwards. This is the easiest and least move-efficient solution - it is often less efficient than the 4 corner solution.
Pair the edge with the corner that will complete the 1x3x4 block, and then solve that pair while also solving one top-layer corner. This is relatively easy to visualize, but restricts your solving options.
Keep the edge in the bottom layer until the last few moves of your solution, then pair it with whichever corner will end up in the bottom layer, whether or not that corner is solved. This gives you the freedom to solve any two corners while also solving the last edge efficiently, but it is difficult to visualize because the edge and corner may not match.

Personally I have found this 5-corner solution to be quite challenging, but extremely fun and interesting. Both the 5-corner and the 4-corner solutions work as a method for solving corners on any cubic puzzle reasonably efficiently. Practicing with a 2x2 can be very helpful.



*Step 3: Solve 3/4 of one middle slice, to extend one 1x3x4 block into a 2x3x4 block.* (~14 moves)






This is more block building, but you have to use entirely new tactics that don't apply to 3x3. It took me some time to get the hang of this step, but I can now complete it in 12-15 moves. You can use several techniques to connect center pairs with edge pieces and insert them, but this is the most efficient way I have found:

1. Place a bottom-layer wing edge piece in the top layer on the L or R side, oriented such that the color you want to pair is on the U face.
2. Rotate the slices to join center pieces with the edge, making a bar that goes from the L to the R face - perpendicular to the slice where it will be inserted. Rotate the U layer 180 degrees to shift the edge piece between the L and R side, depending on where the center pieces are located.
3. Once the two center pieces are joined to the edge piece, rotate the U layer 90 degrees to place the three pieces in the correct slice, then rotate that slice to insert the trio.

It's not obvious, but this step sets up the last step to use efficient 4-move commutators.

*Step 4: Use the unsolved slice to solve 7 of the remaining 10 edge pieces.* (~14 moves)






It took me a while to get the hang of this as well, but it is more efficient than using commutators for all 10 edge pieces. Instead of pairing adjacent edges, you pair opposite edges in the unsolved slice, then insert them into the top face. The principal is the same as that used in step 4b of the Roux method.

The goal here is to arrive at a state in which three edge pieces are unsolved, which will mean that we have even edge parity, and we can solve these last three edge pieces with one commutator.

There are a lot of different ways to do this, but I like to solve all of the edge pieces except for those in the unsolved slice. It's not guaranteed to end up with only 3 pieces unsolved if you do this, but the odds are favorable - for the even parity cases, you have a 2/3 chance for 3 unsolved pieces, a 1/6 chance for 4 unsolved pieces (which you can solve using 2 commutators), and a 1/6 chance for a skip in which all 4 pieces are solved. This is my preferred technique because of that sweet and satisfying skip. However, you can frequently save a lot of moves by just looking out for good cases and solving whatever edges are easiest.

It's usually not necessary to check for parity since you will correct it automatically by arriving at a state with 3 unsolved edge pieces, which is an even parity state. 2 unsolved edge pieces means odd parity. If you want to check parity earlier, or if you have more than 3 unsolved pieces, you can trace swaps and cycles just as we did when solving the corners. Note that individual wing edge pieces cannot be flipped in place, so a flipped edge piece must always be permuted to be solved.

If you have odd edge parity, simply do a single quarter turn of the unsolved slice to get to even parity. That's all it takes to avoid edge parity problems. Once you have even parity, you can check which of the two even-parity positions is most favorable for edges and centers - switch between them with a 180 degree turn of the unsolved slice.

*Step 5: Use a commutator to solve the last 3 edge pieces and some center pieces.* (~10 moves)






Since edges now have even parity, we can solve the last edge pieces with a commutator instead of learning a set of "last edges" algorithms.

It's possible to include either three or six center pieces along with the edge commutator and conjugate, similarly to how we construct a pair 3-cycle on a 3x3 cube. This is easiest to see if the edges are not conjugated outside of the M slice layers. You can also include center pieces in your conjugates, of course. Sometimes it even makes sense to conjugate only the centers with a wide S2 or E2 move.

Using tricks like this, it's possible to move a lot of center pieces along with the edge commutators, without increasing the move count much or at all. Solving even one center piece during this step can end up being very helpful, since it could decrease the number of commutators needed to solve the centers in the next step.

If you like algorithms, note that all cases in which the last 3 edges are in the same slice can be solved with the same commutator or its mirror. For example, if the unsolved slice is u, the unsolved edges are in the columns FL, FR, and BR, and the FL edge belongs in the FR column, use [L': [F' U' F, u]].


*Step 6: Center commutators* (~16-26 moves)






In this last step, we have four types of commutators available:

1. 8-move commutators, moving 3 pieces
2. 8-move pair commutators, moving 6 pieces
3. 4-move commutators, moving 6 pieces
4. 4-move pair commutators, moving 12 pieces

Because center pieces have a 1/4 chance of being solved randomly, you will most often end up with 7 or 8 unsolved pieces, just by random chance, or less if you were able to solve some more center pieces along with your edge commutator. Centers will usually take 2 or 3 commutators to solve, the first of which can usually be a 4-move commutator that moves 6 pieces. Examples of 4-move center commutators include r u2 r' u2 and r2 u2 r'2 u2.

One of the strengths of this method is that step 3 sets up the centers for 4-move commutators in step 6. Because of this, you will often be able to easily conjugate a 4-move commutator with a wide slice move. Note that 4-move commutators can be extremely efficient, even with long conjugates. I frequently solve 5 pieces with a single 4-move commutator, which is very efficient even if it requires a 3-move conjugate for a total of 10 moves. It's worth studying and understanding how these 4-move commutators work.

Once you complete the centers, the cube is solved!

*Some additional questions

Wait, what about PLL and OLL parity?*

Since we are solving pieces directly and ensuring even edge parity in step 4, we will never get PLL or OLL edge parity problems. We avoid corner permutation parity problems in step 2.

*Does this work with larger cubes?*

Yes! It needs a few modifications for odd-layer cubes, but it certainly works. Adding the middle slice on the 5x5 actually enables us to solve proportionally more of the center pieces before the last step: 65% on the 5x5 vs about 58% on the 4x4. However, the method gets progressively less efficient as the cubes get larger than 5x5, since you always have to leave 5/8 of the wing slice centers unsolved, and there are proportionally more center pieces versus edge pieces as cubes get lager. But hey, at least you don't have to learn any parity algorithms!

Here is the modified method for 5x5:

1. 1x4x4 block and 1x4x5 block around opposite centers.

2. 3/4 of the middle slice, matching the 1x4x5 block (this makes a cool-looking pattern!)

3. Pair (not solve) the last edge of the second 1x4x4 block

4. Solve all middle edges and corners exactly as in Heise steps 3-4

5. 3/4 of a wing slice, creating a 3x4x5 block

6. 7 wing edges, using the unsolved wing slice

7. Commutator to solve last 3 wing edges

8. 3-5 center commutators

I will probably do a detailed tutorial of the 5x5 version of this method at some point, since it is really fun. You get all of the problems and techniques from the 4x4 method, plus more. You also don't need to keep track of corner parity, since you can simply use Heise steps 3 and 4 to solve the corners and middle edge pieces at the same time. You can also use different variations, such as modifying steps 1-3 to orient edges earlier: make two 1x4x4 blocks, solve 1/2 of the middle slice to match these blocks, do Petrus-style middle-edge orientation, extend one 1x4x4 block into a 1x4x5 block while solving the last middle edge piece on the bottom layer, solve another 1/4 of the middle slice to extend it to a 3/4 slice matching the 1x4x5 block, proceed with step 4.

*Can this be adapted for speedsolving?*

Maybe, but I can't say for sure because I'm not a speedsolver. You could easily use existing algorithm sets for corners, last edges, and last centers. The method relies heavily on slice moves, though Roux solvers may not mind this. Last center commutators are not known for speed, but the Sandwich method uses them, so there is some precedent for their use in speedsolving. The method that is most similar is Roux, so perhaps a Roux solver could find common ground.

The biggest problem is likely the fact that this method uses several techniques that are not useful elsewhere. It would require lots of specific practice that would not transfer to other methods, and would not leverage other speedcubing skills. I designed the method this way on purpose. I wanted many different challenges that could be solved intuitively in a variety of ways, and were different than the challenges of the 3x3. This is the opposite of what you want in a speedsolving method.

As for my personal times, I can solve the 3x3 in about 3 minutes 35 seconds and I can solve the 4x4 using this method in about 5 2:20. My personal best is 1:444:20, which is recorded in my demonstration video. In my demonstration video, which took 4:20, it took me 2:12 to solve first blocks and corners, which is about 4 times longer than a competent solver using the Lewis method, which uses the same steps up to that point. So, if a speedy solver is 4 times faster than I am, they should be able to get to 1 minute pretty easily.

*Just how move-efficient is this method?*

For the 4x4, My personal best move count is 105, and the average of my last 5 solves (at least, those in which I counted my moves) is 110. My personal worst, including mistakes, is 137. I have only counted my moves on 5x5 twice, and I came up with 208 and 212. This is an average of 2.14 moves per piece solved, which is only slightly less efficient than my average of 1.96 moves per piece solved on the 4x4. The difference is probably due to the fact that I am just not as good at solving 5x5.

Those might seem like pretty good numbers, but keep in mind that I am not a speed cuber, so I take a really long time to complete these solves. I'm sure that many other methods would become much more efficient if you spent lots of time deliberately trying to be efficient. In my demonstration video, during which I was not trying to be efficient, my move count was 123. But a more competent cuber could probably be much more efficient than me, particularly with blockbuilding. Anyhow, I don't think that this method is amazingly move-efficient, but at least it is not inefficient.

*The End*

So, that is my method. If you have any suggestions for improvements I'd love to hear them. Please also let me know if any part of the explanation was unclear or confusing. Thanks for reading!


----------



## PapaSmurf (Mar 26, 2019)

I'll add this here: improvements for speedsolving: Applying 42 corners or even L5C will mean that you can do corners plus FR in less than 20 moves, and algorithmically. Secondly, memorising comms for L3E, or even L5E would be good, so that you reduce the amount of edges needed to solve in step 6 and you increase speed and move optimality. Similarly for the centres, you can learn comms for L5centres as it's a reduced set, therefore allowing you just to Lookahead and not think about the moves. I would encourage anyone who is good with roux and is good at big bld to get into this method, as it has a lot of potential.


----------



## dudefaceguy (Mar 26, 2019)

PapaSmurf said:


> I'll add this here: improvements for speedsolving: Applying 42 corners or even L5C will mean that you can do corners plus FR in less than 20 moves, and algorithmically. Secondly, memorising comms for L3E, or even L5E would be good, so that you reduce the amount of edges needed to solve in step 6 and you increase speed and move optimality. Similarly for the centres, you can learn comms for L5centres as it's a reduced set, therefore allowing you just to Lookahead and not think about the moves. I would encourage anyone who is good with roux and is good at big bld to get into this method, as it has a lot of potential.


Thanks, that's awesome to hear! I agree with your ideas for speed optimization and algorithms. I think one of the strengths of the method is that the last 3 edges in the same slice can always be solved with the same algorithm. The 7 edges step is also rotationless and 2gen, which I know that speedcubers like.

I suppose you could do the whole thing rotationless, from blockbuilding through the last edges. Here it would probably just be best to do Sandwich/Lewis method to get to 2 blocks + corners, since those methods are designed for speed already. This method only really departs from those with the 3/4 slice and 7 edges steps.

Center commutators seem like a big problem, since they require you to deal with the back face of the cube, and that means extra rotation and inspection time. But, you might be able to do some lookahead during previous steps. It might also be possible to construct more ergonomic commutators. I can't find anything on "L5centers" but I know that @rachmaninovian uses an algorithmic method for sandwich centers which is on the wiki: https://www.speedsolving.com/forum/threads/expansion-of-sandwich-centers.17138/


----------



## PapaSmurf (Mar 27, 2019)

L5centres is a thing that I made up. It should probably be named something like 5 cycle centres. My idea behind it: you have a possible of 10 centres being messed up. You could have all algs from U that cycle 5 of them, 4 of them, 3 of them and 2 of them. 2 of them is a Niklas, 3 is just standard comm. 4 will most likely be algs, same with 5. Then you can solve all the centres in 2 algs.


----------



## dudefaceguy (Apr 22, 2020)

I'm getting a bit faster. Here's a slightly less slow solve. The first blocks are my worst step, interestingly enough.


----------



## newtonlkh (Jun 8, 2020)

did my first QTPI solve last night! I nearly messed up everything by the 7 edges step, but managed to get back to (4/10 edges solved) state and continued. Everything then was simple commutators, but at least commutators worked (no more parity yay!)


----------



## dudefaceguy (Jun 8, 2020)

newtonlkh said:


> did my first QTPI solve last night! I nearly messed up everything by the 7 edges step, but managed to get back to (4/10 edges solved) state and continued. Everything then was simple commutators, but at least commutators worked (no more parity yay!)


Awesome! Did you find it a fun challenge?


----------



## dudefaceguy (Jul 4, 2020)

dudefaceguy said:


> Yup, that's my method! I solve the inner slice after completing both blocks, but you can really do it either way. Hm, maybe I will experiment with switching some of the steps around. Very cool that you remembered
> 
> Seems to me that it has potential as a speed method, but I don't really know since I'm not a speed solver. The most obvious problem is that it uses completely different skills compared to 3x3, so it's not as easy to leverage your existing skills. I designed it this way on purpose, because I wanted my 4x4 solves to be different than my 3x3 solves.
> 
> ...





dudefaceguy said:


> By the way, I have tried to do this, and you CANNOT solve both centers and edges using only U and r (unless I have really missed something). It's either centers first and then edges using commutators (Lewis) or edges first and then centers using commutators (QTPI and Sandwich). You can do some center control while solving edges to get a few extra center pieces solved, but I'm not sure that this is worth it. There are 10 center pieces left if you solve edges first, or 8 if you also solve the two centers in the l slice while solving edges. 1/4 of these will usually be solved by accident, so there are usually 7 or 8 center pieces left, or 6 if you solve the extra 2 center pieces while solving edges. This is the difference between 2 and 3 commutators (or 1 4-move commutator cycling 6 pieces). Center commutators/algs can be really fast, but you have to look at the bottom and back faces to recognize the case.
> 
> Anyhow, I am obviously very excited to talk about this method but I will stop now and go to sleep.





Alex Shih said:


> Do you know any specific cases where this isn't possible, or the specific reason this isn't possible? There might be a workaround (although I have a feeling that the workaround would probably be algorithmic). Also, if you want to continue this discussion, we should probably move to a different thread.


Continuing this discussion from the New Method thread.

As to solving the last 7 wing edges and the last 10 centers using only U r, I have not mathematically proven that this is impossible. But I have tried and failed to do it, for a simple reason: you need both U and r moves to solve both piece types, so solving one will scramble the other.

However, it seems that I can scramble these pieces using only U and r moves, and if that's possible then it's possible to solve them using the same move set. So now that I think about it, it may be possible. I just managed to solve all but 3 edges and 4 centers with just U r. It seems to take an absurdly large number of moves though.

Edit: Here's what I'm doing. Solve the last orange/green wing edge and the orange/green centers. Then use the F face of the r layer and the U face to solve 7 wing edges. You have to use a lot of moves to flip the edges around to the right position, but I'll see how efficient I can make it.


----------



## Alex Shih (Jul 4, 2020)

AlphaCuber is awesome said:


> I think step 5 would be too hard to do fast in a solve and you would have to learn a new style of blockbuilding for 4x4 but I think it would be cool if this works.


Personally, I don't think the ergonomics of inner slice + U are significantly worse than the ergonomics of doing outer-layer CFOP. But I could be definitely be convinced otherwise.



> This is similar to @dudefaceguy's intuitive 4x4 method, with some variations. His method uses commutators for your 5th step, to stay intuitive, but maybe you can find a faster alg based approach.


After some experimentation, I came up with this:

1. Pair up centers (2x1 center piece blocks) while solving ULUR
2. Solve the rest of the cube using U2's and inner slices (basically an analogue to 4c in normal Roux)

There are only 4 center pairs you need to solve (since the fifth one gets solved automatically). There are also 4 ULUR edges (2 in each ULUR wing) to solve, so you can solve one center pair and one ULUR piece simultaneously and repeat 3 times to reduce the amount of algs. There are only two potential problems this has:

1. As you said, it may not be possible to solve the rest of the cube using <r, u>.
2. It seems like there are a LOT of cases.

If my math is correct, there are 45 center pairing cases, 10 places for a ULUR edge piece to be, and 2 possible places to insert, creating 900 cases for step 5a. 5b has 43,200 cases. If we orient edges before, we get much lower numbers: 450 cases for 5a and 2160 for 5b. However, I have no idea how edge orientation could be implemented before these steps without drastically increasing the movecount. Also, these numbers are only upper bounds for how many algs there are (F2L technically has 384 different cases, but we obviously don't memorize 384 different algs for it). So there's hope.


----------



## trangium (Jul 4, 2020)

dudefaceguy said:


> As to solving the last 7 wing edges and the last 10 centers using only U r, I have not mathematically proven that this is impossible. But I have tried and failed to do it, for a simple reason: you need both U and r moves to solve both piece types, so solving one will scramble the other.


You can move centers around without messing up edges. One (long) alg that does this is U2 r U' r' U2 r U' r' U2 r U2 r U r' U2 r U r' U2 r'. So it should be possible to solve edges and centers with just U and r.
EDIT: (r U2)6 also moves some centers while preserving edges


----------



## dudefaceguy (Jul 4, 2020)

trangium said:


> You can move centers around without messing up edges. One (long) alg that does this is U2 r U' r' U2 r U' r' U2 r U2 r U r' U2 r U r' U2 r'. So it should be possible to solve edges and centers with just U and r.


Cool, so it is reasonably possible. But it's competing with much more efficient commutators, so I'm not sure if it's ultimately worth it to strictly enforce U r 2-gen solutions. But we will never know unless we do it, so let's do it!



Alex Shih said:


> Personally, I don't think the ergonomics of inner slice + U are significantly worse than the ergonomics of doing outer-layer CFOP. But I could be definitely be convinced otherwise.
> 
> 
> After some experimentation, I came up with this:
> ...


I recall messing around with a few different methods to try to solve centers and edges with U r. I tried creating half-center bars but rejected it for some reason - I'll go back and try optimizing.

As I said, I rejected this because the move count seemed too high to be worth it compared to solving edges first and then centers. But with an algorithmic solution it might be reasonable, especially if you get a lot of value from 2 gen restrictions. Intriguing!

Edit: solving the DBr edge along with the B and D centers can cause odd edge parity. This is why I rejected that technique. I also tried making center bars and then solving UR/UL edges, but I had to break the bars to solve the edges.
Using center control while solving edges, I'm usually left with about 5 or 6 unsolved center pieces, which is what I expected. These are solvable with 2 commutators, so 16-20 moves (or about 10 if you do it with a conjugated 4 move commutator, but recognition is hard). With 8 centers unsolved, working out algorithmic solutions should not be too hard.

But of course it should be possible to have a 2 gen solution since you can do a 2 gen scramble.


----------



## Alex Shih (Jul 4, 2020)

I've come up with a possible improvement. The first part of solving rU can actually be done intuitively without commutators by making a 2x2 block composed of 2 adjacent wings and 2 top-layer centers, although this takes a fair amount of moves and can only be done once before intuition becomes impossible. Here's a photo:


https://imgur.com/a/nSu8U2w

 (couldn't upload directly because the file size was apparently too big).

What's great is that this step completely demolishes the maximum number of algs for 5a: if EO isn't done, there are 112 cases, and if EO is done, there are 56 cases.

EDIT 1: I just realized that this step could also be used to restrict the number of 5b cases. After 5a is done, we can easily restore the 2x2 block with 1-2 moves. This reduces the maximum number of algs to 17,280 (no EO) or 864 (with EO).

EDIT 2: I realized another thing that reduces 5b algs by a ton. After the 2x2 block is restored, there are 4 unsolved half-centers. It's guaranteed that you'll be able to solve at least two of the remaining centers simultaneously with a simple r, r', or r2. This leaves two unsolved half-centers and reduces the maximum number of 5b algs to 1,440 (without EO because the r or r' would destroy edge orientation).

If necessary, we can go one step further by using wide slice moves and single slice moves to solve the last 2 centers intuitively while preserving previously solved pieces, and there is probably a way to do this with just <r, U>. So in this case, really the only thing we need to worry about are the last six edges. There are 720 cases for this (no EO) or 36 cases (with EO). However, I don't think this would be very move-efficient.


----------



## I'm A Cuber (Jul 5, 2020)

Can you explain how a 4 move center comm works? I’ve tried this method and found it very interesting, the only things I need to work on are steps 4 and 6, and 4 can be only be improved with more practice


----------



## dudefaceguy (Jul 5, 2020)

I'm A Cuber said:


> Can you explain how a 4 move center comm works? I’ve tried this method and found it very interesting, the only things I need to work on are steps 4 and 6, and 4 can be only be improved with more practice


They use exclusively slice moves - r u2 r' u2 is an example. They move 6 center pieces around, affecting 2 on F, 2 on B, 1 on U and 1 on D. Try it on a solved cube to see how it works. You will usually have to conjugate into a state where you can use these. In this method you can often do it with F' B for example. This will move 6 pieces in the r slice: [F' B: r,u2].

There is an example video above in the first post.



Alex Shih said:


> I've come up with a possible improvement. The first part of solving rU can actually be done intuitively without commutators by making a 2x2 block composed of 2 adjacent wings and 2 top-layer centers, although this takes a fair amount of moves and can only be done once before intuition becomes impossible. Here's a photo:
> 
> 
> https://imgur.com/a/nSu8U2w
> ...


You are using different numbering for the steps, so I don't know what you mean by 5a and 5b. What are you trying to solve in these steps?

Also, what are you referring to regarding edge orientation? Wing edges cannot be misoriented, only permuted incorrectly.

If you don't care about parity and you just want to decrease the number of cases, then I suggest trying the technique of solving the DB edge and centers in the r slice - this takes care of 5 pieces, and you can then solve the UL and UR edges, leaving at most 4 center pieces and 5 wing edges unsolved. I can do all of this intuitively, but it could easily be made algorithmic.

For example:



https://imgur.com/a/CD5MEJ7


Here I intuitively solved everything except 3 wing edges and 2 center pieces intuitively. First I solved one UL/UR pair of opposite wing edges (one white/blue and one white/yellow), then solved the DB block, then solved the other UL/UR edges, then solved 2 of the remaining 5 wing edges.

Here is the same thing, but with odd parity:



https://imgur.com/a/N60KlBA


From here you can just do a "last edges" 5x5 alg and then a Niklas to solve those 2 center pieces. Or, develop an algorithm set to solve the last edges and the centers at the same time. There should not be many cases.

Edit again: 5x5 algs won't work because they move corners and edges. But the number of edge cases is the same (12?). There are 14 center cases I think so this is about 168 algs to do it in one look, including odd parity cases. But 2 looks is trivial and is 26 cases I think.

Edit again: Here are the last 4 edges algs from the sandwich method which you can use here as well: https://web.archive.org/web/20090202164706/http://rachmaninovian.webs.com/step4b.htm


----------



## dudefaceguy (Jul 5, 2020)

So, here is my speed version of this method:

1. Opposite centers.
2. Two 1x3x4 blocks around the centers.
3. Expand left block to a 2x3x4 block.
4. CMLL
5a. Solve one pair of opposite UL/UR wing edges using U r.
5b. Solve the DB edge and center block in the r slice using U r.
5c. Solve the remaining UL/UR edges and the DF edge with U r.
5d. Use the center-safe algs here to solve the last 4 edges: https://web.archive.org/web/20090202164706/http://rachmaninovian.webs.com/step4b.htm
5e. Solve the last 2 or 4 center pieces using a set of algs.

There is probably a better set of algs for 5d. 5d and 5e could probably be combined into a larger algs set. Step 5 is 2-gen except for these last algs. You may be able to generate 2 gen algs.

Edit: It might be easier to just solve the DB edge/center block first and then solve both UL/UR edge pairs afterwards. Then you are using the same technique to solve both UL/UR pairs, and the DB block is of course much easier to make.


----------



## Alex Shih (Jul 5, 2020)

It seems that I've made things really confusing for no good reason lol. Hopefully this post clears things up.

The 5a/5b numbering was referring to my post in the new method thread because I copy-pasted part of that post from something I was originally going to post there. My bad.

When talking about EO I was really referring to restricting the edge permutations. Basically, the idea was to find some way to restrict edge permutation so that every edge had a blue or green sticker pointing up or down (exactly like Roux EO).

I'm having trouble with the intuition for 5b and 5c. How are you able to preserve the ULUR pairs while solving the DB edge and center block? The most I'm able to preserve is one piece in the ULUR pair for 5b. Also, I'm only able to solve the DF edge intuitively in 5c while preserving everything else.


----------



## dudefaceguy (Jul 5, 2020)

Alex Shih said:


> It seems that I've made things really confusing for no good reason lol. Hopefully this post clears things up.
> 
> The 5a/5b numbering was referring to my post in the new method thread because I copy-pasted part of that post from something I was originally going to post there. My bad. However, since your method uses step numbering that splits up rU extremely differently, I'm unsure what numbering to use now to make things convenient.
> 
> ...


Check out my main guide and the video. I solve opposite wing edge pairs, not adjacent pairs. It's the same way you solve the UL/UR edges in Roux, except with individual wing edges.

First, I make sure I break up the edges into different slices. Then I put one edge "upside down" on the wrong side. Then I put the other edge at DF. Then I can insert both with U r U r' for example.

If you solve one of the opposite pairs before solving the DB block it's a lot easier and the movecount is not excessive. I'll upload a video showing an example.


----------



## dudefaceguy (Jul 5, 2020)

Here's an example of solving step 5 of the speed version with only U and r moves. I end up with an odd parity case.

I just figured this out today so I'm very inefficient and slow - this is just a proof of concept. A competent speed solver could probably do this very quickly.

Even though you get odd parity, the advantage for a speed solver is that you solve the last edges while also solving parity at the same time - you don't have to pair the edges first, then solve the cube, then break up and solve the edges again to solve parity.


----------



## Alex Shih (Jul 5, 2020)

There are at most 70 center cases and exactly 12 edge cases, so there are at most 840 cases if we try to do 5d/5e in one look. Right now I'm trying to generate algs and see how much AUF can reduce the number of center cases.


----------



## dudefaceguy (Jul 5, 2020)

Alex Shih said:


> There are at most 70 center cases and exactly 12 edge cases, so there are at most 840 cases if we try to do 5d/5e in one look. Right now I'm trying to generate algs and see how much AUF can reduce the number of center cases.


I calculated 14 center cases, since only 2 or 4 centers can be unsolved, and 2 of the 4 are interchangeable.

With 4 center pieces unsolved:
4 cases with bars on U
2 cases with an X on U
With 2 center pieces unsolved:
8 cases, since the F piece can be in 4 places and the U piece can be in 2 places.

12*14=168 so that's where I got my figure from.

If you solve centers separately from edges, it's just 3 cases since you can rotate U to change between the different cases. So, 15 algs in two looks.


----------



## Alex Shih (Jul 5, 2020)

This probably doesn't change much, but I just realized that 5b can be done with other centers/edges besides DB. You can then solve everything else, and then do an r, r', or r2 to solve everything. This way, you can take advantage of small blocks that are already made. The only downside is that recognition might be a bit harder.

For example, let's say I'm solving with blue top, orange front. Normally for 5b I would do DB (red and green centers + a red green wing). But if I already have a blue center pair formed, I can make a blue-red or blue-orange block with the centers and a wing, place this block in DB, continue the solve, and then do a r, r' or r2 at the end.

Also, maybe I'm just missing some detail, but why can only 2 or 4 centers be unsolved? There can't be an odd number unsolved, but why can't there be 6 or 8 unsolved?


----------



## dudefaceguy (Jul 5, 2020)

Alex Shih said:


> This probably doesn't change much, but I just realized that 5b can be done with other centers/edges besides DB. You can then solve everything else, and then do an r, r', or r2 to solve everything. This way, you can take advantage of small blocks that are already made. The only downside is that recognition might be a bit harder.
> 
> For example, let's say I'm solving with blue top, orange front. Normally for 5b I would do DB (red and green centers + a red green wing). But if I already have a blue center pair formed, I can make a blue-red or blue-orange block with the centers and a wing, place this block in DB, continue the solve, and then do a r, r' or r2 at the end.
> 
> Also, maybe I'm just missing some detail, but why can only 2 or 4 centers be unsolved? There can't be an odd number unsolved, but why can't there be 6 or 8 unsolved?


Doing unmatched blocks, right? Good idea. You can actually do this at any stage of the method! There is some study of this as an advanced Roux technique. Of course, it does make recognition very difficult but I used to do unmatched 1st and 2nd blocks when trying to get low movecounts.

As for the centers, the left 2 center pieces on the F face are already solved in a previous step, so only 2 F center pieces can be unsolved. The only place they can go is the U face, since every other center face is solved. So, either 1 F center is swapped with a U center, or 2 F centers are swapped with U centers. Those are the only groups of cases.


----------



## mitja (Jul 5, 2020)

dudefaceguy said:


> This is the method that I use to solve the 4x4 intuitively without using any memorized algorithms, and to easily avoid parity problems.


Hi,
this is all very nice reading, but when you use the word "intuitive" in the title, I get very sceptical. It is all about setting the margin when the intuitive ends and alg starts?
Do you really believe comms are intuitive?
Then I guess RUR' is intuitive and reverse? Sledgehammer?
Don't get me wrong, I like what you wrote, but why not banalize it completely? You could do Yau method up to F2L and stop at OLL. By upper standards you would consider F2L and edge pairing intuitive( you could say flips are just RUR' and reverse, Sledgehammer from the right and left).
So for the last layer corners you would need only 1-2 3 cycles-comms and for the dedges that are left you could use another 3- cycle or even easier - only flips. OLL parity is solved( like you proposed) by one upper layer move and PLL parity can be solved by using flips.

Of course everything could be solved by using 3-style( parity included), but efficiency would suffer.

I believe all above are algs and what is more important, you could hardly find a random person( that has never solved a cube) to understand and use it successfully.
For all above, you need to have quite advanced understanding of the cube.


----------



## Alex Shih (Jul 5, 2020)

dudefaceguy said:


> I calculated 14 center cases, since only 2 or 4 centers can be unsolved, and 2 of the 4 are interchangeable.
> 
> With 4 center pieces unsolved:
> 4 cases with bars on U
> ...


14 cases for centers is definitely correct, but I'm not sure whether 12 is the right number for edges. If we take AUF into account, there are 4 different 3-cycles, 4 single swaps, and 3 double swaps, making for 11 edge cases. However, taking AUF into account for both centers and edges simultaneously makes things messy.


----------



## dudefaceguy (Jul 5, 2020)

mitja said:


> Hi,
> this is all very nice reading, but when you use the word "intuitive" in the title, I get very sceptical. It is all about setting the margin when the intuitive ends and alg starts?
> Do you really believe comms are intuitive?
> Then I guess RUR' is intuitive and reverse? Sledgehammer?
> ...


Yes, I define "intuitive" as "without written or memorized algorithms," and I mention in my description that it's not a beginner method. Of course you use algorithms in that you use a series of moves. But they are not written or memorized - this is usually what the term "algorithm" means in cubing. If you look at the Wiki page on "Intuitive Solving" it describes the concept like this:

"Intutive solving can basically be broken into two parts :

solving most of the cube with intuitive moves (first two layers or more)
solving the remaining pieces with commutators"
So, this method seems to fit the accepted definition of "intuitive."

I say in the method description that "This is not intended for complete beginners, since it assumes knowledge of concepts such as commutators and blockbuilding." I realize that there are probably very few people who are experienced cubers but don't like to memorize agorithms. This method will only appeal to a very small subset of people.

You can indeed solve OLL parity intuitively with an r move and then commutators. But then you are solving the r slice twice. I designed this method to leave the r slice unsolved until you can detect the parity state so that you only have to solve it once.

I'm glad that you are interested in the method! It's designed to present very different challenges than a 3x3 solve, so I hope that you will try it out and have a good time solving the different steps. They are meant to be challenging for someone who knows how to solve a 3x3, but still move efficient.



Alex Shih said:


> 14 cases for centers is definitely correct, but I'm not sure whether 12 is the right number for edges. If we take AUF into account, there are 4 different 3-cycles, 4 single swaps, and 3 double swaps, making for 11 edge cases. However, taking AUF into account for both centers and edges simultaneously makes things messy.


Are you using software to generate algs? I'm getting interested in this concept and am thinking of downloading some so that I can see what kind of algs are required.


----------



## ThisNameIsAlreadyTaken (Jul 5, 2020)

mitja said:


> Hi,
> this is all very nice reading, but when you use the word "intuitive" in the title, I get very sceptical. It is all about setting the margin when the intuitive ends and alg starts?
> Do you really believe comms are intuitive?
> Then I guess RUR' is intuitive and reverse? Sledgehammer?
> ...



Intuitive doesn't mean easy. If you can do something intuitively you don't need to remember formulas or algs to get a certain result: you just know how it works. A deep understanding of the subject is needed, though, which rarely takes little effort and time to develop. 
I first solved 4x4 using commutators. It took some time though to understand the cube, before I could solve it every time.


----------



## Alex Shih (Jul 5, 2020)

dudefaceguy said:


> Are you using software to generate algs? I'm getting interested in this concept and am thinking of downloading some so that I can see what kind of algs are required.


I've looked for 4x4 alg generators similar to cube explorer online, but the best I could find was ksolve++, which is able to solve any type of twisty puzzle, but is not user-friendly at all. I'm trying to get it working on my computer so I can generate some algs, and I'm still sorting out the issues.


----------



## dudefaceguy (Jul 6, 2020)

Alex Shih said:


> I've looked for 4x4 alg generators similar to cube explorer online, but the best I could find was ksolve++, which is able to solve any type of twisty puzzle, but is not user-friendly at all. I'm trying to get it working on my computer so I can generate some algs, and I'm still sorting out the issues.


Cool, I'll see if I can get it up and running too.

Just smooshing together the Sandwich algs for edges and centers, it looks like the worst case is 32 moves (OLL parity then 2 Niklas for an X center case). With one cancellation it's 30 moves - not terrible for solving 8 pieces. Two 3 cycles would be much more common, for 16-20 moves.

Of course that is not 2 gen, but these algs are made to be fingertrick friendly. Here is a list of center algs from a Sandwich main: https://docs.google.com/document/d/1VOnmw93CoK4OB9N_Orq5Eb_cc9ILtXgpQEHhiELgMhk/mobilebasic

Only a few are applicable since we will always have an adjacent center case with 2 or 4 pieces unsolved.


----------



## Alex Shih (Jul 20, 2020)

I'm sorry for disappearing for a while, but currently I can't seem to get ksolve++ to work, and because of college classes I don't currently have the time to diagnose the problem. I'm still really interested in developing this method, and I will definitely contribute more when I get the chance, but as of right now I'm not really able to do much. Just FYI.


----------



## dudefaceguy (Jul 22, 2020)

Alex Shih said:


> I'm sorry for disappearing for a while, but currently I can't seem to get ksolve++ to work, and because of college classes I don't currently have the time to diagnose the problem. I'm still really interested in developing this method, and I will definitely contribute more when I get the chance, but as of right now I'm not really able to do much. Just FYI.


Hey no problem - I haven't gotten it working either. Life comes first.

I did some experimentation, recording my movecounts for the last steps solving the r slice and U layer. Compared to the intuitive method, I use fewer moves to solve centers, but more to solve edges (as we would expect). I averaged about 50 moves, with a range between 40 and 60 moves. The movecount for the original intuitive method is also 40-60 moves for these steps, so the average movecount for the speed method should be about 115. But, I just started working this out today so I am probably less efficient than I could be if I systematized everything. The intuitive method could also save a lot of moves if I learned 1 alg to solve the worst case, instead of using 2 commutators to solve 4 pieces.

Here is the full speed method as I am doing it now:

1. Opposite centers on L and R
2. Roux blocks around the completed centers
3. CMLL
4. Solve the complete DB block, the Dl edge and the Fl centers (leaving unsolved all U layer centers and edges, the Dr wing edge, and 2 center pieces at Fr).
5a. Solve the UL/UR wing edges and one addition wing edge (leaving unsolved 6 center pieces at U and Fr, and 4 wing edges at UF/UB and Dr)
5b. Solve the last 4 wing edges with algs
5c. Solve the last 2 or 4 center pieces

Note that this is almost the same as the Lewis method: the difference is that we leave a half-center unsolved in the r slice at Fr and use this keyhole to solve 5 of the last 9 edges. Thus we do not have to use commutators to solve the last 10 edge pieces, as in Lewis.

5a was difficult at first, but there are only a few cases for each edge pair. I tried a few different things here, including solving one UL/UR pair and one UF/UB pair. There is no significant difference, so I decided to solve both of the UL/UR pairs since this leaves me with cases that have already been widely studied. The obvious next step is to solve the last D layer edge at Dr, but you can frequently save lots of moves and get better cases if you solve 1 or 2 of the U layer wing edges instead. These cases can easily be conjugated with a slice move.

5b has only a few sets of cases. There are 4 cases with 3 unsolved pieces, which are all solved with commutators and are all basically the same. Not counting mirrors, there are 5 cases with 4 edges unsolved, and 3 cases with 2 edges unsolved. This makes 9 basic cases if we don't count mirrors and similar 3-cycles separately (16 total).

5c has 3 cases: you can solve 2 center pieces, or 4 pieces in bars with 1 commutator. 4 unsolved centers with an X on the U face can be solved with an 11-move double Niklas, cancelling 4 moves in between the 2 commutators.

So, why is this faster than the intuitive method? It's because of a restricted move set, optimized algs, and ease of recognition. Here are the specific improvements in these areas:

1. The D and B faces are solved, so you don't have to waste time tilting the cube to look at them.
2. The number of cases for the last steps is drastically less, so recognition can be instant and solutions can be algorthmic.
3. The moveset is restricted to U r except for solving the last centers which requires some l moves, and the last 4 edges which use a set of algs.

I would be curious to see a set of algs that can solve 5b and 5c together as one step using only U and r moves, but I'm not sure it would be worth it. But hey, I'm not even going to use the speed version so I will leave that up to you to decide.

I'll upload a video of the last steps of the speed method, now that I have practiced them a few times.


----------



## dudefaceguy (Jul 22, 2020)

Here are 2 examples of me solving the last steps in the speed variant:






Obviously the word "speed" does not apply to me personally, but this variant would be faster than the completely intuitive method for a theoretical speedcuber who was not old and slow.


----------



## Alex Shih (Aug 26, 2020)

Alright I've got some really good news. I wasn't able to get ksolve++ running, but I was able to write a program to generate algs anyway. Still working out the bugs, but I should be able to start generating algs within a day or two.

EDIT: I think I've fixed all the bugs, but I can't find solutions for the final step that are less than 30 moves and are rU. For reference, solving ULUR plus center bars and then solving the rest using an algorithm takes about 16 moves on average for the final step.


----------



## dudefaceguy (Aug 26, 2020)

Alex Shih said:


> Alright I've got some really good news. I wasn't able to get ksolve++ running, but I was able to write a program to generate algs anyway. Still working out the bugs, but I should be able to start generating algs within a day or two.
> 
> EDIT: I think I've fixed all the bugs, but I can't find solutions for the final step that are less than 30 moves and are rU. For reference, solving ULUR plus center bars and then solving the rest using an algorithm takes about 16 moves on average for the final step.


Cool, that is great news! But this is as I feared - that a 2 gen solution would be too long to make it worthwhile. Are you just solving last 4 wing edges, or are you including the last 4 center pieces as well? Combining those steps could yield some efficiencies, though there are still a large set of cases.


----------



## Alex Shih (Aug 26, 2020)

dudefaceguy said:


> Cool, that is great news! But this is as I feared - that a 2 gen solution would be too long to make it worthwhile. Are you just solving last 4 wing edges, or are you including the last 4 center pieces as well? Combining those steps could yield some efficiencies, though there are still a large set of cases.


I'm solving last 4 edges + last 6 centers (4 centers on top and 2 centers in front). Something that's been nagging at the back of my head for a long time is that the Hoya-y nature of the current version of the method has a few shortcomings. The rU movecount, even without considering the final step, is pretty large because every r has to be followed by an r' and vice versa. This is exacerbated by the fact that r moves in particular (not r' or r2) have bad ergonomics.

An alternative I've been considering is something like this:

1. Create the ULUR pairs like before
2. Solve the centers
3. Use an algorithm to solve the last six wings

Step 3 here would still need a lot of algs (360 if I counted correctly), but the algs would be ~16 moves on average. Really the only problem is finding some viable way to get to #3 (step 2 here is impossible to do without destroying the ULUR pairs, but it was just the first thing that came to mind).


----------



## dudefaceguy (Aug 26, 2020)

Alex Shih said:


> I'm solving last 4 edges + last 6 centers (4 centers on top and 2 centers in front). Something that's been nagging at the back of my head for a long time is that the Hoya-y nature of the current version of the method has a few shortcomings. The rU movecount, even without considering the final step, is pretty large because every r has to be followed by an r' and vice versa. This is exacerbated by the fact that r moves in particular (not r' or r2) have bad ergonomics.
> 
> An alternative I've been considering is something like this:
> 
> ...


I get what you're saying about the rU inefficiency. 2-gen solutions are usually less efficient, but faster to recognize and execute in certain circumstances. For example, 2-gen EPLL algs for OH. I'm not sure these is as much benefit to a 2-gen solution here. It's fun and interesting, but nobody really cares about that except me.

You can solve the center cases with one commutator, or a double Niklas that's 11 or 12 moves with cancellations, I think. Is that what you're thinking of?

At this point, it's very similar to Lewis method. Either solve centers first intuitively and use commutators for the edges, or vice versa.


----------



## Alex Shih (Aug 29, 2020)

I think I've come up with 2 possible algorithmic rU methods, but they both use a fair amount of algs. Here they are if you're interested in developing them further:

Option 1 (Centers first):

1.) Solve centers (intuitive)
2.) Solve each ULUR edge one-by-one until all four ULUR edges are solved (18 algs)
3.) Edge "orientation" (8 algs). More on this later.
4.) Solve the rest of the cube (17 algs)

Step 3 here restricts the permutations of the unsolved edges so that only the D or B face colors face up or down (just like regular Roux EO). This is necessary because otherwise there are 360 cases for the final step.

Option 2 (ULUR first):

1.) Solve ULUR (intuitive)
2.) Create the 5 center-bars one-by-one (4 algs).
3.) Completely solve centers (intuitive)
4.) Edge "orientation" (8 algs). This is the same as step 3 from centers first.
5.) Solve the rest of the cube (17 algs). This is the same as step 4 from centers first.

I'm in the process of genning algs for both of these, so I don't really have anything more to contribute at this time. My program brute-forces through every possible combination of rU moves, so each alg will take a really long time to gen (almost 2 hours from my calculations).


----------



## dudefaceguy (Aug 29, 2020)

Alex Shih said:


> I think I've come up with 2 possible algorithmic rU methods, but they both use a fair amount of algs. Here they are if you're interested in developing them further:
> 
> Option 1 (Centers first):
> 
> ...


Awesome, sounds like a lot of good progress on the algs! 

I don't understand the edge orientation step. If you're spending time and learning algs to orient the edges, I don't see why you wouldn't just solve them instead to reduce the number of cases, since there is no real edge orientation on 4x4 and you are just permuting the edges. Might as well permute them to the right spot.

Where are these steps starting from? When you solve"the rest of the cube," is that just 5 wing edges? If so, you get fewer cases by just solving 1 edge intuitively instead of learning a set of algs to "orient" the wing edges.

Sorry for the short response, I only have a few minutes. Very cool that you're able to generate the algs and come up with alternate routes to solving.


----------



## Alex Shih (Aug 29, 2020)

dudefaceguy said:


> Awesome, sounds like a lot of good progress on the algs!
> 
> I don't understand the edge orientation step. If you're spending time and learning algs to orient the edges, I don't see why you wouldn't just solve them instead to reduce the number of cases, since there is no real edge orientation on 4x4 and you are just permuting the edges. Might as well permute them to the right spot.
> 
> ...



I don't know this for sure since I haven't genned the algs yet, but I have a hunch that restricting permutation + finishing permutation will on average be fewer moves than permuting some edges + permuting some edges. But you have a point; I could absolutely be wrong. 

These steps solve any piece that can be scrambled by rU (so Dr edge + Br edge + all U layer centers and edges). "Solving the rest of the cube" would be solving 6 edges: the two edges on D and the four UFUB edges. Unfortunately there is no intuitive way (that I know of) to solve these edges without messing up centers.

Also, to clarify, the alg counts I put up are the number of *total* algs for each step. I haven't actually finished genning any algs yet lol.


----------

