Quest for OLL/PLL skips

[hawkmp4]

Now, stop being a troll, and go to bed mister.

Because I'm the one who started with ad hominem attacks, right?

 

[V-te]

Ok, Cubes

I tried it, turns out you will need a minimum of 13 moves, 15 if you want it fingertrick friendly.

Does 15 moves make up for the skipped PLL?

 

[4Chan]

Ah, yes it does.
But... you're going to have to generate a lottt of those. o_o
Umm, most of the time you can force the optimal solution to be finger trick friendly. I could show you an example but....

It's 3am here, and i'm only on because of /b/.
D:

 

[hawkmp4]

Umm, most of the time you can force the optimal solution to be finger trick friendly. I could show you an example but....

I had a small program on my old computer (which is in storage right now unfortunately) that had a program called...Gripper, I think. I can't remember who wrote it though- it was one of the regulars here though. I'll do a search in the morning on the forums, too tired right now. It essentially automated the task of making algorithms more fingertrick friendly by introducing double layer turns, cube rotations, etc. That might be helpful if you haven't done much of that on your own before.
EDIT: Clarification- I quoted Cubes=Life but I was directing the post to V-te. I know you've done plenty of optimising.

 

[nzcuber40]

Lol, the only way i got the record that i have is an accidental oll/pll skip!

 

[hawkmp4]

Lol, the only way i got the record that i have is an accidental oll/pll skip!

Erm. And your contribution to this thread was...?

 

[nzcuber40]

he he... um, i was bored. sorry

 

[V-te]

Umm, most of the time you can force the optimal solution to be finger trick friendly. I could show you an example but....

I had a small program on my old computer (which is in storage right now unfortunately) that had a program called...Gripper, I think. I can't remember who wrote it though- it was one of the regulars here though. I'll do a search in the morning on the forums, too tired right now. It essentially automated the task of making algorithms more fingertrick friendly by introducing double layer turns, cube rotations, etc. That might be helpful if you haven't done much of that on your own before.
EDIT: Clarification- I quoted Cubes=Life but I was directing the post to V-te. I know you've done plenty of optimising.

Interesting. Let me know if you find it. I would really like to work on this concept.

 

[rubiknewbie]

Lol, the only way i got the record that i have is an accidental oll/pll skip!

The objective is to get a non-lucky OLL/PLL skip! Luck gives no satisfaction.

 

[DavidWoner]

Why does Dan Cohen use it ?

He hates it btw.

I don't think VHF2L is worth it. A bit of edge control can be nice from time to time, but its not worth.

The shorter WV cases are useful, but I wouldn't learn all of them.

COLL is a many-headed beast, with various advantages and disadvantages. I don't think its good for 3x3, losing a second or more during OLL is not worth the half a second I save on PLL. I do use it on some cases, but that's just to avoid diagonal corner PLLs. However, its quite useful on bigcubes, where EPLLs can be twice as fast as other PLLs.

Basically, for cube explorer, i paint the cube into the program, select optimal, and fiddle around with the algorithm until it's finger trick friendly. It's super easy!~ (Unless you have to do it 200 times. T_T)

Did you explore all AUFs as well? If not, you could have missed a nice optimal alg that was just an AUF away from how you painted it.

 

[4Chan]

Ah?
He hates it. I could have sworn I saw him use it in 3x3 avgs, as well as big cubes. Hm, interesting.

Also, I didn't know that AUFs would influence the program!
Thanks for the tip! 0:

 

[Cride5]

... COLL (which has worse recognition than PLL)...

