Orienting corners while permuting edges instead of COLL for OH

Weston

Premium Member
Joined
May 22, 2009
Messages
980
WCA ID
2008MIZU01
YouTube
Visit Channel
This might have been thought of before, but this idea occurred to me.

Some people use COLL for one handed solves so that they have an some sort of edge cycle as their PLL, which is very fast.
One down side of this is that the COLL algorithms are generally not as fast as the corner OLL algorithms because the corner OLL algorithms can be 2 gen and the for COLL, about 7/8 (and 3/4 of the H case) can not be 2 gen.

However, if instead of COLL, on the last layer with all edges oriented correctly, one performed an algorithm that oriented corners and permuted edges, it would be 2 gen. Then for PLL, you could have a skip, A, or E perm. A perms in my opinion for OH are pretty fast, but I haven't looked for a good OH E perm yet. I'm pretty sure there is one.

I'm not sure how many algorithms this would require, but if it isn't too many, I think it is a pretty good idea.

What do you think?
 
Very interesting idea...
You would also recognize it similar to ZBLL (edge cycles).. but ignore the COLL case...
Very creative!~

EDIT: My estimate is around 24 x 7 algorithms because of 24 possible edge cycles and 7 OCLL cases.
However, i may be wrong, since i have little knowledge of Cube Theory, this is from experience with ZBLL.
 
Last edited:
What are you talking about? You can generate LUR COLLs for "bad" cases and they are very good for OH. I don't know of many COLLs that I dislike. Probably 1/2 of them are easily sub-2.
E perm has to be the worst PLL ever; I guess you are happy that it now pops up very often. EPLLs are lightning fast OH, they are easily sub-3, and sometimes even sub-2. A Perms are good, but no where near as good as U perms. Their weakness is that you have to rotate the cube before executing them and they lock up more than U perms.
 
Hmmm, from what I can see for myself, Fanwuq is right.

Thats a little over 4 times as many algorithms as COLL, and the E perms isnt very good.

Recognition with edge cycles is also slightly slower than COLL recognition with the corner colors.

Again, Innovative idea, but not feasible.

EDIT: 666 POST COUNT
 
Last edited:
if LUR algs are so good for OH, I know of an LUR E perm that would be pretty good.

And you can sub 2 half of your OH COLLs?
Wow that's impressive.

Of course, the number of algs might be a drawback to this.
Its a similar idea to MGLS though.
 
if LUR algs are so good for OH, I know of an LUR E perm that would be pretty good.

And you can sub 2 half of your OH COLLs?
Wow that's impressive.

Of course, the number of algs might be a drawback to this.
Its a similar idea to MGLS though.

Clarification:
I don't know full COLL and I haven't done 3x3x3 OH in a while. But at one time, I knew around 25 COLLs and could get sub-2 singles after a few tries on maybe 15 of them. All the COLLs I knew were sub-4.5 on average. I was getting around 2.5-3 for A perm and 5-6 for E perm. I have achieved 1.5x singles on both of my U perms and average sub-3 on H and Z perms. I can insure you that plenty of people turn faster than me. I wouldn't be surprised if someone can sub-3 all COLLs and sub-2 75% of them.
 
Its a similar idea to MGLS though.
Plese don't say that. It's no more similar to MGLS than COLL.

Well, I just said that because isn't the basic idea of MGLS-F is to alter the Fridrich method such that instead of OLL algorithms, which might be slow in some cases, you have CLS algorithms which can all be 2 gen which might be faster than just OLL.
(also its easier to get an ELS skip (or easy case) than to get an accidental CE pair in. But that is irrelevant here.)

EDIT: Oops. I messed up the quote function. Oh well.
 
Very interesting idea...
You would also recognize it similar to ZBLL (edge cycles).. but ignore the COLL case...
Very creative!~

EDIT: My estimate is around 24 x 7 algorithms because of 24 possible edge cycles and 7 OCLL cases.
However, i may be wrong, since i have little knowledge of Cube Theory, this is from experience with ZBLL.

Your amount of algorithms is wrong.

Because just by using logic 2GLL has 70 algorithms (or a bit more).

And that whiles keeping corner permutation.

So it should be about as much as that.

So this should also be about 70 algorithms.

And they all could be RU.(Making it very fast)
 
Back
Top