Thermex
Member
@Pyjam I like your OL9E idea. You should continue to develop it.
Second, I wasn't trying to shoot down @Pyjam's idea, I was trying to encourage it. I was simply saying that it would be good for OH. However, I will admit I am guilty of doing what you mentioned above on numerous other occasions, and I'll try to cut down on how much I say that, because as you said, it doesn't really give much feedback to the proposer.
Third, I think today I'll explore more ways to cut down on PLS algs without CPFB, like Anti-phasing and corner control. Those are probably better than the 2GPLS algs, which I genned a couple of today and were terrible (~16 moves).
Also I should download HARCS, I'm not sure why I keep asking @Arc to do all that for me
And finally, EOStripe sounds cool. Let's use EOStripe.
Okay, so I have a couple of things to say. First off, you're right that there are methods out there with similar movecounts and less algs than mine, but that doesn't mean they're "better". You could say the exact same thing about ZBLL. It's less efficient than "42" or WaterRoux or whatever, but many top solvers use it. Why? Because it's ergonomic and easy to understand. Sure people have made methods with less algs than mine that are equally efficient, but they're often difficult to learn and have a lot of steps. My method is 4 simple steps that are ergonomic, rotationless, and easy to understand, despite being a lot of algs. I'm not saying people should use it over other methods, I just think it could be a really fast method for Rouxers willing to take the extra mile. Another thing I want to point out is that I said the method is potentially sub-40 moves, not sub-40 in its current state. Most methods are less efficient in the pre-developed proposed form than the mastered, developed form. Basic Roux is around 48 moves on paper, but after being developed and pushed to its limits by people like Kian, it's nearing 42-43 moves. If I developed and practiced my method for months and months and added little tricks to speed up steps, at some point I could probably push it under 40 moves. And I have to agree with you that I say "sub-40" too much; we all do.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?
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.
<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.
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.
- 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.
With this you avoid the pure twist cases, but your algs now must be at least 3-gen.
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
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.
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.
Approximate movecount: 7 FB + 8 sq + 10 EODFDB + 5 insert&phase + 13 L5C&EP = 43
Perhaps, but I can see someone getting sub-7 with much simpler methods.
Others are already calling EODFDB EOStripe(Arc/Atunez)/EOLine(Pyjam) so I would suggest one of those existing names.
Second, I wasn't trying to shoot down @Pyjam's idea, I was trying to encourage it. I was simply saying that it would be good for OH. However, I will admit I am guilty of doing what you mentioned above on numerous other occasions, and I'll try to cut down on how much I say that, because as you said, it doesn't really give much feedback to the proposer.
Third, I think today I'll explore more ways to cut down on PLS algs without CPFB, like Anti-phasing and corner control. Those are probably better than the 2GPLS algs, which I genned a couple of today and were terrible (~16 moves).
Also I should download HARCS, I'm not sure why I keep asking @Arc to do all that for me
And finally, EOStripe sounds cool. Let's use EOStripe.
Last edited:
