The New Method / Substep / Concept Idea Thread

[Shiv3r]

anyway, I like ZZ-D but I don't want to learn 2GLL just to make it usable.

 

[Teoidus]

..well, I think the only reason zz-d would be viable is that it ends with 2gll...

the issue with 2g that is that it's very ergonomic but can tend to be inefficient. solving the entire last layer with 1 algorithm is one of few ways in which you can efficiently take advantage of 2g

the other option is to solve all of the remaining f2l+ll with new algsets, like maybe some 3phase orient-separate-permute type thing. those algs will likely be R2-heavy though

 

[Shiv3r]

..well, I think the only reason zz-d would be viable is that it ends with 2gll...

the issue with 2g that is that it's very ergonomic but can tend to be inefficient. solving the entire last layer with 1 algorithm is one of few ways in which you can efficiently take advantage of 2g

the other option is to solve all of the remaining f2l+ll with new algsets, like maybe some 3phase orient-separate-permute type thing. those algs will likely be R2-heavy though

Its a king OH method anyway, even without 2gLL, even with 2gOCLL-EPLL

 

[Teoidus]

zz-d w/o 2gll is certainly not a king OH method, and i'm not sure zz is even a king OH method

 

[Shiv3r]

zz-d w/o 2gll is certainly not a king OH method, and i'm not sure zz is even a king OH method

ZZ = Roux and both >CFOP in terms of both ergonomics and efficiency

 

[Teoidus]

ZZ and CFOP are usually comparable in efficiency, so I don't know where you're getting that

Roux is more efficient but has a lower tps esp. in OH

 

[Shiv3r]

ZZ and CFOP are usually comparable in efficiency, so I don't know where you're getting that

Roux is more efficient but has a lower tps esp. in OH

but CFOP is not comparable to ZZ in terms of ergonomics, which I think is a lot more important for OH.

 

[Teoidus]

I think ZZ ergonomics is a bit overhyped for OH. Sure, you only have to do z rotations, but there are still double turns that CFOP doesn't have and awkward D moves.

 

[Shiv3r]

I think ZZ ergonomics is a bit overhyped for OH. Sure, you only have to do z rotations, but there are still double turns that CFOP doesn't have and awkward D moves.

I do say that the beginning of ZZ is a little hard. But I still like the ergonomics of COLL-EPLL over OLL/PLL. You know how hard it is to do G perms OH? In fact, I specifically don't use CFOP for OH because of how much I hate OH-ing the last layer.

 

[CxCxC]

Hey everyone,

I had an idea that can be useful for total beginners if they want to start out with the ZZ method.
As everyone knows, LL edges in ZZ are already oriented and so there are only 7 OLL cases that a beginner will have to remember. But if the solver also applies phasing and then solves the OLL, out of the 7 OLL cases, 5 of them will preserve the solved edge permutation and the solver will only have to memorize 9 PLL cases!!!
A-a, A-b, E, F, H, Z, N-a, N-b, T
and the two OLLs that don't preserve the edge permutation : they are the ones that have all the 4 corners un-oriented.
and instead of using sune/antisune, the solver will have to use Alan/Inverse Alan so that the permutation of the edges is preserved and then he'll get a PLL case only out of the 9 ones that I stated above.

I guess that this can help a beginner solve a cube with moderate speed without having to learn too many algs right from the start

For the rest of the 2 OLL cases, the edges, if they are not permuted correctly and after applying the OLL, there is a 50% chance that a PLL out of the above 9 will occur, as after applying the OLL, the edges will get permuted correctly

What do you guys think about this? Can this help a beginner cuber only slightly or can it help him/her to a large extent?

 

[xyzzy]

So… ZZ-reduction? It's okay for the reduced alg count, but using OCLL and two-look PLL might be better anyway.

Pros: fewer algs than OCLL + PLL; phasing is very intuitive; lower move count than OCLL + two-look PLL.
Cons: more algs than OCLL + two-look PLL; OCLL preserving phasing has slightly worse algs; you can't always phase while inserting the last pair.

("Frequent skips" as mentioned on the wiki is super-misleading. The skip rates are comparable to OCLL with 2-look PLL.)

 

[Shiv3r]

I feel like genning a algset: <R2 U D> PLL's, just because I can (mostly for squan lolz)

 

[Sion]

I decided to get my 4x4 method and optimize it into a 3x3 method, and actually, it seems quite good, so i'll place the format here. I found it to be a hybrid of Petrus and PCMS, which are two methods highly acclaimed for their low movecount and ergonomics. Since none of the steps are really unique to this method, I'm inclined to call it LMBC, or Low Movecount Block Conglomerate.

- Make a 2x2x3 block at the back of the cube. The sky is the limit. I usually do A 2x2x2 block and add a 1x2x2 extension. However, you could also make a 1x2x3 and extend that into a 2x2x3, or make a 3cross and add the two f2l pairs.

- Make two columns on the F face. you could also do a psuedo WV here if you wanted to.

-COLL/CLL

-L5EOP

Edit:
Can someone do an example solve?

 

[Teoidus]

I decided to get my 4x4 method and optimize it into a 3x3 method, and actually, it seems quite good, so i'll place the format here. I found it to be a hybrid of Petrus and PCMS, which are two methods highly acclaimed for their low movecount and ergonomics. Since none of the steps are really unique to this method, I'm inclined to call it LMBC, or Low Movecount Block Conglomerate.

- Make a 2x2x3 block at the back of the cube. The sky is the limit. I usually do A 2x2x2 block and add a 1x2x2 extension. However, you could also make a 1x2x3 and extend that into a 2x2x3, or make a 3cross and add the two f2l pairs.

- Make two columns on the F face. you could also do a psuedo WV here if you wanted to.

-COLL/CLL

-L5EOP

Hilarious, this is literally hawaiian kociemba + a y rotation

It just makes my day that two people have come up with this method independently.

 

[Sion]

Hilarious, this is literally hawaiian kociemba + a y rotation

It just makes my day that two people have come up with this method independently.

So I created Hawaiian Kociemba for 4x4? AWESOME. I CALL IT Hawaii 4-O!

Heres the overview of Hawwii 4-O

1: Solve a 3x3x4 block on the back. To me, this was the longest step, but probably more because I am not too familliar with how Cubies move around it.

2: at front, solve two 1x1x3 pillars. This should leave f3l in a state of the FD edges unsolved and it's center.

3: L5EO- do a general L5EO to flip most of the edges as if it were on a 3x3.

4: LNEA- Last Nine Edges Augment, flip remaining edges while inserting Last FD edge. this would also be the prime step to solve Parity cases.

5: EEPLL- extended EPLL, or just permute the already oriented edges, but unsolved edges in a single algorithm.

 

[AreRouxAmused]

Has there been any subsets created for roux because I want to do CO and maybe CP with a last slot f2l style insertion?

 

[Đỗ Viên]

I created a new method for 3x3. I call it Perry !
The step:
S1: Make b-block + last edge in E-slice ( seems like 3x2x1 block in LD+ 2x2x2 block in BR) (intuitive)
S2: Orient
a) Orient corner (23 cases)
b) Orient edge (intuitive)
S3: Make 2x2x1 block on UBL (intuitive)
S4: Permute last 4 corner and last 3 edge (about 20 cases + symmetry).
What do you think about this method ?

 

[Teoidus]

If you have FB + 2x2x2 on DBR solved, then CO and EO solved, it will be hard to make a square in UBL without breaking your 2x2x2 on DBR

Or maybe I'm not reading this correctly. Example solve?

 

[Đỗ Viên]

You can use M,U2 to make a square on UBL without breaking your 2x2x2 in DBR.
Here is example solve:
SCR: F' D R' F B2 L' U' F U2 R D2 R2 B2 L D2 R' U2 L2 F2
S1: F2 R U' B r2/FB
+ U R2 U' R U' M U' r U2 R' U' R2 U2 R'/2x2x2 in DBR
S2
a) skip
b) M' U2 M U2 M' U M
S3: U2 M' U2 M U M' U2 M U2
S4: B2 U L2 F2 U' B2 D2 R2 D' F2 D'
sorry for my English

 

[Teoidus]

Recognizing and Solving CP in Inspection

Motivation
To solve FB + EO + CP within the first 13 moves of the solve and without any need for a complex recognition system. This is a big cornerstone of a method that I'm working on (which begins with EO -> CPLine -> FB), and I figured I'd put this up here in the meantime since it could help develop other CP-first methods. I don't know nearly enough group theory to formalize a lot of the things below (and if someone does, please offer suggestions as I'd like to look into group theory/algebra at some point), but I'll try and explain as concretely as I can.

