# OLL Naming and Reorganization



## Razgorth (Nov 20, 2016)

We need a new system for OLL naming and organization. The current number system is unintuitive and poorly structured, not to mention easily forgettable, while the other random names like "Zamboni" and "City" are even more difficult to remember and even potentially offensive ("Nazi"? Really?).






_Which OLL number is this? Most people probably have no idea, myself included._​*So I'm proposing a new OLL organization and naming system, built around the 2-look OLL patterns to smooth the transition between 2-look and 1-look OLL, and using naming structure derived from COLL for general coherency.*

This system hinges around the fact that *every single OLL is a combination of 2-look OLL's edges and corners. In other words, even if you only know 2-look OLL, you can already recognize every single OLL case. You just haven't been taught how.* Therefore, our main *orients* will be named after the 7 COLL sets.




is the *H orient*.



is the *PI orient*.



is the *U orient*.



is the *T orient*.



is the *L orient*.



is the *AS orient*.



is the *S orient*.​
Next, edge orientation will be delineated by simply specifying which edges are correctly oriented using the letters *B R F L*, except in the case of everything already correctly oriented, which will be just the edge orient name, and the dot case, which will be *DOT*. (*EDIT - *I think the dot case should be *O*, just because it's simpler. Also I main a Gans. ) If that didn't make much sense, here are some examples:



is the *T-BR orient*.



is the *PI-RL orient*.



is the *U-DOT orient*.



is the *L-BF orient*_.



_is the *S-RF orie-* wait, what?​So yeah, that's a problem we need to solve, one that the current system has not handled very well: namely, that we need a fixed orientation of the 7 OLL edge cases in order for the *B R F L* system to work properly. The *L-BF* example actually already shows this problem, but since the *L orient* is symmetrical, it ends up being the same case, assuming we adopt the current algdb OLL 25 orientation, which I actually do not suggest. I think the transition to COLL could be improved as well if we fix these orients according to the current COLL sets, or change the orientation of the existing COLL images.

In conclusion, I think this system is a more organized, more intuitive, and more streamlined approach to OLL naming convention than currently exists on sites like algdb. *The orient names are definitely not fixed, and neither are their current orientations (I'm too lazy to rotate the existing algdb images ).* They could even be changed entirely, assuming we make the COLL sets follow suit. The edge *B R F L *order can be changed: maybe *R F L B*?* F L B R*? *F R B L*? Doesn't really matter to me.* EDIT - *Actually the edge system is simple enough that you can write whatever order you want. It takes the same minuscule amount of time to process LB and BL.

The most important thing here is the idea, and I really hope that we can end up adopting this system or some derivative of it. It helps with both 2-look -> 1-look OLL and OLL -> COLL transition, adopts a somewhat unified naming scheme for last layer algs, and even helps people with OLL recognition: *once you understand that every OLL is just a fusion of OCLL + OELL from 2-look, you realize that you only have to look at the U layer pattern and a maximum of 3 other corner stickers for recognition of any OLL case, and potentially even just one other corner sticker.*

*tl;dr - The current OLL number system sucks, mine is better so support me. *

*EDIT - It seems some people are missing critical parts of this post. More highlights have been bolded and some edits have been made.

EDIT 2 - The other ideas in this post are just that: ideas. I am not saying you must use this recognition style. I am not saying you need to throw out the informal lightning bolt shapes, Z shapes, etc. that you are currently using. I am saying that my system is better than the current number system, and so we should replace the current number system. I am saying my system is better for communicating without misinterpretation than the informal shape system. Everything else is secondary.*


----------



## Razgorth (Nov 21, 2016)

Some thoughts on improved names and fixed orientations for the 7 edge cases: we should orient each case according to the popular 2-look OLL orientations to make it easier to learn. Also, naming should resemble PLLs so that we have some sort of continuity.





*E orient* - Fixed orientation should be with a y rotation so it resembles correct E-perm orientation.





*T orient* - Looks like a T-perm, keep the orientation.





This is the hardest one to name. Orientation is good for the alg, but it doesn't really look like a U perm at all.
Maybe *C orient*?





*I orient* - Keep the orientation.





*Y orient *- Rotate by y. Resembles a Y-perm in that two corners are wrong.





*A orient* - Resembles an A perm in that 3 corners need to switch. Also, A for *anti-sune*.





*S orient* - Sune is so well-known it makes no sense to change it.​


----------



## Daniel Lin (Nov 21, 2016)

Razgorth said:


> In conclusion, I think this system is a more organized, more intuitive, and more streamlined approach to OLL naming convention than currently exists on sites like algdb. The orient names are definitely not fixed, and neither are their current orientations (I'm too lazy to rotate the existing algdb images )


I agree with you 100%. I hate how algdb doesn't stick to one orientation
Doubt anything will change though


----------



## Razgorth (Nov 21, 2016)

Daniel Lin said:


> I agree with you 100%. I hate how algdb doesn't stick to one orientation
> Doubt anything will change though



No harm in trying. I think Stachu is working at the Cubicle, so if everyone who makes an order there puts this in the comments, he might get around to doing it sometime.


----------



## sqAree (Nov 21, 2016)

Okay, numbers might not be the perfect choice, I agree no one memorizes which case corresponds to which number. However, I dislike your approach as there already exists a popular way of naming OLLs by shapes (small/big lightning bold shapes, letter shapes, etc.) which is just perfect as it directly corresponds to the way we recognize OLLs (I don't think anyone recognizes OLL cases by their OCLL case).


----------



## Razgorth (Nov 21, 2016)

sqAree said:


> Okay, numbers might not be the perfect choice, I agree no one memorizes which case corresponds to which number. However, I dislike your approach as there already exists a popular way of naming OLLs by shapes (small/big lightning bold shapes, letter shapes, etc.) which is just perfect as it directly corresponds to the way we recognize OLLs (I don't think anyone recognizes OLL cases by their OCLL case).



I think we should be recognizing OLL by *top pattern and OCLL case*. All you have to do is recognize the 2-look cases at the same time. There are 4 possible edge orients (line, L, cross, and dot) and 8 possible edge orients (7 OCLLs and solved). Every single case is just a simple OCLL + OELL recognition. The idea is you never have to rotate to recognize the case, even for things like OLL 53-54 (*E-FL* and *E-RF*).

Also, please tell me the names of 47-50 and 53-54.

Also I just realized we need an all edges solved case. In that case, just omit the first letter.




is *BF orient*. Or *RL*, if you prefer.




is the real *DOT orient*.​EDIT - OLL 18-19 are also problems, 9-10, etc. Even 32 and 44 are problematic.


----------



## Dash Lambda (Nov 21, 2016)

Razgorth said:


> Some thoughts on improved names and fixed orientations for the 7 corner cases: We should orient each case according to the popular 2-look OLL orientations to make it easier to learn. Also, naming should resemble PLLs so that we have some sort of continuity.
> 
> 
> 
> ...


It's kind'a pointless to try to force naming continuity between OLL and PLL. They're just different.
And the names the OP gave for the corner cases are pretty commonly accepted and make sense. H because the corners make two parallel lines, Pi because the corners make two parallel lines with a hat, U because the corners make the two endpoints and it's kind'a easy to visualize the 'U' shape, etc...
So, I respectfully, but entirely, disagree.



Razgorth said:


> I think we should be recognizing OLL by *top pattern and OCLL case*. All you have to do is recognize the 2-look cases at the same time. There are 4 possible edge orients (line, L, cross, and dot) and 8 possible corner orients (7 OCLLs and solved). Every single case is just a simple OCLL + OELL recognition. The idea is you never have to rotate to recognize the case, even for things like OLL 53-54 (*E-FL* and *E-RF*).
> EDIT - OLL 18-19 are also problems, 9-10, etc. Even 32 and 44 are problematic.


The problem with that is that it's just not efficient. We recognize cases by shapes and patterns, and the fewer patterns we need to process the faster we are. If we force ourselves to process two separate cases, it'll be slower than just seeing one shape.
That is, unless you're saying we actually should recognize the pattern like normal and use COLL recog if there are hidden corners, which is just something you develop anyway.

While I love systematic naming conventions, I think your framework is a little too rigid to be practical. In the end, a string of letters (especially orientation-dependent) is just as bad as a number. There are a lot of OLL cases, so it's not like we can fit one to a letter like with PLL, so we just have to come up with good names (which we have for many of them, but not all).

-For 9-10: Those are "Kite" cases, and I think that name works great. They're mirrors, so I think it's perfectly reasonable to call them Kite-a and Kite-b.

-For 18-19: The names the wiki gives for those are "Crown" and "Bunny," but I don't really like those. I think they should both be called either "Bunny" or "Mickey" (the mouse, for obvious reasons), either being "Bunny-a" and "Bunny-b" or, since they're not mirrors, "Bunny-dot" and "Bunny-line," characterized by the row opposite the ears.

-For 31, 32, 43, 44: I think those should all be "P" cases, and they should be differentiated by "line" and "dot" as per the previous one and "a" and "b" for mirrors. So we have "P-dot" a and b and "P-line" a and b.

-For 47-50, 53, 54: I think those should all be "Angle," though I don't know how best to differentiate them. You can separate them into three sets of mirrors, and I'd personally call them "Long," "Short," and "L," characterized by the pattern on the sides, but I don't know how intuitive that is or how well it works for other people.

All in all, I do think our current OLL naming conventions are inconsistent and unintuitive to the point of uselessness, and you're definitely onto something, but I think you're trying to apply a little _too much_ structure.

I'll try to compile a complete list of the names I use internally pretty soon to post here, I'm curious to see what everyone else thinks of them.


----------



## AlphaSheep (Nov 21, 2016)

So that people know how the orientation was chosen for the cases on algdb.net, the images all just use the orientation for the first alg that was loaded for that case.

I think using the corners only as the first categorising feature is a bad idea. The first visible feature is the shape on top, which people have already given names like lightning, L, line, etc. Then you can categorise these by the corner twist as you would look at that second. That's how most people seem to group the cases anyway.


----------



## Razgorth (Nov 21, 2016)

Dash Lambda said:


> It's kind'a pointless to try to force naming continuity between OLL and PLL. They're just different.
> And the names the OP gave for the corner cases are pretty commonly accepted and make sense. H because the corners make two parallel lines, Pi because the corners make two parallel lines with a hat, U because the corners make the two endpoints and it's kind'a easy to visualize the 'U' shape, etc...
> So, I respectfully, but entirely, disagree.



I am the OP. I realize the current system makes sense, and that's why the first post had those naming conventions. I also think, however, that we shouldn't stagnate with what is commonly accepted if there is a potentially better alternative. I think that to an established cuber, suggested changes makes very little sense. To a new cuber, the fact that OLL and PLL have naming continuity is probably helpful.



> The problem with that is that it's just not efficient. We recognize cases by shapes and patterns, and the fewer patterns we need to process the faster we are. If we force ourselves to process two separate cases, it'll be slower than just seeing one shape.
> That is, unless you're saying we actually should recognize the pattern like normal and use COLL recog if there are hidden corners, which is just something you develop anyway.



I really don't think you've thought about this at all. Please explain to me how to recognize an OLL case with at least 2 unsolved corners by looking only at the top pattern. *It's not possible.* If you're saying look at top pattern + front face, I'm saying that's inefficient (also you still can't recognize most cases). You don't need to look at any of the edge orientations, because you know edge orientation from just looking at the top pattern. If we count in terms of stickers, all you need to know are the 9 top stickers and one sticker each from 3 corners to recognize OLL. *Don't look at the full front block, right block, left block, etc. It's not necessary.*



Dash Lambda said:


> While I love systematic naming conventions, I think your framework is a little too rigid to be practical. In the end, a string of letters (especially orientation-dependent) is just as bad as a number. There are a lot of OLL cases, so it's not like we can fit one to a letter like with PLL, so we just have to come up with good names (which we have for many of them, but not all).



I respectfully disagree. You'll end up with at least 15-20 different names instead of an intuitively understandable 1-3 letter set.



> -For 9-10: Those are "Kite" cases, and I think that name works great. They're mirrors, so I think it's perfectly reasonable to call them Kite-a and Kite-b.



Which one is Kite-a, which one is Kite-b? More importantly, how do you enforce the distinction?



> -For 18-19: The names the wiki gives for those are "Crown" and "Bunny," but I don't really like those. I think they should both be called either "Bunny" or "Mickey" (the mouse, for obvious reasons), either being "Bunny-a" and "Bunny-b" or, since they're not mirrors, "Bunny-dot" and "Bunny-line," characterized by the row opposite the ears.



Now you've hit the problem on the head: you don't like those. What if people don't like Bunny or Mickey? What if they want to call it V or Peace Sign?



> -For 31, 32, 43, 44: I think those should all be "P" cases, and they should be differentiated by "line" and "dot" as per the previous one and "a" and "b" for mirrors. So we have "P-dot" a and b and "P-line" a and b.



Here is another issue: why are you bothering with line and dot? What if you can't see the line or dot? Do you waste time rotating or AUFing, or do you just recognize by OCLL? Assuming you do do OCLL, even subconsciously, why not just do that all the time?



> -For 47-50, 53, 54: I think those should all be "Angle," though I don't know how best to differentiate them. You can separate them into three sets of mirrors, and I'd personally call them "Long," "Short," and "L," characterized by the pattern on the sides, but I don't know how intuitive that is or how well it works for other people.



Again, you claim that my system is rigid and impractical, but don't propose a good alternative. Honestly, using my system, I can probably write out all 57 OLL cases in about 5 minutes, without needing to consult a wiki or try to figure out which one I'm missing, and it will be immediately understandable to even a non-cuber so long as I show them the 7 OCLL pictures and the edge orientation idea. I really don't see how you would achieve anything remotely close to that with an arbitrary shape naming system.



AlphaSheep said:


> I think using the corners only as the first categorising feature is a bad idea. The first visible feature is the shape on top, which people have already given names like lightning, L, line, etc. Then you can categorise these by the corner twist as you would look at that second. That's how most people seem to group the cases anyway.



What I'm suggesting is that cases are grouped by OCLL because you can derive subsets from that. Instead of having OLL as one giant, menacing block of 57 algs, you can have OLL H, OLL Pi, etc. There is very little rhyme or reason as to the current sequence of OLL algs that flows well beyond a group of 2-4 algs.

It also facilitates recognition for people coming from 2-look. If you only know all of the OLL U cases, for example, you can see if it's a U orient: if so, try to remember the alg, if not, just 2-look it.


----------



## Razgorth (Nov 21, 2016)

As a demonstrative exercise, please name the OLL solved by this alg without consulting any sources (I tried to choose a common one): *F (R U R' U') (R U R' U') F'*. Don't use algdb, don't use a wiki, don't Google, don't look at notes, don't even tab away from the thread. Just try to think of the OLL number, the wiki name, and then the name under my system (okay fine the system is in the thread, but the idea is that I don't blatantly provide this name and its accompanying picture, so you're still figuring it out yourself). Which one is easiest?

EDIT - I'll even provide the picture.



Now even those of you who use 2-look could probably name this using at least _one method hint hint_.


----------



## sqAree (Nov 21, 2016)

Yeah, I agree that with using shapes we still run into the issue of distinguishing between cases when there are many of one shape. I'm personally not too bothered about mirrors and such; after all for PLL we also use Jb and Ja for instance.

I don't know how you think OLL recognition works, but it's more or less one look to recognize the case, when turning slightly slower than usually I think most cubers can predict the OLL case a few turns before reaching it. After knowing the top pattern in most cases there is like one side sticker left to look at to know the case and it's easy to memorize which side sticker to use after knowing the top pattern.

The great advantage of our PLL naming system is its intuitivity and that it works with images. It's easy to assign a letter to a pattern there. Your naming system requires us to count unoriented edges and the OCLL case which might be efficient in terms of stickers (granted) but not intuitive and, contrary to instant shape recognition, requires us to built the picture in our head step by step. I'd say it's easy for everyone to link a shape name with its shape (so the according case).

Furthermore I'd like to point out that I still use 2-look OLL for 2H solving at least so I guess I can speak on behalf of people who want to do the transition between 2L and 1L. Your system is kinda discouraging, and also I think it's inherently not a good idea to use 2L methodology for the transition.


----------



## stoic (Nov 21, 2016)

This feels like one of those worthy ideas that crop up every now and again but end up going nowhere. (Fingertrick notation, anyone?) 

A lot of the OLLs already have names; well, according to the wiki they do, but most of them I never notice anyone using. So is there a need? Anyone learning full OLL is already free to learn the names if they so wish without learning a system to predict them, and that doesn't strike me as too much work. 

I respect how much effort you've put in but it seems like you're solving a problem that isn't really there. I'd suggest you don't expend too much more effort at this stage unless the community starts to take this and run with it.



Razgorth said:


> As a demonstrative exercise, please name the OLL solved by this alg without consulting any sources (I tried to choose a common one): *F (R U R' U') (R U R' U') F'*. Don't use algdb, don't use a wiki, don't Google, don't look at notes, don't even tab away from the thread. Just try to think of the OLL number, the wiki name, and then the name under my system (okay fine the system is in the thread, but the idea is that I don't blatantly provide this name and its accompanying picture, so you're still figuring it out yourself). Which one is easiest?
> 
> EDIT - I'll even provide the picture.
> 
> ...



I don't know the name of this case; however I can "see" in my mind what algs I'll use to solve it depending on orientation. I don't know that I'll ever *need* to name it, and therein lies the problem. For me, at least.


----------



## Oatch (Nov 21, 2016)

I agree that a better naming/categorisation scheme would make the learning and recognition process for OLL simpler. Breaking down larger alg sets into subsets can really help with this - as with COLL, basing them on the OCLL cases. However, I'm not a CFOP solver myself, so I have not really delved into or really attempted at all learning full OLL, so the current system of shape-recognition may already be sufficient - but, with a bit of work, this idea does seem promising.


----------



## 1973486 (Nov 21, 2016)

Razgorth said:


> As a demonstrative exercise, please name the OLL solved by this alg without consulting any sources (I tried to choose a common one): *F (R U R' U') (R U R' U') F'*. Don't use algdb, don't use a wiki, don't Google, don't look at notes, don't even tab away from the thread. Just try to think of the OLL number, the wiki name, and then the name under my system (okay fine the system is in the thread, but the idea is that I don't blatantly provide this name and its accompanying picture, so you're still figuring it out yourself). Which one is easiest?
> 
> EDIT - I'll even provide the picture.
> 
> ...



"F double sexy F prime".


----------



## Dash Lambda (Nov 21, 2016)

Razgorth said:


> I am the OP.


Whoops, didn't read the username XP

To respond to most of what you're saying, a naming convention shouldn't be something you have to think about. You should be able to say the name naturally just by seeing the case, and vice versa. Descriptive names based on shapes and patterns satisfy that, but adding any cognitive steps between an image and a name makes the name less effective. Case recog, of course, is another matter and discussion entirely, and isn't something you can base a universal naming convention off of.

Oh, and for mirrors, it doesn't matter what's a, b, c, d, etc. because they're the same case. We just need to decide which one is which and keep that consistent on paper, in conversation people will normally just leave the letter out.


----------



## Razgorth (Nov 21, 2016)

sqAree said:


> I don't know how you think OLL recognition works, but it's more or less one look to recognize the case, when turning slightly slower than usually I think most cubers can predict the OLL case a few turns before reaching it. After knowing the top pattern in most cases there is like one side sticker left to look at to know the case and it's easy to memorize which side sticker to use after knowing the top pattern.



This is true for most cases if you look at one or two specific side stickers. If that sticker is hidden, you need to AUF to find it.

*OLL recognition is eventually one-look, yes. Just like how PLL recognition is eventually 2-sided, OLL should be 2-sided as well from every angle. My point is simply that a lot of people incorporate the sides of the edges into that one-look. The sides of the edges are useless. Why? Because by looking at the top pattern, you already know the orientation of all edges.*

I am not saying that one-looking OLL is impossible. I am saying that for someone just starting to learn OLL, it is entirely possible that _they need to break down the OLL case in their head_. How many people developed perfect OLL recognition after a day? Or perfect PLL recognition after a day? I'll bet that even Faz didn't. *I am not forcing you to not one-look OLL. I am explaining what you should be looking at to one-look OLL. I've simply divided it into two steps because it's really uninformative to say " its ez just check the top pattern and OCLL simultaneously".*

Here's an example.



The tentatively named *H-BR orient*. OLL 54. According to the wiki, "Anti-Frying Pan". How do you recognize this case, assuming you can only see the top, the front, and the right side? Well the pattern on top tells you it is one of 6 possible OLLs. The left and right front edge stickers are not the top colour, narrowing it down to 2 possible OLLs. *You have to look at the back sticker on the right side to determine OLL case. The fact that there is a "dot" edge on the front tells you nothing. Don't look at it then.*



sqAree said:


> The great advantage of our PLL naming system is its intuitivity and that it works with images. It's easy to assign a letter to a pattern there. Your naming system requires us to count unoriented edges and the OCLL case which might be efficient in terms of stickers (granted) but not intuitive and, contrary to instant shape recognition, requires us to built the picture in our head step by step. I'd say it's easy for everyone to link a shape name with its shape (so the according case).



Really? Tell me, which part of the Gabcd classification is intuitive? If I go to a random person on the street and show him 4 G perm images, how do I explain why Ga is Ga and not Gb? Again, to reiterate, *shape recognition is fine. However, just knowing the shape does not tell you which OLL case it is most of the time.*



sqAree said:


> Furthermore I'd like to point out that I still use 2-look OLL for 2H solving at least so I guess I can speak on behalf of people who want to do the transition between 2L and 1L. Your system is kinda discouraging, and also I think it's inherently not a good idea to use 2L methodology for the transition.



Please, humor me. Try the system for a week. Then tell me the issues with it.



stoic said:


> A lot of the OLLs already have names; well, according to the wiki they do, but most of them I never notice anyone using. So is there a need? Anyone learning full OLL is already free to learn the names if they so wish without learning a system to predict them, and that doesn't strike me as too much work.



There are a few extra benefits to knowing the name. Let's say you're skimming example solves on cubesolv.es, or reading a deconstruction, and someone uses an unfamiliar, or obscure, OLL alg. Which case did they solve? With my system, instead of simply writing OLL next to the OLL step, you can know which case it is immediately, without needing to look up the number or run the alg through Cube Explorer.

There was a video on Youtube of Keaton Ellis and Kim Jokinen (IIRC, it's the Euro 2016 vlog posted by the Cubicle's channel) where, for fun, they were blindfolded and each had one hand on the cube. Jayden McNeill was their "spotter", so to speak, and when they got to OLL he called out, "Stealth Bomber!" Keaton knew which case it was, Kim had no idea wtf Jayden was talking about. (The video's pretty funny by the way, there's more OLL shenanigans in the other blind team solves as well.) I'm not saying that this situation will occur every other day, I'm just saying that having an easy way to talk about individual OLLs is conducive to better communication. *People used to think that being colour-neutral was a pointless waste of time as well. This is much easier than switching to colour-neutral.*


----------



## Razgorth (Nov 21, 2016)

Dash Lambda said:


> To respond to most of what you're saying, a naming convention shouldn't be something you have to think about. You should be able to say the name naturally just by seeing the case, and vice versa. Descriptive names based on shapes and patterns satisfy that, but adding any cognitive steps between an image and a name makes the name less effective. Case recog, of course, is another matter and discussion entirely, and isn't something you can base a universal naming convention off of.



This is why I'm saying that you should try the system out. Go down the list of OLL algs, name each one using the shape system, then name it using my system. *I can even name 4x4 OLL parity cases using my system. Intuitively. Within a half second. It's that easy.*



> Oh, and for mirrors, it doesn't matter what's a, b, c, d, etc. because they're the same case. We just need to decide which one is which and keep that consistent on paper, in conversation people will normally just leave the letter out.



And this is why some people don't know which case is actually Ga, which is Gd, etc. Which case is this?



I know which one it is, but I had to memorize that information. *You don't have to memorize any specific cases with my method except for the 7 OCLL orientations.*

But specific orientations are too much work, you say. And letters are just arbitrary! None of our other naming systems require specific solving orientation or letter schemes! Oh wait. *PLL does. PLL demands you orient the cube in a specific way for each alg that you use and requires you to memorize a total of 13 letters, not including mirrors. My OLL system uses 7 + 4 + 1 dot case = a total of 12 unique letters, for 57 cases, including mirrors.*


----------



## sqAree (Nov 21, 2016)

Razgorth said:


> Here's an example.
> 
> 
> 
> The tentatively named *H-BR orient*. OLL 54. According to the wiki, "Anti-Frying Pan". How do you recognize this case, assuming you can only see the top, the front, and the right side? Well the pattern on top tells you it is one of 6 possible OLLs. The left and right front edge stickers are not the top colour, narrowing it down to 2 possible OLLs. *You have to look at the back sticker on the right side to determine OLL case. The fact that there is a "dot" edge on the front tells you nothing. Don't look at it then.*



Hm, no matter what recognition method one uses, in the end we still have to look at 3 edges and 3 corners at least? When solving I have full vision on top, front and right anyway, so no AUF needed and I can instantly spot the case.
Sure, I agree looking at UF twice (once for the top pattern, and once when looking at the front) is useless. But the good thing about top pattern recognition is that after it you have to look at 3 more side corners stickers at most, and one less for each oriented corner because we already saw it on the top.



Razgorth said:


> Really? Tell me, which part of the Gabcd classification is intuitive? If I go to a random person on the street and show him 4 G perm images, how do I explain why Ga is Ga and not Gb? Again, to reiterate, *shape recognition is fine. However, just knowing the shape does not tell you which OLL case it is most of the time.*



Sorry, I confused something and thought you said the PLL naming convention already makes sense. The letters are intuitive, but the mirror classification is not, you're right.



Razgorth said:


> Please, humor me. Try the system for a week. Then tell me the issues with it.



Hm, difficult, as their is no need to name certain OLL cases most of the time. At least for me, very rarely. So the possible issue that might come up is the delay that occurs when trying to encode a case into its name and vice versa. Your system is more accurate than current systems but also requires more time I'd say.


----------



## Dash Lambda (Nov 21, 2016)

Razgorth said:


> *OLL recognition is eventually one-look, yes. Just like how PLL recognition is eventually 2-sided, OLL should be 2-sided as well from every angle. My point is simply that a lot of people incorporate the sides of the edges into that one-look. The sides of the edges are useless. Why? Because by looking at the top pattern, you already know the orientation of all edges.*


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.



Razgorth said:


> This is why I'm saying that you should try the system out. Go down the list of OLL algs, name each one using the shape system, then name it using my system. *I can even name 4x4 OLL parity cases using my system. Intuitively. Within a half second. It's that easy.*


I've already tried naming a few, even just in understanding your system you need to construct a few names. I've already explained the thing about intuition and speed.



Razgorth said:


> And this is why some people don't know which case is actually Ga, which is Gd, etc. Which case is this?
> 
> 
> 
> ...


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.


----------



## Razgorth (Nov 21, 2016)

sqAree said:


> Hm, no matter what recognition method one uses, in the end we still have to look at 3 edges and 3 corners at least? When solving I have full vision on top, front and right anyway, so no AUF needed and I can instantly spot the case.
> Sure, I agree looking at UF twice (once for the top pattern, and once when looking at the front) is useless. But the good thing about top pattern recognition is that after it you have to look at 3 more side corners stickers at most, and one less for each oriented corner because we already saw it on the top.



This is what I've been trying to say the whole time, just in a different way. And no, you only have to look at 3 corner stickers for the H and Pi cases. *For every other OCLL case, you only need to look at one corner sticker. ONE. TOP PATTERN + ONE STICKER. BOOM. MIND BLOWN.*


----------



## Razgorth (Nov 21, 2016)

Dash Lambda said:


> 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 (Nov 21, 2016)

Razgorth said:


> 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.



Razgorth said:


> 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 (Nov 22, 2016)

Dash Lambda said:


> 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.



Noyes_Maybe said:


> 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.
> 
> ...



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 -


Dash Lambda said:


> 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 (Nov 22, 2016)

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.



Razgorth said:


> 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.



Razgorth said:


> 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.
> 
> ...


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 (Nov 22, 2016)

Dash Lambda said:


> 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 - 


Dash Lambda said:


> 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 (Nov 22, 2016)

Razgorth said:


> 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.



Razgorth said:


> 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.



Razgorth said:


> 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.



Razgorth said:


> 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.)



Razgorth said:


> 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.



Razgorth said:


> 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 (Nov 22, 2016)

Dash Lambda said:


> 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.



Dash Lambda said:


> 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.



Dash Lambda said:


> 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 -


Dash Lambda said:


> 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 (Nov 22, 2016)

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 (Nov 22, 2016)

Razgorth said:


> -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 (Nov 22, 2016)

Dash Lambda said:


> 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.


----------

