PLL Probability?

[TimMc]

Hi All,

Has anyone done the math for figuring out PLL Probability?

To narrow down the probability here's the only OLL algorithms that I use:
1) R' F' U' F U R (x1) (x2) (x3)
2) R U' L' U R' U' L (Niklas)
Special thanks to Werner Randelshofer for his Java Applet...

Some common PLL algorithms after my OLL seem to be:
- J Perm
- U Perm
- Z Perm
- T Perm
- H Perm

At the moment when I'm faced with a PLL case that I don't know I just do a J Perm and another algorithm in the list above to solve the cube. In theory it'd be faster to just do one short algorithm instead of two.

I don't know all PLL algorithms so I can't identify the other common cases after my OLL method. Knowing the exact probability would allow me to selectively learn few more algorithms to try to get near 20 seconds

Any help would be greatly appreciated!

Tim.

 

[cmhardw]

http://www.speedsolving.com/showthread.php?t=2394

And yes these probabilities describe the same ones as for using your OLL method.

Chris

 

[TimMc]

So...

PLL:
- G (4 algorithms)
- A J R U (including reflections)
- F T V Y
- E N Z
- H

EDIT: I'll start working on G A and R. I already know J U T Z H from that list

Tim.

 

[Swordsman Kirby]

Um the calculation for PLL probability goes way back:

http://www.ws.binghamton.edu/fridrich/Mike/permute.html

Or am I missing some crucial step?

 

[TimMc]

Or am I missing some crucial step?

I'm not sure of all the conditions for the calculated probability, e.g. the algorithms leading up to it.

Tim.

 

[tegalogic]

The OLL leading up to the PLL doesn't matter. Last layer cases for every OLL and PLL case combination is possible (I'm quite sure), you can create them using PLL then commutators to flip the corners and edges "individually" (paying attention to the law of the cube, of course).

 

[cmhardw]

The OLL leading up to the PLL doesn't matter.

What he means is were any influencing effects on the PLL done during the OLL step or not? Such as does the probability include the possibility that you used a COLL alg during the OLL step if the edges were oriented. This would leave an oriented OLL and the corners solved relative to each other. Or sometimes people form a 2x2x1 block in the LL during F2L, and then preserve that block during the OLL step which leaves fewer possible LL cases.

Chris

 

[TimMc]

Hmm, I just thought that always finishing OLL with Niklas all the time would have an affect on PLL probability...

Tim.

 

[tegalogic]

Oh, well, if an OLL was supposed to do a 3-cycle PLL for instance (above Niklas does UBL to UFL to UBR), the OLL could solved the orientation, but sometimes the target PLL (not symmetrical) was not reached because the PLL was not aligned correctly for the OLL (for example, UBR to UBL to UFR).
I'm not sure if this makes any sense, but... I'm guessing that the differences in probablility will differ very little.

 

[qqwref]

If you aren't deliberately trying to affect the PLL during OLL, it will remain random and the probabilities will remain the same. Of course some people will deliberately affect PLL in order to get a nicer one, which *would* change the probabilities, because then you make certain PLLs impossible to get in certain cases. For instance, if I have a Sune OLL but a solved 2x2x1 block, I'll do Niklas instead to preserve the block, which means I can only get A (1/3), J (1/3), V (1/6), or solved (1/6).

 

[TimMc]

If you aren't deliberately trying to affect the PLL during OLL

After Orienting the Edges if the case isn't Sune or Anti-Sune then I perform Niklas or Anti-Niklas to make it so. Then I perform Niklas or Anti-Niklas to have it ready for PLL.

I wouldn't say I'm deliberately setting it up like that. I just do it that way because I can perform Niklas faster than other OLL algorithms.

Tim.

 

[coopersacatfilms]

I would think it is the same for OLL