How OLS for CFOP could be developed intelligently

[ottozing]

A few disclaimers before I begin:

• I want to make it clear that with this potential OLS tool I have in mind, the UI/UX would be nearly identical to what Kirjava developed for doing 1LLL with 2 algs that are considered nice to execute, but also with some additional features and probably some more complex code. I highly recommend learning more about it by clicking here and following the rabbit-hole until it makes sense to you
• I don't have any background in coding/programming/developing & I'm sure that what I'm proposing won't be easy to put together correctly. I'm a speedcuber who screwed around all of highschool and dropped out of university after one year. I'm just an ideas guy who's main credential is being a high level 3x3 2H CFOP speedsolver who's arguably seen the most success using a high risk:low-medium reward solving style out of anyone. Much of this is due to the amount of random algs and tricks I know
• Nearly all of my examples will be given from a 2H CFOP-centric context. This is because 3x3 2H will always be the "main" event as long as speedcubing exists, it's the event I've put the most time into mastering, and CFOP is the method I've done so with. It also happens to be the most popular 3x3 2H method to this day, so the barrier to entry for understanding WTF I'm talking about will be as low as it can possibly be

Part 1: The two kinds of advanced subsets


When it comes to advanced subsets for any core 3x3 method, I've noticed that without fail, almost all of them suffer from "COLL syndrome", a term I coined a few days ago after discussing some stuff in a cubing discord server. More specifically, they suffer from COLL syndrome when the advanced subset in question doesn't actually skip a step, but tries to make the next step "nicer". I have an old/bad video trying to explain it here if you're interested, but I'll do a quick writeup so you don't have to listen to me ramble for over 20 minutes

Whenever I say "COLL syndrome", I'm referring to the phenomenon where once a cuber learns full COLL and using full COLL every chance they get, their LL times actually slow down on average. This is because some cases have really slow algs relative to the base OLL alg, and unless you get a PLL skip (1/12 chance), the difference between doing a Uperm/Hperm/Zperm VS doing any other PLL isn't going to justify the time lost doing a slower alg. This means that cubers who want to get the most out of advanced subsets which don't actually skip steps NEED to be VERY CAREFUL with which cases they do & don't use

Recognition itself isn't the problem in most cases, since cubers can & have accidentally develop "partial CP vision" (I wish I had a better term for this, IYKYK) where they recognize the full OLLCP every time they do OLL at their preferred COLL angle, without even trying to. By extension, if you get good enough at recognizing COLL from every angle, you could get to a point where you have full "CP vision"

anyway, with that out of the way, it's my belief that for any method, the best advanced subsets are going to be ones that aim to skip an entire step, rather than aim to make the next step nicer, which brings me to ZBLL

ZBLL has for a long time been considered something of a "holy grail" within advanced CFOP, and for good reason. Assuming you can go into LL with all of your edges oriented without wasting too much time during last pair, you can do one of 400something algs to get a PLL skip

It's taken a very long time for the algorithms to get developed in line with modern hardware, but at the time of doing this writeup, many notable cubers are of the opinion that at the very least, every non Sune/Antisune ZBLL set is worth it in full (though H and especially Pi are notably trickier to master)

Even if (hypothetically speaking) S/AS ZBLL is never considered worth it in full, you always have the option to do the fastest possible OLL cases into PLL. This makes getting your LL edges oriented before LL a desirable outcome, and there are even some specific OLLCP cases where cubers will do EO>ZBLL (usually only the U, T, and maybe L sets) instead of OLL>PLL

Point being, ZBLL has proven itself to be a good option, because even if you don't don't do ZBLL for S/AS, you still have a good option, which now brings us to Option Select (I hate that I coined this term since it's just an incorrect bastardization of how professional fighting game players describe covering multiple options at once, but it's caught on now and most advanced cubers generally know what the term means. My b lmao xd)


Part 2: Option Select & how it could be used to make OLS actually viable if done carefully


Let's move back to the idea of subsets that skip an entire step. I don't want to do another writeup on why OLS recognition itself isn't too bad, but just take my word as someone who has learned/used VLS in high level solves that recognition isn't the reason VLS kinda sucks

