# Idea for CFOP users learning ZBLL



## irontwig (Jul 1, 2010)

So it struck me that Lars Petrus' approach[1] of combining two COLL/EPLL algs is also usable with OLL algs, eg: Pi7: f R U R' U' f' F R U R' U' F' (P+T OLL). Since there's quite a number of 6-8 move OLL that a CFOP user would know I think this approach has got some potential, but it would probably take a computer search like the one Lars did to prove that.

Because I couldn't find any trace of said method in the ZBLL list on the wiki I guess this could possibly be a somewhat new idea. Hopefully someone will find learning ZBLL slightly easier with this idea.

[1] http://lar5.com/cube/270/index.html


----------



## Kirjava (Jul 1, 2010)

irontwig said:


> f' F




S'

Anyway, another popularly considered approach is simply learning the OLL/PLL combos for all cases.

I imagine that many of the 'pure' ZBLL algs that can be created from two OLL algs are simply two OLL algs anyway.

Also, are you sure you can cover all the ZBLL cases with the short OLL algs? I have doubts.


----------



## irontwig (Jul 1, 2010)

Kirjava said:


> irontwig said:
> 
> 
> > f' F
> ...



Well, that's just a matter on how you would prefer to execute it, besides with "f' F" it is more obvious that it's just two algs back-to-back.



> Anyway, another popularly considered approach is simply learning the OLL/PLL combos for all cases.
> 
> I imagine that many of the 'pure' ZBLL algs that can be created from two OLL algs are simply two OLL algs anyway.
> 
> Also, are you sure you can cover all the ZBLL cases with the short OLL algs? I have doubts.



Yeah, alot of fast OLLs are unfortunately Sune-variations who doesn't affect corner permutation and the 6 movers swap diagonally. So that's not too good, but even a small part of ZBLL is probably a lot of cases anyway, and I doubt only one approach is the best one for all cases. Anyway, anything that makes ZBLL easier to learn is IMO quite welcome.


----------



## joey (Jul 1, 2010)

But.. there could be faster algs


----------



## JeffDelucia (Jul 1, 2010)

Joey brings up a very good point. If you're going to learn 500 algorithms you better learn 500 good algorithms or your really wasting your time.


----------



## irontwig (Jul 1, 2010)

JeffDelucia said:


> Joey brings up a very good point. If you're going to learn 500 algorithms you better learn 500 good algorithms or your really wasting your time.



But what do you think is faster executing 2 algs you know by heart or executing one you "kinda know" since you've learnt so many? A lot of people use two OLLs to solve T and/or Y perm, so there's probably at least a few cases that are quite decent.


----------



## MiloD (Jul 1, 2010)

Petrus' alg combos are only 2-3 moves above optimal on average and all the algs are pretty easy to execute. 

How many people are using all optimal ZBLL algs anyway? And how fluent is their execution?


----------



## irontwig (Jul 1, 2010)

MiloD said:


> Petrus' alg combos are only 2-3 moves above optimal on average and all the algs are pretty easy to execute.



Right and by expanding the "alg bank" to include some OLLs you can only make things better.


----------



## Cride5 (Jul 1, 2010)

I really like Lars's idea of a 1-look 2-alg system. To me it makes all sorts of sense. Minimum alg approaches are great because the amount of time practising each one is maximised, which really makes a difference to execution speed. The benefits of using only one-look are obvious. I'm already learning this kind of thing with separation prediction in the first step of Guimond, and it really is quite a bit faster!

The main thing which is missing from Lars's page is the combination of algs which can be used to solve each ZBLL case. He possibly hasn't actually figured all of them out himself yet.

Certainly this system is capable of solving both ZBLL, or a completely scrambled LL (CFOP users). However, applying it to CFOP will create major recognition issues! I'm not sure if this applies to all ZBLL cases, but I haven't yet found a set which isn't recognisable by looking at only the U-face and two specific sides. I doubt the same would apply to full LL recognition.

Anyway, cheers for the inspiration irontwig, I think I'm going to dig deeper into this 1-2 LL approach...


