• Welcome to SpeedSolving.com — the world’s largest puzzle community!

    You’re currently browsing as a guest, which means you have limited access to discussions, resources, member profiles, and community features.

    Join 50,000+ cubers and puzzle enthusiasts from around the world to ask questions, share solves, improve faster, and be part of the community.

    Registration is free, fast, and easy — create your account today.

    Already a member? Log in here to hide this message and start participating.
Been fiddling with an idea. Let the bashing begin. If it survives, I'll gen the algs for example solves for further scrutiny.

Philosophy and motivation:
Algorithmic methods are doing fairly well compared to block building methods, and for good reason. TPS on the new hardware has shot up and it makes sense to make best use of it. A method with a bearable number of algorithms, yet highly algorithmically reliant and with good recognition has the potential to beat a good deal of methods. A means to achieve that is to have 3 algorithmic steps (compared to 2 for CFOP for example); while ensuring that those algorithms do indeed tackle a large set of cases (2LLL CFOP handles ~15k cases).
Orientation steps are almost always recognition friendly as long as they involve one (or two) top colour (like TSLE is decent for recog, OLL is pretty good, etc. but LEOR EO is hard) Permutation steps are good for recognition if a single glance at a cube, and registering 4-5 stickers at most can uniquely identify each case (like 2 sided PLL recognition system if good, ZBLL recognition on the other hand is hard, so is 4x4 PLL).
Cube symmetries can play a huge role in reducing number of algorithms while getting tons of cases solved (There are 72 PLL cases, but symmetry reduces it to 22 (21+1)). These symmetries can be exploited much better once we think about it.

Based on these primers and a bit of work, there seems to be one very promising end to a solve using 3 algorithms:
Suppose a 2x2x3 is solved on DL; FR and BR edges are solved; and the remaining 5 edges are oriented (i.e. white/yellow facing up/down say).
Alg-1: orients 6 corners. This will be a short <R,U> alg; and surprisingly, there are very few cases thanks to the freedom of U layer and the S slice symmetry. Also, R2 setups cut this down much further. There are 23 + (4 x 8) + (2 x 8) = 71 cases, though only 39 algorithms excluding mirrors. If we consider R2 setups, this number goes below 30.
Alg-2: Permutes 6 corners. These will be <R,U,D> algs (<R2,U,D> is enough, but algs may get lengthy); and again surprisingly, there are very few cases thanks to the same freedom and symmetry. There are 5 + (4 x 6) + 18 = 47 cases, though only 29 algorithms excluding mirrors. 2 sided recognition is possible here.
Alg-3: L5EP, <M,U> gen 16 short algs very simple to recognise during the previous alg.

This 3 alg system, which without any reduction has 71+47+16 = 134 algs (CFOP has 78 excluding F2L) can reduce the cube state from a possible 6! * 5! * 3^5 / 2 = 10M cases! This is 700 times more than 15k of CFOP, instead of an expected sqrt(15k)~120. Basically, this algorithm system is better per algorithm required compared to 2LLL, plus has comparable to better recognition; and looking at the movesets potentially better and shorter algs.

Now to the hard part:
How do we achieve " a 2x2x3 is solved on DL; FR and BR edges are solved; and the remaining 5 edges are oriented"?

