The New Method / Substep / Concept Idea Thread

[Shiv3r]

at first I didnt understand the Idea, because it seems like theres 10 corners, until I realized the L4C at the end stood for last 4 centers.
I thought up of some big cube Idea where you solved F2B and CMLL(at least corners) and then used the slices for edge pairing.
your final 2 steps could be to create 2-color seperation like in roux, then to solve the centers and then the edges.

 

[Teoidus]

That is basically what's happening yeah. After UL and UR dedges are solved, two-color separation arises naturally.

 

[Shiv3r]

anyway, I had this idea for a rotationless petrus and a less hard EO:
FB
orient 3 edges and place them in the places the SB would normally go
roux LSE 4a and also place down edges simultaneously
solve 2x2x3+EO.

 

[Shiv3r]

--Sub 40 with sub-40--
okay, so this challenge is simple: design a method that averages under 40 moves during a speedsolve, and record at least sub-40(with sub-40 moves) average of 12 with it.
fastest average wins.
whoever wins will be given recognition and the devotion of a group of people like me who develop solving methods further.

 

[Daniel Lin]

Tentative idea for 4x4 direct solving method
My attempt to do something similar to stadler, but hopefully not as inefficient.

(Note: the notation I use has l' r = M', not l' r = x)

1. FB (1x3x4 on L)
2. SB (1x3x4 on R) with <l, r, R, U>
3. CMLL
4. L28P = L12E + L4C with <l, r, U>

Obviously the only really new part here is the last step, so here's my approach:
4.1. Orientation

4.1a. OBlock: orient a 4x3x1 on l slice (so U/D colors only on D, F/B colors only on the l half of F/B centers)
4.1b. EO with <r, U> (one r/r' flips all edges on r, and this is analogous to 3x3 arrow case)
4.1c. OL4C: orient the last 10 center pieces (w/ <l, r, U> Niklas)​

4.2. ULUR with <l2, r2, U> + M' U2 M
4.3. Permutation with <l, r, U2>

4.3a. Pair L8E
4.3b. L4C (3x3 redux)
4.3c. L4E (+PLL parity)​

Pros:
No OLL parity
Rotationless
Lookahead in step 4 easier than in cage/stadler (EO can be detected w/o looking at B/D, reduction-based approach -> don't have to look for specific pieces -> cases are easy to come by, always solving a specific thing involving very few pieces -> things are easy to track and identify, similar to 3x3 LSE)
Centers don't take forever like in cage/stadler
Direct solving is fun, slice turns are fun

Cons:
Lookahead may be hard in F2B
Without being able to plan whole FB in inspection, effieciency is non-ideal
OL4C, L8E, and L2C currently still take more moves than I'd like
No easy way use 3x3 hax like CMLLEO or ULUR influencing during EO (though I was thinking one might be able to influence OL4C during EO)

Still developing algs, but current average movecount estimate based on own solves:
50 F2B + 10 CMLL + (8 Oblock + 6 EO + 16 OL4C) + 8 ULUR + (16 L8E + 16 L4C) + 5 L4E (+ 6 PLL parity) = 135-141 STM

Compare with me going to cubesolv.es, opening up a bunch of ~30second 4x4 reconstructions, and getting an avg Yau/Hoya movecount of (131 + 120 + 154 + 139 + 137 + 124 + 134 + 173 + 176 + 158 + 162 + 158 + 161 + 155 + 135 + 136 + 137)/17 = 146.47 STM

Don't really get how the EO works. what do you mean by "orient a 4x3x1?

sounds like a cool method though

 

[sqAree]

Hm, I'd say planning a 1x3x4 in inspection should be pretty impossible?

 

[Shiv3r]

yeah, but he said that it isnt possible, so it may be un-optimal movecount.

 

[sqAree]

Alright. I still find that approach interesting. Can I see a full example solve somewhere, or at least of step 4?

 

[Shiv3r]

yeah, the LSE-equivalent step, I would like to see how that goes.

 

[Teoidus]

Don't really get how the EO works. what do you mean by "orient a 4x3x1?

Yeah, I wasn't sure how to explain that part clearly. More explicitly, what I meant is that you want to build a 4x3x1 "block" on the l inner slice that satisfies the following:
U/D colors only on D
F/B colors only on the half of the F/B center that's on the l slice

The approach I take to do this, if that helps to clarify:
Form a 2x1 bar of center pieces made up only of U/D colors, use l move to put onto D face
Form a 3x1 bar of pieces, composed of a 2x1 bar of center pieces made up only of F/B colors and one wing piece, such that when inserted with l' U2 l, l U2 l', or M' U2 M or M U2 M', the color of the wing piece that ends up on D face is a U/D color.

Alright. I still find that approach interesting. Can I see a full example solve somewhere, or at least of step 4?

I should have one up by tonight.

Example solve

Pulled the first scramble I got from qqtimer and did a solve.
alg.cubing.net doesn't let me write things like M', E2, etc and counts things like 2R' R as two moves, so for move count I was counting in terms of what I thought constituted a "move" during execution (which basically just ends up being a more restrictive form of ATM, since obviously things like 2L 2R are not easily done in one motion). I've put those counts in the comments on the reconstruction, so if you disagree with my counting you can feel free to come to your own conclusions.

Movecount breakdown:
F2C: 12
FB: 12
SB: 37
CMLL: 10
LSD: 83

Orientation: 33 (8 Oblock, 8 EO, 17 OL4C)
Permutation: 50 (11 ULUR+forcing even pairs, 32 finish redux, 7 permute the rest)​

Total: 142

Happy to see that things weren't so far off from my initial estimate (50 F2B + 10 CMLL + (8 Oblock + 6 EO + 16 OL4C) + 8 ULUR + (32 Finish redux) + 5 L4E (+ 6 PLL parity) = 135-141 BTM)

I would still like to push the movecount down further, though (the only way I think this could be remotely competitive, as lookahead is harder than Yau/Hoya and I think people usually prefer outer layer turns). I think the main concern on this front is OL4C and finishing up redux. I really hope there's a less nasty alg for finishing edge pairing, and perhaps algs could be genned for orienting or permuting all 4 centers at once.

 

[Daniel Lin]

for the end of center EO, you could've done
[2R U2 2R', 2U2 2D2]=r U2 r' U2 D2 l U2 l' U2 D2

I really hope there's a less nasty alg for finishing edge pairing,

for last 2 edge pairs, isn't that the same thing as OLL parity? if you get that case in Yau and try pairing the edges you will get OLL parity later in the solve. So I don't think there is a better alg

really cool method btw

 

[Teoidus]

for the end of center EO, you could've done
[2R U2 2R', 2U2 2D2]=r U2 r' U2 D2 l U2 l' U2 D2

Oh yeah, good point. I'll update my alglist with that

for last 2 edge pairs, isn't that the same thing as OLL parity? if you get that case in Yau and try pairing the edges you will get OLL parity later in the solve. So I don't think there is a better alg

Yeah, it seems very similar (I don't have OLL parity algorithm memorized, so maybe they are in fact identical). My hope is that there might be some friendlier alg that doesn't have to preserve solid color centers, or maybe there is some intuitive way to force it not to happen while solving ULUR.

Speaking of forcing skips: if anyone tries this method, you might find that sometimes after ULUR pairing step you have a 3-cycle of wing pieces (so 3 of the last six edges are paired, and the last 3 have to be solved with a 3-cycle). You can solve this by pairing up edges as you would in redux, though what I prefer is to: get exactly two paired edges into the M slice diagonally across from each other, along with two wing pieces that need pairing, then do an l2 or r2 to pair the wing pieces and break the two pairs (3 original pairs + 1 new pair - 2 broken = 2 pairs). After solving ULUR you'll find that the last 4 edges are trivially solvable by l2 or r2 (at least that's what I've found to be true thus far). This way you don't have to rotate or break F2B to complete edge pairing

really cool method btw

Thanks! I'm still unsure of its viability but am hoping that it could be competitive with the right adjustments, as I really like the premise of it.

 

[antech101]

So i was bored and decided to just think of new ways to solve a 3x3, and eventually i made something! It may already be a method but i'm proud of myself for figuring it out anyway xD so it basically works like this:

Center: you start off with solving the center layer, not much to be said here.

Edge swap: After you solve the centers you use a simple algorithm to swap the edges so they match their centerpiece

Corner Swap: same thing as edge swap but with corners

Last 2 Layers: You then use CFOP last layer algs to solve the 2 sides


So is this already a method? And are there any ways i can improve on this method? thanks!

 

[Daniel Lin]

So is this already a method?

belt

 

[antech101]

belt

man, thought i was on to something there xD

 

[Daniel Lin]

Hm, I'd say planning a 1x3x4 in inspection should be pretty impossible?

I think people really good with Roux or big cubes could predict a 1x3x3, not sure about a 1x3x4

 

[Shiv3r]

hey what if we did something like COL/ZZ-line on left and did FB on d face and SB on U face, then did CMLL on side then you can use E and R moves to solve LSE???
LOL nope this would suck pretty bad

 

[Teoidus]

Hey man if you can get good with <E,R> LSE I'd be pretty impressed

Since I can't seem to find a good 4x4 solver that's flexible enough for my needs, I'm biting the bullet tonight and writing up a 4x4 definition file for ksolve. Hopefully some good algorithms will come of it!

In the meantime, I'm trying to figure out if it'd be possible to do:
EO and OL4C at the same time
3x3 redux in one step (this would leave the finish to be: solve ULUR, permute the rest super easily)

I also learned that the last two edges algorithm is indeed just OLL parity in disguise so chances are the movecount on that monster isn't going down too much

 

[Shiv3r]

what about for 3x3 redux you do some intuitive M-slice pairing and the solve the centers in one step

 

[Teoidus]

That's pretty much what I'm doing now. I'm going to be trying to generate PL4C algorithms, but in the meantime I want to see if there's another approach to this that I'm missing