# APB - An efficient, ergonomic, algorithmic, 2x2x3 based method



## Athefre (Sep 17, 2021)

*APB Website*

*








Join the APB Discord Server!


Check out the APB community on Discord - hang out with 110 other members and enjoy free voice and text chat.




discord.gg




*​Here I am presenting a new method which efficiently reaches ZBLL without the requirement of efficient blockbuilding for most of the solve or the memorization of 400+ algorithms before ZBLL. The primary steps are:

*Step 1:* Build a 2x2x3 on the left.
*Step 2:* Create the F2L pair that belongs in the back (DBR + BR edge) and keep it on the U layer. This is 3-4 moves.
*Step 3 (EOPair):* Orient all edges while inserting the pair. There are 63 total cases averaging 5.76 moves.
*Step 4 (LXS):* Solve the final three pieces (FR + DR edge + DFR corner). This step contains 116 algorithms averaging around 8.59 moves.
*Step 5:* ZBLL

The recommendation is to always create the back pair (dBR) in Step 2. This provides the best recognition for the proceeding steps and is also the most efficient option. It is also possible to create the 2x2x3 in the back in APB. This is actually the most efficient overall but has R r U M ergonomics for the LXS step versus all R U if the block is on the left. The algorithms for 2x2x3 at db are also provided on the website. For LL, ZBLL is the ultimate goal. OCLL+PLL is also great to use with APB. Users would average 50-52 moves with that simple two step LL method.

In total versus alternatives, APB is efficient, requires many fewer algorithms, and is more ergonomic. The total average move-count considering a 12 move 2x2x3 and including AUFs for all steps is ~48 moves. This is achieved without requiring the memorization of a few hundred algorithms as in alternative methods such as Mehta. Comparing against the same method, APB's EOPair step contains 63 algorithms that are slightly more ergonomic and average the same move-count as the 56 EOLE algorithms. The LXS step contains 116 shorter, more ergonomic algorithms versus 350 longer, less ergonomic algorithms in TDR. Comparing to Petrus, there is no mid-solve recognition of seven edges, APB is more efficient, and is also more ergonomic due to the refined algorithms for each step. In Petrus a user can't always choose the most efficient or most ergonomic solution.

*Pros:*

More efficient than EO + last block in Petrus
Algorithmic for most of the solve. Everything after 2x2x3 can be algorithmic which would be 70-75% of the solve.
More ergonomic than algorithmic alternatives and intuitive blockbuilding
Expandable for further move-count reduction or for non-ZBLL use
Very easy to solve each algorithm step intuitively while learning
No rotation required
Can track EO while creating the pair
*Cons:*

Memorization versus intuition
Involves EO recognition. Requires checking the orientation of five edges similar to other methods.
Pseudo application for those that have an interest in using that means creating a pseudo pair. Creating a pseudo pair requires a different kind of recognition from a normal pair.
*Steps in Detail:

Step 1:* There are many ways to build a 2x2x3. The most well known option is 2x2x2 then expand to 2x2x3. Another way is to build a 1x2x3 on the L layer or D layer then add the two remaining edges with their centers. There are other ways of building a 2x2x3 so it may be best to choose the way that works best for the current scramble. As Trangium pointed out, the 1x2x3 then two edges option removes the necessity for efficient blockbuilding. And for an advanced solver, planning the full 2x2x3 in inspection, using any method, also means there is no need to focus on blockbuilding and thinking time. This is because the full 2x2x3 solution is known and the proceeding steps are algorithmic.

*Step 2:* Creating the pair can be done using just R and U moves. F or even S moves can also work well depending on the situation. There aren't that many possible orientations and positions for this corner and edge. So after a while it will be a very natural, almost algorithmic step.

*Step 3:* During the previous step, track the other E layer edge. Then once you get to this step (EOPair) it is easy to recognize the recognition of the remaining edges. Since you know where the other E layer edge is and its orientation, the other edges are U/D edges and the recognition is similar to Roux LSE. If a U/D color isn't facing U or D, then it is misoriented. Credit to Trangium for this observation.

*Step 4:* Recognition for this step is easy. The DFR corner and FR and DR edges look different from everything else that belongs on the U layer. So just find those pieces. You can track them during the EOPair algorithm execution.

*Step 5:* As mentioned, ZBLL is the recommendation. But it isn't necessary to be fast. APB is still a top method even without ZBLL. So choose what you are most comfortable with at first.

*How to get started:*

It is very easy to solve each step of APB intuitively while learning the algorithms. For Step 3 (EOPair), if you come across an EOPair case that you don't yet know, insert the pair that you created. Then orient all edges using one of 11 algorithms that are provided in the EOPair document on the website. For Step 4 (LXS), if you come across a case that you don't yet know, you can insert the DR edge intuitively by using S' U2 S if it is on the U layer or R' U' R' U R if it is at FR. Then just solve the last slot pair.

*Expansions:*

The EOPair step can be expanded to further reduce the move-count of APB. In Step 2 of creating a pair, you can instead set up a pair so that it is a move or two away from being paired. Then the EOPair step would finish and insert the pair while orienting the remaining edges. You can also build one of the other three possible F2L pairs if the opportunity is good. Then use the associated EOPair and LXS algorithms. This would save moves during the pair creation step and is likely best used at an advanced level.

APB also has the ability to end the solve in ways other than ZBLL. One main option is to add the opposite side F2L pair after the EOPair step then finish with CDRLL and L5EP. This would be a pretty efficient alternative to learning ZBLL. Another primary option is to expand the EOPair step to become EOSquare. After the 2x2x3 and creating a pair, the next step can place the pair while orienting all edges and solving the DR edge. This allows the user to end the solve with LSLL. There are some great LSLL developments occurring right now and likely more to come in the future. It is possible that there could be something better developed than LS + ZBLL.

*Application to other methods:*

Some of APB can also be used in other methods. Specifically the LXS step. In a method that already has all edges oriented before getting to the right side block, the user can create a pair, leave it on the U layer to save moves versus inserting the pair, then use an algorithm that solves the three remaining pieces while inserting the created pair. This allows for around a 13 move right block solution. Recently 𝝅/Sosimomonon tested right block using the HARCS program. They discovered that solving a pair first then solving the remaining square (LXS) is more efficient than solving a square first then the final pair. This aligns with the efficiency of APB.

*Block on Left Example:

Scramble:* B2 L2 B D2 F2 L2 F L2 B L2 R2 U2 R' D' B U' R2 B L2 R2 D'

*2x2x2:* y z D' B' M' B'
*2x2x3:* F' R2 U' R U R' F
*Pair:* R2 U' R
*EOPair:* U2 F' U F R
*LXS:* R' U' R U R U R U R'
*ZBLL:* F R' F2 R F R' F2 R U2 r U r' F' U'

View on alg.cubing.net

*Block on Back Example:

Scramble:* D' R2 B R2 D B2 R' U D2 R' U2 L D2 R2 B2 L' F2 R F2 U2 B'

*2x2x2:* D' R' U2 R F R2
*2x2x3:* U' L' F2 L' U L'
*Pair:* R U R'
*EOPair:* U' R U' R' U' F'
*LXS:* r U2 r' U2' r U2 M U R'
*ZBLL:* R' U' R U R2 D' R U' R' D R2 U2 R' U2 R

View on alg.cubing.net

Some may ask "Is this Petrus?" APB was originally developed with the intent to fix the common complaint against Petrus which is the EO step. The EO step of Petrus is a bit of an inefficiency. It may only be ~5 moves but I've always felt that there should be something more done while orienting the edges. So with APB, instead of separating EO and the last block, partial blockbuilding is performed while orienting the edges. At first APB could have been viewed as algorithmic Petrus. But it has since been expanded to have the ability to end in different ways that aren't LL and part of the method has been adapted to work with ZZ, LEOR, and other methods. APB has developed into something unique of its own.


----------



## DuckubingCuber347 (Sep 17, 2021)

Athefre said:


> *APB Webpage*​
> Here I am presenting an alternative way of orienting all edges and solving the last block after the 2x2x3 is built in Petrus. I have always felt that the EO step of Petrus is a bit of an inefficiency. That there should be something more done while orienting the edges. So with APB, instead of separating EO and the last block, partial blockbuilding is performed while orienting the edges. The primary steps are:
> 
> *Step 1:* Build a 2x2x3 at db.
> ...


I'll have to take a look at it more in depth later but this definitely seems like an improvement for Petrus.
@PetrusQuber


----------



## Athefre (Sep 17, 2021)

Going to run the dl block EOPair algs through a solver again including f and S moves in the move-set. Hopefully that will get the algs up to the same quality as those for db block.


----------



## xyzzy (Sep 17, 2021)

Athefre said:


> *Step 3:* Orient all edges while inserting the pair. For each of the pair situations there are 31 or 32 cases.


With the block at db, does EO here refer to EO along the F-B axis? (In other words, _not_ the usual Petrus EO?)


----------



## Athefre (Sep 17, 2021)

xyzzy said:


> With the block at db, does EO here refer to EO along the F-B axis? (In other words, _not_ the usual Petrus EO?)


It's the EO used in most methods. F and B changes the edge orientation. L, U, R, and D only change their permutation. This way R r U M can easily be used during the square step. And I suppose this means rotating and using R U algs actually wouldn't work out so well. The L R EO would have to be used for that if someone really wants to rotate for R U algs. But possibly the f and S moves inclusion will improve the algs for dl block.


----------



## BenChristman1 (Sep 18, 2021)

If I understand correctly, doesn’t this just turn it into Nautilus?


----------



## LukasCubes (Sep 18, 2021)

Looks interesting...


----------



## voidrx (Sep 18, 2021)

BenChristman1 said:


> If I understand correctly, doesn’t this just turn it into Nautilus?


Proves that nautilus is the best lol


----------



## DuckubingCuber347 (Sep 18, 2021)

BenChristman1 said:


> If I understand correctly, doesn’t this just turn it into Nautilus?


and thus the Nautilus takeover began...


----------



## Cubing Forever (Sep 18, 2021)

Athefre said:


> *APB Webpage*​
> Here I am presenting an alternative way of orienting all edges and solving the last block after the 2x2x3 is built in Petrus. I have always felt that the EO step of Petrus is a bit of an inefficiency. That there should be something more done while orienting the edges. So with APB, instead of separating EO and the last block, partial blockbuilding is performed while orienting the edges. The primary steps are:
> 
> *Step 1:* Build a 2x2x3 at db.
> ...


