# ZZ-Edges First discussion



## mDiPalma (Dec 31, 2014)

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]



Spoiler



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!


----------



## Artic (Dec 31, 2014)

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.


----------



## GuRoux (Dec 31, 2014)

got the general idea, seems promising, can you post a couple of example solves?


----------



## guysensei1 (Dec 31, 2014)

Sorry, I'm terrible at comprehending text based tutorials... Could you make an example solve video?


----------



## mDiPalma (Dec 31, 2014)

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.


----------



## AlphaSheep (Dec 31, 2014)

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'


----------



## Smiles (Dec 31, 2014)

i like it, other than the rotation before solving the D corners.


----------



## mDiPalma (Dec 31, 2014)

AlphaSheep said:


> 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 *speed*cubing 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)


----------



## jjone fiffier (Dec 31, 2014)

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.


----------



## MrMan (Dec 31, 2014)

jjone fiffier said:


> 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 ?


----------



## TDM (Dec 31, 2014)

jjone fiffier said:


> 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.


You could, but then the F2L would be less efficient.


----------



## mDiPalma (Dec 31, 2014)

MrMan said:


> 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 (Dec 31, 2014)

mDiPalma said:


> 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 (Dec 31, 2014)

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.


----------



## brian724080 (Dec 31, 2014)

This approach looks really interesting. I look forward to the example solves!


----------



## mDiPalma (Dec 31, 2014)

StachuK1992 said:


> 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?


----------



## Randomno (Dec 31, 2014)

Since when is CFCE mainstream and popular?


----------



## bobthegiraffemonkey (Dec 31, 2014)

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 (Dec 31, 2014)

mDiPalma said:


> 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 


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.


----------



## supercavitation (Dec 31, 2014)

StachuK1992 said:


> Awesome stuff



That might have been the best explanation I've ever seen about why some methods work and some don't. 

Also, just wondering, but how hard is it to ensure that you have a valid 3-cycle on the bottom during F2L? That seems rather thought intensive.


----------



## mDiPalma (Dec 31, 2014)

StachuK1992 said:


> snip



Then why isn't Old Pochmann a good speedsolving method? Ergonomic algs. One/two ideas. Small alg set. Flows very well, just watch some blindsolves. I think your rating system is poor. 

First, this is not a method; it's a variant. This is a simplification of the ZZ approach with increased leniency. Therefore, it cannot be worse than ZZ. Because the *worst* case for this variant is exactly the true ZZ case, in which the correct corners are placed correctly with the correct edges. Instead, this variant permits us to throw almost any corners in the F2L, after applying some brief mindless rules which will become second nature after a few solves (I have experienced this, and I have only done a few dozen solves). The ergonomics are superior. The flow is greater. The movecount is less. That's as far as the EOF2L is concerned.

The only true alteration made (that is, not a simplification of the standard ZZ approach, but actually straying from the regular ZZ method) is the change we are making on the insertion of the last F2L "pair", in that the LL edges and 1 corner must be relatively solved during the pair insertion. This is the only section of the solve where you can claim the "flow" and "idea count" suffers. Certainly however, this is a sacrifice made for a decreased "idea count" later in the solve. My blind goldfish could see that.


And as far as I'm concerned, EOLine+Block+Block+OLL+PLL, is the same quantity of "ideas" as EOLine+Easy Block+Easy but special Block+Commutator+Commutator

And because you grouped CFOP's second idea, into a factor of 4 (pair*4), I don't see why you can't group the commutator ideas of this approach in the same way.

Frankly, I just think you haven't read the method thoroughly enough. There are not "too many ideas". In fact, there are only 3 distinct steps, in the way I outlined it. Instead, there are only constraints to keep in mind, while solving the cube. Comparable constraints exist in every other method. They are just things to keep in mind, while you burn through the lucky, simple cases.

TL;DR I think counting the number of steps in a method is a poor way of concluding viability. I disagree with every judgment you made based off that.



supercavitation said:


> Also, just wondering, but how hard is it to ensure that you have a valid 3-cycle on the bottom during F2L? That seems rather thought intensive.



It's not difficult at all. These are the constraints that I wrote about above. You can literally toss any corner you want into the first "pair". The only constraint on the second pair is that it must not be the twin of the "pair" you just inserted. And the third "pair" must involve the final edge and corner piece to complete the edge cycle, and the corner must be oriented in a particular way, which will feel right after a few iterations of practice.

Remember that before, between, or after these three "pairs" you must also insert a correct F2L pair. Because you have 4 chances, just sit and wait for a 3 or 4 move insert.


----------



## StachuK1992 (Dec 31, 2014)

Old Pochman is a fair, but useless stab at the idea. Ok fine, overall movecount is a factor.


Due to the lack of constraints here and the seemingly sudden comm-pair, there is less overall flow.

I too have been drunk on my own methods; give it time.
I truly say this without intentional condescension. I'd love for something truly innovative and efficient to come out, more than anyone. My opinion is that this just isn't it.

The method is complicated. I've lied to myself about many methods; it takes a long time to become entirely objective about these things.

For all I know, though, this could turn out really well.
I've build up a mental construct of why methods do and don't work, and this simply falls into that schema for me.
I'll try to sleep on it and prove myself wrong though!  I'd love to.


EDIT:
As to not hijack this thread, I'll create a thread in the coming days in order to create some sort of method-efficiency metric. I'd love to hear your thoughts on the subject.


----------



## TDM (Dec 31, 2014)

mDiPalma said:


> In fact, there are only 3 distinct steps, in the way I outlined it.


Personally, I'd outline it as having four distinct steps: EOLine, F2L-1, LS+edges, comms.


----------



## mDiPalma (Dec 31, 2014)

I added 1 walkthrough example solve video to the OP.

Looking back, you should probably have a decent understanding of the method before watching the example. It's incorporates a bit of method explanation for visual learners, but not nearly enough for a standalone tutorial.


----------



## obelisk477 (Jan 1, 2015)

Do you think full ZBLL would be better than speed-heise slot + LL commutator? I mean certainly not in terms of alg-learning, but as in the most efficient method. It is a ZZ variant after all.


----------



## mDiPalma (Jan 1, 2015)

obelisk477 said:


> Do you think full ZBLL would be better than speed-heise slot + LL commutator? I mean certainly not in terms of alg-learning, but as in the most efficient method. It is a ZZ variant after all.



well, theoretically yes. but that isn't "Edges First"

but using ZBLL for the LL does not preclude you from solving the F2L to an unsolved state. In other words, you can solve the LL with ZBLL, then do a z2 and do a quick commutator, all the same. That would still be more efficient than standard ZZ-a.


----------



## Athefre (Jan 1, 2015)

Half-solving pieces only to fix your "mistakes" with an alg later? Few methods benefit from this. It would be nice to see a move comparison between:

X-EOLine
F2L-1
Pair + That Speed Heise thing

and

X-EOLine
Fake F2L-1
Fake Pair + That Speed Heise thing
Fix D Corners

How many fewer moves are saved with the Lazy Solving technique?


----------



## mDiPalma (Jan 1, 2015)

Athefre said:


> Half-solving pieces only to fix your "mistakes" with an alg later? Few methods benefit from this. It would be nice to see a move comparison between:
> 
> X-EOLine
> F2L-1
> ...



Keep in mind that the "XEOLine" in the second option can also be some bogus block. That saves a huge number of moves.

Do a few solves for yourself. You will certainly save more moves than an 8/9-move commutator is worth.

But yes, the first option you suggested is also very fast. I average around 15 with it, and I have really poor speed-heise recognition.


----------



## Smiles (Jan 3, 2015)

why is a commutator necessary for LL?
couldn't you just do LL any way you want?


----------



## TDM (Jan 3, 2015)

Smiles said:


> why is a commutator necessary for LL?
> couldn't you just do LL any way you want?


Yes, but you only have three corners to solve, so a commutator is the fastest way.


----------



## Smiles (Jan 13, 2015)

TDM said:


> Yes, but you only have three corners to solve, so a commutator is the fastest way.



i kinda meant why permute the edges and solve 1 corner in the first place, instead of just finishing the slot and doing whatever LL you want.
this is just from a speed standpoint.


----------



## IRNjuggle28 (Jan 13, 2015)

Matt, have you speedsolved with this much since last posting in this thread? If so, how is it?


----------