CP basics
If we assume DLB and DLF are solved, the remaining 6 corner pieces can be in 6! = 720 distinct permutations. However, only 120 of these permutations are reachable by <R,U> (there is a proof of this at Jaap's puzzles page).
For each of the 720-120 = 600 permutations not in <R,U>, there exists at least 1 single swap that will place the corners into <R,U> (you can prove this yourself by solving up to 2x2x3+EO, then solving the F2L and OLL with only <R,U>, leaving either an adjacent or diagonal swap. Had this swap been performed before you solved F2L+OLL <R,U>, you would have been left only with an EPLL, showing that one need only a single swap to place any permutation into the 2-gen group). Since we can perform pure corner twists with sune combinations, we also know that corner orientation is completely solvable <R,U>, so we can now extend this statement and say that this one swap is all that is necessary to make the corners completely solvable <R,U>. I'll call this swap the "key swap".

Only 5 distinct key swaps are necessary to reduce any of 720 permutations to the <R,U> group
For any of the 720 permutations, we can use <R,U> to solve ULB and ULF, leaving the remaining 4 pieces on R unsolved. We can now use a single R move to fix one corner on the R layer, leaving at most 3 on R unsolved. These 3 corners can be permuted in any of 3! = 6 ways. Since one of these permutations results in the 4 corners on R being permuted correctly relative to each other, we only need 5 distinct swaps to reduce any 6-corner permutation to one solvable <R,U>.

By extension, any permutation on 6 corners can be reduced to a functionally equivalent key swap that restores the corners to <R,U> group
Examples: If I perform an E permutation, which performs a double 2-cycle on U, I can put corners back into <R,U> group by performing a Y perm (single diagonal swap on U) or [R2: T perm] (single adjacent swap on D).

With DLB solved, DLF piece insertions can be encoded as a composition of an "auxiliary" swap and some permutation on the remaining 6 corners
So basically we can express the insertion of the last FB corner piece as a composition of the single swap between the actual yet unsolved DLF piece & whatever piece is currently incorrectly permuted at DLF (= auxiliary swap) and some arbitrary permutation on the remaining 6 corners. Since we know that such an arbitrary permutation can be reduced to a functionally equivalent key swap, we can identify different ways of inserting DLF by the key swaps that their respective 6-corner permutations reduce to.

Thus any arbitrary permutation of the 8 corners can be expressed by a key swap!
Since we can express any permutation of 7 corners as a DLF insertion + some leftover permutation of 6 corners, and since we can reduce any DLF insertion to an auxiliary swap + some arbitrary permutation that reduces to a key swap, we can express any permutation of 7 corners in terms of the key swap that will be needed if we simply insert DLF with a pure auxiliary swap. In other words, any permutation of 7 corners can be expressed in terms of a soon-to-be key swap that will be necessary after a pure auxiliary swap is performed to solve DLF. And of course it's sufficient to show that we can do this for 7 corners, since any permutation of the 8 corners can be reached by a permutation of 7 + some rotation. Thus this soon-to-be key swap must be present in any arbitrary 3x3x3 scramble, and so a means of identifying it would allow us to determine what CP fix we need in inspection!

For reasons explained later on tracking CP, I've chosen these key swaps to be defined as the 5 possible swaps between DLF piece and the other 5 pieces if DLF is unsolved, and the 5 possible unique swaps on R if DLF is solved.

BLD memorization methods encode inverse permutations as a composition of multiple single swaps
I'm not sure if this is common knowledge, but I figured I'd put this here for completeness' sake. Given some buffer position A, the memo "BCD" essentially can be expanded to: swap positions A&B, then A&C, then A&D. So basically when you BLD trace, you're constructing a way to invert the corner permutation through a series of single swaps.

The permutation given by any successive series of swaps between positions A B1, A B2, ... A Bn can be inverted by performing the successive series of swaps between positions A B1, B1 B2, ... Bn-1 Bn
Each new swap in the permutation A B1, A B2, ... A Bn places the piece at A into position B1, B2, ... Bn, resulting in a cyclic right-shift of the string (A B1 B2 ... Bn). Each new swap in A B1, B1 B2, ... Bn-1 Bn places the piece at B1, B2, ... Bn into position A, B1, ... Bn-1, resulting in a cyclic left-shift of the string (A B1 B2 ... Bn). Thus these two permutations are inverses of each other. (lol, someone help formalize this for me pls, i get it intuitively but i don't know group theory or cycle notation)

Thus modified BLD tracing techniques can be used to determine key swap of any 3x3x3 scramble during inspection
Rotate the cube so that DLB is solved. We can trace the permutation out as we would in BLD (if we hit the DLF piece, we pretend it's the piece that's actually currently at DLF, essentially imagining the auxiliary swap has already been done). However, instead of keeping track of the swaps A B1, A B2, etc. (which solve the corner permutation being traced), we keep track of the swaps A B1, B1 B2, etc. (which generate the corner permutation being traced), and instead of memorizing the swaps, we memorize a single key swap that we update with each new swap that we trace out. Since we know that any arbitrary permutation of 6 can be reduced to a key swap, we can reduce the composition of the stored key swap + the new swap being traced out to a new, updated key swap. An outline of this algorithm:

1. Let key swap be the identity
2. For each new target in BLD trace:
2a. Update key swap based on the swap between new target and previous target

and of course we don't have to handle cycle breaks the way BLD solvers do as we don't actually have to execute the swaps on a fixed buffer, so we can simply move the buffer to the location of the new cycle and continue updating the key swap from there.

For each of the 30 key swaps, there are 30 possible new swaps... however, don't fear the 900 cases you might have to memorize in order to do this (they're not even real algs, just facts about swaps. Like memorizing your multiplication tables, or eating vegetables. It'll be healthy for you.). I believe you can reduce by symmetry along S and along UL edge, leaving ~225 cases. Either way, if people can memorize hundreds of 3style commutators or ZBLL algorithms I'm sure one can remember these permutations. In the end with AUFs there are only 2 permutations * 3 orientations * 6 swaps = 36 actual algorithms to insert the DLF corner and fix CP.

So now we have a way to figure out the key swap in inspection ("CP Tracing"). Now to discuss how to keep track of this key swap as we solve other things like EO, FB square, etc. ("CP Tracking").

One need only know the unique effects of F and B moves on key swaps + some simple equivalency rules in order to fully track CP
Let "generators" mean the 2 faces that we intend to reduce the corners to (for example, if the scramble begins with DLB in ULF position with yellow sticker on L, the two generators that we reduce to will not be <R,U> but <B,R>. This isn't a worry as by the time we solve DLB to its proper place our generators have necessarily shifted back to <R,U>). Now for simplicity's sake we will speak of moves and faces with respect to our generators (so if our generators are <B,R>, we'll call a U move a B move, because that's what it functions as if we imagine <B,R> are actually <R,U>). Now we just have to show that, given some key swap + any face turn wrt our generators, we can easily know what the updated key swap will be.

For U and R moves, tracking CP is pretty trivial. This will be basically identical to tracking pieces on the cube normally.

For L and D moves, tracking CP is essentially the same as for U and R moves, but we also have to make use of the identities L = Rw x' and D = Uw y'. First, the swap is affected by the R or U move respectively (which we have covered above); then, the rotation changes the identity of our generators. For example, if we have an adjacent URB-DRB swap on R with respect to <R,U>, and then we do a D move, we can simply track the effect of the D move on our swap like we do with U moves (so now we have URB-DLB swap, or diagonal swap, since the DRB piece gets moved to DLB from the D move) and then change our generators from <R,U> to <B,U> to account for the y' rotation in the identity D = Uw y'. Notice now though that our definitions in terms of absolute face turns change if we do this: before, an R move wouldn't do much to CP, but after the D move, an R move is essentially an F move with respect to the <B,U> group, and so will have a very different effect. This is why I'm choosing to refer to faces and such wrt generators, so we don't run into these errors.

F and B moves are where things get a bit complicated. First we can just consider F moves, since B moves will be basically the same thing + a rotation (like how we dealt with L and D moves). Because F moves involve moving stuff into and out of the 7th DLF corner position, we get all sorts of strange behavior. I don't see much of a pattern here (though admittedly I haven't looked into it much), so I think the only way to do this is to memorize the effect of an F move on any possible key swap you might have. There will probably be ~105 cases without symmetry (35 possible swaps * 3 possible F moves) so I can't imagine it'd be that bad.
And as said above B moves will essentially behave the same way but with an additional rotation.

Thus corner permutation can be detected in inspection, tracked or predicted during whatever first setup moves are necessary, and reduced to <R,U> soon after
So there it is. BLD tracing techniques + some memorization to figure out what swap you need, then some tracking while or before you solve FBsq/EO/whatever crazy first step you want your CP method to have, and then one of 36 DLF insertions that simultaneously reduces the remaining corners to <R,U>. Not quite the missing link of ZZ, but still pretty cool imo.