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

#### Athefre

##### Member

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 (L3P): 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 L3P 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 ~45 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 L3P 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 (L3P), 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 L3P 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 L3P 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 (L3P) 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
L3P: 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'
L3P: 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.

Last edited:

#### TheCubingCuber347

##### Member

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.
Step 2: Create the left side pair (dFL). Or set up the left side pair so that the corner and edge can be paired in a single move.
Step 3: Orient all edges while inserting the pair. For each of the pair situations there are 31 or 32 cases.
Step 4: Solve the final square (dFr). This step contains 116 algorithms averaging 8.27 moves.

Pros:
• More efficient than EO + last block
• No rotation
• Can track EO while creating the pair
• Algorithmic last step
Cons:
• Slightly less ergonomic overall. This sometimes comes from the first step of creating the pair. And the final square step is R r U M versus R U.
An additional option is provided on the site for solving the 2x2x3 at dl. It works the same. You create the 2x2x3 on the left, create a pair, insert + EO, then solve the final square using R U based algorithms. However, the EOPair algorithms for block on left aren't very good. If you wanted, you could rotate after step 3 above then use all R U algs to solve the final square. But that may not be worth the rotation when the dFr algorithms are good. There are some add-ons to this method that I plan to develop. The biggest thing is the ability to create any of the four F2L pairs then in the last step solve the remaining corner and two edges. More information about the add-ons can be viewed on the site.

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'
Square: 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
I'll have to take a look at it more in depth later but this definitely seems like an improvement for Petrus.
@PetrusQuber

Last edited:

#### Athefre

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

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

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

Last edited:

#### BenChristman1

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

#### LukasCubes

##### Member
Looks interesting...

#### voidrx

##### Member
If I understand correctly, doesn’t this just turn it into Nautilus?
Proves that nautilus is the best lol

#### Cubing Forever

##### Member

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.
Step 2: Create the left side pair (dFL). Or set up the left side pair so that the corner and edge can be paired in a single move.
Step 3: Orient all edges while inserting the pair. For each of the pair situations there are 31 or 32 cases.
Step 4: Solve the final square (dFr). This step contains 116 algorithms averaging 8.27 moves.

Pros:
• More efficient than EO + last block
• No rotation
• Can track EO while creating the pair
• Algorithmic last step
Cons:
• Slightly less ergonomic overall. This sometimes comes from the first step of creating the pair. And the final square step is R r U M versus R U.
An additional option is provided on the site for solving the 2x2x3 at dl. It works the same. You create the 2x2x3 on the left, create a pair, insert + EO, then solve the final square using R U based algorithms. However, the EOPair algorithms for block on left aren't very good. If you wanted, you could rotate after step 3 above then use all R U algs to solve the final square. But that may not be worth the rotation when the dFr algorithms are good. There are some add-ons to this method that I plan to develop. The biggest thing is the ability to create any of the four F2L pairs then in the last step then solve the remaining corner and two edges. More information about the add-ons can be viewed on the site.

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'
Square: 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
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

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

##### Member

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.
Step 2: Create the left side pair (dFL). Or set up the left side pair so that the corner and edge can be paired in a single move.
Step 3: Orient all edges while inserting the pair. For each of the pair situations there are 31 or 32 cases.
Step 4: Solve the final square (dFr). This step contains 116 algorithms averaging 8.27 moves.

Pros:
• More efficient than EO + last block
• No rotation
• Can track EO while creating the pair
• Algorithmic last step
Cons:
• Slightly less ergonomic overall. This sometimes comes from the first step of creating the pair. And the final square step is R r U M versus R U.
An additional option is provided on the site for solving the 2x2x3 at dl. It works the same. You create the 2x2x3 on the left, create a pair, insert + EO, then solve the final square using R U based algorithms. However, the EOPair algorithms for block on left aren't very good. If you wanted, you could rotate after step 3 above then use all R U algs to solve the final square. But that may not be worth the rotation when the dFr algorithms are good. There are some add-ons to this method that I plan to develop. The biggest thing is the ability to create any of the four F2L pairs then in the last step then solve the remaining corner and two edges. More information about the add-ons can be viewed on the site.

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'
Square: 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
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

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

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.

Last edited:

#### Athefre

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

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

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

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

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

#### tsmosher

##### Member
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?