The New Method / Substep / Concept Idea Thread

[Teoidus]

With these splits, the method is about 40 moves and could be done in sub 6 seconds on average by someone who's mastered it.

You can say the same of @shadowslice e 's 42- with just 42 algs

 

[Thermex]

You can say the same of @shadowslice e 's 42- with just 42 algs

What method did he propose that was 42 moves? Whatever it is it probably isnt quite as ergonomic as this.

 

[Arc]

What method did he propose that was 42 moves? Whatever it is it probably isnt quite as ergonomic as this.

The method name is 42.

I don't think 1 second is realistic for CPFB. World class Roux solvers average about 1.3 for normal FB. They're obviously not perfect, but because CPFB is a bit harder I'd say that a Feliks-level+ solver of a method with CPFB could maybe get down to 1.2ish with x2 y color neutrality. At 7-8ish moves that is 6-7 TPS which is quite good for the somewhat awkward move group.

I don't think you will find much faster algs that aren't 2gen.

 

[GuRoux]

What method did he propose that was 42 moves? Whatever it is it probably isnt quite as ergonomic as this.

yo guys, roux is sub 40 moves too. the real question is how efficient these methods are in speedsolves.

 

[Thermex]

The method name is 42.

I don't think 1 second is realistic for CPFB. World class Roux solvers average about 1.3 for normal FB. They're obviously not perfect, but because CPFB is a bit harder I'd say that a Feliks-level+ solver of a method with CPFB could maybe get down to 1.2ish with x2 y color neutrality. At 7-8ish moves that is 6-7 TPS which is quite good for the somewhat awkward move group.

I don't think you will find much faster algs that aren't 2gen.

Sure, 1.5 seconds for CPFB. I'll check out 42 tomorrow, I gotta go to bed.

yo guys, roux is sub 40 moves too. the real question is how efficient these methods are in speedsolves.

How do you get sub-40 with Roux? Like I've seen some pretty efficient variants but nothing sub 40. And you make a good point, we can't prove how fast any of this is until someone actually gens the algs and learns it.

P.S. I made a huge math error on the last step I'm calling PLS, I'll talk more about that tomorrow.

 

[GuRoux]

How do you get sub-40 with Roux? Like I've seen some pretty efficient variants but nothing sub 40. And you make a good point, we can't prove how fast any of this is until someone actually gens the algs and learns it.

just use a lot of tricks and think longer for more efficient blockbuilding. i probably can average around 40 doing minute solves and i would assume many others can too. the problem is that when speedsolving, not doing the tricks and looking for more efficiency is often faster.

9 moves for CPFB would be awesome even just for regular roux; so i'm interested in that.

 

[shadowslice e]

yo guys, roux is sub 40 moves too. the real question is how efficient these methods are in speedsolves.

In defense of 42 the movecounts I use are the same movecounts which a reasonably good roux solver would get in a speedsolve and more advanced versions would be more efficient (16/8/17+AUFs)

What method did he propose that was 42 moves? Whatever it is it probably isnt quite as ergonomic as this.

There have been a few things that I proposed which can be sub-40 moves all of which are reasonably ergonomic- 42-, M-CELL and variants of SSC. I will concede that M-CELL requires a fair amount of algs to do so (~300 iirc) and the SSC variant is not really speedsolvable though 42- is pretty ergonomic, reasonably low algcount and the movecounts are achievable in a speedsolve.

 

[Arc]

9 moves for CPFB would be awesome even just for regular roux; so i'm interested in that.

Generally solving CP during FB is as simple as throwing in an extra R or U where they don't affect any block pieces or by inserting the pair slightly differently. Meaning your CPFB solution will only be a move or two more than your normal FB solution. However, identifying these couple of moves is quite difficult. I'm using a slightly generalized version of @Teoidus' 2GR tracking. The jist is that you recognize your "key swap" via the identities of 3 specific corners based on the permutation of your DR corners in relation to your "base" corner, which is just whichever corner you put in the block first. Then you track how the key swap changes while you are building your square (this is the hard part) using a handful (12ish) 4-cycles of key swaps called quadruples. Finally it's trivial to insert the final pair while solving CP with knowledge of your key swap (the process is simply to move the second piece of the key swap to UBR before inserting the final pair with an F move, or more generally any move parallel to the F/B sticker of your base corner).

