OLL execution and PLL recognition at the same!

[OreKehStrah]

I agree that the ao50 doesn't really prove anything. It seems like I misunderstood you when you said that "It is the most accurate result". I guess we're on the same page then. Also, I agree that my ao12 doesn't take everything into consideration. That's why said it's not perfect and doesn't prove anything. So far we agree.

What you're saying about zero pause and twice the moves makes no sense though. As you can see in my long post, my average PLL recognition time makes the RUD 2-twist a lot better for me, even if I can't finish recognition before OLL execution. That being said, I CAN actually do that about 90% of the time, and I haven't even practiced that much. I'm pretty sure that it will be close to 100% with a little more practice.

If you can't finish the recognition before you complete the RUD 2 twist, then you are still going to have a pause to recognize the PLL, in which case you have done basically double the moves of the normal OLL (which mind you only does a 3 cycle of corners so you would have partial information going into PLL just the same) and still have a pause (albeit probably smaller pause). I don't think anyone will argue that the 2twist is faster than the OCLL alg and so you are adding in more moves to not really get much out of it besides extra risk for locking up.

 

[Aergyl]

If you can't finish the recognition before you complete the RUD 2 twist, then you are still going to have a pause to recognize the PLL, in which case you have done basically double the moves of the normal OLL (which mind you only does a 3 cycle of corners so you would have partial information going into PLL just the same) and still have a pause (albeit probably smaller pause). I don't think anyone will argue that the 2twist is faster than the OCLL alg and so you are adding in more moves to not really get much out of it besides extra risk for locking up.

If I cant't finish recognition before I complete the RUD 2-twist, the execution time of LL is going to be
(Execution time of OLL 23) + (PLL recognition time) + (PLL execution time)
with the standard OLL 23 and
(Execution of half the 2-twist) + (PLL recognition time) + (PLL execution time)
with the 2-twist. The recognition time isn't affected by finishing OLL execution first. And I don't think anyone will argue that HALF of the 2-twist is slower than the OCLL alg. Your arguments makes no sense, except for maybe the lock up part. I've adressed that in my long analysis though, and I have actual statistical evidence for why that's not any problems for me. It might be a problem for you though, I don't know.

Also, just to be clear, you can do partial PLL recognition for the 2-twist as well during the first half, speeding up PLL recognition in the exact same way, so the PLL recognition time is still going to be pretty much the same.

 

[OreKehStrah]

If I cant't finish recognition before I complete the RUD 2-twist, the execution time of LL is going to be
(Execution time of OLL 23) + (PLL recognition time) + (PLL execution time)
with the standard OLL 23 and
(Execution of half the 2-twist) + (PLL recognition time) + (PLL execution time)
with the 2-twist. The recognition time isn't affected by finishing OLL execution first. And I don't think anyone will argue that HALF of the 2-twist is slower than the OCLL alg. Your arguments makes no sense, except for maybe the lock up part. I've adressed that in my long analysis though, and I have actual statistical evidence for why that's not any problems for me. It might be a problem for you though, I don't know.

Also, just to be clear, you can do partial PLL recognition for the 2-twist as well during the first half, speeding up PLL recognition in the exact same way, so the PLL recognition time is still going to be pretty much the same.

The standard U OCLL algs preserve a 2x2 block in the U layer. So you can use that to partially predict PLL as well. So if you are doing the RUD 2Twist and still only partially predicting PLL, you are probably introducing more risk for locking up and doing more moves than predicting the PLL from the standard alg. That is my point. If you are going to do this, you should practice it to the point you will always know the PLL before you finish the 2twist, or you are doing extra moves and adding risk for little prediction advantage over the standard algs.

I also don't have this issue since I just use the ZBLLs : p

 

[Aergyl]

Are you saying

The standard U OCLL algs preserve a 2x2 block in the U layer. So you can use that to partially predict PLL as well. So if you are doing the RUD 2Twist and still only partially predicting PLL, you are probably introducing more risk for locking up and doing more moves than predicting the PLL from the standard alg. That is my point. If you are going to do this, you should practice it to the point you will always know the PLL before you finish the 2twist, or you are doing extra moves and adding risk for little prediction advantage over the standard algs.

I also don't have this issue since I just use the ZBLLs : p

Sure, if your PLL recognition is very fast (possibly by partially predicting parts during OLL), the standard OLL might be faster for some people. I agree on that.

By the way, I think I explained one part poorly, which seems to have caused some misunderstanding. Just like with the standard algorithm, you can do partial PLL prediction with the 2-twist, during the first half. That information can then be used to speed up the PLL recognition during the second half of the execution, not after it. Therefore, I think the PLL recognition time of the 2-twist (starting at the second half) can be just as fast as the PLL recognition time (starting after the OLL) of the standard, even when using partial PLL recognition to speed them up. It's unfair to compare the 2-twist without partial recognition with the standard with partial recognition, when it's just as easy to do for both. Do you agree so far?

 

[Aergyl]

The standard U OCLL algs preserve a 2x2 block in the U layer. So you can use that to partially predict PLL as well. So if you are doing the RUD 2Twist and still only partially predicting PLL, you are probably introducing more risk for locking up and doing more moves than predicting the PLL from the standard alg. That is my point. If you are going to do this, you should practice it to the point you will always know the PLL before you finish the 2twist, or you are doing extra moves and adding risk for little prediction advantage over the standard algs.

I also don't have this issue since I just use the ZBLLs : p

I should probably add that one of the best ways of doing partial PLL prediction with the (first half of the) 2-twist is to simply look at LUB + LU + UFL. That's a very easy way of predicting 3 stickers in a row used for PLL recognition (in the second half), which is very similar to the 3 stickers in a row you can see from the 2x2 block. In both cases you know half of the colors used in PLL recognition, and they're consecutive in both cases. They only differ by their position. This clearly shows that PLL recognition time should be about the same for both algorithms.

 

[ethen]

IDK how you guys are doing this lol, im not that good at all. you guys are goated

 

[Aergyl]

IDK how you guys are doing this lol, im not that good at all. you guys are goated

I'm not sure what you're referring to, but thank you

 

[OreKehStrah]

Are you saying

Sure, if your PLL recognition is very fast (possibly by partially predicting parts during OLL), the standard OLL might be faster for some people. I agree on that.

By the way, I think I explained one part poorly, which seems to have caused some misunderstanding. Just like with the standard algorithm, you can do partial PLL prediction with the 2-twist, during the first half. That information can then be used to speed up the PLL recognition during the second half of the execution, not after it. Therefore, I think the PLL recognition time of the 2-twist (starting at the second half) can be just as fast as the PLL recognition time (starting after the OLL) of the standard, even when using partial PLL recognition to speed them up. It's unfair to compare the 2-twist without partial recognition with the standard with partial recognition, when it's just as easy to do for both. Do you agree so far?

I'm comparing them both with prediction. If you're able to do partial prediction with either, then I don't see a reason to do an RUD 2twist instead of OCLL.

I should probably add that one of the best ways of doing partial PLL prediction with the (first half of the) 2-twist is to simply look at LUB + LU + UFL. That's a very easy way of predicting 3 stickers in a row used for PLL recognition (in the second half), which is very similar to the 3 stickers in a row you can see from the 2x2 block. In both cases you know half of the colors used in PLL recognition, and they're consecutive in both cases. They only differ by their position. This clearly shows that PLL recognition time should be about the same for both algorithms.

Especially if you say the recognition time should be about the same for both, why not do the standard OCLL which is half the moves of the RUD 2twist.

 

[Aergyl]

I'm comparing them both with prediction. If you're able to do partial prediction with either, then I don't see a reason to do an RUD 2twist instead of OCLL.

Especially if you say the recognition time should be about the same for both, why not do the standard OCLL which is half the moves of the RUD 2twist.

I can't really tell from your response if you actually think the PLL recognition time (with or without prediction) is about the same, but I'm going to assume that's the case (correct me if I'm wrong though). Assuming that, you're disregarding a very important detail. I'll try to explain that and precisely when the RUD 2-twist has potentiaI.

First of all, let A, B and C be your average execution time of the OCLL, the 2-twist, and half of the 2-twist (including the U'), respectively. To make a fair comparison, the algorithms should be executed with about the same amount risk (instead of saying that the 2-twist is risky, just slow down the execution as much as you need). Also, let R be your average PLL recognition time (same for both methods), and P your average PLL execution time (also essentially the same).

Then, the average time tA it takes to solve LL with the OCLL is clearly tA = A + R + P. As for the 2-twist, there are two scenarious. In the first scenario, we finish recognition before the end of the OLL execution, in which case the average time tB1 it takes to solve LL is clearly just tB1 = B + P. In the second scenario, we finish recognition after the end of the OLL execution, and the average time tB2 it takes to solve LL then becomes tB2 = C + R + P (NOT B + R + P, as you're suggesting).

Now, since C is clearly smaller than A, it follows that tB2 < tA, proving that the 2-twist is always faster in the second scenario. As for the first scenario, it's pretty obvious that tB1 < tA precisely when B < A + R. In other words, the 2-twist is faster if its execution is faster than the execution of the OCLL and the PLL recognition time together. Since A is clearly smaller than B, this simply means that the OCLL can be faster if your PLL recognition is faster than (B - A). But if it's slower than that it's going to be worse, no matter how much slower it is, and no matter if you can finish PLL recognition before the end of the 2-twist or not (contrary to what you're suggesting).

I hope that cleared things up!

 

[Aergyl]

If I wasn't clear, I admit that getting used to the recognition for the 2-twist will take some practice (as with most things we're not used to), but I think it has potential to be just as fast as for the standard OLL.