Welcome to the Speedsolving.com, home of the web's largest puzzle community! You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

I have created a table of PLL combinations. As you may know, when you perform two PLLs in a row, you will end up with a third one. What is this third PLL, I wondered?

In fact I wanted to make a way for a PLL attack to end in a solved cube, but that 'puzzle' I haven't solved yet. Of course that also depends on your cube rotations and personal PLL set.

Pls add comments and point out mistakes. I also have the program that generated this is if someone is interested. I'll post it in the software area.

How to read: perform PLL in first column, perform PLL in top row, you'll end up with the PLL in the corresponding cell.

if you do it like that you should add AUFs in between. so there will be 72 PLLs + 72 PLLs which makes a really big grid.
but its a difference between [randomPLL1] [randomAUF1] [random PLL2] and [randomPLL1] [randomAUF2] [random PLL2]

PLL1+PLL2=PLL3+AUF
Where AUF is a combination of (y,y',y2),(U,U',U2)

Another option is

PLL1+AUF+PLL2(+AUF)=PLL3

However, that is not as nice to perform. Here's the full output list so you can compare and see for yourself. Not all of these are included in the table.

The problem is that the combined result of two PLL may depend on the algs you're using, because PLL algs of the same name only have the same effect up to AUF. Say for example that I use an alg which swaps two opposite edges and rotates all 4 corners clockwise on the U layer. That's a Z perm, but with this alg, I will get Z+Z=H, not Z+Z=id. That's why whauk suggested you the 72*72 grid.

The problem is that the combined result of two PLL may depend on the algs you're using, because PLL algs of the same name only have the same effect up to AUF. Say for example that I use an alg which swaps two opposite edges and rotates all 4 corners clockwise on the U layer. That's a Z perm, but with this alg, I will get Z+Z=H, not Z+Z=id. That's why whauk suggested you the 72*72 grid.

Are you saying you ignore any U moves at the end of your PLL's? I don't have a problem with two Z's cancelling each other out (same with all the PLL's that aren't cycles (or alternate)), but my Z ends with a U' which I'll always do (in PLL Time attacks anyway, I'll miss it out in a solve if I know I don't need it).

I use PLLs onlly for BLD, and I thus can't ignore the U moves anyway or else I will get a DNF. But that's not my point. My point is that you have to define precisely what a Z-perm is (is it what I described or a double adjacent edge swap ? In the second case, is it (UF UR) (UB UL) or 'UF UL) (UB UR) ?), or else Michiel's grid is jst meaningless.

Yeah, that is a good point, I guess there are lots of different orientations, but I'm guessing it means, do an alg (from which ever orientation you choose) then repeat it.

Yeah, there are really some problems with this approach, because the exact orientation of the algs you used is (a) different than what someone else's might be, and (b) going to affect the final result. So then you get weird things like Aa+Ab = solved, but Ab+Aa = not solved. If you really want to make a table like this, it would only be useful if you list every possible result (for instance: E + Aa = Aa/Ab). Also, of course, you should replace #N/A with "solved" or "I" (for identity).

PS: If you want a PLL attack that cancels out, start by getting rid of groups of algs that cancel out, and then just do a brute force search on the last couple. For instance: Ja/Jb/Ra/Rb, Ga/Gb/Gc/Gd, Na/Nb/H, Ua/Ub, Aa/Ab, and then V Y Z E T F left. (No guarantees this one works )

Yeah, there are really some problems with this approach, because the exact orientation of the algs you used is (a) different than what someone else's might be, and (b) going to affect the final result. So then you get weird things like Aa+Ab = solved, but Ab+Aa = not solved. If you really want to make a table like this, it would only be useful if you list every possible result (for instance: E + Aa = Aa/Ab). Also, of course, you should replace #N/A with "solved" or "I" (for identity).

PS: If you want a PLL attack that cancels out, start by getting rid of groups of algs that cancel out, and then just do a brute force search on the last couple. For instance: Ja/Jb/Ra/Rb, Ga/Gb/Gc/Gd, Na/Nb/H, Ua/Ub, Aa/Ab, and then V Y Z E T F left. (No guarantees this one works )

R' U2 R U2 L U' R' U L' U L U' R U L' [V]
R2 U R' U' y (R U R' U')*2 R U R' y' R U' R2 [E]
R' U R U' R2 y' R' U' R U y x R U R' U' R2 x' [F]
y2 R U R' U' R' F R2 U' R' U' R U R' F' [T]
F R U' R' U' R U R' F' R U R' U' R' F R F' [Y]
y M' U M2 U M2 U M' U2 M2 [Z]

I realized everyones concerns beforehand. I cannot reasonably create a table that contains all possible orientations of all algorithms into account. It's (y',y2,y)*(U',U2,U)=9 combinations. That makes 21*9=189 horizontal and vertical. It becomes unreadable. qqwref is right, but I don't understand whauk's 72. Explain?

Everyone is right that the result is somewhat personal since it is based on the orientations of my own PLL set. Still I wouldn't call the current table 'useless'.

You could adapt and run the program with your own algorithms to get a personal table. I didn't make an interface for this (yet).

There are only 4 combinations for each pairing, because you don't care about AUF after both algorithms. (So between your algorithms you have: no rotation, y, y2, y'.) But some algorithms don't change when you do a rotation, and if you count solved, you find 72 possibilities. Don't worry about that number though.

