• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Intuitive 4x4 Method with Parity Avoidance

Alex Shih

Member
Joined
Jun 23, 2020
Messages
27
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?
 
Last edited:

dudefaceguy

Member
Joined
Feb 17, 2019
Messages
254
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

Member
Joined
Dec 22, 2015
Messages
232
Location
Ljubljana, Slovenia
WCA
2016POPO02
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

Member
Joined
Jun 23, 2020
Messages
27
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.
 
Last edited:

dudefaceguy

Member
Joined
Feb 17, 2019
Messages
254
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 :
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.
 
Joined
Jul 27, 2019
Messages
49
Location
Mithlond
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

Member
Joined
Jun 23, 2020
Messages
27
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

Member
Joined
Feb 17, 2019
Messages
254
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

Member
Joined
Jun 23, 2020
Messages
27
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

Member
Joined
Feb 17, 2019
Messages
254
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

Member
Joined
Feb 17, 2019
Messages
254
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

Member
Joined
Jun 23, 2020
Messages
27
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.
 
Last edited:

dudefaceguy

Member
Joined
Feb 17, 2019
Messages
254
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

Member
Joined
Jun 23, 2020
Messages
27
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).
 
Last edited:

dudefaceguy

Member
Joined
Feb 17, 2019
Messages
254
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

Member
Joined
Jun 23, 2020
Messages
27
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).
 
Last edited:

dudefaceguy

Member
Joined
Feb 17, 2019
Messages
254
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

Member
Joined
Jun 23, 2020
Messages
27
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.
 
Top