A few of us had come to the conclusion that it isn't worth it for Roux since the CP solved CMLLs aren't particularly better than the others, but you've got much more knowledge in that area so I'd love to hear your take on it. Another option to consider is forcing a diagonal swap, which is just as easy as forcing no swap. Forcing an adjacent swap is also the same, but the 4 adjacent swaps are identical when you get to CMLL because it's the orientation of the pieces that matters, not their identity, meaning you'd cut down to 2/3 the cases as opposed to 1/6 with solved/diag.

 

[Arc]

Sure, 1.5 seconds for CPFB. I'll check out 42 tomorrow, I gotta go to bed.

How do you get sub-40 with Roux? Like I've seen some pretty efficient variants but nothing sub 40. And you make a good point, we can't prove how fast any of this is until someone actually gens the algs and learns it.

P.S. I made a huge math error on the last step I'm calling PLS, I'll talk more about that tomorrow.

Depending on how you divide it up, HARCS gives 38-40 for optimal Roux. Obviously human SB will be a handful of moves more, however the other steps are fairly close to optimal in human execution, and color neutrality and influencing EOLR during CMLL still drop quite a few moves off the solution. Simple EOLR L4E generally results in an LSE solution within a move of optimal.

Overall Roux is an superb method. Excellent move count, good ergonomics, and medium alg count (assuming two algs per CMLL). I'd say the largest drawbacks of Roux are CMLL recognition, leaving DB unsolved for so long, and the MU move group of LSE, all of which are minor.

 

[Pyjam]

Two easy questions for you, experts: How is called this method, and how many moves per step:

1. 1st Roux block (left)
2. EO-DFDB (=EO-line)
3. Right block
4. ZBLL

Many thanks

 

[Arc]

Two easy questions for you, experts: How is called this method, and how many moves per step:

1. 1st Roux block (left)
2. EO-DFDB (=EO-line)
3. Right block
4. ZBLL

Many thanks

I have yet to see a name for this method, despite having used it myself. It is essentially Briggs without the CP part. Roux block is 7-8, F2L should be around 13, ZBLL is about 14. As for EODFDB, since you don't have CP solved, you have the option to use F/B. If you don't use F/B, it's around 10, I'm not sure what it is if you do.

 

[Teoidus]

Two easy questions for you, experts: How is called this method, and how many moves per step:

1. 1st Roux block (left)
2. EO-DFDB (=EO-line)
3. Right block
4. ZBLL

Many thanks

Approximate movecount: 7 FB + 10 EODFDB + 13 SB + 14 ZBLL = 44

 

[Thermex]

just use a lot of tricks and think longer for more efficient blockbuilding. i probably can average around 40 doing minute solves and i would assume many others can too. the problem is that when speedsolving, not doing the tricks and looking for more efficiency is often faster.

9 moves for CPFB would be awesome even just for regular roux; so i'm interested in that.

I agree with this; Roux could be sub-40 in an optimal solution, but during speedsolves (at least the ones I use with it) I get movecounts closer to 47-48 (I don't use EOLR and have far from optimal blockbuilding, so of course it's a bit lower for people like you). My point though, is that during speedsolves my method actually does regularly achieve sub-40 movecounts, while being around 37 moves optimal. 4 moves isn't a huge difference; you basically end up adding ~2 moves to FB so that later in the solve you can one-look both LS+CMLL and LSE. It adds ~300 algs for the same reason ZBLL adds 400 algs to CFOP LL: to veer closer to a sub-40 movecount while only sacrificing the amount of time needed to learn huge alg sets. In no way is this method a "replacement" or "upgrade" from standard Roux; it just saves a few moves, maybe a full second and some of the time needed to recognize the steps that are skipped in this method by using CPFB (LS pair & LSE 4C). It has the same great efficient, ergonomic, and rotationless approach Roux has but with 350 more algorithms. It's simply for people willing to go the extra mile to save an extra second from a solve, just like ZBLL.

Generally solving CP during FB is as simple as throwing in an extra R or U where they don't affect any block pieces or by inserting the pair slightly differently. Meaning your CPFB solution will only be a move or two more than your normal FB solution. However, identifying these couple of moves is quite difficult. I'm using a slightly generalized version of @Teoidus' 2GR tracking. The jist is that you recognize your "key swap" via the identities of 3 specific corners based on the permutation of your DR corners in relation to your "base" corner, which is just whichever corner you put in the block first. Then you track how the key swap changes while you are building your square (this is the hard part) using a handful (12ish) 4-cycles of key swaps called quadruples. Finally it's trivial to insert the final pair while solving CP with knowledge of your key swap (the process is simply to move the second piece of the key swap to UBR before inserting the final pair with an F move, or more generally any move parallel to the F/B sticker of your base corner).

