A potentially faster OLL 23 algorithm

[Aergyl]

To be fair, I've never timed them or anything, some algs just felt faster to me. The ones I was thinking of in particular are
R' D' R U' R' D R2 U2 R' U R U R'
R' U' R U' R' U2 R2 U R' U R U2 R'
I feel they're more finger-trick friendly, in particular the second one which is just 2 sunes. But they are 4 moves longer, so maybe I just thought they were faster because I could get higher TPS on them but overall they still took longer to execute. Anecdotally, I've only seen top cubers do the standard 3 cycle when they don't know ZBLL for this case.

PS: I didn't know BLDers did the RUD alg for 2 twist. For the 2 twist ZBLL case, I've always done antisune U2 back-antisune. I wonder if the RUD alg is just faster or if it's a difference of hand position, etc., between 3-style and CFOP.

I see, thanks! I think I prefer the first one, lol. I use a very weird fingertrick for that U2, which is U' (with right thumb) plus U' (with left index). Otherwise, the U2 is kind of awkward right after the D move IMO. I haven't heard of anyone else using that fingertrick though, so maybe it's just stupid...

I think most 3BLDers use RUD 2-twists, me being one of them. At least for me, it's a lot faster than the RU 2-twist. I just tried to execute them both as fast as I can a couple of times, and framecounted my fastest attempt. The RUD 2-twist was 0.87s and the RU 2-twist was 1.37s, lol. I'm sure there are people who can execute the RU 2-twist better than me though! And yeah, the grip definitely makes a difference. The RU 2-twist is easier to execute from a more neutral grip, which works well with CFOP. Also, the left double flicks can be pretty awkward during 3-style corner execution.

 

[Aergyl]

Lmao I completely missed those somehow. I counted 19 and 22 frames for the 2 vids respectively

I tried it again on a computer, and I agree with your numbers! So basically, the difference is only 0.1s (slightly more if we account for soft regrips).

 

[Aergyl]

I tried looking for some more OLL 23 executions to framecount and I found these (all of them being the standard RUD 3-cycle):

at 1:23, by Matty Hiroto Inaba, (48/60)s.

at 0:36, by Leo Borromeo, (46/60)s.

at 6:22, by Yiheng Wang, (39/60)s.

Except for Yiheng's execution that was 0.08s faster, the other two were even slower than Tommy's 2-twist. Admittedly, it looked like Matty messed up a slight bit, and I think it could've been about the same speed as Yiheng's.

 

[Aergyl]

For anyone interested, I've also framecounted the average PLL recognition time of the first 50 solves in the ao100 by Yiheng Wang above. If I did it correctly, it was approximately 0.16s. In some solves, it's not 100% clear exactly which frames should be counted, but I tried my best to make it as fair as possible. For example, whenever the OLL ended with a slight misalignment, I counted those frames, and whenever the PLL started with a regrip, I stopped counting as soon as the fingers started moving.

This of course doesn't necessarily reflect how fast it's going to be for the OLL 23 specifically, but I still think it's pretty interesting. Also, among the solves I counted, four of them had literally 0 recognition time. In other words, he predicted the PLL in about 4/50 = 12.5% 8% of his solves.

 

[Jorian Meeuse]

4/50 = 12.5% of his solves.

4 in 50 is 8% (you probably confused it with 1 in 8 which is indeed 12.5%)

 

[Aergyl]

4 in 50 is 8% (you probably confused it with 1 in 8 which is indeed 12.5%)

Oops! You're right!

 

[Areli Gómez]

Not me reading the title and thinking you meant OLL with 23 algorithms

 

[Aergyl]

Not me reading the title and thinking you meant OLL with 23 algorithms

Sorry to disappoint you!

 

[Areli Gómez]

Sorry to disappoint you!

it’s fine

 

[turtwig]

I found these (all of them being the standard RUD 3-cycle)

Matty and Leo were doing ZBLL, so it doesn't necessarily mean they would use it as their "default" OLL. (Even those who do not know all of ZBLL would be able to recognize this skip case)
According to speedcubedb though, most reconstructed solves from top cubers use the 3 cycle (and its mirror). Interestingly, Max Park seems to use
F R U' R' U R U R' U R U' R' F'

 

[Aergyl]

Yeah

Matty and Leo were doing ZBLL, so it doesn't necessarily mean they would use it as their "default" OLL. (Even those who do not know all of ZBLL would be able to recognize this skip case)
According to speedcubedb though, most reconstructed solves from top cubers use the 3 cycle (and its mirror). Interestingly, Max Park seems to use
F R U' R' U R U R' U R U' R' F'

True. I simply wanted to see how fast top cubers can execute the 3-cycle in solves. Oh, I didn't know that you can filter reconstructions with specific algorithms like that! Thank you for showing me!

 

[Aergyl]

So I tried framecounting a couple of more executions from speedcubedb, and I got the following numbers:

R2 D R' U2 R D' R' U2 R': 20/30, 55/60, 36/30, 20/30, 19/30, 23/30
R2 D' R U2 R' D R U2 R: 22/30, 25/30, 22/30, 44/60, 34/30
F R U' R' U R U R' U R U' R' F': 26/30, 27/30, 28/30

There were mistakes in some of them, but most of them looked good. Note that I didn't count the frames of regrips at the beginning when it was executed together with AUF. Unfortunately, I can't find any more videos on the RUD 2-twist though...

 

[Aergyl]

So I tried framecounting a couple of more executions from speedcubedb, and I got the following numbers:

R2 D R' U2 R D' R' U2 R': 20/30, 55/60, 36/30, 20/30, 19/30, 23/30
R2 D' R U2 R' D R U2 R: 22/30, 25/30, 22/30, 44/60, 34/30
F R U' R' U R U R' U R U' R' F': 26/30, 27/30, 28/30

There were mistakes in some of them, but most of them looked good. Note that I didn't count the frames of regrips at the beginning when it was executed together with AUF. Unfortunately, I can't find any more videos on the RUD 2-twist though...

I also framecounted the PLL recognition time of a couple of solves from speedcubedb with the 3-cycle that didn't end in a PLL skip.The results are:

19/60, 12/30, 0/60, 0/60, 9/30, 12/30, 5/30, 10/30, 8/30​

The reason two solves had 0 recognition time is that there was no pause and the regrip after the 3-cycle was done together with AUF. Also, the average of the framecounted times above is 0.24s. Of course, the small amount of data I have might not create very accurate results that can be used to compare the 3-cycle and the 2-twist in a good way, but I think that all of the data I've analyzed so far suggests that the 2-twist might actually have potential over the 3-cycle, even for some top cubers.

 

[Aergyl]

Update: I've used the 2-twist for a while now in real solves, and I think it works really well. I can do the recognition essentially 100% of the time without slowing down, and I almost never lock up. So there's no doubt about what algorithm I'm going to main from now on! I'm actually experimenting with using RUD 2-twists for OLL 24 and 25 as well. For various reasons, it's not as good as for OLL 23, but can still be slightly better than the standard algorithms depending on your recognition time.

 

[Aergyl]

I've now found this video with a 18/30s execution of OLL 23 and 7/30s pause between OLL and PLL (at 1:41):

This is the fastest execution I've managed to find so far, but it's still only about 0.13s faster than the 2-twist execution by Tommy Cherry.