I think the current table really is kinda useless because it's completely dependent on the exact algorithms you've chosen, which will be different for other people. Anyway I don't expect you to have 189 horizontal and vertical, that would be completely stupid and inefficient. As I said before (maybe not completely clearly): you should keep the 21x21 table setup, but each cell should have up to 4 entries, for the 4 possible ways to combine the two PLLs. (You don't need to list the same outcome more than once, for instance H+Z = always Z, so just list that once.)

If the goal is to find a sequence for a PLL attack to end up with the cube solved, I would think you would want to avoid any extra unnecessary cube rotations or AUFs. So what really matters is how the algs a given person uses permutes the LL cubies.

So I would assign a unique number (0..287) to each of the possible 288 permutations. (There are algorithmic ways to calculate such a number from a permutation.) Then you just need to build a 288 x 21 lookup table giving the result of applying each of the permutations of the 21 algs that you use to the 288 possible arrangements. Then the search routine just has to do a simple table lookup to apply each PLL.

Actually, the algs could leave the bottom 2 layers rotated. If so, you would also have to track the state of the bottom 2 layers if you want to be sure the U layer is rotated consistently with the bottom 2 layers at the end.

Let's say you want to do each "letter" as a set. There are 13! (over 6 billion) different orderings you can use for the letters. It would seem quite likely that at least one of these would result in the 1 of 288 possibilities that you want (corresponding to the last layer being correctly permuted). Actually, if your algs collectively correspond to an odd permutation of the corners (or edges) with respect to the bottom 2 layers, then you will need to have at least one AUF to correct for that.

It's quite cool ending a PLL time attack in a solved state, but I really don't think anyone should do that, I think the PLL's should be ordered so that you can efficiently move from one to another (for example in my list I have the G's all over the place cause they are great for changing between some common right hand orientations). As an alternative, why not see if you could come up with a pre PLL that when you do the time attack will end in a solved state.

1. Do your PLL time attack sequence
2. Look at the final permutation and figure out which PLL solves the cube
3. That PLL is your 'setup' to a solved time attack.

(Thanks, Chris Hardwick, for your BLD post-mortem method! )

Yeah, I thought that would be the case, but when I tried it out it didn't work, but I must have messed up somewhere cause I just went again and it worked fine

I implemented my idea anyway. As a test case, I just used the "canonical PLLs" as shown in the Wiki (that is, taking its arrow diagrams literally). The routine calc_plls can be changed to use different angle cases and/or different AUF cases.

For this test case, I got over 45 million letter orderings that create a no AUF result. (I note that in the Wiki, the Ua and Ub are inverses, as are Ga and Gb, and Gc and Gd. So the placement of U and G in the letter ordering doesn't matter. Ignoring G and U there are over 290000 orderings for the remaining 11.) So I would say there may be enough orderings that work (result in a solved cube) that you can probably find one that works flows good" for you as well as leaves the cube in a solved state. If you like scattering the G's, example, the search routine could be changed to allow for such. 21 factorial orderings would be too large a search space to do a brute force search, though.

I note that as is, this program generates an immense amount of output. You are hereby warned. The PLLs are defined in the calc_plls routine. I didn't create code that converts an alg into a permutation number. Instead, permutations are defined directly in terms of swaps and 3-cycles. The program then (by default) tries to apply all 13! possible letter orderings. It uses a fixed order of the PLLs for each of the letters.View attachment PllAttack_cpp.txt