# A perm (cw) In 0.47 seconds



## wlstjd2145 (Mar 11, 2012)

Maybe Youtube UWR?


----------



## Stefan (Mar 11, 2012)

16-17 frames at 30 fps = 0.53-0.57 seconds


----------



## Zarxrax (Mar 11, 2012)

which alg?


----------



## aronpm (Mar 11, 2012)

Zarxrax said:


> which alg?


 
R'UR'D2RU'R'D2R2


----------



## Iggy (Mar 11, 2012)

Wow. That's really fast.


----------



## Ickenicke (Mar 11, 2012)

I wish I could be that fast.


----------



## amostay2004 (Mar 11, 2012)

So fast @[email protected]


----------



## cityzach (Mar 11, 2012)

0_o
SUPER FAST!!


----------



## That70sShowDude (Mar 11, 2012)

Holy a-perm batman


----------



## JianhanC (Mar 11, 2012)

How was D2 done?


----------



## Sillas (Mar 11, 2012)

Fazt A-perm.


----------



## ThomasJE (Mar 11, 2012)

9 HTM / 0.47 = 19.15 TPS

That's fast. I just did 3 A-perms - 2.34, 2.34, 2.40 with R2 D2 R U R' D2 R U' R. 9 HTM / 2.34 = 3.85 TPS.

And what cube?


----------



## andyfreeman (Mar 11, 2012)

Awesome: that's 3x faster than mine.

Can you edit that video and and a slowed down version after? Like 10% speed???


----------



## NSKuber (Mar 11, 2012)

andyfreeman said:


> Awesome: that's 3x faster than mine.
> 
> Can you edit that video and and a slowed down version after? Like 10% speed???


It won't help: 10% speed means 3 frames per second. Better download video from Youtube and watch it in VirtualDub by frames.


----------



## Owen (Mar 11, 2012)

Woah, you could almost do that twice, and make it a sub-1 anti-A.


----------



## andyfreeman (Mar 11, 2012)

NSKuber said:


> It won't help: 10% speed means 3 frames per second. Better download video from Youtube and watch it in VirtualDub by frames.


 
And? What's your point? I've just downloaded it and played it at 3fps and it's fine... you can actually see what's happening


----------



## NSKuber (Mar 11, 2012)

andyfreeman said:


> And? What's your point? I've just downloaded it and played it at 3fps and it's fine... you can actually see what's happening


 
Instead of him slowing the video and uploading it again you just did it yourself. Wasn't that more convenient for everyone?


----------



## andyfreeman (Mar 11, 2012)

NSKuber said:


> Instead of him slowing the video and uploading it again you just did it yourself. Wasn't that more convenient for everyone?


 
Wouldn't it be better for everyone to see it in slow mo?


----------



## ben1996123 (Mar 11, 2012)

holy what the poop.


----------



## DYGH.Tjen (Mar 11, 2012)

Double flick D2 <3 so fast.


----------



## wlstjd2145 (Mar 12, 2012)

ThomasJE said:


> 9 HTM / 0.47 = 19.15 TPS
> 
> That's fast. I just did 3 A-perms - 2.34, 2.34, 2.40 with R2 D2 R U R' D2 R U' R. 9 HTM / 2.34 = 3.85 TPS.
> 
> And what cube?


 
Guhong Version 2 cube.


----------



## wlstjd2145 (Mar 12, 2012)

rainballdog said:


> 집에서 한번 더 하면 0.45도 뜨겠는데요 ㅋㅋ 저번에 0.46 떴으니께


 
어제 2.44+까진 해봤어요.. 가능성이 아직은 큰거같은뎀



andyfreeman said:


> Awesome: that's 3x faster than mine.
> 
> Can you edit that video and and a slowed down version after? Like 10% speed???








In slow motion.


----------



## Godmil (Mar 12, 2012)

Agh! That's too fast!


----------



## Ickenicke (Mar 12, 2012)

My A-perms is like your in slow motion


----------



## teller (Mar 12, 2012)

I don't understand how this is even possible.


----------



## Kirjava (Mar 12, 2012)

ThomasJE said:


> 9 HTM / 0.47 = 19.15 TPS


 
More like 16 TPS. Still fast though.


----------



## Florian (Mar 12, 2012)

Kirjava said:


> More like 16 TPS. Still fast though.


 
I'm pretty sure its 19


----------



## NSKuber (Mar 12, 2012)

Ickenicke said:


> My A-perms is like your in slow motion


 
Definitely agree.


----------



## Stefan (Mar 12, 2012)

Florian said:


> I'm pretty sure its 19


 
You think my video analysis is so far off while his stackmat-starting/-stopping is accurate?