Two premises about this.
Firstly, blockbuilding is probably the best thing that can be done with the inspection time in terms of reducing the number of cubestates. A roux block does this slightly better than a petrus block, which is better than a cross; all solving the same number of pieces (counting centres, since roux centres aren't fixed).
Second, there is a reason CFOP is as successful as it is, and that is the symmetry in F2L. We can choose to do whichever F2L pair we please, and we can do these in any order. This is very good for a step that is neither algorithmic, nor block building; because we can simply do whatever we see first. Finally, we can use only the last pair to influence LL.

This gives us a beautiful way to achieve the above mentioned cubestate. A roux block can be done in inspection, and then each of the 4 edges UF, UB, DF and DB can be placed between corresponding centres in any order convenient; while influencing EO. Follow this with a rotation and you have your required cubestate! The best part is, this central "belt" doesn't have to align with FB, because at the end of the solve, we can do an AUF with an ADF and will be done.
The EO condition in the belt can be relaxed in a more advanced version of the method, where one can learn all L5E algs (roughly 200 cases, ~60 algs excluding mirrors and setups).


Summing it all up:

Intermediate version:
Step 1: FB (~6 moves)
Step 2: EO-Belt (~16 moves) <r,R,U>
Step 3: 6COLL (~13 moves) <R,U>
Step 4: 6CPLL (~12 moves) <R,U,D>
Step 5: L5EP (~13 moves) <M,U>
Avg ~ 60 moves

Advanced version:
Step 1: FB (~6 moves)
Step 2: Belt (~9 moves) <r,R,U>
Step 3: 6COLL (~13 moves) <R,U>
Step 4: 6CPLL (~12 moves) <R,U,D>
Step 5: L5E (~15 moves) <M,U>
Avg ~ 55 moves

Promising a higher TPS than CFOP, this should be pretty good. Let me know.
I CBA to read all of this but 55 moves Is quite a lot, and im skeptical whether it is even 55 moves as FB definitely takes more than 6 moves. Also Leor EO isn’t that hard and is definitely worth it as the rest of the solve is good.
 
I CBA to read all of this but 55 moves Is quite a lot, and im skeptical whether it is even 55 moves as FB definitely takes more than 6 moves. Also Leor EO isn’t that hard and is definitely worth it as the rest of the solve is good.
You will find reading it quite helpful to see why it’s at most 55 moves (or as it turns out, under 50 consistently, check out the example solves or the method thread).
Even if FB takes 8 moves not 6 (which I really doubt), it doesn’t make much difference in the overall movecount.
 
ribbon method is good but zipper method better cause zipper is less algs but its just my opinion so don't take it to seriously
 
Last edited:
ribbon method is good but zipper method better cause zipper is less algs but its just my opinion so don't take it to seriously
Alg count is irrelevant on whether or not a method is good. Basic full CFOP has more algs than basic full Roux, but both are good. ZZCT is decent, but ZZ-A is better, despite having nearly 4x the algs for LL.
Some methods like full ZB may not be practical for most people because of the higher alg count, but that doesn't mean the method is inherently bad just because it might be out of reach for the majority of people.

What makes a speedsolving method good, at least in my opinion, is how well it fares on a few basic needs for speedsolving.

1. Simplicity. A method with too many steps makes it more mentally draining and hinders look ahead. Cross, F2L, OLL, PLL. First block, second block, CMLL, LSE. EOCross, F2L, ZBLL. You get the idea. The popular methods are all incredibly simple with very few steps needed to master. Compare that to some of the more obscure methods, and you can instantly appreciate the simplicity of the big methods.

2. Look Ahead Potential. I already mentioned this in the last point, but if your method has some obvious problems with look ahead, you may as well just can your idea and move on. You can have the greatest method in the world, but if it takes a few seconds just going from step to step because the look ahead is trash then it's worthless.

3. Ergonomics. This is also pretty darn important. The moveset that a method uses is also pretty influential on how well the method can do. 3-style in theory would be good for speedsolving normally because if you're good you can one-look the whole cube during inspection and never stop turning during the actual solve. However, 3-style uses nearly every move you can do on the cube, face, wide, and slice, which drastically hinders ergonomics as some moves simply don't flow well into others. The moveset very much influences the speed at which you can turn, so ergonomics is also a major factor to consider when developing or assessing a method.

4. The Human Factor. Quite simply, we are humans with human limitations. Methods need to take that into account. It would be unreasonable to ask a human to do something similar to Kociemba and the like since those methods are meant for computers. A human could probably do something like that, considering how well people do with FMC, but it would take such a long time that it would be impractical for speedsolving, and would also circle back to an ergonomics problem. In short, methods that have intuitive steps need to keep in mind the limits of human thought and have a semi structure for how to do the intuitive steps.

There are probably other major things to consider that I haven't listed but those are what came to mind when writing this!
 
Alg count is irrelevant on whether or not a method is good. Basic full CFOP has more algs than basic full Roux, but both are good. ZZCT is decent, but ZZ-A is better, despite having nearly 4x the algs for LL.
Some methods like full ZB may not be practical for most people because of the higher alg count, but that doesn't mean the method is inherently bad just because it might be out of reach for the majority of people.

What makes a speedsolving method good, at least in my opinion, is how well it fares on a few basic needs for speedsolving.

1. Simplicity. A method with too many steps makes it more mentally draining and hinders look ahead. Cross, F2L, OLL, PLL. First block, second block, CMLL, LSE. EOCross, F2L, ZBLL. You get the idea. The popular methods are all incredibly simple with very few steps needed to master. Compare that to some of the more obscure methods, and you can instantly appreciate the simplicity of the big methods.

2. Look Ahead Potential. I already mentioned this in the last point, but if your method has some obvious problems with look ahead, you may as well just can your idea and move on. You can have the greatest method in the world, but if it takes a few seconds just going from step to step because the look ahead is trash then it's worthless.

3. Ergonomics. This is also pretty darn important. The moveset that a method uses is also pretty influential on how well the method can do. 3-style in theory would be good for speedsolving normally because if you're good you can one-look the whole cube during inspection and never stop turning during the actual solve. However, 3-style uses nearly every move you can do on the cube, face, wide, and slice, which drastically hinders ergonomics as some moves simply don't flow well into others. The moveset very much influences the speed at which you can turn, so ergonomics is also a major factor to consider when developing or assessing a method.

4. The Human Factor. Quite simply, we are humans with human limitations. Methods need to take that into account. It would be unreasonable to ask a human to do something similar to Kociemba and the like since those methods are meant for computers. A human could probably do something like that, considering how well people do with FMC, but it would take such a long time that it would be impractical for speedsolving, and would also circle back to an ergonomics problem. In short, methods that have intuitive steps need to keep in mind the limits of human thought and have a semi structure for how to do the intuitive steps.

There are probably other major things to consider that I haven't listed but those are what came to mind when writing this!
Sorry i meant higer alg methods are sometimes better
 
Almost exactly the same step.

Okay, you added a step, good job.


Exact same thing.


All of this is the exact same, too.

So basically, you added an extra step (PLL on bottom) by making it so that it can be any PLL instead of just A perm or E perm, and you added the step where you make the belt, which actually solves the cube this time, because in your first proposal, the E layer wouldn't have been solved.
no cause I get a perms on the bottom and e perms with this method and this method does domino reduction in a diffrent way and tao says its similar to ssc
 
Keep in mind that this is only a concept, but any help developing it would be very nice.


The main problem with the VH/ZB methods is the fact that learning over 500 algorithms isn't fun. This problem is combated with ZZ-B. ZZ-B is the same as ZZ-A, but during last slot, you would "phase" two opposite edges to be permuted, so you would use only the chunk of ZBLL that deals with two permuted edges, also known as ZZLL. It's pretty good, but you have to use ZZ, which is saddening. This concept started with me trying to find a way to implement this into CFOP, and I think I found a way that might even work better.

ZZLL has 169 algorithms, compared to the nearly 500 of ZBLL, all because of this phasing part. So, I thought, why not take it a step further and permute all 4 edges? That way, you wouldn't have to learn 169 algorithms, but only 76 algorithms, a difference of 93. The only problem with this would be making a way to permute all the edges (since you aren't guaranteed to have the edges oriented in CFOP.) The best way, I think, would be to make a ELS variant that also permutes the last corner

I would predict that there are around 100-120 algorithms, which would make this more efficient than zz-b. This number is based on the fact that COLL has 4-6 cases for each of the 7 cross oll cases. there would also have to be cases for when they are all oriented, but in the wrong place.

So the steps would be:

1) Cross + Corner in right place

2) 3 F2L slots

3) ELS varient (temporarily being called RELS, since R is the first initial of my real name)

4) ZZLL fully permuted cases

Let me know what you think!
 
Last edited:
Keep in mind that this is only a concept, but any help developing it would be very nice.


The main problem with the VH/ZB methods is the fact that learning over 500 algorithms isn't fun. This problem is combated with ZZ-B. ZZ-B is the same as ZZ-A, but during last slot, you would "phase" two opposite edges to be permuted, so you would use only the chunk of ZBLL that deals with two permuted edges, also known as ZZLL. It's pretty good, but you have to use ZZ, which is saddening. This concept started with me trying to find a way to implement this into CFOP, and I think I found a way that might even work better.

ZZLL has 169 algorithms, compared to the nearly 500 of ZBLL, all because of this phasing part. So, I thought, why not take it a step further and permute all 4 edges? That way, you wouldn't have to learn 169 algorithms, but only 76 algorithms, a difference of 93. The only problem with this would be making a way to permute all the edges (since you aren't guaranteed to have the edges oriented in CFOP.) The best way, I think, would be to make a ELS variant that also permutes the last corner

I would predict that there are around 100-120 algorithms, which would make this more efficient than zz-b. This number is based on the fact that COLL has 4-6 cases for each of the 7 cross oll cases. there would also have to be cases for when they are all oriented, but in the wrong place.

So the steps would be:

1) Cross + Corner in right place

2) 3 F2L slots

3) ELS varient (temporarily being called RELS, since R is the first initial of my real name)

4) ZZLL fully permuted cases (Gonna call it PEPCOLL, where PEP stands for Preservation of Edge Permutation)

Let me know what you think!
Not to diminish the idea but I strongly feel this would not be worth exploring further.
The primary reason is that it defeats the point of ZZLL/ZBLL. The whole point is that you get to save like .1 to .3 seconds at most by doing 1 alg to solve the whole LL. The problem with this idea is you are still doing the equivalent of a 2 alg last layer. Instead of OLL and PLL, you are doing a F2L alg that would probably be slot dependent for a while, just to set up your subset of ZZLL, and then the ZZLL alg itself.
This is worse because you will have to take more time to recognize the awkward ELS thing compared to quickly recognizing and executing an OLL alg, and then you would have to take time to recognize and execute the ZZLL, which would probably end up just being worse than OLL and PLL.
 
Not to diminish the idea but I strongly feel this would not be worth exploring further.
The primary reason is that it defeats the point of ZZLL/ZBLL. The whole point is that you get to save like .1 to .3 seconds at most by doing 1 alg to solve the whole LL. The problem with this idea is you are still doing the equivalent of a 2 alg last layer. Instead of OLL and PLL, you are doing a F2L alg that would probably be slot dependent for a while, just to set up your subset of ZZLL, and then the ZZLL alg itself.
This is worse because you will have to take more time to recognize the awkward ELS thing compared to quickly recognizing and executing an OLL alg, and then you would have to take time to recognize and execute the ZZLL, which would probably end up just being worse than OLL and PLL.

I must say that I really disagree. ELS is not meant to be a part of the last layer, but just a slightly longer insert to orient the edges. The average move count for OLL in htm is 9.7, while in els it is only 6.04, but this isn't counting rotations for both (More of them in ELS) they have a similar moveset, both utilising m and wide moves. COLL has a similar average moves to OLL, with 9.78. It would make sense that ELS would follow suit, and even if it doesn't, it would have around 3.5 average moves of wiggle room before it becomes the same amount as OLL. Also, recognition for the ELS thing would be similar to COLL or TSLE

Talking about the ZZLL thing, from a quick glance at the algorithms, it would probably a bit higher than ZBLL, which is 12.08. If we assume that it's about 15, and the ELS thing is 9.7, it would be around 25 altogether, compared to OLL and PLL's around 22.

For a comparison between CFOP and my new method

CFOP New Method

1) Cross (~6 Moves) 1) Cross + Corner (~9 moves)

2) F2L (~26.8 Moves) 2) 3 F2L Pairs (~20.1 Moves)

3) OLL (~9.7 Moves) 3) CLS thing (~9.5 Moves)

4) PLL (~11.8 Moves). 4) ZZLL thing (~15 Moves)

CFOP = 54.3 New Method = 53.6

It's actually less than CFOP, and this is with the worst ones I've discussed.

I'll calculate the actual average for ZZLL thing later

EDIT: The ZZLL thing actually has 81 algorithms, and the average moves is 13.3. This would change the average moves to 51.9.
 
Last edited:
I must say that I really disagree. ELS is not meant to be a part of the last layer, but just a slightly longer insert to orient the edges. The average move count for OLL in htm is 9.7, while in els it is only 6.04, but this isn't counting rotations for both (More of them in ELS) they have a similar moveset, both utilising m and wide moves. COLL has a similar average moves to OLL, with 9.78. It would make sense that ELS would follow suit, and even if it doesn't, it would have around 3.5 average moves of wiggle room before it becomes the same amount as OLL. Also, recognition for the ELS thing would be similar to COLL or TSLE

Talking about the ZZLL thing, from a quick glance at the algorithms, it would probably a bit higher than ZBLL, which is 12.08. If we assume that it's about 15, and the ELS thing is 9.7, it would be around 25 altogether, compared to OLL and PLL's around 22.

For a comparison between CFOP and my new method

CFOP New Method

1) Cross (~6 Moves) 1) Cross + Corner (~9 moves)

2) F2L (~26.8 Moves) 2) 3 F2L Pairs (~20.1 Moves)

3) OLL (~9.7 Moves) 3) CLS thing (~9.5 Moves)

4) PLL (~11.8 Moves). 4) ZZLL thing (~15 Moves)

CFOP = 54.3 New Method = 53.6

It's actually less than CFOP, and this is with the worst ones I've discussed.

I'll calculate the actual average for ZZLL thing later

EDIT: The ZZLL thing actually has 81 algorithms, and the average moves is 13.3. This would change the average moves to 51.9.
That difference in movecount is so marginal that just the speed aspect of doing what is conventional compared to this again leads me to think this simply wouldn't be worth using in practice. The point of any ZBLL subset, whether it's the full set or a subset, is to do the last layer in one alg. Anytime you need another alg set just to setup up to something that will barely save any time anyway probably isn't worth it. Especially when you consider the times when you can just do a 3-4 move insert for the last pair and do OLL and PLL, vs doing some kind of alg just for ZZLL. If you want to explore this idea, by all means go ahead. Prove me wrong. But until you do, I have good reason to believe this probably isn't worth it. Especially now that people are really starting to dig into ZBLL and figure out what subsets of ZBLL are and aren't worth using in the first place.
 
if you used ZB method, that's still using 2 algorithms. Mine also uses 2 algorithms. Even if it ends up being unviable for speed solving, it will still serve as an introduction to zzll, which is an introduction to zbll, which is confirmed to be good.
zb method is 2 step lsll, your method is 3 step which is same as cfop but with more algs.
 
I really don't see ZB as the future these days. People are finding tons of cases where the better solution is OLL/PLL instead of a ZBLL. There are probably several cases where normal F2L is better than ZBLS. I think more option select ideas are going to come into play rather than a ubiquitous 1LLL or LSLL idea.
 
Back
Top