----------



## irontwig (Jul 1, 2010)

Cride5 said:


> I really like Lars's idea of a 1-look 2-alg system. To me it makes all sorts of sense. Minimum alg approaches are great because the amount of time practising each one is maximised, which really makes a difference to execution speed. The benefits of using only one-look are obvious. I'm already learning this kind of thing with separation prediction in the first step of Guimond, and it really is quite a bit faster!
> 
> The main thing which is missing from Lars's page is the combination of algs which can be used to solve each ZBLL case. He possibly hasn't actually figured all of them out himself yet.



Just click on the COLL cases and it will bring you that a page with cases



> Certainly this system is capable of solving both ZBLL, or a completely scrambled LL (CFOP users). However, applying it to CFOP will create major recognition issues! I'm not sure if this applies to all ZBLL cases, but I haven't yet found a set which isn't recognisable by looking at only the U-face and two specific sides. I doubt the same would apply to full LL recognition.



What do you mean "applying it to CFOP"? Full 1LLL or what? I think 1LLL will only be mastered if people are able to make a living out of cubing and even then I kinda doubt anyone will use it, but then again people used to doubt that people would do sub-10 avg in competition. 1LLL recog would be something like OLL, CLL and then look at two edges, fortunately with non-ZBLL there's always at least two non-U edge stickers on U.



> Anyway, cheers for the inspiration irontwig, I think I'm going to dig deeper into this 1-2 LL approach...



Thanks, I try to make the forum a bit more interesting than "speedcubin".


----------



## Cride5 (Jul 1, 2010)

irontwig said:


> Cride5 said:
> 
> 
> > I really like Lars's idea of a 1-look 2-alg system. To me it makes all sorts of sense. Minimum alg approaches are great because the amount of time practising each one is maximised, which really makes a difference to execution speed. The benefits of using only one-look are obvious. I'm already learning this kind of thing with separation prediction in the first step of Guimond, and it really is quite a bit faster!
> ...


Ah right, thanks. So that covers each of Bernhard Helmstetter's 177 cases?

I think it would still be useful to generate more options for each case, and also to cover mirrors/inverses separately.




irontwig said:


> Cride5 said:
> 
> 
> > Certainly this system is capable of solving both ZBLL, or a completely scrambled LL (CFOP users). However, applying it to CFOP will create major recognition issues! I'm not sure if this applies to all ZBLL cases, but I haven't yet found a set which isn't recognisable by looking at only the U-face and two specific sides. I doubt the same would apply to full LL recognition.
> ...


Yup, I mean full 1LLL (any number of edges oriented/disoriented). Remember, 1LLL includes ZBLL, so any disadvantage of ZBLL is also in 1LLL.

For ZBLL recognition I start with the COLL case, and then figure out the edge permutation case by looking at patterns of blocks/opposite colours in F and R (similar to PLL recognition). Having random edges flipped would make this sort of recognition system unusable.

I think developing a good recognition system for 1LLL would be quite a challenge!




irontwig said:


> Cride5 said:
> 
> 
> > Anyway, cheers for the inspiration irontwig, I think I'm going to dig deeper into this 1-2 LL approach...
> ...


Speedcubin?


----------



## Chapuunka (Jul 1, 2010)

Cride5 said:


> Speedcubin?



Speedcubin.


----------



## trying-to-speedcube... (Jul 1, 2010)

Speedcubin.

I know about 90 ZBLLs. All the algs I know are either speed-optimal or very very nearly speed-optimal. A few things I want to note:

- You are overreacting. Learning ZBLL isn't nearly as hard as people make it sound. The point is to take your time and rehearse your algs a lot. Rushing it won't work.
- People who are learning ZBLL are surely already very much motivated to learn algs, and fast ones. Using slower, easy to learn algs just doesn't contribute to the whole point of ZBLL, which is turning a 2-look LL into a 1-look LL, not into a 2-alg LL.


----------



## Kirjava (Jul 1, 2010)

trying-to-speedcube... said:


> - People who are learning ZBLL are surely already very much motivated to learn algs, and fast ones. Using slower, easy to learn algs just doesn't contribute to the whole point of ZBLL, which is turning a 2-look LL into a 1-look LL, not into a 2-alg LL.




The point is that 1 look 2 alg LL is probably faster than 2 look 2 alg LL.


----------



## Tim Reynolds (Jul 1, 2010)

trying-to-speedcube... said:


> Speedcubin.
> 
> I know about 90 ZBLLs. All the algs I know are either speed-optimal or very very nearly speed-optimal. A few things I want to note:
> 
> ...



This. Learning 72 ZBLL algs wasn't all that difficult, and just like OLL/PLL or any other alg set you know, each alg is distinctive. I'm not sure I have the time to continue learning ZBLL algs, but I'll try to move to the next set of 72 soon. Also, at least for the U cases, recognition isn't actually all that hard. I use mostly block recognition, just like for PLL, and when I've been practicing ZBLL recently it's not that hard.

Incidentally the ones I have the most difficulty with are the ones that are two "short algs" put together. I can never remember what moves I do in between the two algs, and it makes it flow not-so-well. I like the other algs I've found way more, and they flow better. I used to have Allan+Bruno as one of my algs for four cases, but then I found something way nicer and switched.

Right now I have a text file with algs for each of the T cases in RU (when possible), RUL, RUF, and RULF. At some point soon I'll go through and pick out the good algs. But I generated them a while ago and haven't been motivated enough to bother yet, so...we'll see.


----------



## trying-to-speedcube... (Jul 1, 2010)

Kirjava said:


> trying-to-speedcube... said:
> 
> 
> > - People who are learning ZBLL are surely already very much motivated to learn algs, and fast ones. Using slower, easy to learn algs just doesn't contribute to the whole point of ZBLL, which is turning a 2-look LL into a 1-look LL, not into a 2-alg LL.
> ...



No, the point is that a 1 look 1 alg LL is probably faster than a 1 look 2 alg LL.


----------



## Kirjava (Jul 1, 2010)

trying-to-speedcube... said:


> Kirjava said:
> 
> 
> > trying-to-speedcube... said:
> ...




Yes, I fully understand the point *you're* trying to make and do not disagree with it. 

However, it'd be nice if you tried listening to the point I'm making.


----------



## StachuK1992 (Jul 1, 2010)

Kirjava said:


> irontwig said:
> 
> 
> > f' F
> ...


I like how this is "***," kinda making it seem that you're all / ***, man - simplify it!)


----------



## irontwig (Jul 1, 2010)

trying-to-speedcube... said:


> You are overreacting. Learning ZBLL isn't nearly as hard as people make it sound.



So that's why there's so many people that know part of ZBLL, but almost no one that knows full ZBLL. Oh wait, that would point more towards people thinking it would be easier than it is. Is it that hard to agree that memorizing and keeping 100s of algs fresh is hard work? One can only speculate on what the best way of learning ZB would be, since no one's mastered it, and besides; different ways are probably better suited for different people.


----------



## Cride5 (Jul 1, 2010)

irontwig said:


> trying-to-speedcube... said:
> 
> 
> > You are overreacting. Learning ZBLL isn't nearly as hard as people make it sound.
> ...



I have to agree with this. I think whether ZBLL 'feels' easy isn't just down to experience, but also the type of mind you have.

I personally find it quite difficult to remember infrequently used algorithms. Of the hundred or so algs I've learned and use, the most difficult ones to maintain are the ZBLL algs. Unlike any other alg sets, I have to periodically set aside time to practice just ZBLL's because they don't appear in my solves often enough. Perhaps if I had more time to dedicate to cubing this wouldn't be the case. Regardless, remembering ZBLL's isn't _easy_ for me.


----------



## Ranzha (Jul 1, 2010)

irontwig said:


> trying-to-speedcube... said:
> 
> 
> > You are overreacting. Learning ZBLL isn't nearly as hard as people make it sound.
> ...