----------



## Kirjava (Mar 12, 2012)

Florian said:


> I'm pretty sure its 19


 
I'm pretty sure you're wrong.


----------



## ThomasJE (Mar 12, 2012)

Stefan said:


> You think my video analysis is so far off while his stackmat-starting/-stopping is accurate?



9 HTM / 0.55 (Stefan's estimate) = 16.36. So it depends on whether you take Stefan's time or the Stackmat time.


----------



## Mollerz (Mar 12, 2012)

ThomasJE said:


> 9 HTM / 0.55 (Stefan's estimate) = 16.36. So it depends on whether you take Stefan's time or the Stackmat time.


 
And of course you take Stefan's time because it's a frame by frame analysis which is always more accurate than manual stackmat start-stop.


----------



## Godmil (Mar 12, 2012)

Yttrium said:


> And of course you take Stefan's time because it's a frame by frame analysis which is always more accurate than manual stackmat start-stop.


 
What's the error on frame counting? +/- 1/15th of a second? Does that make much of a difference? I don't have time to do the maths.


----------



## Ickenicke (Mar 12, 2012)

He wrote in the second post .53-.57


----------



## insane569 (Mar 12, 2012)

Florian said:


> I'm pretty sure its 19


 
It seems someone here wants to argue with stefan. You can totally win. Cause you know...stefan is always wrong.


----------



## Stefan (Mar 12, 2012)

Godmil said:


> What's the error on frame counting? +/- 1/15th of a second?


 
At frame x he hadn't started the alg, at x+1 he had started, at x+16 he wasn't finished, at x+17 he was. So it's 15-17 but I think 16-17 is more realistic than 15, so I said 16-17. Probably should've said ~16, though, and will do so in the future.



Yttrium said:


> frame by frame analysis which is always more accurate than manual stackmat start-stop.


 
Assuming that hardware, software and human did a proper job, yes. The camera could record non-linearly, the software could distort things (both his encoder and my viewer), and I could miscount. But yes, I do trust it more than stackmat start-stop.



insane569 said:


> It seems someone here wants to argue with stefan. You can totally win. Cause you know...stefan is always wrong.


 
Thank you so much for your support, I'm sure the arguments themselves wouldn't suffice.


----------



## ThomasJE (Mar 12, 2012)

Basically, 16 TPS and 19 TPS are both correct. It all depends on whether 0.47 or ~0.55 is the time that you believe.



Ickenicke said:


> He wrote in the second post .53-.57



So I went in the middle with 0.55.


----------



## qqwref (Mar 12, 2012)

ThomasJE said:


> Basically, 16 TPS and 19 TPS are both correct. It all depends on whether 0.47 or ~0.55 is the time that you believe.


I disagree. The time displayed on the stackmat doesn't represent the time taken to do all of the moves of the alg, so 19 TPS is not correct.

This is somewhere around 22 QTPS, though.


----------



## ThomasJE (Mar 12, 2012)

qqwref said:


> I disagree. The time displayed on the stackmat doesn't represent the time taken to do all of the moves of the alg, so 19 TPS is not correct.



That's because you believe Stefan's time. Others MAY believe the Stackmat time. Although I have to say that I tend to lean towards Stefan's time.


----------



## Stefan (Mar 12, 2012)

ThomasJE said:


> *Basically, 16 TPS and 19 TPS are both correct.* It all depends on whether 0.47 or ~0.55 is the time that you believe.


 
The calculations, not their results.

The two calculations are correct, but only one premise and only one result really is correct (or rather neither is correct, as neither can provide absolutely accurate measurement).

In other words:



ThomasJE said:


> Others MAY believe the Stackmat time


 
Believing something doesn't make it correct.


----------



## ThomasJE (Mar 12, 2012)

Stefan said:


> Believing something doesn't make it correct.


 
But we can't be 100% sure of the correct answer.


----------



## Kirjava (Mar 12, 2012)

ThomasJE said:


> But we can't be 100% sure of the correct answer.


 
It is known beyond reasonable doubt that the tps is around 16 and not 19.


----------



## Ickenicke (Mar 12, 2012)

ThomasJE said:


> But we can't be 100% sure of the correct answer.


 
But counting frames is probably more exact than stackmat timing.


----------



## Ickenicke (Mar 12, 2012)

It is hard to stop the timer perfect.


----------



## DrKorbin (Mar 12, 2012)

Though wlstjd2145's TPS is amazing, it seems to me that he began to apply moves before he lifted his hands up from the timer. This can be a reason why Stefan's time and stackmat result are different. Or am I wrong?


----------



## qqwref (Mar 12, 2012)

ThomasJE said:


> That's because you believe Stefan's time.


Belief doesn't factor into it (IIRC this isn't a theological debate). Since we don't know the exact number, the best answer we have is the one which we got with the most precise measurement, i.e. Stefan's technique. If you disagree with that, you're simply wrong.


PS: This topic is a good demonstration of why nobody seriously keeps track of PLL UWRs.


----------



## insane569 (Mar 12, 2012)

DrKorbin said:


> Though wlstjd2145's TPS is amazing, it seems to me that he began to apply moves before he lifted his hands up from the timer. This can be a reason why Stefan's time and stackmat result are different. Or am I wrong?


 
That's what I was thinking. If a small move/turn was made before the timer started(not on purpose, it's hard to make sure the timer is running at the same time you start the alg so going by frames is more accurate)then the time would be shorter and his TPS would be higher.