An alternative to this would be the usual Petrus 223 in dl>EO>dBR>dfR square(for which the algs are genned but not yet formatted)
anyway, algorithmic blockbuilding is a really cool and underexplored concept.


----------



## PetrusQuber (Sep 18, 2021)

TheCubingCuber347 said:


> I'll have to take a look at it more in depth later but this definitely seems like an improvement for Petrus.
> @PetrusQuber


Seen it in the discord server, looks pretty promising


BenChristman1 said:


> If I understand correctly, doesn’t this just turn it into Nautilus?


Nautilus follows different first steps, and only one of the other variants is similar in finishing the EO, but yeah


----------



## abunickabhi (Sep 18, 2021)

Athefre said:


> *APB Webpage*​
> Here I am presenting an alternative way of orienting all edges and solving the last block after the 2x2x3 is built in Petrus. I have always felt that the EO step of Petrus is a bit of an inefficiency. That there should be something more done while orienting the edges. So with APB, instead of separating EO and the last block, partial blockbuilding is performed while orienting the edges. The primary steps are:
> 
> *Step 1:* Build a 2x2x3 at db.
> ...


Really good work Athefre.

A lot of momentum is being put into making new methods and I like it in general. Makes cubing more creative.


----------



## Athefre (Sep 18, 2021)

Cubing Forever said:


> An alternative to this would be the usual Petrus 223 in dl>EO>dBR>dfR square(for which the algs are genned but not yet formatted)
> anyway, algorithmic blockbuilding is a really cool and underexplored concept.



That's definitely something that I considered. I even have the ZZ section on the page with algs that could be used. However, the primary goal with APB is to do something during EO. To have EO not be a step of its own.



PetrusQuber said:


> Nautilus follows different first steps, and only one of the other variants is similar in finishing the EO, but yeah



There is at least one person that does Nautilus as 2x2x3 at db then add the pair at dFL. Then let's say that I or someone else would have eventually proposed EO + the dFL pair for those users. This shows that APB almost creates a kind of merged method of Nautilus and Petrus (There's even a section on the page that I call Nautrus). At least in most cases. For more advanced applications of APB where someone builds one of the D layer pairs it wouldn't look like Nautilus.

However, APB is developed for Petrus. So as long as users follow the steps of APB and don't do EOPair then some other Nautilus steps, I definitely classify it as Petrus.


----------



## voidrx (Sep 18, 2021)

TheCubingCuber347 said:


> and thus the Nautilus takeover began...


YES!!!!


----------



## Athefre (Sep 18, 2021)

I regenerated the EOPair algs for dl block. Incorporating f and S moves made a huge difference. A few cases still aren't great, but overall it is a much better move-count and no more repeating F and U moves. Though the new set contains a lot of S moves so users would have to practice the fingertricks. S moves can be fast but they aren't yet commonly used.

View algs (images will be added soon)

I want to eventually try generating EOPair which keeps the pair on the U layer. Just to see if there is even a small difference in ergonomics and how the last three pieces step compares to when the pair is placed in F2L.


----------



## Tao Yu (Sep 19, 2021)

I kind of like this method a lot. I'm a sucker for two things: methods that end with ZBLL, and algorithmic steps that feel intuitive... and this has both.

I'd really like to add these algs to my trainer and play around with it. Unfortunately, my interest in cubing in general is pretty low these days so idk if it will go much further than that.


----------



## Athefre (Sep 19, 2021)

Tao Yu said:


> I kind of like this method a lot. I'm a sucker for two things: methods that end with ZBLL, and algorithmic steps that feel intuitive... and this has both.
> 
> I'd really like to add these algs to my trainer and play around with it. Unfortunately, my interest in cubing in general is pretty low these days so idk if it will go much further than that.


That would be useful. If you get these added to your trainer, I'll link to it on my site.


----------



## Tao Yu (Sep 19, 2021)

Athefre said:


> That would be useful. If you get these added to your trainer, I'll link to it on my site.


Cool, thanks for letting me use your algs. I'll try and do it at some time during the next month or so.


----------



## Athefre (Oct 10, 2021)

APB is now fully usable! Adding in S and f moves into the moveset for the block on left algs completely changed everything. Block on left might be my recommended way to use APB now. It is efficient and maintains the R U ergonomics.

I have also created a dedicated website for APB.









APB


APB efficiently and ergonomically combines EO plus blockbuilding after a 2x2x3 is built. The first step is to solve the 2x2x3. After the 2x2x3 is built, create one of the F2L pairs. Then use an algorithm to orient all edges while inserting this pair. Finally, the last three pieces of the F2L are




sites.google.com


----------



## tsmosher (Oct 10, 2021)

Athefre said:


> APB is now fully usable!



So, what is the final alg count for all pair situations?

For dl, is it just ~64 cases for dFR and ~64 cases for dBR? Or am I missing some?


----------



## Athefre (Oct 11, 2021)

tsmosher said:


> So, what is the final alg count for all pair situations?
> 
> For dl, is it just ~64 cases for dFR and ~64 cases for dBR? Or am I missing some?


For using the same pair every solve, which is my recommendation until really advanced use, it is 63 EOPair algorithms and 116 L3P algorithms. For a total of 179 algorithms.