Do remember that 4Chan (Chris Tran) knows ZBLL and the disconnected ZBF2L cases. He'd know first hand ZBLL's difficulty.


----------



## 4Chan (Jul 1, 2010)

I use the case in OP's post. (Except with what Kirjava said, and I use my thumb to do the S.)

I also use the cases in which 2 sunes to solve 2 GLLs (And some are optimal)



MiloD said:


> Petrus' alg combos are only 2-3 moves above optimal on average and all the algs are pretty easy to execute.
> 
> How many people are using all optimal ZBLL algs anyway? And how fluent is their execution?



>.>
A lot of my algorithms are in fact,optimal.

For like, a few of my sune cases, the optimal solution actually was 2 OLLs together, examples:

U2, F R U R' U' F' U' r' U' RU' R' U2 r
And 
F R U R' U' F' B' U' R' U R B



Edit: Irontwig: http://www.youtube.com/results?search_query=zb+method&aq=f

Look at the first 4 videos.
They're mine.


----------



## irontwig (Jul 1, 2010)

=4Chan said:


> I use the case in OP's post. (Except with what Kirjava said, and I use my thumb to do the S.)
> 
> I also use the cases in which 2 sunes to solve 2 GLLs (And some are optimal)
> 
> ...



Oh, cool. Have this approach been brought up before? I've seen conjugates and COLL combinations, but not this. 



4Chan said:


> Edit: Irontwig: http://www.youtube.com/results?search_query=zb+method&aq=f
> 
> Look at the first 4 videos.
> They're mine.



Yes, I have already seen them, I'm not sure why you're rolling your eyes


----------



## 4Chan (Jul 1, 2010)

Because you said noone knew ZBLL, which is false.


----------



## irontwig (Jul 1, 2010)

4Chan said:


> Because you said noone knew ZBLL, which is false.



I said "almost no one". Have you completed ZBF2L?


----------



## 4Chan (Jul 1, 2010)

No. >.>
I actually just know all the disconnected cases of ZBF2L, whenever a connected F2L case appears, I just disconnect it with R U R', and do the ZBF2L from there.


----------



## Kirjava (Jul 1, 2010)

Wait what.

I always thought the connected cases were easy and intuitive o_o.


----------



## irontwig (Jul 1, 2010)

Well you probably don't disconnect if it's a VHF2L case .

Edit:


Kirjava said:


> Wait what.
> 
> I always thought the connected cases were easy and intuitive o_o.



Yeah, I would probably orient some edges while breaking up the pair and then finish up, but then again I've got no experience with this method.


----------



## 4Chan (Jul 1, 2010)

I've been so lazy, I'll start learning them soon. Dx


----------



## nck (Jul 2, 2010)

hmm wouldn't it be nicer to consider coll and epll combination because recognizing 4 edge pieces would probably be easier to do than trying to recognize all 4edges and the corners?


----------



## irontwig (Jul 2, 2010)

nck said:


> hmm wouldn't it be nicer to consider coll and epll combination because recognizing 4 edge pieces would probably be easier to do than trying to recognize all 4edges and the corners?



I don't think I understand what you're saying.


----------



## Anonymous (Jul 7, 2010)

He's saying that he thinks that a COLL + EPLL one-look system would be better, because after fairly quick recognition of COLL, one would only have to look at the way the edges are arranged, which is arguably easier than any OLL + PLL or OLL + OLL combination.


----------



## FatBoyXPC (Jul 7, 2010)