That's not to say that I think OLS recog (same recog system as VLS but applied to different F2L cases) is ever going to be as passive as CP recognition is, but I think that there's a ton of potential to get around this creatively. Namely, finding ways to deal with cases that have 3 misoriented LL corners in the LL and no nice 1x2 corner edge pairs, cases that don't have "immediate" recognition compared to something like the R U2' R' U R U2' R' U R U2' R' OLS, which has "immediate" recognition

Spoiler: Example of how this could be done

Grab 3 3x3's (or nxn's 3x3 and above) to follow along

Setup 1 - R' F' U' F U R U2 R U' R' U' R U R'
Setup 2 - R U' R' U R U' R' F R' F' R F R' F' R U R U' R' U' R U R'
Setup 3 - F U2 F' U' R' F R U' R' F' R U2 R U' R' U' R U R'

Some would argue that it's "objectively optimal" to learn an individual OLS alg for all 3 of these cases

Personally, I see two very different possibilities that make much more sense for humans

Notice that all 3 of these OLS cases look very similar

More specifically, they all have the same CO case (2 U layer corners oriented in the front & the UBL corner facing the left), and they have 1/3 LL edges in the U layer oriented

Point being, in a real solve, it would be very easy to confuse these three cases

So, what's better than learning 3 separate algs that probably have nothing in common with each other?

I see two ways you could go

#1 - you do R U' R' U R U R' and have a 2/3 chance of a really good OLL case, and a 1/3 chance of a bad OLL case
#2 - you do R U R2' D' R U R' D R and guarantee either the R U' R' U' M' U R U' r' OLL, or the M' U' M U2 M' U' M OLL, both of which are really really fast and some some interesting properties

Option one is very simple and sensible, but you do run the risk of getting a pretty bad OLL. Over time you could potentially learn to differentiate that case from the other 2 and get the best of both worlds

That said, option 2 is pretty cool since for one, those OLL's have the unique property of making PLL prediction very easy (since all they do is cycle 3 edges around)

In the event of a CP skip, you could also just do ELL, and I believe that most (if not all) of the non-dot ELL cases have good algs nowadays

Lastly, if you have a daigswap of CP, you could do a 6 move FRURUF variant to guarantee U 2GLL, and in my personal opinion, U ZBLL is the best of the 7 ZB sets (T very close behind), and U 2GLL is certainly the best of the 6 COLL sets you can get with U

If you're still not convinced that full algorithmic OLS isn't optimal for humans, I really don't know what to tell you

anyway, the real core issue with VLS is the fact that a significant portion of the algs aren't that nice, and assuming the cuber in question knows full UTL ZBLL, there are a LOT of cases where it's straight up better to do a clever EO insert that's fast to execute like R B U' B' R' or M' U R U' r' to specifically force UTL ZB cases. In the future, if H and/or Pi ZB gets worthwhile enough, you could open up even more freedom, or just bypass VLS recognition entirely for some EO sets (notably the R' F R F' set)

That being said, as someone who has both used VLS at high level & has occasionally used obscure OLS tricks like L R U2' R' U' R U R' U L' or R2 D R' U R D' R2', I've always felt that OLS has too much potential to completely write it off as being impractical

I just don't think that the path forward is going to be as simple as having an algorithm for every case, since recognition and recall issues would make such an approach more time than its worth (and that's ignoring the hundreds of hours of wasted human productivity needed to create such a list over a period of probably several years)

I think the best approach would be compiling a list of OLS algs over time that are very clearly worth it, and then filling in the blanks with smart Option Select's

Also, FWIW, I have similar feelings about OLLCP. I think that on a case by case basis, some OLLCP's are best done with an OLLCP alg, others are best done with OLL>PLL, and others are best done with EO>ZB in some fashion

