OLL Naming and Reorganization

[Razgorth]

When I see a 'dot' on the side, it's not the difference between a dot and no dot, it's the difference between a dot and a line. I already know the edge is there, what I'm looking at is the corners, and on a low level it's faster to process the presence of one thing than the absence of two.
Not that that matters for a naming convention, though, because recog is different from communication. It just so happens that it's easy to assign names based on the shapes you recognize in OLL. We don't name PLL cases in terms of headlights, opposites, adjacents, bars, and blocks, we names them by overall shape.

You're not processing the presence of one thing. You're processing the state of 3 individual stickers, whether subconsciously or not. I am saying that you only need to process the state of 2 of those stickers, even just 1 for every case that is not H or Pi. If at least one corner is already solved, you only need to look at one non-top sticker to recognize the OLL case, regardless of what colour that sticker is, as long as you understand which sticker to look for.

I don't know which G case is which, but I can use them just fine. You only need to say "G-perm" in conversation, and when you make a table or something you can just look it up. You don't need to memorize them.
And for orientation, there actually isn't a standard orientation. Depending on the alg you use, you start from different orientations.

You can use them just fine because, whether you like it or not, you've memorized that alg's orientation and differentiated that G perm from all the other G perms. I'm simply proposing a more intuitive way of differentiating similar cases.

As an example, some friends I taught to solve the cube had no idea which G perm was which. So I told them "hold the headlights on the left, look for the bar location." So they learned 4 G-perms: G-F, G-RF, G-RB, and G-B. Much more intuitive than Ga, Gb, Gc, and Gd. Actually the names corresponding to order I listed would be Ga, Gd, Gb, and Gc. Because that totally makes sense.

 

[Dash Lambda]

You're not processing the presence of one thing. You're processing the state of 3 individual stickers, whether subconsciously or not. I am saying that you only need to process the state of 2 of those stickers, even just 1 for every case that is not H or Pi. If at least one corner is already solved, you only need to look at one non-top sticker to recognize the OLL case, regardless of what colour that sticker is, as long as you understand which sticker to look for.

I actually am.
The stickers as distinct entities is up a layer of abstraction. First you recognize the color and basic physical aspects of an object (distance, size), then the relative dimensions of the object, then its shape, and then you start to recognize precise edges and components, only after that point can you distinguish entities and their states explicitly. When I look for a dot, a short line, or a long line, I see a dot, a relatively small off-center line, or a big line, and don't bother thinking past that because I already have all the information I need.

You can use them just fine because, whether you like it or not, you've memorized that alg's orientation and differentiated that G perm from all the other G perms. I'm simply proposing a more intuitive way of differentiating similar cases.

As an example, some friends I taught to solve the cube had no idea which G perm was which. So I told them "hold the headlights on the left, look for the bar location." So they learned 4 G-perms: G-F, G-RF, G-RB, and G-B. Much more intuitive than Ga, Gb, Gc, and Gd. Actually the names corresponding to order I listed would be Ga, Gd, Gb, and Gc. Because that totally makes sense.

There are lots of different ways I recognize the G-perm depending on the situation.
In general, if I can see the bar on the G-perm, if the colors around it are opposites then I start the alg by pushing on the end of the bar, and if they're adjacents then I cut the bar in half going up on its side, and the rest of the alg follows because I have a feel of how it flows.

The thing is, one of the primary concepts of speedsolving is that you have to think as little as possible. Condense everything down to visual cues, shapes, colors, make everything that goes through your head as simple and direct as possible. What you're talking about is a layer on top of immediate pattern recognition, which is exactly the opposite of what you need to do.
It's not like you're completely wrong, most of the things you're talking about do factor into normal recog (at least mine), but they're not treated as separate because incorporating them into the entire picture at once is more efficient. These are things that people develop and account for naturally through practice, like only seeing FTL pairs (for CFOP) and reducing algs to muscle-memory.

But I reiterate: "Not that that matters for a naming convention, though, because recog is different from communication. It just so happens that it's easy to assign names based on the shapes you recognize in OLL. We don't name PLL cases in terms of headlights, opposites, adjacents, bars, and blocks, we names them by overall shape."

 

[Razgorth]

I actually am.
The stickers as distinct entities is up a layer of abstraction. First you recognize the color and basic physical aspects of an object (distance, size), then the relative dimensions of the object, then its shape, and then you start to recognize precise edges and components, only after that point can you distinguish entities and their states explicitly. When I look for a dot, a short line, or a long line, I see a dot, a relatively small off-center line, or a big line, and don't bother thinking past that because I already have all the information I need.

Once again, to reiterate. If it is a dot or big line, you do not have all the information you need. There is more information required: a third sticker from a corner. I agree that eventually, it becomes second nature and you just see the pattern. But for learning purposes, it is much easier to break it down and see it that way.

I am not forcing you to use my system for recognition. I am proposing this system mainly as categorization and communication. If you feel like your recognition works for you, then by all means do it. You do not need to suddenly abandon your current OLL recognition because of my system.

Let's say that in ten years, everybody somehow magically learns 1LLL. Somehow. Then, when people say "1LLL is just predicting the PLL following the OLL" are you going to reply "no that's silly just look for the pattern"?

Cubing is a gradual buildup of skills that eventually mesh together. Why bother learning beginner's edge insertion instead of learning F2L? Why bother learning 2-look OLL or PLL when 1-look recognition is possible? Because you have to start somewhere. Because nobody can just pick up a cube and be sub-10.

There are people who are sub-10 with 2-look OLL. There are people like Collin Burns who are very fast, but know very few alg sets. But does that make full OLL or other alg sets useless? Does that mean full OLL is not efficient? No.

Objectively speaking, looking at a top pattern + 3 stickers is less visual information to process than top pattern + 2 side edge blocks of 6 stickers each. This is not an opinion. This is a fact. A 2x2 has less states than a 3x3. Some people are faster at 3x3 than others are at 2x2. Does this mean that 3x3 is easier than 2x2?

But I reiterate: "Not that that matters for a naming convention, though, because recog is different from communication. It just so happens that it's easy to assign names based on the shapes you recognize in OLL. We don't name PLL cases in terms of headlights, opposites, adjacents, bars, and blocks, we names them by overall shape."

It seems we are in agreement then. Recognition is different from communication. My system is better for communication than any of the existing ones.

I linked to this thread on reddit, and someone made a very good comment that I'd like to repost here.

I am a total newb but let me offer this thought: There's a lot of disagreement here about whether all OLL cases should be named using OP's formal system, or using informal English names. Can I offer the possible reality that choosing an alternative formal scheme does not mean abandoning any informal names people have to help them remember? I'm guessing that people now use the formal names to look up algorithms in a database, whereas they use the informal names for largely mnemonic purposes. Thus, formal and informal naming schemes can and do coexist and are by no means mutually exclusive.

There is no doubt that OP's system is better than "OLL cases 1-57," the latter of which tells the user literally nothing about each case. If I, as a beginner, have questions about a certain OLL case and can reliably use a formal name, even if it is a string of letters that is not immediately intuitive, then that will be a huge benefit over the current system. If the new system offers predictability so that once I understand the system, I can then predict the name and search for it without having to sort through 57 different pictures, then that is, to my mind, perhaps the most important attribute for an OLL naming system.

Searching the internet for the formal case, I would hopefully then see some results referring to the case's informal name(s), which would help me as I try to commit the case to memory.

Thus, my two cents is that, rather than being worried about having to abandon informal names, everyone should work together on adapting OP's system (or an alternative, but OP seems to have given a lot of careful consideration to this issue) into something usable as a formal system so that we can get rid of the useless number names as soon as possible.

This is what I wanted to achieve. This is exactly what my goal is. You can keep calling your OLLs whatever you want. But this is a means to unify naming so that if you're trying to talk to someone else about OLLs, there is no confusion and both of you know exactly what the other is referring to.

EDIT -

There are lots of different ways I recognize the G-perm depending on the situation.
In general, if I can see the bar on the G-perm, if the colors around it are opposites then I start the alg by pushing on the end of the bar, and if they're adjacents then I cut the bar in half going up on its side, and the rest of the alg follows because I have a feel of how it flows.

I do the same. I'm not thinking "this is Gb" or this is "G-RB" in my head when I see a Gb perm. However, what if you're just starting to learn G perms? "Oh this is a G perm. Which alg was it again? I have no clue." vs "Oh this is a G perm. The bar is on the right back side, so it's a G-RB perm. Which alg was it again? I forgot." The second situation is better because at least you've managed to differentiate which of the four cases it is, even if you still don't remember the alg. You don't even have to know the name of the perm beforehand: as long as you can recognize it is a G perm, you can figure out the type of G perm. With Gabcd, if you don't remember the specific order, you're just guessing.

 

[Dash Lambda]

Note: In the interest of being constructive, I'm gonna stop arguing about recognition. I still disagree (Grrr...), but I have a nasty habit of latching onto irrelevant parts of a discussion and diverting from the main topic, a habit I need to work on.

Cubing is a gradual buildup of skills that eventually mesh together. Why bother learning beginner's edge insertion instead of learning F2L? Why bother learning 2-look OLL or PLL when 1-look recognition is possible? Because you have to start somewhere. Because nobody can just pick up a cube and be sub-10.

I don't see 2-look OLL/PLL, beginner's F2L, keyholing, or anything like that as an actual step. I consider them degrees of progress, because you can't immediately learn everything in a set.

It seems we are in agreement then. Recognition is different from communication. My system is better for communication than any of the existing ones.

I linked to this thread on reddit, and someone made a very good comment that I'd like to repost here.

-quote-

This is what I wanted to achieve. This is exactly what my goal is. You can keep calling your OLLs whatever you want. But this is a means to unify naming so that if you're trying to talk to someone else about OLLs, there is no confusion and both of you know exactly what the other is referring to.

That guy makes a damn good point that I'm surprised I didn't actually think of.

In that context, your naming system still doesn't work well though. It can, but we have to find a way to resolve the rotation issue and condense the names a little. I'm not sure how best to go about that.
Using a suffix to identify edge orientation I think sort of necessitates that, at least if you use R, L, F, and B. I think leaving it blank for no correctly oriented edges works well (So just "Pi"), and I think "Plus" for all oriented edges works well (So "Pi-Plus"), but for directional shapes it doesn't hold up. Maybe if you hybridized it with shape names, like turning "S-LF" into "S-Block," but I don't know how I'd standardize that...

I just read your edits to the original post, and yes, this is better than the number system, because it actually identifies the case, whereas the numbers just assign unrelated names. It just needs some work.

 

[Razgorth]

In that context, your naming system still doesn't work well though. It can, but we have to find a way to resolve the rotation issue and condense the names a little. I'm not sure how best to go about that.
Using a suffix to identify edge orientation I think sort of necessitates that, at least if you use R, L, F, and B. I think leaving it blank for no correctly oriented edges works well (So just "Pi"), and I think "Plus" for all oriented edges works well (So "Pi-Plus"), but for directional shapes it doesn't hold up. Maybe if you hybridized it with shape names, like turning "S-LF" into "S-Block," but I don't know how I'd standardize that...

The rotation issue is easy to resolve. Standardize fixed rotations based on most popular OCLL algs.

Why do you need plus for all oriented edges? The all edges oriented case is the OCLL alg, so just name it the OCLL alg. It doesn't make sense to make the OCLL case Pi-Plus but have the dot case be the default OCLL name, because the OCLL alg doesn't solve the dot case.

You're still thinking about shape names. My names are at most four letters long, assuming we condense stuff like Pi into P and AS into A. The four letter ones are because of the DOT name: if we replace that with something like X or O, then the maximum length is 3 letters.

I really believe that this is the most elegant solution. You have two possible OELL cases for line and 4 possible OELL cases for L shape. Add in a dot case and that's 7 levels of differentiation. Sure we could have 7 different letters and make people memorize which one corresponds to which line or L case. Or we could just do it by cube face notation, which people know already.

My system names cases based on OCLL, of which there is already an accepted naming (although I don't think it's a very elegant one) and simple edge orientation. With 12 different letters total, it provides complete information about 57 different cases plus all possible parity OLL cases, in a 3 letter package, of which two letters (the edge orientation) are completely intuitive, assuming you know basic cube notation. If you don't, then you can't even learn alg execution unless someone physically shows you what to turn.

Please explain what you find wrong with the system objectively. Please don't tell me "the existing system works, so we don't need to fix it". Please don't tell me "I don't like it", without a concrete reason other than because it is out of your comfort zone. Please explain to me why 3 letters is too many, when we have stuff like Gabcd. I really don't understand any of the issues you seem to see with it.

EDIT - Pi-Plus is also six letters long. S-Block as well. Pi-Block would be 7. Really? You suggest shortening the names, then suggest that a better name should be potentially more than twice as long as the proposed ones? You're contradicting yourself now.

EDIT 2 -

I don't see 2-look OLL/PLL, beginner's F2L, keyholing, or anything like that as an actual step. I consider them degrees of progress, because you can't immediately learn everything in a set.

I don't see CFOP as an actual step. I consider it a degree of progress, because you can't learn to solve the cube with God's algorithm immediately.

Learning is a gradual process. Do you consider everything below differential calculus "not really math", because it's just progress? Do you consider someone who takes ESL classes "unable to speak English" because he or she does not have adequate command of the language? Do you consider a runner who isn't Usain Bolt "not a real runner", because he is not the best in his field? Do you think Jabari considers OLL and PLL "not steps" because he thinks it should be CF1L?

 

[Dash Lambda]

The rotation issue is easy to resolve. Standardize fixed rotations based on most popular OCLL algs.

That doesn't really fix the problem. You don't make something independent of rotation by standardizing rotation.
I don't know how you'd fix that, but I still see it as a problem.

Why do you need plus for all oriented edges? The all edges oriented case is the OCLL alg, so just name it the OCLL alg. It doesn't make sense to make the OCLL case Pi-Plus but have the dot case be the default OCLL name, because the OCLL alg doesn't solve the dot case.

Fair point, it would work either way but the OCLL cases are already established like that.

You're still thinking about shape names. My names are at most four letters long, assuming we condense stuff like Pi into P and AS into A. The four letter ones are because of the DOT name: if we replace that with something like X or O, then the maximum length is 3 letters.

We're not talking about maximizing storage space or anything like that, the number of letters doesn't really matter. What matters is how easily it's interpreted and used by people.

I really believe that this is the most elegant solution. You have two possible OELL cases for line and 4 possible OELL cases for L shape. Add in a dot case and that's 7 levels of differentiation. Sure we could have 7 different letters and make people memorize which one corresponds to which line or L case. Or we could just do it by cube face notation, which people know already.

My system names cases based on OCLL, of which there is already an accepted naming (although I don't think it's a very elegant one) and simple edge orientation. With 12 different letters total, it provides complete information about 57 different cases plus all possible parity OLL cases, in a 3 letter package, of which two letters (the edge orientation) are completely intuitive, assuming you know basic cube notation. If you don't, then you can't even learn alg execution unless someone physically shows you what to turn.

Please explain what you find wrong with the system objectively. Please don't tell me "the existing system works, so we don't need to fix it". Please don't tell me "I don't like it", without a concrete reason other than because it is out of your comfort zone. Please explain to me why 3 letters is too many, when we have stuff like Gabcd. I really don't understand any of the issues you seem to see with it.

I'm not arguing that the number system is better, I'm just saying that the rotation issue kind'a gets in the way. The entire problem I have the the face-notation for the edges is based on the fact that you have to assume the rotation of the corners.
And, of course, I have to point out that there's a difference between intuitive and structured. (Neither is bad, they're just different.)

EDIT - Pi-Plus is also six letters long. S-Block as well. Pi-Block would be 7. Really? You suggest shortening the names, then suggest that a better name should be potentially more than twice as long as the proposed ones? You're contradicting yourself now.

Okay, I invited this misunderstanding. When I talk about condensing the names, I mean reducing the number of components, not the number of letters. Like replacing the two separate face letters with a single one or two syllable word, like "Angle," "Line," "Bar," or something like that.

EDIT 2 - I don't see CFOP as an actual step. I consider it a degree of progress, because you can't learn to solve the cube with God's algorithm immediately.

Learning is a gradual process. Do you consider everything below differential calculus "not really math", because it's just progress? Do you consider someone who takes ESL classes "unable to speak English" because he or she does not have adequate command of the language? Do you consider a runner who isn't Usain Bolt "not a real runner", because he is not the best in his field? Do you think Jabari considers OLL and PLL "not steps" because he thinks it should be CF1L?

Oi, don't get clever XP
CFOP is a complete method (with extensions and whatnot, but there's a clear distinction between base and auxiliary), so there's a clear "complete" state and a clear "incomplete" state.

As for the rest: There's a spectrum of fluency with languages, I think of runners the same way I think of speedcubers (You don't have to be the fastest to be one, you basically just have to try to do it fast), I don't really know what Jabari thinks, though I am a bit of a snob with math. I hate arithmetic and elementary algebra, so I don't like to call them "math" just because that associates them with the higher level stuff that I really, really like.

 

[Razgorth]

That doesn't really fix the problem. You don't make something independent of rotation by standardizing rotation.
I don't know how you'd fix that, but I still see it as a problem.

