Algebraic PLL recognition

CarlBrannen

Veteran
Joined
May 6, 2012
Messages
367
Location
Pullman, WA
WCA ID
2013BRAN01
So I've decided to learn 1-look PLL. The first problem seems to be recognition.

It's a fact that all the cases can be completely recognized from seeing only two edges (five cubies). There's some code that helps you figure it out quickly. But my mind does algebra very quickly. For example, I orient the last 2 edges of the 7x7x7 based on a 3-digit number I get by watching the orientations unfold.

So I'd like to see if I can develop a way of doing PLL recognition based on an algorithm that works with the view from two edges.

The algorithm needs to say (a) which PLL case, and (b) how much to rotate U before you apply the case.

Has this been done before? If so I'd appreciate a note here.

I'll put what I find here.
 
I recently learned full PLL, and the recognition from four faces is actually quick and easy. What's more, I have found that I'm starting to anticipate the case from the first two faces I look at, without deliberately learning two-face recognition. For example I'll see the first two faces after OLL and "know" it's a J perm, so glancing at the second two faces is just a quick verification. I guess the colour patterns are becoming familiar, although I could not tell you what they are.

Anyway, it doesn't address your question, I just mention it because it seems to me that two-face recognition emerges naturally with practice, to an extent.
 
It seems like you want to make 2-side PLL recognition way more complicated than it needs to be. IMO the best way it just to memorize all 72 cases. Developing an algorithm or a code so that in order to determine the case and AUF quickly sounds terribly impractical.


It's a fact that all the cases can be completely recognized from seeing only two edges (five cubies).
*faces

Edge means something else.
 
Last edited:
But my mind does algebra very quickly. For example, I orient the last 2 edges of the 7x7x7 based on a 3-digit number I get by watching the orientations unfold.
Can you give an example? I assume that would also help anyone who wants to help you make a similar system for PLL. Also, is this actually faster for you than normal pattern recognition for others? Or do you just really like doing it this way?

IMO the best way it just to memorize all 72 cases.
I think he's trying to do this, just in his own way (which would presumably involve additional time/information since there is no obvious pattern to PLL naming/AUF with respect to stickers).
 
The algorithm needs to say (a) which PLL case, and (b) how much to rotate U before you apply the case.

You don't apply a case. You apply a maneuver. The same case may have many maneuvers, and different maneuvers for the same case may require a different U rotation (except H-Perm and N-Perm NEVER require the LL to be turned before applying the maneuver) for the same arrangement of the LL pieces. So you must decide what you're maneuvers are for each case before you can talk about what U rotation is needed before applying the maneuver.
 
Yeah, I mean "six stickers". And different people's minds work differently. For me, it works best to apply an algorithm. Then it eventually becomes automatic.

As a first step in defining an algorithm, it's useful to immediately know the required corner permutation. These are the cases (which correspond to the 2x2x2 I guess):

Assume front and left are visible.

Divide the permutations according to what they do to the corners, ignoring edges, and ignoring rotations. Then the cases are:

1) Two sets of headlights:
Corners are done (done, H, U, Z)

2) Headlights on left or right only, or
no headlights and exactly one pair of opposite colors:
swap an adjacent pair of corners as in F, R or T, or do a 3-swap as in A, G, J so (A, F, G, J, R, T)

3) No headlights, both with opposite colors:
Swap across pairs as in E or across diagonal as in N, V, or Y so (E, N, V, Y)

So I end up renaming the permutations to match how I think of them in terms of what they do to edges and corners.

Rather than describe them as looking like letters, it's a matter of the permutations they do to the edges and corners. For example, on edges, H, U and Z are:

H = (13)(24)
Ua = (134)
Ub = (143)
Z = (14)(23)

where (1,2,3,4) are (green, orange, blue, red) or (orange, blue, red, green), or etc.

I work faster if I convert everything to numbers.
 
Last edited:
I don't think learning PLLs in terms of numbered cycles and abstract sticker patterns is the best idea :| I mean, you can continue if you want, but if you're doing this for speed you would have a much better result by just learning the block-style recognition most people use. It's a lot faster than you might think - doing a little rotation (or simply using lookahead to figure out a few extra pieces during OLL) doesn't take much time at all. Basically, I'm just skeptical that this approach will end up faster than a more traditional way of doing things.
 
Oh I am quite sure this approach will be no faster than a more traditional way of doing things for almost no one but me. It's just the only way I can approach the problem. I have to understand what I'm doing at a theoretical level. Otherwise I'm quite slow at picking things up. Eventually it becomes second nature.

Right now I'm doing a slightly abbreviated version of 2-look PLL. That is, I just added H and Z and I'm making E with two As. So when I look at the LL I need to address which of (none, H, Ua, Ub, Z) I need. Right now I don't have a decent way of doing that. Instead, I rotate the LL until some edge lines up. Then I compare two more edges to see what I have to do. It makes something in me wince every time I do it. I'm sick of it, which I guess is how people recognize that it's time to improve their algorithms or recognition.

Tonight I'll see if I can make a reasonable recognition system for 2-look PLL.

[I suppose I should add that I'm a very theoretical person. For example, see: https://privatelee.qrobe.it/search/?q=brannen+neutrinos+site:arxiv.org&s=sbv2 ]
 
Last edited:
Okay I've made some progress.

I'm using the front and right sides of the cube.

There are six "stickers" visible and each can be of 4 colors so the total number of cases can't be larger than 4^6 = 4096. But the front right top cubie has two stickers visible and if you see one you know the other. This reduces it to 1024 cases.

Of those 1024 cases, only 256 can appear in a legal cube.

By cycling the colors you can reduce those 256 cases by a factor of 4 to 64 cases.

Those 64 cases are what I need to recognize. Each implies a U rotation and a PLL algorithm, but some of them are shared.

So to learn them, I think I'll start with a "standard" orientation for the front right top cube of orange on left, blue on right. (In my cube coloring scheme, these two colors are "metallic" and easier to pick out.)

To learn those 64 cases I'll always rotate U untilI get that green/orange cubie front and right, then figure out what algorithm is needed. After I've got the orange/blue cases under my belt I'll add the red/green cases. And then the remaining cases.

So given the orange/blue at FR, there are 4^4 = 256 possibilities for the remaining 4 stickers. But only 64 of these are legal. The remaining 192 are what we call in digital electronics "don't cares". To get an optimal algorithm, I'll code up the don't cares in such a way that it minimizes the amount of thought required to classify the 64 that matter. To optimize the encoding, I'll probably want to redefine the standard permutations.

For example, my Z-perm already is different from the definition given in the wiki here on speedsolving. Instead of a Z-perm I actually do U followed by a Z-perm. This is because M' is faster for me than M so I do (M2 U M2 U M' U2 M2 U2 M' U2) instead of (M2 U M2 U M U2 M2 U2 M U2). So I'll choose perms that fit naturally with a pattern for what U rotation has to precede them. That is, the first thing you have to do (for most perms) is make a U rotation so I'll make the coding for those U rotations as simple as possible by modifying the permutations appropriately.

This is going to be a lot of work but it looks like fun.
 
There are six "stickers" visible and each can be of 4 colors so the total number of cases can't be larger than 4^6 = 4096. But the front right top cubie has two stickers visible and if you see one you know the other. This reduces it to 1024 cases.

Of those 1024 cases, only 256 can appear in a legal cube.

By cycling the colors you can reduce those 256 cases by a factor of 4 to 64 cases.
Lol what? You must be doing something wrong because there are 72 cases (6 possible corner orientations * 12 possible edge orientations for each one).

So to learn them, I think I'll start with a "standard" orientation for the front right top cube of orange on left, blue on right. (In my cube coloring scheme, these two colors are "metallic" and easier to pick out.)

To learn those 64 cases I'll always rotate U untilI get that green/orange cubie front and right, then figure out what algorithm is needed. After I've got the orange/blue cases under my belt I'll add the red/green cases. And then the remaining cases.
If possible, I'd suggest learning the cases in terms of relative colorings ("F color", "R color", "these two colors are opposite", etc.). If you do it the way you're planning it sounds like you'll end up having to learn the same thing multiple times, because most permutations can be colored in 4 ways. Also, although I see what you're trying to do, doing U turns to set up the case kind of defeats the purpose of recognizing PLL with only two faces :p
 
Your count for 72 situations is correct, I forgot the 8 Ua/Ub cases. Undoubtedly I've got other errors. I'll eventually iron them out.

The idea here is to first learn with a standard corner, and then (maybe someday) learn the other corners. I can look ahead the orange/blue corner during F2L so it's not a matter of searching for it. (And you can easily see where it is by looking at the six visible "stickers".) But after doing some calculations, my guess on this is that going to orange/blue recognition will get me fast enough for what I want. Basically what you're saying is "go color neutral", but that's going to be a choice that really depends on the person. I'm figuring that my recognition will be a lot faster with fixed methods.

Letting 0=orange, 1=blue, 2=red, 3=green, these are the 72 possible configurations, and which perm they correspond to:

000111) done
000121) Ua
020111) U Ua
010131) U2 Ua
010121) U' Ua
030111) Ub
030101) U Ub
020101) U2 Ub
000131) U' Ub
020131) H
010101) Z (my non standard)
030121) U Z
220132) Aa
300113) U Aa
010122) U2 Aa
310121) U' Aa
200112) Ab (my non standard)
320133) U Ab
020102) U2 Ab
330101) U' Ab
210123) E
230103) U E
000132) F
320111) U F
210102) U2 F
310103) U' F
030122) Ga
320101) U Ga
230102) U2 Ga
200123) U' Ga
310133) Gb
020132) U Gb
310131) U2 Gb
200132) U' Gb
010132) Gc
330112) U Gc
230112) U2 Gc
310123) U' Gc
320131) Gd
220102) U Gd
320113) U2 Gd
020102) U' Gd
200133) Jb
000122) U Jb
200333) U2 Jb
200122) U' Jb
330111) Ja
220112) U Ja
330113) U2 Ja
000112) U' Ja
200133) Na
220113) Nb
210132) Ra
330103) U Ra
030112) U2 Ra
310101) U' Ra
010102) Rb
200121) U Rb
210122) U2 Rb
320103) U' Rb
330123) T
020112) U T
300131) U2 T
230122) U' T
220103) V
200113) U V
230133) U2 V
230103) U' V
220133) Y
230113) U Y
230123) U2 Y
200123) U' Y
 
Last edited by a moderator:
Back
Top