Invalid PLLs on the wiki?

[It3ration]

Hey all,

I normally use Ryan Heise, but lately I've been memorizing all the OLLs/PLLs to improve my speedcubing times. It seems many of the algorithms listed on the wiki are invalid. This is probably due to missing rotations, etc. at the start of algorithms, I'm not sure. At any rate, perhaps there should be some verification process when someone adds a new algorithm. For example, if you post an algorithm but the starting permutation of the cubies does not match the picture, then say so or add the correct starting rotation.

An example of this is one of the PLL algorithms (F perm):

R U' R' U R2 y R U R' U' x U' R' U R U2

This doesn't work if you start with the F perm on the U face.

Any clarifications/help would be appreciated. Thanks all!

It3ration

 

[ShadenSmith]

Your example works.

 

[masterofthebass]

That is an F perm... It just may be from a different angle than you are used to. For this alg, you put the solved bar on the back.

 

[It3ration]

I'm a bit confused. If the starting orientation of the cube isn't specified, how do you know how to apply the algorithm? Trying it forever until you find the correct starting orientation?

Thanks!

 

[Novriil]

every alg you start yellow top.. they work !

 

[ShadenSmith]

Just do it once and see what it does to the cube. You can then determine the correct way to hold it before applying the algorithm.

In this case you'll see that it performed the F perm with the bar in back. It just looks funny because of the y rotation in there. That's why it's off by a U at the end.

 

[LarsN]

For ease of use I've added a (y2) rotation to the alg. You should do that yourself if you find and confirm a mistake like that.

 

[It3ration]

I'm sorry guys, I think I'm just a bit confused here. If you perform (y2) at the start, then you still have to add an x' U at the end?

E.g.

(y2) R U' R' U R2 y R U R' U' x U' R' U R U2 x' U

I'm sorry, i feel pretty silly, I must be losing my marbles.

 

[trying-to-speedcube...]

AUF doesn't matter, because it's always different, so for ease it's not included in the algorithm.

 

[It3ration]

Thank you - that's good to know! My only remaining question is, how did you derive that (y2) had to be performed at the start?

My apologies again and thank you.

 

[mcciff2112]

If you look at the picture of the cube displaying the case, it shows that the solved bar is in the front, thereby making all listed algorithms start in that position. Adding a y2 at the beginning of the algorithm will bring the bar to the back layer, which, as Dan (masterofthebass) stated, will allow the rest of the algorithm to complete the cube. Sorry if that's a little confusing I had trouble finding the right words to explain it.

 

[It3ration]

Ok thanks!

 

[teller]

Thank you - that's good to know! My only remaining question is, how did you derive that (y2) had to be performed at the start?

My apologies again and thank you.

Execute it into a solved cube.

 

[Cride5]

I have noticed a small number of incorrectly placed OLL/PLLs on the Wiki, but not that many. A good way to check them is with Lucas Garron's algorithm animator @ alg.garron.us For example, here is the alg you were having trouble with. You can see it is indeed an F-Perm. Be sure to use SOLVER mode (rather than generator) otherwise it'll simply execute the alg from a solved state, and the pattern you will see on the cube will only be solvable using the alg's inverse.
(site note: F-perms look the same in both solver and generator mode because F is the inverse of its self)

Although the alg is correct, it doesn't leave the cube in the same orientation as it was to start with (because of rotations within the alg). This can be fixed by adding the correct rotations at the end. For this example its x' y'. Also, as pointed out, that alg doesn't technically solve an F-perm from the orientation in the diagram. It does it with the bar in the B face, so to make it match up with the diagram it needs an initial y2. So the 'correct' way to present the alg in the Wiki would be:(y2) R U' R' U R2 y R U R' U' x U' R' U R U2 x' y'

 

[CanadianPires]

(y2) R U' R' U R2 y R U R' U' x U' R' U R U2 x' y'

My only concern with this is, using your example above, how did you know to execute the alg with the orange center on the right face. On the wiki, all it shows is the positioning of the LL. Such as for the F perm in question, it shows that the bar is on the F face. However, when I first looked at that same alg I held the cube with the orange LL bar towards me (on the F face) and the orange center (face) towards me. I made this assumption so that what I had in front of me was a true F perm where two swaps needed to be executed to solve the cube. Unfortunately, after executing the alg I found I needed an additional U rotation. This is what I find annoying about the wiki. It says nothing about executing the alg with the LL bar not matched up with its correct face. Though, I'm not sure if the same thing occurs for any other cases.

 

[Cride5]

I see what you mean. Unfortunately, with this particular F-perm a B turn would be needed at the end to correct the final alignment of the U-layer (or you could possibly do a U turn after the final rotations). I'm guessing the reason most PLLs don't bother correcting the U-layer at the end is that its assumed that the U-layer won't be aligned correctly before PLL execution anyway, so the final AUF could be anything.

A good wee while ago I experimented with adjusting the U-layer before PLL so that the cube was solved without needing a final AUF, but I found trying to align the U-layer before PLL took longer than aligning the U-layer at the end of the solve for two reasons: (1) The recognition is slightly harder and (2) cube rotations are required.

 

[Jokerman5656]

I found the solution. use this alg... L U2 L U2 R' U L U L U' L' U2 R U2 L' U' L'