JDAW6
Legend
- Joined
- Mar 4, 2023
- Messages
- 5,793
- Location
- Stuck in 2016
- WCA ID
- 2023KOTW01
- YouTube
- Visit Channel
I can predict some of the blocks in pll while doing at full speed but only on some of the olls like oll 33, 37 , 24 , 6 and 5.
OLL execution and PLL recognition at the same!
- Thread starter Aergyl
- Start date
Do you mean with the RUD 2-twist? Assuming your 2-sided PLL recognition is good, you don't have to slow down at all. That's why it has potential to be faster than normal OLL + PLL for OLL 23. If you disagree, I would love to hear an actual logical argument against itHow much slower must you execute OLL to have enough time to predict the PLL before finishing the OLL?
Billabob
Regular
- Joined
- Jul 12, 2018
- Messages
- 227
Have you tried timing LL with this? I'd love to see some actual tests because this looks slow and directly worse than just doing OLL -> PLL
Yeah, I've done a lot of testing with it. I also thought it would be slower at first lol. I'll come back soon with some results!
So, I'm not sure how to compare my method with standard OLL + PLL in the best way, but I tried a couple of different things. First, I made an ao12 of my method + a random Jb Perm (random angle and AUF), and compared it with the standard OLL + random Jb Perm. In both cases, I started the execution not knowing the angle of the Jb Perm. My method got a 1.99 ao12, and the standard method got a 2.38 ao12. The reason why I limited myself to only Jb Perm, was to get rid of as much variance as possible. Even though the only method that actually benefits from limiting the PLL's to only one (making recognition faster), my method was still significantly faster.
I also tried another ao12 with random Jb perms and the standard OLL algorithm, knowing the angle beforehand, and I got a 2.01 ao12. It's so close to my method, that I can't say for sure which one is actually faster, but my theory is that the reason they're so close is because the OLL ends with thumbs down, meaning that there's still a pause between OLL and PLL. As I mentioned before, the difference in OLL execution time is actually very small (about 0.2s for me), so I think it makes sense.
This of course isn't a perfect comparison against ROLL/JOLL with the standard algorithm, but it's at least something. Please let me know if you have any ideas for making a better comparision
ruffleduck
Veteran
My logical argument is that OLL 23 is sub 0.7Do you mean with the RUD 2-twist? Assuming your 2-sided PLL recognition is good, you don't have to slow down at all. That's why it has potential to be faster than normal OLL + PLL for OLL 23. If you disagree, I would love to hear an actual logical argument against it
OreKehStrah
Veteran
In order to make a better comparison, you should do maybe an Ao50 with PLL scrambles then twisting the corner without looking. Knowing ahead of time it is J perm is going to skew the results, and not every PLL is equally easy to recognize, especially while turns are being made.So, I'm not sure how to compare my method with standard OLL + PLL in the best way, but I tried a couple of different things. First, I made an ao12 of my method + a random Jb Perm (random angle and AUF), and compared it with the standard OLL + random Jb Perm. In both cases, I started the execution not knowing the angle of the Jb Perm. My method got a 1.99 ao12, and the standard method got a 2.38 ao12. The reason why I limited myself to only Jb Perm, was to get rid of as much variance as possible. Even though the only method that actually benefits from limiting the PLL's to only one (making recognition faster), my method was still significantly faster.
I also tried another ao12 with random Jb perms and the standard OLL algorithm, knowing the angle beforehand, and I got a 2.01 ao12. It's so close to my method, that I can't say for sure which one is actually faster, but my theory is that the reason they're so close is because the OLL ends with thumbs down, meaning that there's still a pause between OLL and PLL. As I mentioned before, the difference in OLL execution time is actually very small (about 0.2s for me), so I think it makes sense.
This of course isn't a perfect comparison against ROLL/JOLL with the standard algorithm, but it's at least something. Please let me know if you have any ideas for making a better comparision
That is kind of a logical argument, except that you completely forgot to compare it with how fast the RUD 2-twist is. If OLL 23 is sub 0.7 for you, I wouldn't be surprised if you can execute the RUD 2-twist sub 0.9, but correct me if I'm wrong!My logical argument is that OLL 23 is sub 0.7
ruffleduck
Veteran
I can, but why would I bother? Using the back mirror of the standard OLL 23 alg from the one in your video, I can predict the important part of PLL recog anyway without slowing down. Besides, executing 2-twist fast in a solve is inconsistent. Standard is much more stable.
edit: 1000th message
If you're going to use risk as an argument, it's better to compare how fast you can execute both of them consistently, starting from homegrip (assuming that's how you're holding the cube when doing OLL recognition). Also, you have to consider how fast your PLL recognition actually is. If you pause longer than how much faster your OLL is than the 2-twist, the 2-twist is going to be faster. Otherwise it's slower. It's pretty simple actually. Of course, none of that matters if you're simply not interested in the methodI can, but why would I bother? Using the back mirror of the standard OLL 23 alg from the one in your video, I can predict the important part of PLL recog anyway without slowing down. Besides, executing 2-twist fast in a solve is inconsistent. Standard is much more stable.
edit: 1000th message
Hmm, I might try that! But I get the feeling that it's not the best way to get accurate results, since it introduces a lot of variance caused by PLL execution.
Also, recognizing the PLL while turns are being made is no problem at all, since most of the stickers used for 2-side PLL recognition don't move at all. Admittedly, it takes some practice to getting used to imagining the last sticker, but it's very easy to do.
So
So, I'm not sure how to interpret the results, but I just did what you suggested. I got a 3.35 ao50 with the standard OLL, and 2.97 ao50 with my method.
OreKehStrah
Veteran
It is the most accurate result. You don’t know what PLL case you’re gonna get
The problem with that is that there's a lot of variance in PLL, both when it comes to what cases you get, and how well you manage to execute them. Sometimes you're lucky and get a lot of good cases, and sometimes you lock up a lot. That's why I chose Jb Perm, since it pretty much gets rid of both of those problems (since it's very consistent for me). Admittedly, it's got some other problems though.
On the other hand, with a sufficiently big average, the results are going to become more accurate, but I doubt that 50 is enough. I think there's a better way of getting a pretty accurate results, which I'll show you soon!
For anyone interested, I've got some decently accurate statistics, supporting why this method is indeed faster for me for OLL 23. I'm going to explain in detail what I did, and I'll also explain why that makes it faster, and how you can figure out if it has potential to be faster for you or not.
First of all, I did an ao48 to figure out what my average PLL recognition time is. I did that by doing a random PLL scramble + Sune ((if you use ROLL/JOLL, setting up OLL 23 is better), without looking at the cube. Then I executed the Anti-Sune as fast as I could, followed by solving the PLL. I recorded 48 such solves and frame counted the pause between the last move of OLL and the first move of PLL. The result was 0.55s, and I'm going to call that number R.
Then I timed the standard OLL 23 (which I'll refer to as A) and the RUD 2-twist (which I'll refer to as B) in two different ways. First of all, I wanted to know how fast I can execute them (starting from homegrip), so I recorded a lot of attempts, trying to execute them as fast as I could. I then frame counted the fastest attempt. For A, the result was 0.8s (which I'll refer to as A1), and for B it was 0.87s (which I'll refer to as B1).
I also wanted to know how fast A and B are, when I execute them at a speed as fast as possible, but with little risk of locking up (which is the speed I will normally aim for during a solve). I did this by executing them over and over, adjusting the speed little at a time, until I hit a point where I locked up a lot. Then I recorded the execution of them at a speed just below that. I did 9 consistent executions in a row for each algorithm, and I took the average of that. The result was 1.04 for A (which I'll refer to as A2), and 1.09 for B (which I'll refer to as B2).
I also considered the first half of B including the U' (which I'll refer to as C). I did the same thing as for A and B, and got C1 = 0.47s (the fastest I can execute C) and C2 = 0.59s (the ao9 of C executed at a consistent speed).
Just to make things more clear, let P be the average time it takes for you to solve PLL. As you'll see in a moment, that number doesn't actually matter at all though.
Now, assuming the regrip after A is faster than R, it should be pretty obvious that the average time it takes to solve LL with A is
TA1 = A1 + R + P
or
TA2 = A2 + R + P
depending on how much you're willing to risk.
As for B, it's slightly more complicated. First of all, I'm going to assume that the PLL recognition when using B is just as fast as R. This might not be true at first since you're not used to the special recognition technique, but I believe that it's not too hard to achieve with practice.
If we ignore cancellations that can be made sometimes, the average time it takes to solve LL with B is approximately
TB1 = max(B1, C1 + R) + P
or
TB2 = max(B2, C2 + R) + P
depending on how much you're willing to risk. We need to use the max expression to make sure that the time counted before starting PLL execution is always at least B1/B2, no matter how fast you recognize PLL.
Now, in order to compare which one is faster, all we care about is the time difference
D1 = TA1 - TB1 = A1 + R + P - max(B1, C1 + R) - P = A1 + R - max(B1, C1 + R) = A1 - max(B1 - R, C1)
or
D2 = TA2 - TB2 = A2 + R + P - max(B2, C2 + R) - P = A2 + R - max(B2, C2 + R) = A2 - max(B2 - R, C2)
depending on how consistent you want to execute LL. As you can see, we got rid of P completely, which makes it easy to evaluate the expressions. For me, D1 = 0.33 and D2 = 0.45, which clearly indicates that (assuming my measurement is accurate) B is significantly faster for me, no matter if I try to execute as fast as possible or slightly slower for consistency.
Of course, you don't have to take my word for it, but if you're interested in seeing if B has potential for you, all you have to do is what I did here, but with your numbers instead of mine. I also did an actual ao50 of solving LL with both A and B, and the time difference between them was 0.38s, just between D1 and D2 lol.
Also, please let me know if you think there are any flaws in my logic! I could potentially have missed something important.
First of all, I did an ao48 to figure out what my average PLL recognition time is. I did that by doing a random PLL scramble + Sune ((if you use ROLL/JOLL, setting up OLL 23 is better), without looking at the cube. Then I executed the Anti-Sune as fast as I could, followed by solving the PLL. I recorded 48 such solves and frame counted the pause between the last move of OLL and the first move of PLL. The result was 0.55s, and I'm going to call that number R.
Then I timed the standard OLL 23 (which I'll refer to as A) and the RUD 2-twist (which I'll refer to as B) in two different ways. First of all, I wanted to know how fast I can execute them (starting from homegrip), so I recorded a lot of attempts, trying to execute them as fast as I could. I then frame counted the fastest attempt. For A, the result was 0.8s (which I'll refer to as A1), and for B it was 0.87s (which I'll refer to as B1).
I also wanted to know how fast A and B are, when I execute them at a speed as fast as possible, but with little risk of locking up (which is the speed I will normally aim for during a solve). I did this by executing them over and over, adjusting the speed little at a time, until I hit a point where I locked up a lot. Then I recorded the execution of them at a speed just below that. I did 9 consistent executions in a row for each algorithm, and I took the average of that. The result was 1.04 for A (which I'll refer to as A2), and 1.09 for B (which I'll refer to as B2).
I also considered the first half of B including the U' (which I'll refer to as C). I did the same thing as for A and B, and got C1 = 0.47s (the fastest I can execute C) and C2 = 0.59s (the ao9 of C executed at a consistent speed).
Just to make things more clear, let P be the average time it takes for you to solve PLL. As you'll see in a moment, that number doesn't actually matter at all though.
Now, assuming the regrip after A is faster than R, it should be pretty obvious that the average time it takes to solve LL with A is
TA1 = A1 + R + P
or
TA2 = A2 + R + P
depending on how much you're willing to risk.
As for B, it's slightly more complicated. First of all, I'm going to assume that the PLL recognition when using B is just as fast as R. This might not be true at first since you're not used to the special recognition technique, but I believe that it's not too hard to achieve with practice.
If we ignore cancellations that can be made sometimes, the average time it takes to solve LL with B is approximately
TB1 = max(B1, C1 + R) + P
or
TB2 = max(B2, C2 + R) + P
depending on how much you're willing to risk. We need to use the max expression to make sure that the time counted before starting PLL execution is always at least B1/B2, no matter how fast you recognize PLL.
Now, in order to compare which one is faster, all we care about is the time difference
D1 = TA1 - TB1 = A1 + R + P - max(B1, C1 + R) - P = A1 + R - max(B1, C1 + R) = A1 - max(B1 - R, C1)
or
D2 = TA2 - TB2 = A2 + R + P - max(B2, C2 + R) - P = A2 + R - max(B2, C2 + R) = A2 - max(B2 - R, C2)
depending on how consistent you want to execute LL. As you can see, we got rid of P completely, which makes it easy to evaluate the expressions. For me, D1 = 0.33 and D2 = 0.45, which clearly indicates that (assuming my measurement is accurate) B is significantly faster for me, no matter if I try to execute as fast as possible or slightly slower for consistency.
Of course, you don't have to take my word for it, but if you're interested in seeing if B has potential for you, all you have to do is what I did here, but with your numbers instead of mine. I also did an actual ao50 of solving LL with both A and B, and the time difference between them was 0.38s, just between D1 and D2 lol.
Also, please let me know if you think there are any flaws in my logic! I could potentially have missed something important.
Last edited:
OreKehStrah
Veteran
Who cares if there’s a lot of variance in PLL? Get good and reduce it then. But the simple fact that you are trying to dodge is that you CANNOT make a claim about something being better when you are only setting things up to produce favorable results. By just using J perm you’re effectively just practicing this on 4 ZBLLs out of 72. So yeah, you’re gonna get faster at recognizing them with practice but you’re probably gonna suck at recognizing thing like G perms from diff angles.
You aren’t going to have any control about what PLL you are going to get in real solves. So if you are saying “it’s good when I get J perm but I’m screwed when it’s Gb perm” or whatever, that means that you cannot claim it’s actually faster.
I’d also rather take the data from 50 attempts with random PLLs than 10000 biased attempts with just J perms.
Lm
Also, the fact that you completely ignore the fact that I actually did an ao50 is just hilarious.
Do you realize that setting up Jb perms literally only works in the favor of the standard OLL? Not knowing the PLL beforehand will slow down my recognition a very small amount, and that just works in the favor of my method. Also, who said recognition was a problem? I was talking about the variance caused by PLL execution, not the recognition. And nobody ever said I'm using that as practice lol. That being said, I never said that my ao12 of Jb Perms was a perfect comparison, and I agree that it doesn't prove anything.
Also, the fact that you completely ignore the fact that I actually did an ao50 is just hilarious.
OreKehStrah
Veteran
Doing an Ao50 is something I would constitute as practice.
Recognition is objectively a problem that you are not taking into account. PLLs are not equally easy to recognize from a given angle. J perm has big blocks which makes it easier to recognize than a G perm like I mentioned previously. The reason I am pointing this out is not for comparison to doing normal OLL, but to point out your own data might be misleading to yourself because of the limited sample. IE, you need to absolutely be able to nail the recognition and have ZERO pause going into the PLL or you will have done twice the moves to orient corners and still have to stop and recognize the case.
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 finishing 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.
Last edited:
