[Help Thread] ZZ and ZB Discussion

There are two things I want to ask some of the more experienced ZZ users here.

First of all, has anyone had any success with solving the entire block, as opposed to breaking it down into a 2x2x1 and and F2L pair? Whenever I pair up a corner with a D edge and happen to get a 1x1x3 strip, and if I have enough freedom, I like to make another 1x1x3 strip using two edges + a center, pair them up, and then move on to the other block, finishing F2L entirely 2-gen. Does anyone have a different way of going about doing this? (I'm also fairly sure that what I outlined above is not uniquely mine)

Also, I'd like to find some opinions on COLL + EPLL vs OCLL + PLL. I recently finished learning COLL, and looking at a recent thread, I realized (stupid of me for not realizing sooner) that EPLL's only real benefit is theoretically faster recognition, considering that most sub-15 cubers have all their PLLs sub-2, or even sub-1. I guess I'm more doubtful of ZZ-VH now, and I'm curious as to how other people feel.
 
You should try to be as flexible as possible when you build your f2l. That said, if you see an easy solution for an entire block, then go for it. I personally don't go out of my way to make 1x1x3 strips unless they are very obvious.

To address your second question, COLL gives you a higher probability of a PLL skip. To me the speed difference between COLL + EPLL and OCLL + PLL is pretty small. However, most people would agree that COLL + EPLL is stronger for OH.
 
@anon. I tend to solve all pieces in one side at once when I can see them. This is a common example:
f2l_mblock_B_1.gif


If I see two pairs for a particular side, or I spot a lucky pair while building another, I'll tend to build the whole side at once, taking advantage of the freedom to store stuff in the alternative side. When a whole side has already been completed its much more difficult to manipulate 2*1x1x2's, to the point that attempting to preserve both will probably slow you down. For these situations I generated some algs see:
http://cube.crider.co.uk/zz.php?p=f2l#multiblocking

... but to be honest, I don't use many of them (I probably should though)!

Generally I've found the openslotting stuff much more useful since openslotting scenarios are much more common - they are almost always present in my F2L.

In practice, solving a 1x1x3 block all at once is only easy to do if the other side is free, or if the E-slice edges are not adjacent to each other. By all means take advantage of it, but if you want to do it when one side is already complete, try to quickly recognise whether you have an opposite/adjacent E-slice edge permutation. If the E-edges are adjacent to each other, then the 1x1x3 block needs to be broken up, and you will probably be faster just solving as normal.

For the COLL vs OCLL debate, my preference is to use OCLL for fast algs like the Sunes, and L, but use COLL for cases like Pi, or H. If you're really slow at PLL, and like EPLL then there is probably more incentive to go for COLL. COLL has a slight move-count advantage over OCLL and as a_small_kitten says, there's more chance of a lucky 1LLL with it.
 
Also, I'd like to find some opinions on COLL + EPLL vs OCLL + PLL. I recently finished learning COLL, and looking at a recent thread, I realized (stupid of me for not realizing sooner) that EPLL's only real benefit is theoretically faster recognition, considering that most sub-15 cubers have all their PLLs sub-2, or even sub-1. I guess I'm more doubtful of ZZ-VH now, and I'm curious as to how other people feel.

I don't do ZZ but I can give you a fairly unbiased view of ZZ-VH as I use pure VH myself (with some shortcuts, etc.).

The Vandenbergh-Harris method was originally designed as a stepping stone to the Zbrowski-Bruchem method. I think of it as more genius than the ZB system, but that's for another time. However, even co-creator Dan Harris has questioned the method's viability as a standalone speedsolving system. But the jump to full ZB is really too big to make without a stepping stone, so the VH system survived on CubeZone, CubeStation, cosinesystems, and Jason Baum's Cubing Site. VHF2L is rather slow for what it accomplishes though with edge control prior to the last slot it becomes much faster and more usable (or you can skip the stupidly long/slow cases and use partial edge control + OLL), but sometimes that isn't possible (and that would lead to a whole new analyses that I find fascinating but don't want to expand on right now).

The modern-day selling point of the VH system is no longer its potential as a ZB stepping stone nor its uses for 2x2x2 (CLL completely outclassing COLL for 2x2x2) but rather the step not involving a V or an H (make it a pun if you want and call me wrong): COLL. Many people know COLL (it's only 40 algs) or parts of it (most commonly choosing to not learn the Sune/Anti-Sune cases) but don't use (LL)EO methods. They just use it for the times when EO is available. When faced with a last layer with edges oriented, these people choose COLL over OCLL. This should signify that one is faster than the other. But unfortunately we cannot look at it like this. The temptation of the 1/12 chance for a PLL skip and the high TPS of EPLL clouds or judgment of speed (I am very much a victim of this). Also, the ability to avoid N, V, F, and E (or whatever non-Edge PLL bothers you) just adds to the temptation. At the same time we are giving up consistently fast PLLs like T, J, and A, yes, but guaranteeing an EPLL is usually faster (and more fun). Then there are those (like myself) who started with COLL because ZBLL was the ultimate goal. However, realizing that it would be too difficult (unlike myself) or too time-consuming, they left it at COLL, content with the speed and/or move count it brought with it.

Many people do not learn COLL because they feel it is not as fast as OLL+PLL. While orienting edges is a pain, let us assume that that has somehow already been done. Do you choose COLL or OCLL? Many people feel OCLL is faster than COLL because OCLLs are the fastest COLLs from that orientation. This is not necessarily true, and is even false in my case. When starting out, COLL recognition comes very slowly. You see the OCLL, set it up for recognition, then determine the corner permutation. My COLL learning recognition was very slow because I was basically on my own. My recognition evolution went something like:
Stage 1: OCLL -> CP
Stage 2: OCLL -> 2FSP (2 face sticker pairs: using U and F sticker pairs to determine the CP after determining the OCLL)
Stage 3: 3FSP (using sticker pairs/anti-pairs on U, F, and sometimes R, I know what COLL I'm dealing with)
I've only been in "Stage 3" for about 4 months, but in that time I've noticed that my COLL recognition is faster than my OCLL recognition. Searching for yellow is a pain but just seeing where things are opposite/adjacent/alike is much easier. Multi-color recognition is faster than specific shape recognition. So COLL recognition can be faster than OCLL recognition. EPLL recognition is also MUCH faster than PLL recognition, especially since after you get going with COLL, you know which EPLL is coming up and how it with be AUF'd. I can BLD the last layer (and often do to avoid pops/lockups) as soon as I see the COLL (though there are 8 sets I cannot do this for).

Performing OCLLs is faster- no one can debate that. But the recognition can be faster with COLL, making the speed difference small. Then you get a PLL or an EPLL. Again, small difference. But there is much, much more room for error with full PLL. At high speeds, the difference in time is minimal, sometimes favoring one method, sometimes the other. Some cases are bad. Some orientations are amazing (H and L are my favorites). Some are poor (Pi). When you get a skip every average of 12, though, I think COLL is well worth it.

For the record, my weighted COLL+EPLL average 3 weeks ago was 4.53. My weighted OCLL+PLL average was 5.02. My weighted OLL+PLL (this took me almost a week to finish) was 6.31. Started from the last F2L slot with R U2 R' insertion. Hope I helped!

EDIT: Ooh! Block of text. Sorry about that. Hope I got my facts right. I hope I convinced you to at least try COLL, because that's the only way you'll know if it's worth it.
 
Generally I've found the openslotting stuff much more useful since openslotting scenarios are much more common - they are almost always present in my F2L.

In practice, solving a 1x1x3 block all at once is only easy to do if the other side is free, or if the E-slice edges are not adjacent to each other. By all means take advantage of it, but if you want to do it when one side is already complete, try to quickly recognise whether you have an opposite/adjacent E-slice edge permutation. If the E-edges are adjacent to each other, then the 1x1x3 block needs to be broken up, and you will probably be faster just solving as normal.

In practice I almost never complete an entire block unless at the very beginning I see a completed 1x1x3. I think it could be useful, though, considering how fast a 2-gen "rest of F2L" would be. Sometimes in F2L, I think my lockups are caused by switching from my right to left hand too quickly.
Would you happen to know how many cases there would be if we generated 3-Gen optimal algs to form a 1x1x3, assuming that it's the very beginning of the solve, and that all components of the 1x1x3 are in the top layer?

I don't do ZZ but I can give you a fairly unbiased view of ZZ-VH as I use pure VH myself (with some shortcuts, etc.).

The modern-day selling point of the VH system is no longer its potential as a ZB stepping stone nor its uses for 2x2x2 (CLL completely outclassing COLL for 2x2x2) but rather the step not involving a V or an H (make it a pun if you want and call me wrong): COLL. Many people know COLL (it's only 40 algs) or parts of it (most commonly choosing to not learn the Sune/Anti-Sune cases) but don't use (LL)EO methods. They just use it for the times when EO is available. When faced with a last layer with edges oriented, these people choose COLL over OCLL. This should signify that one is faster than the other. But unfortunately we cannot look at it like this. The temptation of the 1/12 chance for a PLL skip and the high TPS of EPLL clouds or judgment of speed (I am very much a victim of this). Also, the ability to avoid N, V, F, and E (or whatever non-Edge PLL bothers you) just adds to the temptation. At the same time we are giving up consistently fast PLLs like T, J, and A, yes, but guaranteeing an EPLL is usually faster (and more fun). Then there are those (like myself) who started with COLL because ZBLL was the ultimate goal. However, realizing that it would be too difficult (unlike myself) or too time-consuming, they left it at COLL, content with the speed and/or move count it brought with it.

Many people do not learn COLL because they feel it is not as fast as OLL+PLL. While orienting edges is a pain, let us assume that that has somehow already been done. Do you choose COLL or OCLL? Many people feel OCLL is faster than COLL because OCLLs are the fastest COLLs from that orientation. This is not necessarily true, and is even false in my case. When starting out, COLL recognition comes very slowly. You see the OCLL, set it up for recognition, then determine the corner permutation. My COLL learning recognition was very slow because I was basically on my own. My recognition evolution went something like:
Stage 1: OCLL -> CP
Stage 2: OCLL -> 2FSP (2 face sticker pairs: using U and F sticker pairs to determine the CP after determining the OCLL)
Stage 3: 3FSP (using sticker pairs/anti-pairs on U, F, and sometimes R, I know what COLL I'm dealing with)
I've only been in "Stage 3" for about 4 months, but in that time I've noticed that my COLL recognition is faster than my OCLL recognition. Searching for yellow is a pain but just seeing where things are opposite/adjacent/alike is much easier. Multi-color recognition is faster than specific shape recognition. So COLL recognition can be faster than OCLL recognition. EPLL recognition is also MUCH faster than PLL recognition, especially since after you get going with COLL, you know which EPLL is coming up and how it with be AUF'd. I can BLD the last layer (and often do to avoid pops/lockups) as soon as I see the COLL (though there are 8 sets I cannot do this for).

Performing OCLLs is faster- no one can debate that. But the recognition can be faster with COLL, making the speed difference small. Then you get a PLL or an EPLL. Again, small difference. But there is much, much more room for error with full PLL. At high speeds, the difference in time is minimal, sometimes favoring one method, sometimes the other. Some cases are bad. Some orientations are amazing (H and L are my favorites). Some are poor (Pi). When you get a skip every average of 12, though, I think COLL is well worth it.

For the record, my weighted COLL+EPLL average 3 weeks ago was 4.53. My weighted OCLL+PLL average was 5.02. My weighted OLL+PLL (this took me almost a week to finish) was 6.31. Started from the last F2L slot with R U2 R' insertion. Hope I helped!

EDIT: Ooh! Block of text. Sorry about that. Hope I got my facts right. I hope I convinced you to at least try COLL, because that's the only way you'll know if it's worth it.

That's actually really interesting, that you think that COLL recognition can be faster than OCLL recognition, and I can actually kind of relate to it for subsets like T, U, and L. Do you use COLL for Sune?

Your explanation makes me want to stick with COLL for a while, before I go on to ZZLL. =D

One other thing- I'm just curious... how fast is your last slot, on average?
 
Last edited:
I´m pretty confused now... which 1x1x3 do you mean? In the L/R-clock or an extended line edge?

No matter what you mean I don´t get the benefits of this... why don´t plain your first block only?
 
I don't do ZZ but I can give you a fairly unbiased view of ZZ-VH as I use pure VH myself (with some shortcuts, etc.).

The modern-day selling point of the VH system is no longer its potential as a ZB stepping stone nor its uses for 2x2x2 (CLL completely outclassing COLL for 2x2x2) but rather the step not involving a V or an H (make it a pun if you want and call me wrong): COLL. Many people know COLL (it's only 40 algs) or parts of it (most commonly choosing to not learn the Sune/Anti-Sune cases) but don't use (LL)EO methods. They just use it for the times when EO is available. When faced with a last layer with edges oriented, these people choose COLL over OCLL. This should signify that one is faster than the other. But unfortunately we cannot look at it like this. The temptation of the 1/12 chance for a PLL skip and the high TPS of EPLL clouds or judgment of speed (I am very much a victim of this). Also, the ability to avoid N, V, F, and E (or whatever non-Edge PLL bothers you) just adds to the temptation. At the same time we are giving up consistently fast PLLs like T, J, and A, yes, but guaranteeing an EPLL is usually faster (and more fun). Then there are those (like myself) who started with COLL because ZBLL was the ultimate goal. However, realizing that it would be too difficult (unlike myself) or too time-consuming, they left it at COLL, content with the speed and/or move count it brought with it.

Many people do not learn COLL because they feel it is not as fast as OLL+PLL. While orienting edges is a pain, let us assume that that has somehow already been done. Do you choose COLL or OCLL? Many people feel OCLL is faster than COLL because OCLLs are the fastest COLLs from that orientation. This is not necessarily true, and is even false in my case. When starting out, COLL recognition comes very slowly. You see the OCLL, set it up for recognition, then determine the corner permutation. My COLL learning recognition was very slow because I was basically on my own. My recognition evolution went something like:
Stage 1: OCLL -> CP
Stage 2: OCLL -> 2FSP (2 face sticker pairs: using U and F sticker pairs to determine the CP after determining the OCLL)
Stage 3: 3FSP (using sticker pairs/anti-pairs on U, F, and sometimes R, I know what COLL I'm dealing with)
I've only been in "Stage 3" for about 4 months, but in that time I've noticed that my COLL recognition is faster than my OCLL recognition. Searching for yellow is a pain but just seeing where things are opposite/adjacent/alike is much easier. Multi-color recognition is faster than specific shape recognition. So COLL recognition can be faster than OCLL recognition. EPLL recognition is also MUCH faster than PLL recognition, especially since after you get going with COLL, you know which EPLL is coming up and how it with be AUF'd. I can BLD the last layer (and often do to avoid pops/lockups) as soon as I see the COLL (though there are 8 sets I cannot do this for).

Performing OCLLs is faster- no one can debate that. But the recognition can be faster with COLL, making the speed difference small. Then you get a PLL or an EPLL. Again, small difference. But there is much, much more room for error with full PLL. At high speeds, the difference in time is minimal, sometimes favoring one method, sometimes the other. Some cases are bad. Some orientations are amazing (H and L are my favorites). Some are poor (Pi). When you get a skip every average of 12, though, I think COLL is well worth it.

For the record, my weighted COLL+EPLL average 3 weeks ago was 4.53. My weighted OCLL+PLL average was 5.02. My weighted OLL+PLL (this took me almost a week to finish) was 6.31. Started from the last F2L slot with R U2 R' insertion. Hope I helped!

EDIT: Ooh! Block of text. Sorry about that. Hope I got my facts right. I hope I convinced you to at least try COLL, because that's the only way you'll know if it's worth it.

That's actually really interesting, that you think that COLL recognition can be faster than OCLL recognition, and I can actually kind of relate to it for subsets like T, U, and L. Do you use COLL for Sune?
Absolutely. Sune/Anti-Sune were the last sets that I learned, but I learned them nonetheless. When I started learning the only recognition system I could find was the really odd positioning that Dan Harris uses, which really put me off. But now I find that Sune and Anti-Sune are actually very fast sets, it's just that we're used to doing them 1.x or 0.x. Being able to recognize Niklas is great because it's also a fast alg. I'm not sure it's worth it for just COLL on Sune/Anti-Sune, but I find it more fun and my goal is ZBLL, so I'm sticking with it. I've also picked up on EP recently for most of these sets, though 2 still evade me here.

Your explanation makes me want to stick with COLL for a while, before I go on to ZZLL. =D
Great! I'm the alg publishing guy, so you can take a look at THIS POST (or my sig if you want the monster). The algs are crap but I'm slowly working on it (that's actually a lie, but pretend it's not).

One other thing- I'm just curious... how fast is your last slot, on average?
We're talking VHF2L? hmm...Somewhere 1-2 seconds, almost never more. I skip a few ugly cases here and there, but for the most part I work hard to control EO before the last slot. Yeah, it's not ideal, but I find it more fun than EOLine.

Answers in bold. Hope I helped!

I'm going to be posting a new version of the ZBLL document this weekend. Finally finished testing the H sets!!!
 
Cool- I saw one of your first drafts a while back, and I was really impressed. Can't wait to see the updated version.

@CubeNoobie: For instance, say we solve our EOline and immediately see an easy way to pair up a corner with a D-edge. We do so, and by accident we also solved the other corner corresponding to that edge, forming a 1x1x3 strip. Instead of wasting that solved corner, we could potentially hide the 1x1x3 strip in the opposite side, and use the two E-slice edges that would go with the 1x1x3 strip to form another 1x1x3 using a center. Then you'd pair the two 1x1x3s and therefore solve the entire block. There could potentially be a few reasons to do this- it might occassionally have a lower movecount, although I'm not sure. It also avoids having to do an annoying edge-only insertion, since if you have a 1x1x3 strip of D-layer pieces, and you pair it up with only one edge, you end up with a solved corner and an edge floating around in the top layer, which IMO is one of the worst cases.

Plus, it adds variety, which is fun. :D
 
Didn't know this thread existed. The OP can add my name to the front page list; I always use EO-Cross unless it's an exceptionally lazy day :D
 
@ Anonymous: Ok that sounds really interesting for fmc I´ll definetly think about it, but I won´t use it in Speedsolve imo.

@OP: Plz add me too. I´m near to being sub 15, so definetly fast enough for the list ;).
 
@ Anonymous: Ok that sounds really interesting for fmc I´ll definetly think about it, but I won´t use it in Speedsolve imo.

I actually am the opposite- I doubt this particular approach is much better for FMC, but I could be wrong.
 
I said it might, in certain cases. I doubt a human could acheive a lower movecount every time doing this. I could be wrong, though.
 
I average around 34-35 moves for EO line plus f2l. I can occasionally get high 20s and low 30s. How low do you guys think it can drop while speedsolving?

Just practise your EOLine. After that you may look for better blockbulding ideas and multisloting for the part after the first block ( example: your next block/pair would be ugly... then insert your current pair with U2 instead of U' or U)

sub 30 is definetly possible (with 2 moves per second :P).
 
I average around 34-35 moves for EO line plus f2l. I can occasionally get high 20s and low 30s. How low do you guys think it can drop while speedsolving?
sub30 definitely.
sub25 average...would takes lots of thinking.

I thought I saw a thread a while back about ZZF2L movecount that said optimal solvers solved it in around 30 moves. Will edit with the thread.

EDIT: Okay, I was a little mistaken. The thread is this- http://www.speedsolving.com/forum/showthread.php?t=16020&page=2- and Cride5 posted that solved in the conventional way (two 1x2x2s, two F2L pairs), the average movecount is 30. If I'm not interpreting wrong, though, I think that the solver they used was always solving the blocks in a fixed order, which would make it so that a human solver could *potentially* get lower.

What's interesting is that when they had the computer solve the entire L and R blocks at a time, the movecount could be reduced to 24 on average. I guess sub-30 is possible, but it would require techniques outside of normal ZZ speedsolving, I think. I'm also not entirely sure how one would go about making an entire block except using 1x1x3 strips, but from my little bit of experience with them, I don't think that that significantly improves movecount, so I'm really at a loss as to how the computers were able to solve the entire blocks.
 
Last edited:
Finally updated my ZBLL/ZZLL sheets. Check the sig. 5 edits in ZZLL, some 40-ish in ZBLL. Only the intro and the H set have been modified (or so I hope), so it's not a big update but a rather needed one (because of how terrible the algs were).

More importantly, I have finally completed my learning of the H sets! w00t!!!

Koreancuber: on the OP you might as well just link to my sig. You labeled them ZB algs when they are in fact ZZ algs.
 
I think after the Nebraska Open, I'm going to learn ZZ. I don't know if I'll switch to it for good, but it sounds like a lot of fun (if I can get EOline down :o).
 
I think after the Nebraska Open, I'm going to learn ZZ. I don't know if I'll switch to it for good, but it sounds like a lot of fun (if I can get EOline down :o).

EOline isn't really as hard as it sounds. But why wait until after Nebraska Open? :D
 
Back
Top