Oriented pair EOPair: 31
Misoriented pair EOPair: 32
L3P: 116

Later you can learn the algorithms for when the pair is a move away from being paired. Or algorithms for other pairs. There will be new L3P algorithms for each pair. It is possible to use the same EOPair algorithms for various pairs.

Added a Beginners page with a simple strategy for the algorithm learning process. The summary is that if you don't know the alg for the current EOPair case, insert the pair then use one of 11 algs to orient all edges. Then if you don't know the alg for the current L3P case, insert the D layer edge (just two easy cases) then solve the remaining F2L pair.









APB - Beginners


Where to start




sites.google.com


----------



## tsmosher (Oct 11, 2021)

Athefre said:


> For using the same pair every solve, which is my recommendation until really advanced use, it is 63 EOPair algorithms and 116 L3P algorithms. For a total of 179 algorithms.
> 
> Oriented pair EOPair: 31
> Misoriented pair EOPair: 32
> ...



My question was more around how practical it would be to learn all EOPair cases for a given slot and a given 223 orientation.

e.g., If I always build a 223 in dl, and I always want to insert dBR as my EOPair, how many cases would I have to learn in order to cover *all* F2L scenarios (i.e., make this step entirely algorithmic)?

For the record, I assume this would be a *huge* number, at least as large as ZBLS (302 cases).


----------



## Athefre (Oct 12, 2021)

tsmosher said:


> My question was more around how practical it would be to learn all EOPair cases for a given slot and a given 223 orientation.
> 
> e.g., If I always build a 223 in dl, and I always want to insert dBR as my EOPair, how many cases would I have to learn in order to cover *all* F2L scenarios (i.e., make this step entirely algorithmic)?
> 
> For the record, I assume this would be a *huge* number, at least as large as ZBLS (302 cases).



I put it into trangium's batch solver and it showed a little over 2,000 cases. This would be to orient all edges while solving the dBR pair no matter where the corner and edge is.


----------



## Athefre (Nov 9, 2021)

I have updated the main post with much more detail on why this method is great, comparisons, expansions, and a simple guide for someone new to the method. The website has also been updated with some of these same things.


----------



## voidrx (Nov 9, 2021)

Athefre said:


> *APB Webpage*​
> Here I am presenting a new method which efficiently reaches ZBLL without the requirement of efficient blockbuilding for most of the solve or the memorization of 400+ algorithms before ZBLL. The primary steps are:
> 
> *Step 1:* Build a 2x2x3 on the left.
> ...



The update is great!!




Athefre said:


> S' U2 S


One little thing... It is actually faster to put the DR edge in UL and do S R2' S' R2 than to put the DR edge in UR and do S' U2 S.


----------



## Athefre (Nov 10, 2021)

voidrx said:


> The update is great!!
> 
> 
> 
> One little thing... It is actually faster to put the DR edge in UL and do S R2' S' R2 than to put the DR edge in UR and do S' U2 S.


I think I can do S' U2 S faster. Both are good though so maybe I'll add that as an option on the site.


----------



## OreKehStrah (Nov 10, 2021)

voidrx said:


> The update is great!!
> 
> 
> 
> One little thing... It is actually faster to put the DR edge in UL and do S R2' S' R2 than to put the DR edge in UR and do S' U2 S.


S' U2 S should be faster. A double flick U2 is faster than a rolled or overturned R2.


----------



## Cubing Forever (Nov 10, 2021)

OreKehStrah said:


> S' U2 S should be faster. A double flick U2 is faster than a rolled or overturned R2.


Yeah but here you do R2' from homegrip(dlin Ub style) and S' U2 S has an overwork


----------



## tsmosher (Nov 10, 2021)

Cubing Forever said:


> Yeah but here you do R2' from homegrip(dlin Ub style) and S' U2 S has an overwork


S' U2 S is faster If the edge is in URS IMHO. Any other spot, you can AUF the edge to ULS and do it the Mehta way.


----------



## Athefre (Nov 11, 2021)

A comparison of the three 2x2x3 + EO + RB methods - Petrus, APB, and Mehta.



More detail below. The table compares the F2L part of each method. LL isn't included because it is the same for all three. A rating system of 1-5 was used in the chart for ergonomics and recognition. That was just a way to quantify them and show differences. The exact numbers don't matter so much because we can debate how far from 5 something should be and if something should be .1 higher or lower. It is more important to see the differences in ergonomics and recognition as described below. That will help show why a step was rated .2 higher than another step.

*Movecount:* The movecounts among all three are so close that it probably doesn't even matter. It is pretty much a draw and little things here and there can put any of the three over the others. Things like the skill of the user, how the build the 2x2x3, algorithm choice, pseudo integration, and others. Petrus users often say that a good user should average 12 moves for a 2x2x3 using the 2x2x2 > 2x2x3 strategy. The table bases the 2x2x3 step on this number and should be around the same when using another single strategy. The 2x2x3 for Mehta is input as 11 moves due to the method using a strategy of 1x2x3 on the D layer then any two edges in a pseudo way. This equates to a 6 move 1x2x3 and 5 moves for two E layer edges. I'm not sure if users will actually average this low. I'm just using the 1x2x3 number from the Mehta website. If pseudo is used there will often be a final D or E layer adjustment (ABF in the table). Using a few techniques depending on the scramble to build a 2x2x3 is likely more efficient than always using the same strategy. This is the recommendation in APB so it could also go below 12 moves. Despite the overall movecounts of each method being close to the same, it is likely much more important to consider the movecount of the algorithm-based steps. This means EOPair vs EOLE and L3P vs TDR. EOPair and EOLE are almost exactly the same. The biggest difference is in L3P and TDR where L3P averages over a move fewer. This advantage is especially important when considering the ergonomics of the steps which is talked about in the ergonomics section below.

*Algorithm Count:* Petrus contains zero algorithms before the last layer. The EO step can be performed using algorithms if the user wants. APB's EOPair step contains 63 algorithms and L3P contains 116 algorithms for a total of 179 algorithms. Mehta's EOLE step contains 56 algorithms and TDR contains 350 algorithms for a total of 406 algorithms. This means that a user has to learn 227 more algorithms in Mehta. In L3P vs TDR this means the user needs to learn 234 additional, longer algorithms.

*Ergonomics:* Although the final steps of each is R U only there will be a difference. In Petrus the user isn't going to always be able to choose the most ergonomic solution because it is intuitive. In APB and Mehta the final step uses speed optimal algorithms. These will be both ergonomic and drilled by the user to be performed quickly. APB's final step, L3P, contains algorithms that are a bit more ergonomic than Mehta. With L3P averaging fewer moves than TDR, the better ergonomics combine to give this step a real advantage. L3P containing just 116 cases versus TDR's 350 widens the gap further. In APB's EOPair and Mehta's EOLE, there is a very slight ergonomics advantage in APB's favor. The ergonomics advantage of APB's EOPair versus Mehta's EOLE is further evidenced when putting the algorithm lists into trangium's MCC program. The advantage of L3P versus TDR can be seen when performing the algorithms and considering that APB's L3P step is more free. A full slot is available so many algorithms will be as ergonomic as a last slot algorithm. The L3P step is also solving one corner and two edges. TDR solves two corners and one edge. It is more difficult to work with two corners than it is two edges.

*Recognition:* Mehta's EOLE has a slight advantage vs APB's EOPair. With EOPair the user tracks the other E layer edge during lookahead while building the pair in the previous step. Neither step has difficult recognition, so they both were rated pretty highly. For L3P vs TDR, I feel that L3P has slightly better recognition because a corner has more stickers and the D layer stickers that you want to find can be hidden. L3P has only one corner to find. Edges are easier to find because you just check the U layer (and or the FR sticker in L3P's case). Again though, lookahead is something all solvers should be doing so neither step has bad recognition. Recognition is a tie overall for the two methods. Petrus only has one step during F2L that requires recognition. That is the EO step and is one of the major complaints against the method.

In summary, the primary differences are in the algorithm count and ergonomics. Those two qualities should be the main focus when comparing the methods. Petrus contains zero algorithms for EO F2L, but has slightly worse ergonomics and recognition. For the algorithm-based approaches, APB contains many fewer algorithms than Mehta. APB is a little more ergonomic than both Petrus and Mehta. So with the higher TPS potential of an algorithm-based approach, APB achieves better ergonomics and the same move-count and recognition without requiring the user to learn a huge number of algorithms.


----------



## Cubing Forever (Nov 11, 2021)

Athefre said:


> The ergonomics advantage of APB's EOPair versus Mehta's EOLE is further evidenced when putting the algorithm lists into trangium's MCC program.


can you give the numbers for this(as in average movecount coefficient for EOLE and EOPair)?


----------



## Athefre (Nov 11, 2021)

Cubing Forever said:


> can you give the numbers for this(as in average movecount coefficient for EOLE and EOPair)?


Yeah:

EOPair:

Oriented pair (31 cases) - 7.34 MCC
Misoriented pair (32 cases) - 8.27 MCC
All algorithms (63 cases) - 7.81 MCC

EOLE:

All algorithms (56 cases) - 8.43 MCC
I think both EOPair and EOLE can be further optimized. I'm just one person and EOLE has had a lot of people work on that alg set.


----------



## Cubing Forever (Nov 11, 2021)

Athefre said:


> I think both EOPair and EOLE can be further optimized


I don't know about EOpair but EOLE for sure needs more optimization(since there are some algs with funny ergonomics(eg. F R F2 U F R'))


----------



## voidrx (Nov 12, 2021)

APB-CP

1. CP-line
2. FB
3. Solve dM
4. APB (Some algs might be different??)
5. 2GLL


----------



## OreKehStrah (Nov 12, 2021)

Cubing Forever said:


> I don't know about EOpair but EOLE for sure needs more optimization(since there are some algs with funny ergonomics(eg. F R F2 U F R'))



Bruh, R F' U F R' to solve the case set up by the inverse of that


----------



## Athefre (Nov 12, 2021)

voidrx said:


> APB-CP
> 
> 1. CP-line
> 2. FB
> ...


Yep. APB can be used in methods with edges already oriented. The same algs for ZZ that are provided on the site can be used in LEOR, CP methods, and others. Currently the site has dFR algs. It would be nice to have the dBR algs added.


OreKehStrah said:


> Bruh, R F' U F R' to solve the case set up by the inverse of that