Wow. Just wow.

Here's a sample story. My car has wheels. "Sir, please stop your car from moving." "Okay, let me put it in park and set the handbrake." "Sir, your car still has wheels. Therefore it can still move." "But I've put it in a fixed position!" "Sir that doesn't really fix the problem. Your wheels are still capable of rotation."

OLL cases are dependent on OCLL orientation. This is a fact. There is no way of fixing this short of ensuring OCLL is always solved after F2L.

I'm not arguing that the number system is better, I'm just saying that the rotation issue kind'a gets in the way. The entire problem I have the the face-notation for the edges is based on the fact that you have to assume the rotation of the corners.
And, of course, I have to point out that there's a difference between intuitive and structured. (Neither is bad, they're just different.)

An intuitive system is one where you can infer a previously unknown case based on a systematic approach, without the need for a table of all possible cases or prior knowledge of the specific case. My system handles OLL parity with ease, something that no currently existing system comes even close to doing, in an elegant fashion. My system is intuitive, because using a set of rules, I can generate a name for all possible OLLs on a cubeshape puzzle assuming it is in a solvable state, without the need for naming a case beforehand.

Okay, I invited this misunderstanding. When I talk about condensing the names, I mean reducing the number of components, not the number of letters. Like replacing the two separate face letters with a single one or two syllable word, like "Angle," "Line," "Bar," or something like that.

Alright. Come up with a list of all the words required. You can even use two words together, like Angle-Bar. I guarantee you the list will be more than 4. The face letters are fundamental notations. Why is this hard? Why are B R L F difficult to understand? Do you also complain when people refer to the FR edge? Or the BD edge?

This is like complaining that + - * / is hard to remember. We should be writing 5 plus 7, 8 divided by 2 multiplied by 9.

EDIT -

CFOP is a complete method (with extensions and whatnot, but there's a clear distinction between base and auxiliary), so there's a clear "complete" state and a clear "incomplete" state.

I don't even...

Alright, explain to me the clear "complete" state of the cross. Is it when you can match the cross pieces? Is it when you can always do an xxxxcross? Or the "complete" state of F2L. Is it when you can VLS every time? Oh wait but that would skip OLL. OMG GUYS CFVLSP. What about ZBLL? What about other deliberate OLL skips? CFOP describes an approach to solving the cube, an idea, not a fixed system of steps.

I feel like you're being even more rigid than my system at this point.

 

[Razgorth]

Alright, I'm going to compile a list of all of the OLLs using current COLL notation, but replacing Pi with P and AS with A. Orientations are fixed at the popular OCLL algs. I've also realized something: there is no need for a fixed B R F L order. It's simple enough that you can just write BF or FB, or RF or FR. Here it is.

BL RL DOT
H H-DOT H-BR H-RF H-BF H-RL
P P-DOT P-BR P-RF P-FL P-BL P-BF P-RL
U U-DOT U-BR U-RF U-FL U-BL U-BF U-RL
T T-DOT T-BR T-RF T-FL T-BL T-BF T-RL
L L-DOT L-BR L-RF L-FL L-BL L-BF L-RL
A A-DOT A-BR A-RF A-FL A-BL A-BF A-RL
S S-DOT S-BR S-RF S-FL S-BL S-BF S-RL

As you can see, there are 8 cases each of 6 OCLLs, plus 6 H cases because H is symmetrical on two axes, and 3 solved OCLL cases. ezpz

EDIT - This also provides several good learning orders. You can learn all the cases of one OCLL first. You can learn all the line (BF and RL) cases first. You can learn all the dot cases first. You can even learn all the L shapes first, although that's a much larger starting list. Thus, even if you don't know full OLL, you can realize if you know a case or not by just looking at OCLL or edge orientation, depending on how you want to approach learning the algs.

 

[Dash Lambda]

-snip-

This discussion has long outlived its usefulness. You're twisting my words and being defensive and I'm repeating myself and nitpicking at pointless minutia. I'll stop before we waste too much of each other's time.

 

[Razgorth]

This discussion has long outlived its usefulness. You're twisting my words and being defensive and I'm repeating myself and nitpicking at pointless minutia. I'll stop before we waste too much of each other's time.

Agreed. I think there is some confusion here, but for the life of me I can't spot where the misunderstanding is. I do apologize for the more ad hominem comments. Just getting a bit frustrated because I can't understand the points you're trying to make. I'm sorry about that.