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

tsmosher

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

Athefre

Member
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

Member
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

Member
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

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

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

Member
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

Member
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

Member
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

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

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

Member
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.
What are the MCCs for creating the pair vs inserting a belt edge?

tsmosher

Member
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

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

Member
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

Member
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

Member
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

Member
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

Member
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

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