That alg is in the main document that I used for the numbers.


----------



## Cuberstache (Nov 12, 2021)

OreKehStrah said:


> Bruh, R F' U F R' to solve the case set up by the inverse of that


That's the EOLE alg for that case, not sure which one @Cubing Forever was trying to refer to.


----------



## Cubing Forever (Nov 13, 2021)

Cuberstache said:


> That's the EOLE alg for that case, not sure which one @Cubing Forever was trying to refer to.


I was referring to F R F2 U' F R'


----------



## tsmosher (Nov 13, 2021)

Athefre said:


> The 2x2x3 for Mehta is input as 11 moves due to the method using a strategy of 1x2x3 on the D layer then any two edges in a pseudo way. This equates to a 6 move 1x2x3 and 5 moves for two E layer edges. I'm not sure if users will actually average this low. I'm just using the 1x2x3 number from the Mehta website. If pseudo is used there will often be a final D or E layer adjustment (ABF in the table). Using a few techniques depending on the scramble to build a 2x2x3 is likely more efficient than always using the same strategy.



I thought the estimates for this were always: 7 moves for Dl and 7-8 moves for 3QB. With 5 of these moves being HB, that would be 12 moves for 223 just like the other methods.

I don't think 6 moves for FB is realistic. (Maybe for a computer/FMC but not a speed solver.) For most of us mere mortals, I would estimate 7-8 moves for Dl and 3QB each.


----------



## Cubing Forever (Nov 13, 2021)

tsmosher said:


> I don't think 6 moves for FB is realistic.


but it is realistic assuming you're CN


----------



## tsmosher (Nov 13, 2021)

Cubing Forever said:


> but it is realistic assuming you're CN


I am. Still a lowball estimate IMO but I am admittedly bad at FB especially the way it's built in Mehta.

EDIT: Case in point: Your last 3 solves in the Mehta example solve thread were 9, 7, and 8 moves respectively... (8 moves was FB+1 belt edge)...

Btw, you could also argue: 222 in 4 moves and extension in 5-6... For a 9-10 move 223 in Petrus. (Source: FMC Thread.) No one is consistently being that efficient in a speed solve though.


----------



## Cubing Forever (Nov 13, 2021)

tsmosher said:


> EDIT: Case in point: Your last 3 solves in the Mehta example solve thread were 9, 7, and 8 moves respectively... (8 moves was FB+1 belt edge)...


I'm still bad at FB though

with some efficient Roux like blockbuilding, mid-high 6 average is definitely possible(with CN)


----------



## Athefre (Nov 13, 2021)

tsmosher said:


> I thought the estimates for this were always: 7 moves for Dl and 7-8 moves for 3QB. With 5 of these moves being HB, that would be 12 moves for 223 just like the other methods.
> 
> I don't think 6 moves for FB is realistic. (Maybe for a computer/FMC but not a speed solver.) For most of us mere mortals, I would estimate 7-8 moves for Dl and 3QB each.


I do feel that the movecount gap will actually be wider in APB's favor. Something like a 2-4 move difference which is pretty big. And that movecount difference would be highlighted even more since the ergonomics are better.

One reason I chose to put 11 moves was because it has been very difficult to get a straight answer about what the real movecounts are in Mehta. For a long time it was advertised by the creator using computer based movecounts. First using HARCS then, even after I brought up the HARCS issue, the creator built a personal solver and again announced those computer numbers as the method's average. 5 moves for FB and 5 moves for 3QB. The website still places these computer moves in a table before finally mentioning in the large amount of text the human movecounts of 6-7 moves for FB and 6-7 moves for 3QB. Despite this, I tried to be nice and just use 6 moves for FB and 5 moves for 2QB to complete a 2x2x3. As I said I feel that it may be higher. Meaning movecount would be another point in APB's favor and not an area where they are equal.


----------



## tsmosher (Nov 13, 2021)

Athefre said:


> I do feel that the movecount gap will actually be wider in APB's favor. Something like a 2-4 move difference which is pretty big. And that movecount difference would be highlighted even more since the ergonomics are better.
> 
> One reason I chose to put 11 moves was because it has been very difficult to get a straight answer about what the real movecounts are in Mehta. For a long time it was advertised by the creator using computer based movecounts. First using HARCS then, even after I brought up the HARCS issue, the creator built a personal solver and again announced those computer numbers as the method's average. 5 moves for FB and 5 moves for 3QB. The website still places these computer moves in a table before finally mentioning in the large amount of text the human movecounts of 6-7 moves for FB and 6-7 moves for 3QB. Despite this, I tried to be nice and just use 6 moves for FB and 5 moves for 2QB to complete a 2x2x3. As I said I feel that it may be higher. Meaning movecount would be another point in APB's favor and not an area where they are equal.


I mean, after thinking about this all night, Kian Mansour himself estimates FB at 7 moves. Is the claim here really that Mehta FB is somehow more efficient than that? Why would it be?


----------



## voidrx (Nov 13, 2021)

Cubing Forever said:


> but it is realistic assuming you're CN


CN stats don't even get 6 movecount. They avg around 6.5 iirc. It's better to round up in these circumstances.


----------



## tsmosher (Nov 13, 2021)

voidrx said:


> CN stats don't even get 6 movecount. They avg around 6.5 iirc. It's better to round up in these circumstances.


Well, I mean, with a computer, anything is possible.









Roux move count statistics


I realized the FB+1 stage in Roux, although parallel to XCross in difficulty, hasn't yet been studied carefully, so I programmed a solver to investigate its move count, along with some other interesting stats including FB square, LSE subsets and more! I have summarized my findings in this...




www.speedsolving.com





As you can see from the above link:
RFB+DRS CN is ~6.14 moves.

So, I think that FB is definitely possible in 6 moves. Is it likely for a human speed solver? I dont think so.

EDIT: The same link shows ~5.14 moves for FB CN.


----------



## Cuberstache (Nov 13, 2021)

tsmosher said:


> I mean, after thinking about this all night, Kian Mansour himself estimates FB at 7 moves. Is the claim here really that Mehta FB is somehow more efficient than that? Why would it be?


Was Kian considering full CN or x2y?


----------



## tsmosher (Nov 13, 2021)

Cuberstache said:


> Was Kian considering full CN or x2y?


Full CN, I believe. He said that he is sub 7 ETM with his FB (and that computer-optimal FB is 5.5 ETM), but that there is room for improvement in terms of SB influencing and ergonomics. And, ultimately, he feels that ergonomics > efficiency for speed solving; hence, 7 ETM was his estimate for the future of Roux FB.


----------



## Athefre (Nov 14, 2021)

An ergonomics comparison using trangium's MCC. All algorithm sets were taken from the current sheets. A lower number means better ergonomics.

*APB:*

EOPair: 7.81 MCC
L3P: 9.48 MCC
*Mehta:*

EOLE: 8.43 MCC
TDR: 11.62 MCC
*Petrus:*

EO: 6.56
RB: Varies. User dependent. Inputting a fast user's intuitive RB solutions taken from 50-100 full solves may give a better answer.
Looks like a big difference between L3P and TDR. And the slightly better ergonomics for EOPair is also shown. Petrus has the best first step ergonomics due to having the most freedom in the step. However it likely has the worst, or least consistent, ergonomics in the second step because the user can't always choose the most ergonomic solutions compared to the algorithm-based methods.


----------



## tsmosher (Nov 14, 2021)

Athefre said:


> An ergonomics comparison using trangium's MCC. All algorithm sets were taken from the current sheets. A lower number means better ergonomics.
> 
> *APB:*
> 
> ...



Are these numbers taken with block in db or dl?

What are the MCC numbers for Petrus EO alone? It might be interesting to calculate this from some place with good EO algs (like Trangium's alg sheet, or I've seen other lists on Discord).

Although this comparison is all good and well between the most advanced variants of these methods (each ending in ZBLL), I'm curious what an identical comparison would look like for the variants used by the rest of us peons. Ending, for example, with CDRLL/L5EP or NCOLL/L5E(P) or with any number of other possibilities after EO pair (which do not require 600+ algorithms).


----------



## trangium (Nov 14, 2021)

Athefre said:


> An ergonomics comparison using trangium's MCC. All algorithm sets were taken from the current sheets. A lower number means better ergonomics.
> 
> *APB:*
> 
> ...


What are the MCCs for creating the pair vs inserting a belt edge?


----------



## tsmosher (Nov 14, 2021)

trangium said:


> How about creating the pair vs inserting a belt edge?


3 move estimate for making the pair in APB seems low. Pairing oriented edge and corner averages 3.765 moves for me. Misoriented edge and corner (which I do not account for) must surely bring the average slightly higher?

Belt edge would surely be less moves at ~2-2.5 moves.

I imagine it's tough to get raw data to compare from these steps since they are not usually performed algorithmically and hence cannot be boiled down to MCC.

EDIT: Can ergonomics really be reduced to MCC as well? What are the allowed move sets for each of these steps? And how often do F moves, B moves, S moves, etc. show up? That would seem to me to better describe ergonomics.


----------



## Athefre (Nov 15, 2021)

tsmosher said:


> Are these numbers taken with block in db or dl?
> 
> What are the MCC numbers for Petrus EO alone? It might be interesting to calculate this from some place with good EO algs (like Trangium's alg sheet, or I've seen other lists on Discord).
> 
> Although this comparison is all good and well between the most advanced variants of these methods (each ending in ZBLL), I'm curious what an identical comparison would look like for the variants used by the rest of us peons. Ending, for example, with CDRLL/L5EP or NCOLL/L5E(P) or with any number of other possibilities after EO pair (which do not require 600+ algorithms).


This is all dl block. dl is the recommendation for APB. db is slightly more efficient but dl seems to have slightly better ergonomics.

Petrus EO is provided in the post. The alg sheet used is the latest one that has been created and is pinned in the Reddit server (here). I also generated EO using the batch solver and it was close to the ergonomics of that sheet.


trangium said:


> What are the MCCs for creating the pair vs inserting a belt edge?


Creating a pair in APB can always be R U only. With F, f, and S also being available to make the movecount even lower. Inserting a belt edge can't always be done using R U unless the flipped BR edge alg set idea is used (which may or may not be good). Inserting a belt edge is more like U u R or U F R. Other movesets can be used also.