----------



## Stefan (Mar 12, 2012)

ThomasJE said:


> But we can't be 100% sure of the correct answer.


 
We *can* be 100% sure there is *one* correct answer. Not two different ones.


----------



## samehsameh (Mar 13, 2012)

he does about 2 moves before his hands even leave the timer. Also i would say its 17 frames (0.56s) and definately in the range 0.53s - 0.6s


----------



## Robocopter87 (Mar 13, 2012)

Amazing A perm.

Stefan vs. ThomasJE is like Albert Einstein vs. Barbie.


----------



## Czery (Mar 13, 2012)

Stefan said:


> We *can* be 100% sure there is *one* correct answer. Not two different ones.


 
Isn't this obvious?

People should do PLL times the way they do magic's. Then they can work on how fast they can pick up a cube.


----------



## StachuK1992 (Mar 13, 2012)

Then we still have problems of "ZOMG HE STOPPED WITH HIS WRISTS GUYS!!"


----------



## Cheese11 (Mar 13, 2012)

Kay guys, even if it is .57 seconds, it's still fricken' awesome! The TPS blows my socks off, and I'm not even wearing any!


----------



## Cool Frog (Mar 13, 2012)

I wish I could D2 =(

SO FAST.


----------



## insane569 (Mar 13, 2012)

Cool Frog said:


> I wish I could D2 =(
> 
> SO FAST.


 
D2 is the new M2.


----------



## Rpotts (Mar 13, 2012)

Left ring-pinky is where it's at, though tons of people seem to be super fast with ring-ring. I dun get it.


----------



## speedpicker (Mar 13, 2012)

Does anyone know for sure whether this is ring then pinky or pinky then ring?


----------



## Escher (Mar 13, 2012)

Czery said:


> Isn't this obvious?
> 
> People should do PLL times the way they do magic's. Then they can work on how fast they can pick up a cube.


 
This is what Ravi has been saying for ages, iirc...

It's fun to try, really really hard to get sub 1 with a lot of PLLs, I've managed with J and A only.


----------



## Kirjava (Mar 13, 2012)

I've never seen someone sub1 a stackmat PLL, or even heard of it happening. I keep trying to get Breandan to do it.


----------



## wlstjd2145 (Mar 13, 2012)

Um, I agree that the tps is around 16 since I saw the vid in slow motion  
I think you don't need to be confused anymore.


----------



## TimMc (Mar 13, 2012)

Ickenicke said:


> It is hard to stop the timer perfect.


 
If only there were some kind of Rubik's timer where it would start when you pick the cube up, so that it's no longer touching the surface of the timer, and then stop when you place it back down after the solve. :-(

EDIT: What's the point of calculating TPS for something that takes almost half a second? Are there any trends among competitors where the sustained speed drops off? Is the saturation point 1 second?

Tim.


----------



## Kirjava (Mar 13, 2012)

TimMc said:


> If only there were some kind of Rubik's timer where it would start when you pick the cube up, so that it's no longer touching the surface of the timer, and then stop when you place it back down after the solve. :-(



There is.



TimMc said:


> EDIT: What's the point of calculating TPS for something that takes almost half a second?


 
Similar to why you'd record the time taken to do it. It measures how quickly/fast something was performed.


----------



## Ickenicke (Mar 13, 2012)

Kirjava said:


> I've never seen someone sub1 a stackmat PLL, or even heard of it happening. I keep trying to get Breandan to do it.



Do you mean by picking up the cube also?


----------



## Kirjava (Mar 13, 2012)

uh, yes >_>


----------



## Escher (Mar 13, 2012)

Kirjava said:


> I've never seen someone sub1 a stackmat PLL, or even heard of it happening. I keep trying to get Breandan to do it.


 
I'll try and film a J + stackmat later


----------



## Kirjava (Mar 13, 2012)

I will film E2ME2M' PLL and be the first LOL JK


----------



## RTh (Mar 13, 2012)

I can do A-Perm's in 0.65 on average, peaks 0.57. But 0,47... WOW

(Which based on a simple camera frame by frame analysis turns out to be 0,69 ao12, and 0.61 best time).


----------



## fbgrac (Mar 18, 2012)

*Wrong...*

His hands was still in contact with the timer when making the first move, because the hand "rolled" to the inferior part of the sensor until loose contact. It looks normal, but "rolling" his hands on the sensors made the timer start later than usual (sufficiente for the lasting 0.1). Because of this, the 0.47 is not valid and the question about timer precision is wrong. This solve sould be made starting timer with hands down flat, like official tournaments. I don't like starting timers with cube already on the hands...


----------



## cubingawsumness (Mar 18, 2012)

fbgrac said:


> His hands was still in contact with the timer when making the first move, because the hand "rolled" to the inferior part of the sensor until loose contact. It looks normal, but "rolling" his hands on the sensors made the timer start later than usual (sufficiente for the lasting 0.1). Because of this, the 0.47 is not valid and the question about timer precision is wrong. This solve sould be made starting timer with hands down flat, like official tournaments. I don't like starting timers with cube already on the hands...


 
the frame by frame analysis. anyway, even if it's 0.1 secs slower than 0.47, it's still pretty amazing.


----------



## BrainOfSweden (Mar 18, 2012)

fbgrac said:


> His hands was still in contact with the timer when making the first move, because the hand "rolled" to the inferior part of the sensor until loose contact. It looks normal, but "rolling" his hands on the sensors made the timer start later than usual (sufficiente for the lasting 0.1). Because of this, the 0.47 is not valid and the question about timer precision is wrong. This solve sould be made starting timer with hands down flat, like official tournaments. I don't like starting timers with cube already on the hands...


But this timing is only for the perm. I think the way he (and most people) does it is more accurate. After all, you dont drop your cube and pick it up again before PLL  Sure, the time is a tad bit faster this way, but the official way would make the time look really slow when timing individual algs, we're only after the time the actual execution takes.


----------



## NSKuber (Mar 18, 2012)

Guys, what are you talking about? His speed and time are completely AWESOME, no matter is this 0.47 or 0.57 or something else.


----------



## rubiksarlen (Mar 18, 2012)

What's his time for ccw A-perm?


----------



## Escher (Mar 18, 2012)

BrainOfSweden said:


> But this timing is only for the perm. I think the way he (and most people) does it is more accurate. After all, you dont drop your cube and pick it up again before PLL  Sure, the time is a tad bit faster this way, but the official way would make the time look really slow when timing individual algs, we're only after the time the actual execution takes.


 
It would make doing sub 1 PLLs actually a challenge. Besides, what you said is only half-true - we don't pick up the cube before executing PLLs, but we do put it down.


----------



## Julian (Mar 18, 2012)

Escher said:


> It would make doing sub 1 PLLs actually a challenge. Besides, what you said is only half-true - we don't pick up the cube before executing PLLs, but we do put it down.


That's only if PLL is the last step, though. In the context of the Belt method, for example, it would make more sense to time the alg without pickup/putdown.


----------



## Kirjava (Mar 18, 2012)

Julian said:


> That's only if PLL is the last step, though. In the context of the Belt method, for example, it would make more sense to time the alg without pickup/putdown.


 
Because Belt is way more popular than CFOP.


----------



## Escher (Mar 18, 2012)

Julian said:


> That's only if PLL is the last step, though. In the context of the Belt method, for example, it would make more sense to time the alg without pickup/putdown.


 
Permute LAST Layer.


----------



## insane569 (Mar 18, 2012)

BrainOfSweden said:


> But this timing is only for the perm.


If the time is for the PLL then going by frames makes more sense. It gives a more accurate time then the stackmat time.


----------



## Julian (Mar 18, 2012)

Kirjava said:


> Because Belt is way more popular than CFOP.


I realize, but it should be impartial towards methods.



Escher said:


> Permute LAST Layer.


That's true.


----------



## blackzabbathfan (Mar 18, 2012)

Wow. I can't even sub-1 and H perm.


----------



## Kirjava (Mar 18, 2012)

Julian said:


> I realize, but it should be impartial towards methods.


 
I disagree.


----------



## JLarsen (Mar 19, 2012)

WRONGGGGG. The TPS was EXACTLY 16.75473920273249564020.9872736730243037.


----------



## yoohd77 (Mar 27, 2012)

다시봐도 빠르다 ㅋㅋㅋ


----------