A few of us had come to the conclusion that it isn't worth it for Roux since the CP solved CMLLs aren't particularly better than the others, but you've got much more knowledge in that area so I'd love to hear your take on it. Another option to consider is forcing a diagonal swap, which is just as easy as forcing no swap. Forcing an adjacent swap is also the same, but the 4 adjacent swaps are identical when you get to CMLL because it's the orientation of the pieces that matters, not their identity, meaning you'd cut down to 2/3 the cases as opposed to 1/6 with solved/diag.

I had a lot of the same thoughts running through my head last night; I've always thought of 2GR as more of a way to cut down on the amount of ZBLL cases rather than making a solve particularly more efficient. Reducing the corners to 2 gen definitely makes sense in a ZZ solve, but maybe during CPRRoux forcing a diag-swap PLS gives you better cases. I definitely don't think forcing an adjaceant swap is a good idea, there would be WAY too many algs for PLS. Today I'll take about 10 sample algs from both 2GR no-swap cases and diag-swap algorithms and see which ones are better. @Arc if you have time maybe you could run some tests for them in case the cases I pick out are outliers.

@Pyjam I'm a bit confused about the second step of the method you just proposed, does it orient all edges or just DF, DB and the u-layer ones? If it's only those six than this is pretty much just ZBRoux, with the difference that it works better for OH (you don't need m slices for EOD)

There's also a couple more things I'd like to mention about CPRoux PLS/Higgs. First off, yesterday I had a complete mental lapse and forgot to include corner permutation in my evaluation of how many algorithms the last step would be. Turns out it's in the mid 400s, which is close to double of what I predicted originally and just a little less than full ZBLL. In total the method is now around 500 algs, which is why I'm considering this being more like the "ZBLL" of Roux and less like medium alg method for anyone to learn.
Second, here's an idea I thought of to reduce the amount of algs in the last step while only adding a couple of moves: phasing the FR edge. Basically you do:

1. FB
2. BRSquare
3. EOD
4. Insert the FR edge and phase the u-layer edges
5. L5C

This is about as many algs and has similar movecounts as Roux with EOLR, making it a great stepping stone to learning full PLS. I could honestly see someone getting like sub 7 with this.
Third, just a quick note about what I'll name everything: I plan on just calling this method "Higgs" (my last name), the third step "EOD" instead of "EODFDB" and the last step "PLS". I'll continue to develop Bope as it's still a relevant method since it has so few algs, but I might take a little break from it to generate the PLS algorithms and develop this method further.

 

[Pyjam]

I was talking about orienting the last 9 edges. Not very difficult, actually.

The movecount (for the whole solve) seems to be the same than for vanilla ZZ.

 

[Thermex]

I was talking about orienting the last 9 edges. Not very difficult, actually.

The movecount (for the whole solve) seems to be the same than for vanilla ZZ.

How do you go about doing O9E? I feel like it could be a good step for both regular Roux and the method I recently proposed.

 

[Pyjam]

I use an intuitive approach and I'm still exploring the possibilities.
To orient 4 edges: (r U r) or (r U r'), etc. (Roux-like)
To orient 2 edges: (r U (R/R'/R2) U' r') or (F R' F') or (F/f R U R' U' F'/f')

At least, 8 bad edges is an easy case: r/r' U/U' r/r' reduces them to only 4.

I think that solving the EO at this stage is helping the look-ahead for the second block.
But, I'm really not an expert.
This is from a ZZuser's perspective.

 

[Pyjam]

There's some possible tricks like D r' U r D' in this example:

Scramble: U2 B2 L2 U' L2 U' L2 U F2 R2 U' R' F U B R B D' L R2 B'
R' D' B' r2 U r U' r D2 L' // (10) left block
D r' U r D' // (5/15) EO
U R2 U' R U' R2 // (6/21) right square
U' r' U2 M' // (6/26) DB edge
U R U' L U' R' U L' // (8/34) F2L
R U R' U R U2 R' // (7/41) Sune
U2 x R2' D2 R U R' D2 R U' l // (10/51) PLL A

After EO, I've spotted the 3 pieces in good place for the square, so I've solved DB a bit later.

 

[TDM]

D r' U r D'

woah, this even works with Petrus if you have the block in the left :O

 

[Teoidus]

My point though, is that during speedsolves my method actually does regularly achieve sub-40 movecounts, while being around 37 moves optimal.

Are you sure? Several people on this forum and HARCS appear to provide evidence against this.
For convenience, here are approximations I find reasonable:
9 CPFB + 9 SBsq&DFR + 9 EOLine + 15 remainder = 42.

Please note that, while I do give 9 moves as an estimate for CPFB, I have personally never approached this level of efficiency. I once took an average with unlimited inspection and the ability to backtrack in alg.cubing.net and got 11-12...

Another thing that seems to escape people's attention for some reason is that these are average movecounts. A method averaging 40 is not sub-40; in fact, most methods have a left-skewed movecount distribution and an average of 40 suggests that more than half of the solves are longer than 40 moves(!). Could you imagine getting times greater than 10 seconds more than half of the time and calling yourself sub-10?

4 moves isn't a huge difference; you basically end up adding ~2 moves to FB so that later in the solve you can one-look both LS+CMLL and LSE. It adds ~300 algs for the same reason ZBLL adds 400 algs to CFOP LL: to veer closer to a sub-40 movecount while only sacrificing the amount of time needed to learn huge alg sets. In no way is this method a "replacement" or "upgrade" from standard Roux; it just saves a few moves, maybe a full second and some of the time needed to recognize the steps that are skipped in this method by using CPFB (LS pair & LSE 4C). It has the same great efficient, ergonomic, and rotationless approach Roux has but with 350 more algorithms. It's simply for people willing to go the extra mile to save an extra second from a solve, just like ZBLL.

The issue is that a method like 42- or M-CELL will accomplish pretty much all of these goals with a fraction the number of algorithms. While the method itself might achieve efficient speedsolves, the opportunity cost associated with learning it is simply too high when there are other options like these available.

I had a lot of the same thoughts running through my head last night; I've always thought of 2GR as more of a way to cut down on the amount of ZBLL cases rather than making a solve particularly more efficient.

<R,U> reduction is almost never the most straightforward way to reduce movecount, but it does not simply reduce case count for no compensation (unless you made a bad CP method). For EO methods, it gives a significant ergonomic advantage, and in some cases (e.g. B2) the case count reduction can allow for more complex algsets (this is the main source of efficiency for <R,U>-reduction methods). Additionally, as a minor side effect, skip chances are greatly increased, increasing the chances of favorable results in competition.

For a quick example, I haven't yet posted anything on ways to solve the <R,U> subgroup more cleverly, but I did briefly describe the two following LS tricks on the 2GR wiki page:

• Anti-phasing: A lightweight technique to create much more favorable LL cases. Before F2L is completed, edges are forced to be unphased, avoiding pure twist 2GLL cases (the longest 2GLLs), Z perms (the longest EPLLs), and increasing chances of solving the last layer with a single Sune variant from 1/20.25 to 1/13.5 (this is twice as likely as an OLL skip in ZZ).

• Corner control: The last pair is solved while forcing a Sune, Antisune, Skip, or H OCLL case (these 2GLL subsets are the shortest), reducing LL movecount.

• CO at LS: If LS corner is already solved, an algorithm can be used to orient LL corners while inserting the last edge; if LS edge is already solved, an algorithm can be used to orient LL corners while inserting the last corner. Both situations leave an EPLL to complete the solve.

I don't think I've spent any more than 5-10 minutes exploring this type of thing, but when used in conjunction I see no reason why they would not counterbalance any losses of efficiency when compared to using ZBLL.

Reducing the corners to 2 gen definitely makes sense in a ZZ solve, but maybe during CPRRoux forcing a diag-swap PLS gives you better cases.

With this you avoid the pure twist cases, but your algs now must be at least 3-gen.

@Arc if you have time maybe you could run some tests for them in case the cases I pick out are outliers.

You know, I sorta feel bad constantly asking @Arc to run all of our half-baked method ideas. Perhaps we should all download HARCS and learn to use it-- @mDiPalma did make the software freely available for use by anyone in the forums, after all

@PyjamIf it's only those six than this is pretty much just ZBRoux, with the difference that it works better for OH (you don't need m slices for EOD)

I've seen this sort of sentiment occasionally on this thread and I think it is unhelpful and discouraging to new method developers. This community has been active for a long time and it is fairly safe to say that almost all (perhaps even in the strict mathematical sense) reasonable ways of permuting and orienting subsets of pieces on a 3⊗3⊕3 Rubik's Cube(TM) have been proposed and given a name at some point. Look, watch:

2GR is just B1 but with a key swap recognition method and some system for tracking CP through any arbitrary move sequence (who would ever need that)?
B1 is just NCPB but with some weird D/D' superposition collapse recognition method that I don't understand because @shadowslice e must've been high as a kite when he wrote it
LMCF is just the Rice method but solves FSE algorithmically instead of intuitively and solves 1 edge in LSE at the start of the edges phase because @efattah thinks LSE lookahead is hard
Speed-Heise is just Petrus but it reduces to L3C instead of ZBLL
Cardan Reduction is just Speed-Heise but with a different algset
B2 is just Roux with CP done before SB instead of after SB (mix the steps around, it's the same deal really)
ZZ-CT is just CLS but FR can be anywhere and DFR doesn't have to end up solved
ECE is just SSC but leaves EO for later
SSC is just Orient-First but with 24 algs for some conjugated OL5C thing

I wonder how our beloved big four method creators would feel if we told them:
Roux is just CF but you blockbuild the edges together to reduce to MU (why? Minh Thai was doing just fine with CF)
Waterman is just CF but you blockbuild a layer first for some reason
CFOP is just LBL but you influence edges while solving corners and you just throw a bunch of algorithms at orientation and permutation of last layer
ZZ is just Petrus with EO done in the beginning of the solve with some strange recognition and F/B move magic
Petrus is just Heise but more restricted because you have to blockbuild a certain way
Heise is just FreeFOP but with a commutator finish because Heise was allergic to algorithms

And I'm sure @shadowslice e could come up with a list twice as long where all the sentences are of the form "___ is just M-CELL but ___"...

The point which you might have noticed already is that, unless two methods are literally exactly the same, one difference that you might write off with a "it's just X but ___" can be completely game-changing. Is @Pyjam 's method "pretty much just" ZBRoux but with two steps switched? Well that changes a lot doesn't it? The solve goes from <RUFLBD> <RrUM> <MU> <RULFD> to <RUFLBD> <RrUM> <RU> <RULFD>. The lookahead is different. The whole approach to EO (recognition, prediction, algorithmic vs intuitive) is different. The whole approach to building the right block is different. One of ZBRoux's strengths is that CP can be recognized during EODFDB--that's different too now isn't it?

All these things must be considered, and though you might initially just think "it's X but with ___" that sort of approach is far from constructive.

There's also a couple more things I'd like to mention about CPRoux PLS/Higgs. First off, yesterday I had a complete mental lapse and forgot to include corner permutation in my evaluation of how many algorithms the last step would be. Turns out it's in the mid 400s, which is close to double of what I predicted originally and just a little less than full ZBLL. In total the method is now around 500 algs, which is why I'm considering this being more like the "ZBLL" of Roux and less like medium alg method for anyone to learn.

The issue with this approach, still, is that it offers movecounts obtainable by other methods that have much smaller algsets. Unless the alg or move count can be greatly reduced in some way, I dont think this type of approach is going to be worth it.

Second, here's an idea I thought of to reduce the amount of algs in the last step while only adding a couple of moves: phasing the FR edge. Basically you do:

1. FB
2. BRSquare
3. EOD
4. Insert the FR edge and phase the u-layer edges
5. L5C

Approximate movecount: 7 FB + 8 sq + 10 EODFDB + 5 insert&phase + 13 L5C&EP = 43

This is about as many algs and has similar movecounts as Roux with EOLR, making it a great stepping stone to learning full PLS. I could honestly see someone getting like sub 7 with this.

Perhaps, but I can see someone getting sub-7 with much simpler methods.

Third, just a quick note about what I'll name everything: I plan on just calling this method "Higgs" (my last name), the third step "EOD" instead of "EODFDB" and the last step "PLS". I'll continue to develop Bope as it's still a relevant method since it has so few algs, but I might take a little break from it to generate the PLS algorithms and develop this method further.

Others are already calling EODFDB EOStripe(Arc/Atunez)/EOLine(Pyjam) so I would suggest one of those existing names.

 

[Pyjam]

One precision: it's certainly not my method! I think it's a pretty obvious variant for ZZ or Roux and I was only asking if it has a name.
Otherwise, call-it Reverse-ZZ, or ZogZog, or Zoux.

Actually, I like its ergonomy. I'll continue to use it for a while.