For a more perfect answer, this might take inputting a lot of solves. Or finding solutions to all possibilities and inputting those. Which is something I've been planning since the beginning for finding both movecount and ergonomics. I have an idea of how to do this using the batch solver.


tsmosher said:


> 3 move estimate for making the pair in APB seems low. Pairing oriented edge and corner averages 3.765 moves for me. Misoriented edge and corner (which I do not account for) must surely bring the average slightly higher?
> 
> Belt edge would surely be less moves at ~2-2.5 moves.
> 
> ...


I usually say 3-4 moves for a pair. It depends on if the user wants to always use R U or if they want to really reduce the movecount by incorporating other moves to have a S U R F f moveset.


----------



## Athefre (Nov 21, 2021)

A bit more detail on the CDRLL variant. Comparing APB's EOPair + final pair and Mehta's EOLE + DCAL.

*APB:*

EOPair: Slightly better ergonomics, 63 cases
Pair: Better ergonomics, better recognition, fewer moves, 0 algorithms to memorize if performed intuitively, 26 cases if using algorithms
*Mehta:*

EOLE: Slightly better recognition, 56 cases
DCAL: 80 algorithms to memorize
So in total APB has better ergonomics and has fewer algorithms to memorize. Both average the same number of moves. Recognition looks even since the first step is slightly better in Mehta and the second step is better in APB.

Another big advantage APB has is L5EP neutrality. Users can have the 2x2x3 on the left or the back and use either right side RU L5EP or front side MU L5EP. The algorithms for EOPair and the final pair are good either way and front side L5EP is shorter at 7.38 moves versus right side L5EP at 9 moves. In Mehta you can't really use front side L5EP because the DCAL step isn't good when the corners are on the front.


----------



## Cubing Forever (Nov 21, 2021)

Athefre said:


> In Mehta you can't really use front side L5EP


You can do a D' to bring the unsolved edge to the front.

Also, the original idea(with Mehta-6CP(the original Mehta variant)) iirc was to use algs that actually move the D layer such that you get the unsolved edge in either the front or back(both front and back L5EPs are equally efficient iirc).


----------



## Athefre (Nov 21, 2021)

Cubing Forever said:


> You can do a D' to bring the unsolved edge to the front.
> 
> Also, the original idea(with Mehta-6CP(the original Mehta variant)) iirc was to use algs that actually move the D layer such that you get the unsolved edge in either the front or back(both front and back L5EPs are equally efficient iirc).


Of course. Adjusting the D layer is an option in both APB with 2x2x3 on the left and Mehta. However, in APB it isn't a requirement to add a move then possibly have to ADF again later. Using MU L5EP can be done naturally by just having the 2x2x3 on the back.

For the automatic D layer adjusting algs, I did generate this for DCAL once to see what they are like. Over 50% of the best algs just solved the corners then adjusted the D layer. So pretty much the same as doing DCAL as normal and moving the D layer in the end yourself.


----------



## Cuberstache (Nov 21, 2021)

Athefre said:


> However, in APB it isn't a requirement to add a move then possibly have to ADF again later.


For Mehta, the first ADF would solve the D-layer, then you would do L5EP from whichever angle you need to. I think if this results in the D-layer edge being on the left, we decided that you should just do L5EP on right then D2. So no extra moves for L5EP neutrality.


----------



## Athefre (Nov 25, 2021)

Cuberstache said:


> For Mehta, the first ADF would solve the D-layer, then you would do L5EP from whichever angle you need to. I think if this results in the D-layer edge being on the left, we decided that you should just do L5EP on right then D2. So no extra moves for L5EP neutrality.


Definitely an option. Overall the point was that it is more natural in APB and doesn't require any D layer adjustments. Users can plan a 2x2x3 in the back if they want and the algorithms afterward are good. It also allows the user to be a move or two more efficient if they like the R r U M moveset more than R U F S f.

I still recommend block on left but options are good.


----------



## tsmosher (Nov 25, 2021)

Athefre said:


> Definitely an option. Overall the point was that it is more natural in APB and doesn't require any D layer adjustments. Users can plan a 2x2x3 in the back if they want and the algorithms afterward are good. It also allows the user to be a move or two more efficient if they like the R r U M moveset more than R U F S f.
> 
> I still recommend block on left but options are good.


Yeah I mean, if everything else was equal...
RrUM > RUFfS
I think most would agree.


----------



## Athefre (Jan 2, 2022)

A Discord server has been created for APB. Join below!









Join the APB Discord Server!


Check out the APB community on Discord - hang out with 110 other members and enjoy free voice and text chat.




discord.gg


----------



## V Achyuthan (Jan 5, 2022)

A youtube tutorial on APB (warning - english is dumb)


----------



## SuperDuperSir (Feb 18, 2022)

do you think that cdrll + l5ep is faster than lxs + zbll? I think that cdrll is more of a 3 look variant, with the front pair coming first, but have a lot less algs.


----------



## DuckubingCuber347 (Feb 19, 2022)

SuperDuperSir said:


> do you think that cdrll + l5ep is faster than lxs + zbll? I think that cdrll is more of a 3 look variant, with the front pair coming first, but have a lot less algs.


If you don't want to learn a bunch of algs than CDRLL>>L5EP is better but LXS>>ZBLL is ultimately the fastest. It definitely wouldn't hurt to use CDRLL if that's what interests you.


----------

