Intuitive 4x4 Method with Parity Avoidance

[Alex Shih]

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]

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]

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]

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.

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]

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.

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.

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]

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.

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]

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]

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]

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]

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]

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]

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]

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]

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]

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).

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]

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]

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).

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]

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.

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.

 

[Fred]

Sorry for the necro, but you've linked this thread in a few other places, so I figure I might as well post here.

It's great to see that we use the same method! I even wrote a post about it back when I came up with it (https://www.speedsolving.com/threads/new-4x4x4-method.695/), but you've done a much better job explaining it and drumming up interest. I have a couple of questions and comments. How do you always solve exactly 7 of the 10 edges? I leave a slice for last, and that could be 0 edges left (yay, skip!), a 3-cycle of edges left (what you address), or a pair of swaps. I used to do this last case with two 3-cycles, but I recently figured out a commutator to do it in one step: z' R F U F' U2 R' u2 R U2 F U' F' R' u2. I hadn't even thought of moving centers with the edges. That's clever.

When solving the edges, it's possible to also solve some of the last layer centers at the same time (the ones not in the last slice). This makes more of an impact on bigger cubes, but it may make that step too cumbersome. I usually skip doing this.

For centers, I usually do 8-move commutators with 0-2 setup moves (rarely 2), so I can spot them pretty quickly. Sometimes I permute blocks of centers, especially on bigger cubes. I also use r2 u2 r2 u2 to swap two connected centers on opposite faces. There are more variations of this alg.

For the 1x3x4 blocks, I sometimes switch between blocks, and I sometimes pair up some edges to use later. Basically I use what pieces I see, so I don't have to hunt all over the cube for one specific piece. Flexibility in this step helps prevent long awkward pauses.

When extending to 2x3x4, sometimes I'll screw up and have the centers in the wrong order. If I'm solving with white on top and green in front and I make a slice with blue in front, yellow on bottom, and green in back, I'll just do M2 Uw2 M2 Uw2. This puts the slice on the other side of the cube and corrects it. I also use this alg when I try to use reduction or K4 and screw up my cross.

 

[abunickabhi]

Sorry for the necro, but you've linked this thread in a few other places, so I figure I might as well post here.

It's great to see that we use the same method! I even wrote a post about it back when I came up with it (https://www.speedsolving.com/threads/new-4x4x4-method.695/), but you've done a much better job explaining it and drumming up interest. I have a couple of questions and comments. How do you always solve exactly 7 of the 10 edges? I leave a slice for last, and that could be 0 edges left (yay, skip!), a 3-cycle of edges left (what you address), or a pair of swaps. I used to do this last case with two 3-cycles, but I recently figured out a commutator to do it in one step: z' R F U F' U2 R' u2 R U2 F U' F' R' u2. I hadn't even thought of moving centers with the edges. That's clever.

When solving the edges, it's possible to also solve some of the last layer centers at the same time (the ones not in the last slice). This makes more of an impact on bigger cubes, but it may make that step too cumbersome. I usually skip doing this.

For centers, I usually do 8-move commutators with 0-2 setup moves (rarely 2), so I can spot them pretty quickly. Sometimes I permute blocks of centers, especially on bigger cubes. I also use r2 u2 r2 u2 to swap two connected centers on opposite faces. There are more variations of this alg.

For the 1x3x4 blocks, I sometimes switch between blocks, and I sometimes pair up some edges to use later. Basically I use what pieces I see, so I don't have to hunt all over the cube for one specific piece. Flexibility in this step helps prevent long awkward pauses.

When extending to 2x3x4, sometimes I'll screw up and have the centers in the wrong order. If I'm solving with white on top and green in front and I make a slice with blue in front, yellow on bottom, and green in back, I'll just do M2 Uw2 M2 Uw2. This puts the slice on the other side of the cube and corrects it. I also use this alg when I try to use reduction or K4 and screw up my cross.

Wow an insane necropost. Phewwwww

Do you have any of your k4 solves on cam?