-
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!
The New Method / Substep / Concept Idea Thread
- Thread starter elrog
- Start date
Thermex
Member
Yeah, you're probably right, EOsquare would be tough. Maybe this would work? It's basically "PetrusCP":
1. 2×2×3 block+CP (~16 moves? The whole thing probably couldn't be planned out in inspection but I bet a lot of it could)
2. 1×2×2 square on BR (7 moves)
3. Insert the FR edge while solving EO (7 moves)
4. Solve the rest in one alg (this is probably about as many algs as ZBLL, but they're all 2 gen)
With AUFs this is probably about 40 moves. I like the last two steps but maybe the first two steps could be optimized, I found it hard to preserve CP while doing the square.
Hazel
Premium Member
Also with my method, you can divide MMLS (2G1LLSLL) into 2 smaller steps if you like, TSLE and 2-gen TTLL, much fewer cases (than MMLS) but it's two-look rather than one.
@Thermex the 2x2x1 shouldn't be hard to make while preserving CP, just make sure you solve it with R, U, and slice moves only. Our two methods seem very similar, but (no bias intended) I think mine has some advantages. For one thing, by solving DB and DF during your first step you're making it harder to predict the whole first step in inspection, as well as making your EO more difficult because you'd have to use longer algs to make sure CP is preserved. If you solve EO and DB/DF at the same time, however, after you make the 2x2x1 in the back-right, you can limit it to M/U turns and therefore not have to worry about CP preservation. Then, you could just pair up the last F2L pair and insert it while solving LL in <340 R/U algs.
@Thermex the 2x2x1 shouldn't be hard to make while preserving CP, just make sure you solve it with R, U, and slice moves only. Our two methods seem very similar, but (no bias intended) I think mine has some advantages. For one thing, by solving DB and DF during your first step you're making it harder to predict the whole first step in inspection, as well as making your EO more difficult because you'd have to use longer algs to make sure CP is preserved. If you solve EO and DB/DF at the same time, however, after you make the 2x2x1 in the back-right, you can limit it to M/U turns and therefore not have to worry about CP preservation. Then, you could just pair up the last F2L pair and insert it while solving LL in <340 R/U algs.
Last edited:
Arc
Member
Wow that is a lot. 2x2x3 itself is really hard to plan in inspection. Add in CP and it's far harder. After that, you're going to have misoriented edges which means that the square is going to be very difficult to make (not nearly 7 moves), especially since you can't orient them with F. You're basically going to be breaking and restoring DF/DB every other move. Solving EO while inserting FR will also be very difficult for the same reason.
TSLE TTLL is not a good LSLL. It was a neat idea but in application it's just not good. It's got a high case count and high move count, with mediocre ergonomics.
I honestly don't think that you will find a 2gen LSLL that beats F2L 2GLL. It's got excellent move count and ergonomics, easy recognition, and with only 84 algs, which is just over CFOP.
Also MMLS is 2 looks. You have a look to form the pair, then a look for the alg. The difference between this and F2L 2GLL is that you've got almost 4 times the algs, much harder recognition, and probably save maybe half a move on average. You could maybe save a whole move if you doubled the alg count to include the sexy insert setup in addition to the unsexy insert setup, but I think that that's less worth it. I will do some move count analysis and post the results.
I always like to read this thread and check out the latest ideas, but in my opinion there is a great deal of postulating a new method (even a good one), then forgetting about it and postulating another method, without ever developing any one of them. I suggest picking what you feel is the most promising method and develop it for at least 3 months, and provide updates every few weeks as the method evolves, as the algorithms are tweaked for speed and finger tricks, lookahead is determined to be good or bad, etc...
I have been working on the same method for a year and a half and still have massive amounts of optimization to do, but I do feel focusing on one method is the better approach -- until and unless you feel the method is a dud and you move on to another one.
I have been working on the same method for a year and a half and still have massive amounts of optimization to do, but I do feel focusing on one method is the better approach -- until and unless you feel the method is a dud and you move on to another one.
shadowslice e
Member
I can honestly say I agree with this 100%. A lot of the time I have lots of method ideas but most of the time after only a little probing I find they're duds. This is why most of what I've done (I hope) has been reasonably new/good.
Basically I just throw a load of ideas at a wall, see what sticks then take a cleaner to see which are really stuck and continue to focus on them more than anything else.
Arc
Member
I think that waiting to do LS after EO isn't helpful at all. It makes EODFDB not possible to do with pure MU and as a reward for your harder EODFDB, you get a harder LS too. Better just to do CPFB SB EODFDB 2GLL, since both EODFDB and LS will be easier.
Thermex
Member
That's more I less what I'm doing, the reason I've proposed so many methods is just to see if anything sticks or if anything inspires someone to change it and make something really good. In the past this has worked: Ribbon was developed because I proposed a sorta meh method that JTay messaged me about and ended up optimizing, BOPE was also developed off a mediocre idea Crafto posted that I saw potential in. I think you're right though that eventually you have to stick with something, so I think I'll just stop posting mediocre ideas for a little while so I can work on BOPE and skewb TCLL.
@Aerma I think you and everyone else on this thread should continue to brainstorm CProux variants, I really don't know enough about CP to give much input but I'm sure something will come out of it. I honestly think right now the classic CPRoux Teoidus just proposed above is the best. CPRoux variant, but there might be something better.
Here's an idea:
1. Trigger pairs: Solve corners at DLB+DRB, solve edges at DL+DR, reduce remaining 6 corners to <R U* R', L U* L', U>
2. Expand pairs to squares, then F2B
3. EODFDB
4. 2GLL
Approximate movecount: 8 pairs + 8 squares + 12 pairs + 8 EODFDB + 13 2GLL = 49
1. Trigger pairs: Solve corners at DLB+DRB, solve edges at DL+DR, reduce remaining 6 corners to <R U* R', L U* L', U>
2. Expand pairs to squares, then F2B
3. EODFDB
4. 2GLL
Approximate movecount: 8 pairs + 8 squares + 12 pairs + 8 EODFDB + 13 2GLL = 49
mDiPalma
Member
- Joined
- Jul 12, 2011
- Messages
- 1,533
how about we reduce to <R2,L2,F2,B2,U,D> then we solve it
any thoughts???
any thoughts???
shadowslice e
Member
That's SSC
Thermex
Member
This is basically "CPBope". Not a bad idea but I think the original CPRoux idea you posted is much more efficient.
Ok, on taking a closer look at BOPE I've been inspired to propose the following (which I will call the TT method for teoidus). The blocks are solved in a somewhat different order because I think this way will be more ergonomic and have better flow.
1. Big Block: instead of Blocks from BOPE, which solves 2 1x2x2s on L and R, I solve a single 1x2x3 on L. This allows for greater flexibility in blockbuilding (for example, attaching a 1x1x3 to another 1x1x3 or building 1x2x2 + a corner and then keyholing in the edge), reduces the remainder of the solve to pseudo2gen <R,r,U,M>, and takes care of one of the 6 corners that would have to be otherwise solved by OSC/PSC.
2. Square + corner: build a 1x2x2 on R + solve the DFR corner. Often the DFR corner solution can be cancelled into the square solution, yielding even further efficiency gains and solving a second of the 6 corners otherwise dealt with by OSC/PSC.
3. CLL (OSC+PSC in one step): since 2 of 6 corners have already been solved, we can simultaneously orient and permute the LL corners with an algset 42 wide, skipping PSC 100% of the time!
4. L7E: many strategies described by @shadowslice e can be employed in this step. The entire step is <R,U,M> so guaranteed to be ergonomic, and lookahead is as easy as in LSE.
Approximate movecount: 7 Big block + 10 sq&corner + 9 CLL + 17 L7E = 43
Additional algs could easily reduce L7E movecount. I could see this potentially averaging 35 moves or even less with additional algsets.
1. Big Block: instead of Blocks from BOPE, which solves 2 1x2x2s on L and R, I solve a single 1x2x3 on L. This allows for greater flexibility in blockbuilding (for example, attaching a 1x1x3 to another 1x1x3 or building 1x2x2 + a corner and then keyholing in the edge), reduces the remainder of the solve to pseudo2gen <R,r,U,M>, and takes care of one of the 6 corners that would have to be otherwise solved by OSC/PSC.
2. Square + corner: build a 1x2x2 on R + solve the DFR corner. Often the DFR corner solution can be cancelled into the square solution, yielding even further efficiency gains and solving a second of the 6 corners otherwise dealt with by OSC/PSC.
3. CLL (OSC+PSC in one step): since 2 of 6 corners have already been solved, we can simultaneously orient and permute the LL corners with an algset 42 wide, skipping PSC 100% of the time!
4. L7E: many strategies described by @shadowslice e can be employed in this step. The entire step is <R,U,M> so guaranteed to be ergonomic, and lookahead is as easy as in LSE.
Approximate movecount: 7 Big block + 10 sq&corner + 9 CLL + 17 L7E = 43
Additional algs could easily reduce L7E movecount. I could see this potentially averaging 35 moves or even less with additional algsets.
Isn't this just one of the original WaterRoux variants? Crafto's L7E method is the only one that even approaches 17 moves and I think it was closer to 18. However I had some skepticism about its recognition and speed though.
Other than the LMCF that I am still working on, I would like to see concentrated development on BOPE, ZBRoux, and possibly other WaterRoux variants. Is anyone still working on ECE/SSC, 2GR, 2GRoux? Perhaps we can generate a list of the actual methods that are being seriously worked on.
I am still working on the Waterman Set 2 algorithms (48 on R, 48 on L), as well as set 7 (qty 24), I have been finger trick optimizing them and regenerating the bad ones, etc., it is time consuming but this particular set applies to all methods which finish with L7E.
What is most interesting is how using the left side reflections doesn't work at all. You need totally regenerated algorithms for the left side cases.
My favorite recent discovery is a set 7 algorithm on the left side:
F' R U M2 U' R' F
Swaps UL, FL (both disoriented), and orients midges (2 bad midges on DF, BD).
This algorithm can be done in 0.5 seconds or possibly much faster by an expert.
I would mention that the above algorithm was not discovered by an algorithm generator tool. I have stopped (for the most part) using algorithm generators. Instead I fiddle around with random highly ergonomic sequences and see what they do to the cube. The above sequence was discovered during these 'fiddle sessions' and I found it could replace an existing Waterman Set 7L algorithm. I spend around 30 minutes a day trying new ergonomic sequences and checking their effect. Once in a while the effect is really useful and can be incorporated into my method.
Thermex
Member
This is pretty different from BOPE, and I though of an idea a while ago that almost the exact same thing and maybe saves a move or two with less algs:
1. FB
2. BR square
3. VOP L5E: this solves the last 5 corners in a similar way to OSC/PSC
4. Crafto's L7E method
EDIT: I typed this up as @efattah posted his response, so you probably don't need to look through both. As he said, this sort of idea was proposed a while ago in the WaterRoux thread and is pretty good.
@efattah as far as I know the only methods that are really being worked on right now are our two methods, LMCF and BOPE. BOPE progress is slow, nobody's really helping me right now with OSC/PSC and I'm yet to find a great way to do L8E. One thing I've though about recently is using TEG with BOPE, it saves a move or two to use a TEG and potentially push Bope under 40 moves. I think it's only worth it to use TEG for LSC if you already know the algs from 2×2, though.
As for the other methods you mentioned, nobody's really found a CPRoux variant that has stuck, and I really think someone just needs to figure out how to do CPFB until it goes anywhere. I believe ZBRoux/LLOB has already been fully developed, as has 2GR. WaterRoux was sort of abandoned since Bope looks better, but it could make a resurgence.
Last edited:
For ZBRoux the method is developed from a technical standpoint but there is still not a single person who knows full ZBLL and has the DFDBEO algorithms memorized, so we don't even have a sample size of 1, to get speed comparison estimates vs. CFOP or Roux... By 'developing a method' I mean to imply that there is at least one person who has memorized all the algorithms and can execute full speed solves with it, and has been using it as a 'main' method (even temporarily) for a few months.
This idea is very different from that method and from WaterRoux because it has more of a focus on ergonomics and takes much fewer algorithms and might be the first method to have the potential for sub-40 or even sub-35 movecounts. OSC/PSC are integrated into the other steps to skip PSC 100% of the time with just 42 algorithms. Additional algorithms can be learnt to solve the last edge + corners of last layer, reducing movecount even further (for example Tyrannical Caterpillar which I was inspired by partially and is less efficient than TT).
I think we all should start looking into TT method and variants to try and develop it. Perhaps you should try and modify BOPE to incorporate some of the more efficient aspects of TT instead and meanwhile I can investigate some ways to finish L7E in even less than 17 moves.