Anonymous: The argument is that most of the OLLs are very easy to execute and recognize, whereas the COLL cases take more time to recognize and (I'm not sure about how true this is, it was just argued in another thread in here) the algs aren't nearly as fast to execute.

I've actually been debating on this idea since Ua, Ub, H, Z, are all wickedly fast to execute.

Another point made against this is what happens when you get an OLL skip? Then you might have a corner + edge perm, and bringing your recall down when needed might screw you in those instances.


----------



## Ranzha (Jul 7, 2010)

For these reasons, I learn CxLL/ELL.
3x3 CLL algorithms can either be straight up CLL, COLL, CMLL (for Rouxites), or CLLEF (which, after I'm done learning COLL, I will learn).
Also, 3x3 CxLL is not quite difficult to recognise. I actually think that learning to recognise cases that aren't as easy to recognise could strengthen recognition time/look ahead for, say, OLL/PLL.
ELL is a different story. 30 cases. 30 algorithms. Easy to generate and M-slice friendly, usually. All I try doing is recognise the PLL case, and it's blatantly obvious which OLL case I have. If I had a clockwise U-perm combined with adjacent edge flip, there are 4 cases. Recognising which case it is (AA1, AA2, AA3, AA4, as I call them) is the most difficult part. After using OLL/PLL for a while now, my urge is to use M' U' M U2 M' U' M, but the case usually is a different one.

Although recognition might be different, it's not too difficult. I've tried timing recognition by saying the name of the case I have in the shortest of time.
But do what you will.


----------



## Kirjava (Jul 7, 2010)

Lack of a true naming scheme for ELL annoys me.


----------



## joey (Jul 7, 2010)

Just say (cycle, flips)
(F->L->R,BR)


----------



## Anonymous (Jul 7, 2010)

I only know around half of COLL, so I don't have a lot of experience with it, but most of them seem fairly fast, although I see your point with the OLLs being faster.

The problem with learning all ZBLLs through OLL combinations, or at least what I think makes it inferior to COLL + EPLL combinations, is that all that's involved with the latter system is 

-Recognize COLL case
-Look at edge permutation
-Recall appropriate edge alg
-Perform COLL followed by edge alg

Whereas with an OLL + OLL system, there's essentially an extra step involved:

-Recognize COLL case
-Recognize edge permutation
-Recall OLL alg
-Recall another OLL alg
-Execute 

Maybe the difference is minimal, but I think that the easier recognition will at least make up for the small difference in execution time (if there is one).


----------



## Kirjava (Jul 7, 2010)

Anonymous said:


> -Recognize COLL case
> -Look at edge permutation
> -Recall appropriate edge alg
> -Perform COLL followed by edge alg




This is not how COLL/EPLL works.



Anonymous said:


> Whereas with an OLL + OLL system, there's essentially an extra step involved:




Does a Y Perm require two steps to execute?


----------



## irontwig (Jul 7, 2010)

Anonymous said:


> I only know around half of COLL, so I don't have a lot of experience with it, but most of them seem fairly fast, although I see your point with the OLLs being faster.



Don't think of it as an alternative system, but rather an addition to the same system. My point is that the more algs you know the better 2 alg combination you can make and if you're a CFOP user and thus know OLL, why not try to keep them for ZBLL to? To quote Lars Petrus:

"It is a one look system, that requires learning around 40 algorithms (most of which a serious cuber already knows), and averages 14-15 moves."

Obviously the average length can't increase by adding more algs (OLLs), so at least move wise the algs should be quite close to optimal (12 moves.)



> Maybe the difference is minimal, but I think that the easier recognition will at least make up for the small difference in execution time (if there is one).



There's no "easier recognition" since in both cases if you're using a one look approach you should just see the ZBLL case and then perform the appropriate algorithm, regardless if the algorithm happen to be a combination of two algs or not.


----------



## Anonymous (Jul 7, 2010)

Kirjava: I was referring to how a 1-look system utilizing COLL and EPLL would work, not to a normal solve using COLL then EPLL in two looks.
Sorry, what do you mean about the Y-perm? 

Irontwig: I wasn't being clear at all, sorry. Let's compare the thought processes of two people, one using combinations of OLLs to solve the ZBLL, and another using combinations of COLLs and EPLLs.

The first person, having fully recognized the ZBLL, must now remember two algs that they are familiar with, and execute them. The second person, however, can recall the COLL faster. Think of it this way- there's a set of twelve ZBLLs for every COLL case, right? The first person using OLL combinations would have to remember each of the twelve cases as completely unrelated combinations of two random OLLs. The second person would only have to remember the appropriate EPLL for each case, because recalling the COLL is an inherent part of recognizing the ZBLL.

Is that a bit clearer? I still don't like the way I'm saying it, but maybe I got my point across.


----------



## Kirjava (Jul 7, 2010)

Anonymous said:


> Kirjava: I was referring to how a 1-look system utilizing COLL and EPLL would work, not to a normal solve using COLL then EPLL in two looks.
> Sorry, what do you mean about the Y-perm?




A 2 look COLL/EPLL system would probably be faster than a 1 look system.

The Y perm is two OLLs, but you don't recall each OLL separately.


----------



## Anonymous (Jul 7, 2010)

That's a good point. All I can say is that IMO, the reason why the Y-perm is different from my example is simply that it's part of a much smaller algorithm set. The whole point of learning a 1-look 2-alg system is so that each case can be easily memorized as two "pieces" of information. I think that the reason why people don't do that for the Y-perm is because that's simply not how they memorize it. Am I wrong?


----------



## Kirjava (Jul 7, 2010)

When someone remembers a 2 alg combo for a case, they don't execute the first and then work out the second - they already know what the second will be before executing the first.

This may become an issue with a larger algorithm set, but this is because the number of cases is large - not because of the technique.


----------



## Anonymous (Jul 7, 2010)

To your second point: Yes, but to me that's exactly the point- two OLL combinations could be harder to remember than COLL EPLL combos when you talk about nearly 500 cases.

As for your first point, I realize that, but is it relevant? I know that you'd recall both algorithms before starting to perform them, but the fact remains that recalling them is easier (I think it would be, anyway) when dealing with COLL and EPLL pairs.


----------



## Kirjava (Jul 7, 2010)

Anonymous said:


> two OLL combinations could be harder to remember than COLL EPLL combos when you talk about nearly 500 cases.




This is clearly incorrect.



Anonymous said:


> As for your first point, I realize that, but is it relevant? I know that you'd recall both algorithms before starting to perform them, but the fact remains that recalling them is easier (I think it would be, anyway) when dealing with COLL and EPLL pairs.




As is this. 

I don't think you're quite sure of what you're talking about. Did you read this and this?


----------



## Anonymous (Jul 7, 2010)

I'm not exactly following...

Yes, I read both of those posts, but I'm not quite sure how what I'm saying relates. This thread is meant to be discussing the possibility of using two OLLs in a row to solve a ZBLL case, right? Someone earlier made a suggestion to instead use a system which uses COLL and EPLL combos instead of two OLLs. All I'm saying is that I think that that's easier, for reasons I outlined in another post. Could you explain why you disagree with that?

The second thing you quoted was essentially me saying the same thing, but trying to express that what I was saying addressed both of your earlier points. Could you tell me why you think I'm wrong?


----------



## Kirjava (Jul 7, 2010)

Find me any COLL+EPLL combination that's less moves than an OLL+OLL ZBLL combo.

The reason why I'm telling you that you don't understand things is that it's impossible for an OLL+OLL system to cover every ZBLL case (efficiently). Because of this, OLL+OLL is only used for a few cases because it's fast for them. For some of these cases, it's the optimal solution. 

Therefore, you can't really argue against using OLL+OLL combos for ZBLL. Saying 'COLL+EPLL is probably easier than OLL+OLL' is simply a silly argument to make since you cannot comare the two.


----------



## Anonymous (Jul 7, 2010)

I know that 4Chan mentioned that some of his algs are OLL combinations and optimal, but I was under the impression that whatever portion of ZBLL these OLL combinations could cover, it wasn't necessarily meant to be optimal; it was meant to be an easy alternative to actually learning new algorithms. In that context, I was just saying that COLL + EPLL was more appealing.


----------



## Kirjava (Jul 7, 2010)

It isn't.


----------



## Anonymous (Jul 7, 2010)

Are you saying I still have some fundamental misunderstanding, or do you just disagree?


----------



## Kirjava (Jul 7, 2010)

I disagree.


----------



## 4Chan (Jul 7, 2010)

Anonymous said:


> I know that 4Chan mentioned that some of his algs are OLL combinations and optimal, but I was under the impression that whatever portion of ZBLL these OLL combinations could cover, it wasn't necessarily meant to be optimal; it was meant to be an easy alternative to actually learning new algorithms. In that context, I was just saying that COLL + EPLL was more appealing.



Yep! Those were a coincidence actually. xD

Another coincidence is that on the sune cases with




subset, and double edge swap in UF and UR. 

An optimal solution is actually a sune+optimal J perm with cancellation. LOL


----------



## rubiknewbie (Jul 8, 2010)

I think there might be coincidence cases where the optimal solution happens to be a COLL + EPLL? But maybe isolated cases.

However as a system, I don't think 1-look COLL+EPLL is better than even 2-look COLL+EPLL because: 
1. recognition wise, 1-look COLL + EPLL is much worse than 2-look COLL + EPLL if you are already narrowed down to U, Z, and H on the 2nd look which are all super nice for recognition. Even with no pause in between, the 1-look may take longer than the 2 looks COMBINED, if you have to recognise and recall the combination.
2. move wise you are not saving up in number of moves and fingertrickiness, since you are combinining the same algorithms? 

I think the selling of point of Lars Petrus system is that combining nice algorithms you can sometimes solve last layer in 1 look. You will reject combinations if the algorithms are not nice. So you make up for poor recognition with guaranteed good execution. Not all COLL+ EPLL combinations are nice for execution.


----------



## Rpotts (Jul 8, 2010)

How does anonymous not get what kirjava is saying?

There are so many ZBLL algs you need to consider all different kinds of alg combos to cover all of them. OLL/OLL is good for some, COLL/EPLL may be good for some too. But why try to cover all of them with one strategy? I mean, you're learning almost 500 algs, put forth the effort.


----------



## Anonymous (Jul 8, 2010)

My point was simply that overall, I think that in most situations OLL + OLL is not as good as COLL + EPLL. I understood fully what he was saying. I happen to disagree, but I _understand_ what I'm disagreeing with. I don't think that COLL + EPLL could cover every case better than two OLLs, all I'm saying is it's likely to be better able to cover a larger portion of ZBLL efficiently in terms of memorization and recall.

Edit: Rubiknewbie, I actually don't think that COLL + EPLL could ever be optimal. Both COLLs and EPLLs are mostly pretty long. 
And to your point on 1-look vs 2- you might be right, but I'm not so sure. All you have to do after quick recognition of the COLL case is look at two edges, right? If I understand correctly, ZBLL is theoretically superior to a normal LL system composing of either OCLL/PLL or COLL/PLL because it does two things: it lowers movecount, and there are no pauses as you execute the algorithm. With a 1-look 2 alg system, you're still getting the latter benefit, and considering the speed of EPLL, I'm not convinced that its higher movecount (in comparison to ZBLL) is that much of a hindrance. 

Could 4Chan maybe shed some light on this? As in, provide LL times, and maybe an opinion as to which of these aspects (movecount or fluency) of ZBLL give him the bigggest advantage?


----------



## nck (Jul 8, 2010)

Anonymous said:


> My point was simply that overall, I think that in most situations OLL + OLL is not as good as COLL + EPLL. I understood fully what he was saying. I happen to disagree, but I _understand_ what I'm disagreeing with. I don't think that COLL + EPLL could cover every case better than two OLLs, all I'm saying is it's likely to be better able to cover a larger portion of ZBLL efficiently in terms of memorization and recall.
> 
> Edit: Rubiknewbie, I actually don't think that COLL + *EPLL* could ever be optimal. Both COLLs and *EPLLs are mostly pretty long*.
> And to your point on 1-look vs 2- you might be right, but I'm not so sure. All you have to do after quick recognition of the COLL case is look at two edges, right? If I understand correctly, ZBLL is theoretically superior to a normal LL system composing of either OCLL/PLL or COLL/PLL because it does two things: it lowers movecount, and there are no pauses as you execute the algorithm. With a 1-look 2 alg system, you're still getting the latter benefit, and considering the speed of EPLL, I'm not convinced that its higher movecount (in comparison to ZBLL) is that much of a hindrance.
> ...



What this is I don't even.


----------



## Anonymous (Jul 8, 2010)

11 moves for the Us, 12 for the H, 15 for Z, HTM. Even if you don't consider those long, what I meant was that they're long compared to what the optimal solution would be. I highly doubt that ~10 move COLL and an (at least) 11 move EPLL will even come close to being an optimal solution for a ZBLL. However, if you read my post, you would realize that I'm not going for optimality.


----------



## 4Chan (Jul 8, 2010)

Lol, my LL varies from sub-second(sune and a few 2GLLs) to 6 seconds(Bad cases).
It all depends on the case.

Also, you imply that algorithms with low movecounts can't be fluent.
You just choose algorithms that are both low movecount and fluent.

Cube Explorer can spit out a lot of algorithms within 3-4 moves of optimal. You can even choose which faces to omit, and even slice turns.
(If you know how to use it.)

Pic related: They're 3-gen RUF T perms within 14 and 15 moves.


----------



## Kirjava (Jul 8, 2010)

Anonymous said:


> I understood fully what he was saying. I happen to disagree, but I _understand_ what I'm disagreeing with.




If you understood, you would not disagree.

I'm done wasting my time on you.


----------



## Anonymous (Jul 8, 2010)

4Chan: By fluency, I meant the ability to not have to pause between algorithms, which can be acheived by using ZBLL or some other 1LLL. My main point was that fluency meant in this way is acheived with both 1-look 2-alg combinations and true, direct, 1-alg solves. The latter, however, usually has a lower movecount. My question to you was mostly whether its the movecount or lack of pauses in the LL which makes you think that ZBLL is good. 

Kirjava: If you'll bother reading this post, can I just try to clarify myself one more time? I agree that there will be cases where OLL/OLL is better, and that there will be cases where there simply isn't a good OLL combination. I got sidetracked from my main point, which wasn't even that COLL/EPLL is necessarily better than OLL/OLL. All I was trying to say was that recall would be easier with COLL/EPLL if you were to attempt to cover a large portion of ZBLL with 2-alg combinations.


----------



## 4Chan (Jul 8, 2010)

wat



Anonymous said:


> My question to you was mostly whether its the movecount or lack of pauses in the LL which makes you think that ZBLL is good.



I answered that ZBLL can have both low movecount AND lack of pauses.

Have you tried Petrus' system with 2 algs one look?
It kinda SUCKS.

And the cases with 2 OLL algs together are nice when they work.
Mister Kirjava said all there is to say about it.

It sounds to me like you're fishing for a specific answer, and you're not getting the answer you want.
So uh, I'm going to leave this thread too.




rubiknewbie said:


> I think there might be coincidence cases where the optimal solution happens to be a COLL + EPLL? But maybe isolated cases.



I'm pretty sure there are none.


----------



## Anonymous (Jul 8, 2010)

Sorry, wait, you've got me all wrong.

I'm not fishing for answers here. In a normal Fridrich solve, you have OLL then PLL. There's always a pause between OLL and PLL in a normal solve. ZBLL eliminates that pause. _That's_ what I meant by fluency. ZBLL also happens to have a lower movecount than OLL + PLL. I also didn't mean to say what makes ZBLL *good*. I meant to ask which of those makes you think that ZBLL is *superior* to Fridrich LL. I wasn't trying to weasel either answer out of you, I'm just asking.

As for what Kirjava's saying, I essentially agree with him that in the cases where OLL + OLL combinations work well, they should be used. All I was saying was that _it seemed to me_ like COLL + EPLL would work well more often.


----------



## Rpotts (Jul 9, 2010)

Anonymous said:


> There's always a pause between OLL and PLL in a normal solve.



inb4faz


----------



## Tim Major (Jul 9, 2010)

Rpotts said:


> Anonymous said:
> 
> 
> > There's always a pause between OLL and PLL in a normal solve.
> ...



He said "in a normal solve" ;p


----------

