• 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!

ZZ-Edges First discussion

mDiPalma

Member
Joined
Jul 12, 2011
Messages
1,534
Welcome.

ZZ-EF (edges first) is an interesting and potentially superior approach to the only legitimate 21st century speedcubing method, ZZ. The premise of this method is to capitalize on lucky cases when they appear, and to ignore unlucky cases that other speedsolving methods would unfortunately require that you address. The variant I am about to describe is 72 times luckier than traditional ZZ, with regards to the first block. It is 4 times luckier than traditional ZZ, with regards to a particularly important F2L pair. And it is around 18 times luckier than traditional ZZ with regards to the Last Layer. Note that ZZ is already significantly luckier than other mainstream solution methods, including CFOP and CFCE. As a result of the overall luckiness of this method, speedsolve movecounts should cap, for competent users, at 50 htm. These luckiness factors may sound strange to hear at first. Give me a chance to explain the variant.

This variant is also applicable to the Petrus and Heise methods, provided appropriate measures in adaptation are taken. This variant is not compatible with different (read, "inferior") methods: CFOP, Roux, TFM, etc.

This is an advanced approach to a complicated method. Reader discretion is advised.

The steps of this variant can be summarized simply:

1. EOLine

Per the standard ZZ method, an EOLine is required. This orients the edges on the cube with respect to the front and back faces while placing edges in the DF and DB positions. From this point on, the cube can be solved with only [R,U,L] moves, without cube rotations. This is an ergonomic enhancement as well as a blockbuilding convenience towards the remainder of the solve. EOLine is an investment of less than 7 moves.

2. Lucky ZZF2L

Now, use [R,U,L] (and [D,F2]) moves to begin to create the F2L. Typically ZZF2L involves the solution of 2 cross edges (DL and DR), 4 E-slice edges (FL, FR, BL, BR), and 4 D-layer corners. For this variant, the requirements are loosened. This higher leniency provides both for a significantly reduced movecount and a significantly increased proportion of lucky cases. The requirements for ZZ-EF F2L are as follows:

a) 2 cross edges solved
b) 4 E-slice edges solved
c) 1 D-layer corner solved
d) 3 remaining D-layer corners placed in the D-layer with an overall permutation and corner orientation that can be solved exactly without affecting another piece on the cube. In other words, these 3 corners are to be exactly 1 commutator from solved.

It is also a feature of this variant that the final corner-edge "pair" (it may not in fact be a pair at all, but rather the correct F2L edge attached to some random corner in a predefined orientation) be inserted with a Speed-Heise algorithm. I will explain "Speed-Heise" later.

2 i. So, via the traditional ZZ blockbuilding approach, users will first create an F2L square (2x2x1). This F2L square will include the correct D-layer edge, the correct E-layer edge, and a random D layer corner in any orientation. Because any of 4 random corners is permitted in any of 3 random orientations, instead of 1 particular corner in a specified orientation (per standard ZZ), we note that this F2L square can be 12 times luckier than traditional ZZ.

2 ii. Expand the F2L square to an F2L block (3x2x1 rectangle) (or create another F2L square on the other side of the cube). This time, the specific corner involved is specified to be 1 of 2 potential corners per the rules below, but the orientation of this corner is not yet required, making this step 6 times luckier than traditional ZZ.
2 ii. a) if your first D-layer corner was placed in the correct spot, but misoriented, the corner of the second "pair" must also be placed in the correct spot in any orientation.
2 ii. b) if your first D-layer corner was NOT placed in the correct spot (preferred) and not oriented, then the edge and corner of the second "pair" must NOT have the exact colors of the first "pair" that you placed. For example, if you first placed the Green-Red corner with the Blue-Red edge. It is not permitted for the Green-Red edge to be paired with the Blue-Red corner for the remainder of the solve. You must use some other corner. In other words, you may not have an isolated two-swap of corners on the D layer at any time. It must be a 3-cycle.

2 iii. Create another F2L square (or expand one of previous squares, if you made a square in step 2 ii.). The edges must be placed correctly as usual. But this time, the corner's orientation and permutation are defined. The corner that you use must complete the 3 cycle on the D-layer. For example, if the first random "pair" that you placed was the Green-Red corner in any orientation with the Blue-Red edge, and the second "pair" was the Blue-Red corner with the Blue-Orange edge, then you must insert the Blue-Orange corner with the Green-Red slot. This will complete the 3 cycle. But in order to assure that a commutator is possible, the orientation of this corner must also be defined. Of all the mismatched D-layer corners, the orientations must add up to a multiple of 3. For a corner with the D-color facing down, the number is 0. For a corner with the D-color rotated clockwise from down, the number is 1. For a corner with the D-color rotated anticlockwise from down, the number is 2. You must insert the final mismatched D-layer corner such that its number, when added to the numbers of the other mismatched D-layer corners is a multiple of 3. This may take some time to get used to. But it is certainly not difficult. Now that the exact corner and the orientation of the corner is specified, you may insert this pair.

2 iv. Although I've written this substep as the fourth substep of step 2, it may happen at ANY point during step 2. In this step, you solve a regular F2L pair, regularly. That means the colors of the corner and edge match, and the corner is to be inserted with the D-color facing down. This is a normal pair, just as in CFOP, Petrus, ZZ, or any other method. The advantage here is that because you can choose this as either your first, second, third, or fourth F2L pair, you get 4 chances for an easy case! No more bursting into tears because your F2L pairs are so hard and long to solve! This variant gives you 4 times the chances for a 3-move insert.

2 v. And although I've written this as the fifth substep, it actually applies to whichever "pair" (or pair) that you do last. You must insert the last F2L pair such that 1 U-layer corner, and all the U-layer edges are correctly solved after the pair is inserted. That means that only 3 U-layer corners will be out of place, after this step is complete. This, an idea adapted partially from the Heise method, may seem quite daunting at first. However, it can be accomplished completely intuitively via the approach described in Step 3 of Ryan Heise's site (given that you are solving the F2L pair). Another, perhaps simpler approach is to use the ergonomic algorithms that I generated here, known as Speed-Heise. These algorithms (designed for an F2L insert at FR, but can be mirrored and translated to apply to other F2L slots) place the F2L pair, while solving the LL edges, while solving whichever corner is already at DFR. Right now, these 24 algorithms are only designed for a DFR corner which is oriented down, but I will soon generate 48 more algorithms for the other orientations of the DFR corner. To identify which alg to use, place the F2L "pair" (or pair) over the slot. Then identify which LPELL case that you have. Then, drop the leading R (ie. "R LB" becomes "LB", etc.). Then, look at the destination of the DFR corner, relative to the edge piece at UF. If the corner belongs at the back right of the U-layer, the letter pair is "BR". Then combine the two letter pairs and apply the corresponding algorithm, per the list.

3. Use 2 commutators to solve the cube. 1 in the U layer, and 1 in the D layer. Commutators are described here. 1/27 of the time, you will not have a commutator to apply in the U-layer. It will have automatically solved itself, after the speed-Heise alg.


Example Walkthrough Solve:

[video]www.youtube.com/watch?v=jBlt8lmSlNQ[/video]

R2 U2 F2 D L2 B2 U F2 D2 F2 R2 B' R' D U' F2 D2 L' B2 R B'

L B' F D' F' L2 D' // eoline (7)
U2 L R2 U2 L // real pair (5)
R2 U2 L // fake pair (3)
U' R U2 R2 U' R // fake pair (6)
U R U R' // set up speed-heise (4)
L U' R U L' U R' U' // speed heise RB/FR (8)
L2 D' L U2 L' D L U2 L // commutator 1 (9)
x2 R2 B2 R F R' B2 R F' R // commutator 2 (9)

=51 htm

Good luck! I will post a few example solves and will translate and expand the Speed-Heise description tomorrow. (I didn't post it to the English forum because I wanted to make sure all the algs were good first, and I wanted to iron out any kinks. After learning the first 24 algs, it seems very promising, albeit against the fundamental algorithm-less principle of Heise)

Please let me know what you think!
 
Last edited:

Artic

Member
Joined
Feb 26, 2013
Messages
385
This sounds very promising. This could potentially turn into the best speedsolving method to use, especially in light of its ergonomicness and move count.

Could you post up video tutorials and/or demonstrate this method via a video? Really interested to see this in action.
 

mDiPalma

Member
Joined
Jul 12, 2011
Messages
1,534
Keep in mind that I have done less than a dozen solves with this total variant. There exist optimizations that I can't see.

U' R2 F2 L2 U2 L2 D' B2 D' F2 D R B' D2 L' R' U2 L B' R2

F L B' L' B' U L2 D2 // xeoline, taking advantage of easy case for a free, true square (8)
L' R' U2 R // "pair" 2 (4)
L' U L U2 L' U L2 U' L' // "pair" 3 and form "pair" 4 in U layer (8)
U' L U L' // set up to Speed-Heise case I know (3)
L R' U R U2 L' R' U R // Speed Heise case RL/FR translated via y2 (9)
L U' R' U L' U' R U' // Niklas on U (8)
y z2 r U R' U' r' F R F' // commutator on D (8)
=48 htm

B2 D' L2 D2 U B2 L2 B2 L2 D' F2 L' F2 L B L' F' U F' L D2

y' B' L' B D' R' D' // eoline after y' rotation because taylor swift is good @ singing (6)
U2 R' U2 R2 // fake square (4)
U2 L' U' L U R // throw in a legit pair (6)
L U2 L' U' L2 U' L U2 L' U' L U // left "pairs" and intuitive reduction to L3C (12)
x R2 D2 R U2 R' D2 R U2 R // commutator (9)
x L2 D L' U2 L D' L' U2 L' // commutator (9)
=46 htm

B U2 F2 D2 B D2 U2 F U2 R2 F2 R D' F2 D F' D2 L2 B D U2

y' L2 R' F U B2 D2 // eoline after y' rotation for the same reason as last time (6)
R U' R L // square and imposter square (4)
U' R U2 L U L' // "pair" (6)
U R' U' R U' R' U2 R U' // set up Speed-Heise (9)
R U2 R2 U2 R2 U' R2 U R2 U' R' // speed-heise RL/BR from back (11)
L' U R U' L U R' U' // Niklas (8)
z2 x' L' U2 L' D2 L U2 L' D2 L2 // commutator (9)
=53 htm

ok the last one was pretty bad, but you get the point.
 
Last edited:

AlphaSheep

Member
Joined
Nov 11, 2014
Messages
1,083
Location
Gauteng, South Africa
WCA
2014GRAY03
So if I'm understanding it correctly, if you ignore the top layer and concentrate on the benefits of inserting the D corners permuted incorrectly, your move count for this method will be lower than standard ZZ if you save an average of 2-3 moves during F2L (to make up for the 8-9 move commutator at the end). That doesn't seem unreasonable, since you have so much freedom for the first couple of slots.

Also, in your first example solve, I think the third "pair" insertion is missing the ' at the end. Should be L' U L U2 L' U L2 U' L'
 

mDiPalma

Member
Joined
Jul 12, 2011
Messages
1,534
So if I'm understanding it correctly, if you ignore the top layer and concentrate on the benefits of inserting the D corners permuted incorrectly, your move count for this method will be lower than standard ZZ if you save an average of 2-3 moves during F2L (to make up for the 8-9 move commutator at the end). That doesn't seem unreasonable, since you have so much freedom for the first couple of slots.

Also, in your first example solve, I think the third "pair" insertion is missing the ' at the end. Should be L' U L U2 L' U L2 U' L'

thx for the correction.

and yes, as long as you save 9 moves during F2L, this variant is worth it. I think a competent user will be able to directly solve the F2L blocks, without bothering for this pair/square approach. I think that will prove to be immensely more efficient than standard ZZ, and therefore, all other speedcubing methods.

not to mention that using this Last-Slot+Last-Layer approach is more efficient than COLL/EPLL (which is the most common ZZ option)
 

MrMan

Member
Joined
Nov 26, 2014
Messages
101
Location
France
I already love this method!
But could´t you solve the F2L regularly and reduce unly the U layer to a commutator? This way you save a rotation.

Yeah I just discovered that it is really easy to insert the last F2L and having the edge already permuted so it is just a COLL away from solved. -- Not COLL, L3C
Is this already known ?
 
Last edited:

mDiPalma

Member
Joined
Jul 12, 2011
Messages
1,534
Yeah I just discovered that it is really easy to insert the last F2L and having the edge already permuted so it is just a COLL away from solved. -- Not COLL, L3C
Is this already known ?

Yeah, if you permute the LL edges during the last slot via the 6 LPELL algs, you will end up with L4C (a set of 84 long, sucky algs).

If you apply speed-heise (24 algs for beginner, 72 for advanced) or the superior intuitive Heise alternative to the last slot, you will end up with an L3C case (intuitive commutator or pure Corner Orientation to solve).
 

MrMan

Member
Joined
Nov 26, 2014
Messages
101
Location
France
If you apply speed-heise (24 algs for beginner, 72 for advanced) or the superior intuitive Heise alternative to the last slot, you will end up with an L3C case (intuitive commutator or pure Corner Orientation to solve).

Ok I finally got the principle !
 

StachuK1992

statue
Joined
Jul 24, 2008
Messages
3,812
Location
West Chester, PA
WCA
2008KORI02
YouTube
Visit Channel
This is neat in theory, but for the same reason ZZ-D will never be efficient (any version of it), this won't be.
Great methods come from simplicity with some hacks near the end mostly. Sometimes a nice extra boost at the beginning.

This feels "hacks throughout." That's not bad, I just don't think it'll work for speedsolving.
 

mDiPalma

Member
Joined
Jul 12, 2011
Messages
1,534
This feels "hacks throughout." That's not bad, I just don't think it'll work for speedsolving.

I see what you're saying. This variant certainly requires more active user participation lol, especially towards middle and trailing end of the F2L. But I do think that this method really has that "extra boost" that you mentioned; I did a few slow solves last night where I seemed able to build the first 3x2x1 "block" in just a quick hand motion after the EOLine.

It's also particularly easy when the L-side E-slice edges can be shot to the E-slice on that side in just 1 move or 2, then u build the bogus adjoining 3x1x1 block with [RU] in just a few moves, then slide it into position at UL, followed by L2. Instant "block".

I'd be interested to see the optimal movecount distribution for direct solution of F2L-1 (after EOLine), where only the most efficient "pairs" or pairs were selected, but I don't know how to generate that table apart from brute forcing a sizable amount of cases. Does anyone know how to do this theoretically or have a program for this?
 
Joined
Apr 23, 2010
Messages
1,391
Location
Scotland, UK
WCA
2009SHEE01
YouTube
Visit Channel
Cool idea, looking forward to seeing this in actual speedsolves. There's some nice comms on D that would probably be good to learn to save a rotation, maybe there's something nice for every case if you look for it.

[F':[R U R', D']]
[F':[R U R', D2]]
[R:[R U R', D2]]
[R F':[R U R',D2]]
 

StachuK1992

statue
Joined
Jul 24, 2008
Messages
3,812
Location
West Chester, PA
WCA
2008KORI02
YouTube
Visit Channel
I see what you're saying. This variant certainly requires more active user participation lol, especially towards middle and trailing end of the F2L. But I do think that this method really has that "extra boost" that you mentioned; I did a few slow solves last night where I seemed able to build the first 3x2x1 "block" in just a quick hand motion after the EOLine.

It's also particularly easy when the L-side E-slice edges can be shot to the E-slice on that side in just 1 move or 2, then u build the bogus adjoining 3x1x1 block with [RU] in just a few moves, then slide it into position at UL, followed by L2. Instant "block".

I'd be interested to see the optimal movecount distribution for direct solution of F2L-1 (after EOLine), where only the most efficient "pairs" or pairs were selected, but I don't know how to generate that table apart from brute forcing a sizable amount of cases. Does anyone know how to do this theoretically or have a program for this?
I used to be less cynical. That's why I came up with so many damn methods.

The "Big Four" methods, as I coined years past, are good because they're pretty damn simple.
Petrus: block, expand, eo, f2l, ll. FIVE IDEAS
CFOP: cross, pair*4, oll, pll. FOUR IDEAS
ZZ: eo, block, block, ll. FOUR IDEAS
Roux: block, mirror block, corners, moo.. FOUR IDEAS

All of these methods have around 4 ideas. Hell, petrus is the subjectively 'worst'' of the four, and it's the only one with 5 ideas, kinda sorta proving my point.
They work well because they only have a few ideas, and it's natural to switch from one idea to the next. (The methods have FEW IDEAS and they FLOW from idea to idea)

Let's take a look at two methods that are NOT in the Big Four, and thus doesn't do so well.

LBL: cross, corner*4, edge*4, eo, co, cp, ep.
This FLOWS nice, but has TOO MANY IDEAS

L2Lk: layer, pair+co, pair+cp, l2e, ell
This has FEW IDEAS but DOES NOT FLOW.

(I haven't given up 100% on making this flow, though, but it seems unlikely without modifications.)

To have a method that will WORK, I believe you need five or less basic ideas, and the ability to flow from one to the other.
This method (and most methods created, 90% of mine included) break this basic principle. A few are exceptions, such as MGLS and others that stay within the realm of sanity, as I'll call it.

To sum up (and I'm really sorry to discourage; it's just hard to restrain the cynicism!):
Your method has too many ideas. It's good for slowsolving, but it will unlikely advance past that.
Your method doesn't flow, AND has too many ideas.

Props for the ideas, but unfortunately someone's going to have to be truly original to beat the current line of speedcubing methods.


Hey, that was the longest post I've made in at least a year :p


To clarify on a thing or two:

I suspect that some day there may be an argument similar to "but Petrus' first two steps are really one goal! If we combine them, then that makes it four steps, right?!"
No. There needs to be FLOW *within* each step.
- If an alg is really awkward: no flow.
- If you don't have enough brainpower to solve the step in your head quickly: no flow.
- If an alg set (case group) is too big (like ZBLL), then you also have a risk of having no flow, since the recall is hindered.
 
Last edited:
Top