Random Cubing Discussion

[Shortey]

Random thought:

On the speedsolving wiki, Roux is said to have a 48 movecount on average. Now, if someone had 10 turns/1 second turn speed, then it would take about 4.8 seconds (pauses not included) to solve the cube. Even if someone had 9 TPS, it would take about 5.33 (pauses not included).

CFOP is said to have 56 movecount on average. If someone had 10 TPS, 5.6 seconds would be the time.

My point is that in theory, Roux might be faster than CFOP. Pretty obvious actually.

Look ahead is different... you're just basically saying that Roux is a better method because it has a lower movecount.

 

[RyanReese09]

Look ahead is different... you're just basically saying that Roux is a better method because it has a lower movecount.

You basically said what I was going to write, minus a few...selective words .

 

[Godmil]

Random thought:

On the speedsolving wiki, Roux is said to have a 48 movecount on average. Now, if someone had 10 turns/1 second turn speed, then it would take about 4.8 seconds........

Follow through with that random thought... Heise has a 40 or less move count, why do you think nobody uses it for speed solving?

 

[5BLD]

Random thought:

On the speedsolving wiki, Roux is said to have a 48 movecount on average. Now, if someone had 10 turns/1 second turn speed, then it would take about 4.8 seconds (pauses not included) to solve the cube. Even if someone had 9 TPS, it would take about 5.33 (pauses not included).

CFOP is said to have 56 movecount on average. If someone had 10 TPS, 5.6 seconds would be the time.

My point is that in theory, Roux might be faster than CFOP. Pretty obvious actually.

That is when you discard lookahead, and stuff like that.
And you can never tell anyway which is faster.
And IN THEORY, if someone could turn at infinity tps, they'd be the same speed.

Anyway, stuff like this is rather irrelevant to us as speedcubers... because we're animals. And therefore there are many variables, unlike machines.

Follow through with that random thought... Heise has a 40 or less move count, why do you think nobody uses it for speed solving?

I agree...
I use it for speedsolving on rare occasions, but that's besides the point
Actually, it's not besides the point. The reason why I'm so slow is due to lookahead limits. It is incredibly hard to look ahead with Heise.
Like in Roux, on a much, much larger scale.

 

[DaveyCow]

Well, the L sticker of that piece, so LBD.

hehe oh yeah i meant LBD (dyslexic BLD)

 

[Hershey]

lookahead limits.

How many seconds minimum does one have to pause in a Roux speedsolve"

 

[5BLD]

Minimum? I have absolutely no idea, as no one can answer that question.
Because the future of cubing is so unknown, methods developing at an alarming rate.
We will never know the answer to your question, therefore.

Actually if I were to be a pain the backside, id say minimum pausing is zero seconds. Just turn at 1 tps. And go for speed.

However the serious answer to your question is the former.

My previous answer was in respect to the present-time.
I personally pause for 1-2 seconds a solve. Maybe more. Or less.

It's a rather interesting topic to discuss, human limits, and the future of cubing.


Edit: if you were talking about the fast rouxers, we are all different (don't flame me for calling myself 'fast'. I meant that in a broader sense if you get me).
We all hesitate differently. Watch our videos to see.

 

[RNewms27]

Especially when Jessica Fridrich estimated a full step solve of her method was limited to 7 seconds. Human estimates are kind of difficult...

 

[5BLD]

Yup. As a rule of thumb, estimates are always gonna be wrong
Because right now speedcubing is so... New.

 

[cubersmith]

Especially when Jessica Fridrich estimated a full step solve of her method was limited to 7 seconds. Human estimates are kind of difficult...

We can make educated guesses though, like for example is sub 5 average possible?

 

[Hershey]

I personally pause for 1-2 seconds a solve.

Hmm... As I said:

On the speedsolving wiki, Roux is said to have a 48 movecount on average. Now, if someone had 10 turns/1 second turn speed, then it would take about 4.8 seconds (pauses not included) to solve the cube. Even if someone had 9 TPS, it would take about 5.33 (pauses not included).

Even if someone had 1-2 second pause in the solve, 5.33+2=7. Now if we look at Big Green or other fast Roux users, they might pause even less. Which means sub 7 average is definitely possible for Roux.

 

[Andrew Ricci]

Even if someone had 1-2 second pause in the solve, 5.33+2=7. Now if we look at Big Green or other fast Roux users, they might pause even less. Which means sub 7 average is definitely possible for Roux.

You can't just add up a couple of numbers and say, "Oh, look what's possible!" I don't think anyone using roux will be able to get the TPS and lookahead of a CFOP solve. Different methods work differently, and none of these estimates of yours have any backing.

 

[qqwref]

Indeed. And TPS isn't a constant number, but rather depends strongly on what turns are being done. Show me a cuber who can execute R2DBU2F'R'F'L2D2B2U2 as fast as a 2-gen U-perm, and I'll show you a cuber who calculates speed solutions using Kociemba. (That is, a cubing robot.)

 

[Rpotts]

True and oftentimes what gets people high TPS is using inefficient finger friendly solutions, adding to movecount and semi-artificially increasing TPS. This would skew a simple movecount x TPS formula for calculating "human-limit" averages.

 

[Godmil]

Agh, you're still not getting it Hershey, just cause Faz can average 9tps in a cfop solve (of which his oll/pll will be faster and cross/f2l will probably be slower) you cant expect someone to block build at that kind of speed. There are so many factors involved: Move count (like you said), amount of thought that needs to into each stage to achieve a reasonably optimal solution (of which the number of possible cases is a factor), ability to look ahead easily (looking for pieces on the bottom back will be harder than the top face), typical cube rotations required, algs being optimised for speed (not using 6-gen algs), blah blah blah...
The main thing is, some methods with lower move counts, but also require lower tps, because more time needs to be spent thinking about how to get the move count down, and performing turns that aren't ideal for speed... it's all about finding the right balance.

 

[5BLD]

Then there's the debate about people developing insane lookahead using an efficient method.
We will never know.

What we do know is we can't tell for sure that 'roux will get the WR' or 'roux will never get the WR'

It would be easy to do it simply quantitively, but we are humans, and that brings up the question 'is it humanly possible?'
Godmil basically stated what I wanted to say from here.

 

[Kirjava]

The main thing is, some methods with lower move counts, but also require lower tps, because more time needs to be spent thinking about how to get the move count down, and performing turns that aren't ideal for speed... it's all about finding the right balance.

Not focusing on the movecount so much tends to give more speed optimised solutions. Sometimes.

I don't think the 'thinking' is a big factor. Doesn't seem to slow down BigGreen's TPS.

 

[5BLD]

Hm.. Does biggreen optimise his solutions?
Have you ever watched him in slow motion?
I'm curious...

 

[oll+phase+sync]

Follow through with that random thought... Heise has a 40 or less move count, why do you think nobody uses it for speed solving?

Is a 40 move speedcubing average with Heise really possible?

 

[StachuK1992]

Regarding that^^
By 'speedcubing' do you just mean 'linear solving', or do you mean something beyond that?
If so, then I'd say yes. Heise is powerful.