Is recognition for COLL really worse than PLL? I've started on learning it and so far I'd say it seems better (but then again I'm starting at the pi case). COLL recognition seems more hierarchical than PLL. With PLL I'm simply scanning for blocks, bars and headlights. The reason I don't like it is that I usually have to scan all four sides of the cube. I looked into recognition using only 2-sides and it just seemed impractical.

With COLL, I'm first recognising 1/7 OCLL cases, then within each case I'm usually looking for 1/6 corner permutation cases. For OCLL, the top + 2-sides is more than enough for recognition, and certainly for pi only the top needs to be scanned for CP.

A lot of the discussion comparing COLL/EPLL with OLL/PLL is quite rightly taking account of having to apply VHF2L or ZBF2L algs to orient edges. What if edges are already oriented without any additional effort? Is OCLL/PLL really better than COLL/EPLL? ... this is something I'm really trying to figure out at the moment.. :confused:

 

[Escher]

Why does Dan Cohen use it ?

He hates it btw.

I don't think VHF2L is worth it. A bit of edge control can be nice from time to time, but its not worth.

The shorter WV cases are useful, but I wouldn't learn all of them.

COLL is a many-headed beast, with various advantages and disadvantages. I don't think its good for 3x3, losing a second or more during OLL is not worth the half a second I save on PLL. I do use it on some cases, but that's just to avoid diagonal corner PLLs. However, its quite useful on bigcubes, where EPLLs can be twice as fast as other PLLs.

+1 this post, re COLL/WV/VH.
I use COLL when I know the case on 3x3 and I hate it too

COLL is good for bigcubes imo.
I don't recommend WV for a Fridrich user unless they use it when all edges are oriented.

Personally speaking, I use different OLLs (not OCLLs) to force an EPLL or to avoid a diagonal corner swap case. I don't use it for all of them (and definitely not all the time), but for a couple of cases I know nearly every alg to get a CP skip.
It's a shame I'm not actually very fast at EPLLs...


@OP: Perhaps you could learn ELL? when you get a CLL skip (which is annoyingly rare) you can have a 1LLL. The recognition isn't that great, but I think there are only 20.

 

[rubiknewbie]

@OP: Perhaps you could learn ELL? when you get a CLL skip (which is annoyingly rare) you can have a 1LLL. The recognition isn't that great, but I think there are only 20.

I did consider but it seems to lead to CLL-ELL which is another 2-look. Lucky CLL skip seems more difficult compared to lucky edge orientation (for WV).

Is there a good link to see ELL algorithms?

Actually all this knowledge even if not too useful for speedsolving can still be handy if I want to do fewer moves for fun (hence no plan to learn Petrus yet).

 

[Cride5]

So I've now learned 1/7 of COLL (the pi case), and I can't say the recognition or algs are that bad. Recognition is certainly easier than PLL. The algs I have are almost all zero regrip and feel quite nice. However, OCLLs are so fast and easy to recognise, I'm not really sure whether COLL gives any significant advantage over OCLL/PLL.

In terms of execution I'd imagine COLL and PLL will be pretty similar. PLL probably has slightly worse algs, but there's half as many of them which means each one gets about double the time devoted to it.

To compare OCLL/EPLL I just timed myself. I think I've devoted enough practice to each for the results to be meaningful. My EPLL was definetly slower on average than OCLL. In addition, recognition for OCLL is slightly better than EPLL. So overall I think COLL/EPLL will (even with practice) be a fraction slower than OCLL/PLL. However there's quite a major consideration I'm missing ... which was kindof the point of this thread: Skips!

Below are the comparative chances of a 1-look last layer, where OCLL/PLL and COLL/EPLL are used.

OCLL/PLL
(1/27 + 1/72) ~= 5.1%

COLL/EPLL (with knowledge of PLL)
(1/27 + 1/12) ~= 12.0%

... so COLL/EPLL gives more than double the chance of a 1LLL! If we assume that recog/execution of COLL/EPLL and OCLL/PLL are the same, and we naively assume that a stage skip results in the last-layer time being halved, then it means that on average COLL/EPLL will be:
(1-((1/27 + 1/72)/2)) / (1-((1/27 + 1/12)/2)) ~= 1.037 times faster than OCLL/PLL

that's ~ 3.7% faster.

So in summary, if you're looking to skips to make you faster, be aware that the margin is very slight. I think recognition, execution and number of algs to practice should be a more important consideration.

 

[rubiknewbie]

However, OCLLs are so fast and easy to recognise, I'm not really sure whether COLL gives any significant advantage over OCLL/PLL.

That's the contradiction about COLL. It works on OLLs that are among the easiest and makes them slightly more difficult.

On the topic of lazy methods, how about the opposite approach? Is it possible to generate algorithms to cater to those difficult OLL cases to make them 1LLL. Since the OLL cases are already difficult it might be worth it to use longer algorithms to complete the PLL as well. But I guess it will lead to too many cases to remember .

 

[Cride5]

However, OCLLs are so fast and easy to recognise, I'm not really sure whether COLL gives any significant advantage over OCLL/PLL.

That's the contradiction about COLL. It works on OLLs that are among the easiest and makes them slightly more difficult.

On the topic of lazy methods, how about the opposite approach? Is it possible to generate algorithms to cater to those difficult OLL cases to make them 1LLL. Since the OLL cases are already difficult it might be worth it to use longer algorithms to complete the PLL as well. But I guess it will lead to too many cases to remember .

This kind of idea was touched on a while back. Instead of using COLL for edge oriented cases, another set of algs which flip all edges could be used for cases where no edges are oriented. Search for 'CLLEF' (its in the wiki). Note that like COLL, CLLEF ends in EPLL. To make it a 1LLL you would need to learn the same number of algs as ZBLL. Given you would only be using them a fraction of the time, I doubt it would be worth learning.

 

[David Pritts]

Even though I don't know enough to appreciate half of what was said in this thread, I enjoyed reading it--especially the ad hominem attacks between certain individuals -_-

If what the one guy was saying (forgot his name) was true, I would be kind of disappointed. That is, if OLL/PLL is really the best approach. (I think this was his stance?)

While it would be nice, since it's what I use (though now with 2LOLL), it seems so goddamn boring :-/

 

[Lt-UnReaL]

Um, COLL/EPLL is only like 0.4 moves less than OLL/PLL (with popular algorithms, not 23489-gen optimal algorithms)

VHF2L is pointless to use because of how long the algs are unless it's one of the easy cases. (check Jason Baum's site and scroll down to partial edge control to see some easy cases. So if it's too many moves, it's good to not orient edges and just do OLL/PLL instead.

Double Sune cases are recommended to learn because of how fast and easy they are to recognize. (I them)

 

[hawkmp4]

Even though I don't know enough to appreciate half of what was said in this thread, I enjoyed reading it--especially the ad hominem attacks between certain individuals -_-

If what the one guy was saying (forgot his name) was true, I would be kind of disappointed. That is, if OLL/PLL is really the best approach. (I think this was his stance?)

While it would be nice, since it's what I use (though now with 2LOLL), it seems so goddamn boring :-/

That was me that was saying that.
It does seem to be boring. I agree completely. I know I SHOULD learn full OLL but I can't bring myself to do it. I'm so bored with it. I'm working on Heise method and I might do Roux. But for Fridrich everything points to OLL/PLL being the best :/