For 1LLL, because the recognition gets even more complicated, I'm not convinced that Kirjava's suggested approach will be the way to go. I think that for cases where the 1LLL has "immediate" recognition, you could do an alg or approach that is entirely specific to that case (F R U R' U' R2 D R' U R D' R2' U' F' is an example I love for this). For cases where the recognition isn't immediate, I think my OLLCP OS idea would suffice, and you could fill in the blanks from there


Part 3: The actual idea I have in mind for some OLS OS AI thingamabob


With LSLL in a CFOP solve, there are a handful of non-pure OLS approaches that I think could still be worth it, so long as the alg needed to reach that state isn't total ass

Some OS examples that come to my mind:

• Forcing EO for ZBLL
• Forcing low movecount OLL's
• Forcing OLL's that have above average execution speed (Basically the same as above)
• Forcing OLL's that have easy ways to predict PLL via ROLL/JOLL
• Forcing the R U R' U' M' U R U' r' & M' U' M U2 M' U' M OLL's which have good options outlined in the earlier spoiler-hidden example
• Setting up VLS cases that are guaranteed to be worthwhile using the traditional VLS alg>PLL approach
• Instead of solving the LS, solving the last slot edge while orienting the rest of the cube to do TTLL (Requires TTLL algs to actually be good)
• Same as above but including TTLL+ and TTLL- (Also requires the algs to actually be good... This one in particular I'm quite interested in since if you get lucky with an EP skip, you can do two [R' D' R , U] style comms to finish the cube ridiculously quickly. Feliks has notably done this in a few official solves including at least one sub 5 single)

That's pretty much the essence of my vision for an OLS OS finder. I'm sure more possible OS's could be added, existing ones could be tweaked, and OS's that have proven to be sucky could be removed or just ignored

Similar to how speedcubedb lets users add their own algs which get popularized/scrutinized via an upvote downvote system, I would want this to be something that could eventually operate without needing a central admin maintaining things (basically something decentralized to avoid new good ideas not being able to see the light of day)

If anyone has coding experience & is interested in trying to take this massive project on, but you feel like some of my ideas are going over your head, feel free to DM my SS account and I'll get back to you

 

[Athefre]

Last year I proposed an LL and LSLL system that would be a kind of 2-3 step situation based method. The vision I have is that everything would be based on recognition and good algorithms. LSLL "types" would be split. These LSLL types would be easy to spot things such as all edges oriented, corners oriented a certain way, easy to see solved groups of pieces, and so on. And among those LSLL sets there would be the best ways to proceed determined by the computer analysis. So you would have an easy to recognize case with a good algorithm followed by another easy to recognize case with a good algorithm.

Spoiler: Original proposal

We can create custom, situation-based methods. These methods can be designed for low move-count, easy recognition, best algs, or any combination. Instead of steps always being the same, the steps would vary based on the current overall case. For example, imagine you've gotten to LL and you usually do CLL+1 then L3E. However, maybe analysis has shown that for a certain group of cases under which the current case falls it would instead be faster and more efficient to solve the case into an L3C state.

So a large scale analysis would be done for LL, LSLL, and anything else. The best paths would be identified for groups of cases. Users would know algorithms from several methods including CLL+1, OLL, 22LL, ELL, and so on. Users wouldn't know every algorithm from these sets - only whatever has been identified as part of this situation-based method. Users would be able to execute the best overall set of moves for each situation.

Spoiler: Details from main post

Situation Based Methods: This a new method proposal of mine and would be the optimal application of the system. In these methods, there wouldn't be predefined steps like OLL then PLL or CLL+1 then L3E. Instead, the LL method here would be a first step that uses the algorithm that produces the best result. This algorithm would set up for a second step that has a fast algorithm, a short algorithm, is easy to recognize, or any desired combination. The algorithm for the first step itself would also be optimized to contain these traits. This will produce an LL method that is computer optimized to be the fastest combination of steps while also containing a human manageable number of algorithms to learn, easy recognition, and easy recall. This wouldn't stop at LL methods. It can be applied to any step or group of steps. LSLL is another major application and there are many other methods with algorithm steps that could receive this benefit. There may even be situations where applying this to intuitive steps would produce good results. In this case it would be an analysis that was completed on the various possibilities within the intuitive step. This analysis would give the solver knowledge of which set of moves to solve a piece, pair, or block would produce the best results upon the other pieces that the solver is seeing in their lookahead. Many solvers are already deciding upon using different moves in order to influence surrounding pieces. So this would be the way to optimize that.

Intuition Reduction: Another interesting application would be to end every solve with an easy intuitive solution. Taking an edges oriented LL as an example, you could have an algorithm for each case or set of cases. This algorithm would reduce to one of several intuitive finishes. Endings such as R U' R', R U R', or R U2 R'. This would be versus learning all of ZBLL or using OCLL + PLL. So instead of methods always ending with algorithm based steps, they could end with a few moves that don't require any memorization and the final intuitive solution will be pre-known to the solver.

All of this would use the cycle union system that I discovered and developed last year. You are aware of Petrus 270 and Duplex. The cycle union system also combines algorithms, but in an infinitely expandable way and takes advantage of the properties of the cube to do much more than Petrus 270 and Duplex. It is much more than a "use a group of algs against the same group of algs" system. You can combine any algs in any number overlapped in any possible way. The biggest inclusion in the system is the discovery of the ability and a method to solve any x out of group y pieces. It also includes a way, a puzzle case crossing then situation discovery and selection system, for cases to be generated. I'm currently developing a program that will automate this process. Then a long term goal would be to have an online database and analysis system where users can input what they are wanting to do and the system will guide them toward the best LSLL (or any other step) approach based on what they want.

Algorithm Unions: A New Approach to Method Development

Introducing the Algorithm Unions There was a problem in method development which hadn’t yet been solved. Think about the LL methods and other algorithm-based steps that are commonly used. They usually do one kind of step at a time. COLL+EPLL solves the corners then the edges. OLL+PLL orients...

www.speedsolving.com

For just the OLS aspect, the same system above can likely be used. You can specify within the system the desired states that you want to achieve and the matching algorithms will be found.

 

[ottozing]

A few people DM'd me shortly after posting this thread so I'm pretty sure at least one person is working on building this specific OLS tool behind the scenes

In the meantime, I thought I'd share some general thoughts on a good way to start documenting practical OLS once the tool arrives just so I don't lose them

For recognition, I think dividing each case by the individual ZBLS case makes the most sense, since it seems that a lot of ZBLS cases are already worth it period, and the recognition is much better than full OLS since having 3 misoriented corners can be very annoying

From there, if you decide the ZBLS is worth it, you do ZBLS, and if not, normal insert into OLL

If there's more than one viable ZBLS or normal insert, switch between the 2-3 etc such that you maximize UTL ZBLL (could also throw S/AS in there) while using minimal recognition overhead (using one oriented corner in the U layer or a 1x2 block anywhere on the cube seems like the best case scenario), or in the case of normal inserts you maximize lower movecount OLL's with the same minimal addition to the recognition demands

In the case of pair solutions that happen to reduce to R U' R' you could also throw VLS into the mix. Ideally this would be done in a way where you don't really have to recognize OLS style twice unless the VLS recognition is very very easy, or the VLS cases you're getting are short enough to be worth it (or both)

Could maybe do the same for reductions to R U R' but HLS tends to be mostly miss & rarely hit. I would only consider this viable if it leads to like a 1/3 OLL skip chance and the other 2/3 you get UTL ZBLL

 

[PapaSmurf]

The biggest problem I see with OLS for CFOP is that good cases are a lot rarer than not (this is the same as with ZZ), so the bit of your brain that is focussed on reecognising orientation during last slot would be much better dedicated to EO rather than CO and EO. On the other hand, after solving with ZZ for a long time, you do definitely develop "CO vision". I often do OLSs that I've never learnt an alg for, but I recognise them by simply doing a lot of solves and knowing that if I finish the pair in a certain way (maybe insert with U2) I'll skip OLL. That's why it's definitely a viable thing in ZZ to know lots of random OLS cases, but I'm not sure how much that will carry over to CFOP (seeing as there are 8 times more OLS cases). Don't get me wrong, I think it would be great if this were possible and I'm a massive fan of any OLS that doesn't suffer from COLL syndrome, just it's gonna be a massive undertaking that may detract from other alternatives that may be more fruitful (such as optimising ZBLS/standard OS). Prove me wrong though!

 

[trangium]

Based on the assumption that in a solve it's easy to see which pieces are and aren't oriented (based on whether a yellow sticker is at the top) but hard to see which way a corner is misoriented, I compiled a list of the best (on average, according to the MCC, which approximates execution speed) way to insert each pair given just the top face, taking into account the speed of the insert and the average speed of the resulting OLLs. My findings can be found here. The numbers corresponding to each trigger is the average MCC of doing the insert and OLL if need be.