• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 35,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

Robert-Y

Member
Joined
Jan 21, 2009
Messages
3,287
Location
England
WCA
2009YAUR01
YouTube
Robert271291
On the wikis PLL page, it posts the most common algs first, right? Well, The first Y-perm is that horrible 17 move one. I have come up with a 13 move one. R' U' Lw D2' Lw' U R Dw R2 U' R2 U' R2 Never again will I use the 17 move one.
Erm... it's still 17 moves... People really need to stop measuring algorithm length in HTM and switch to QTM (or perhaps ETM) instead. Any double turn is clearly going to take longer to execute than a quarter turn. QTM or ETM is definitely a far superior measure. You know it makes sense...
 

elrog

Member
Joined
Jan 31, 2013
Messages
514
Location
U.S.A.
YouTube
elrog3
Erm... it's still 17 moves... People really need to stop measuring algorithm length in HTM and switch to QTM (or perhaps ETM) instead. Any double turn is clearly going to take longer to execute than a quarter turn. QTM or ETM is definitely a far superior measure. You know it makes sense...
I can do a single 180 tun quicker than 2 seperate 90s. I guess you would also consider a slice move 2 turns even though its only a 90 degree turn and is just as quick as any other turn. QTM is just as inaccurate.
 

Robert-Y

Member
Joined
Jan 21, 2009
Messages
3,287
Location
England
WCA
2009YAUR01
YouTube
Robert271291
You can do ANY double turn faster than ANY two separate quarter turn? Really? A slice move is just as quick as any other turn? What? I'm pretty sure E and S take longer to execute than most turns. What are you saying is inaccurate about QTM? I'm arguing that if you simply want to judge an algorithm's speed quality based on its move length alone, QTM/ETM would be better than HTM
 

elrog

Member
Joined
Jan 31, 2013
Messages
514
Location
U.S.A.
YouTube
elrog3
I'm not saying that a shorter algorithm is always better than a longer one, but to an extent it is. I'd like to see you do a 20 move algorithm consisting of only quarter turns quicker than I can do a 10 move algorithm consisting of quarter turns, half turns, and slices. Also, I don't do algorithms with S in them ever because its way to hard to preform. There are a couple of algorithms I use with E. Heres one of them: (PBL on 3x3 preserving middle layer) F2 R E2 L2 E2 R' F2. Here's a F perm I came up with by quirking with one that qqwref gave me: M' U2 Lw' U Rw' U2 Lw U' (L' M) U2 (L' Rw'). Hope you guys like it.
 

Robert-Y

Member
Joined
Jan 21, 2009
Messages
3,287
Location
England
WCA
2009YAUR01
YouTube
Robert271291
I'm not saying that a shorter algorithm is always better than a longer one, but to an extent it is.
I know you're not saying this; at no point have I disagreed with you on that, but you claimed that your Y perm is 13 moves. This is true if we measure it in HTM, but really you should be measuring the move length with a better metric system such as QTM or ETM. It's 17 moves in QTM which is the same length as the standard Y perm.

Take for example these E perms:

1)F2 U R2 U' L2 D B2 R2 D' L2 U F2 U' F2
2)R U' R' D R U R' D' R U R' D R U' R' D'

The first one is 14 moves in HTM and the second one is 16 moves in HTM. But why is the second one so much better than the first one (in most people's experiences)?
Well one of the reasons is because we need to cover more "distance" with the first one. The first one is 22 moves in QTM! But the second one is still 16 moves in QTM. Can't you see that this is why I think algorithms shouldn't be measured in HTM for speed. With enough practice, you can easily execute the second algorithm under 1 second. Many people can do this. However the first one is basically impossible to execute under a second. It is longer. I reckon even 2 seconds might be difficult. Prove me wrong if you want...

I'd like to see you do a 20 move algorithm consisting of only quarter turns quicker than I can do a 10 move algorithm consisting of quarter turns, half turns, and slices.
What would be the point of this? One algorithm is 20 moves in QTM, and you haven't told me how long the other algorithm is? You want to compare an algorithm which is 20 moves long against another algorithm with an unknown move length? Also I'm not trying to sound like an elitist but I'm more experienced than you, I probably turn faster than you. Even if I can beat you with your algorithm, so what? What does that tell us? I turn faster? So what?

Anyway, please stop measuring your algorithms for speed in HTM and use something better such as QTM or ETM.
 

omer

Member
Joined
Dec 1, 2012
Messages
205
Location
Israel
You guys are discussing which algorithm is better while ignoring the only thing that actually matters: How fast can you execute the algorithm? It doesn't matter if it's long HTM or QTM, short HTM or QTM, finger-tricky, 2-gen, 5-gen, etc. . The ONLY thing that matters is how fast you can execute it.

I can do R2 U2 by holding the bottom right corners with my thumb and index finger just as fast as I would do a single R2 regularly. The turns themselves don't matter if it's possible to do them really fast in a special way like in this example.
This H-perm for example: (R2 U2) R (U2 R2) U2 (R2 U2) R (U2 R2)
HTM it's very short, only 11 moves.
QTM it's very very long, 20 moves!
But these things don't matter. If you do it like a robot without finger tricks and simply execute the algorithm then these things would matter, this specific algorithm would be slow - a really bad H perm. But if you do it using the finger trick I described above, holding the bottom right corners and doing the R2 U2 and U2 R2 without letting go of them, while executing the moves outside the parenthesis with the left hand, this is an amazing, fast algorithm.

My point is that an algorithm has a lot of properties, saying one algorithm is better than the other because it's shorter is ridiculous - what matters is how all these properties work together. That determines how fast the algorithm can be executed.
 

elrog

Member
Joined
Jan 31, 2013
Messages
514
Location
U.S.A.
YouTube
elrog3
Well, it would be too difficult to come up with a system that measures how long a algorithm takes by the speed that you can preform the different moves in because everyone is different. It would also depend on how quickly you can tranistion from one move to another. So how about we forget I ever compared move counts and we can just post the algs here for people to use if they wish to do so.
 

Robert-Y

Member
Joined
Jan 21, 2009
Messages
3,287
Location
England
WCA
2009YAUR01
YouTube
Robert271291
I'm arguing that if you simply want to judge an algorithm's speed quality based on its move length alone, QTM/ETM would be better than HTM
Notice the "if"

When I'm trying to search for algorithms with cube explorer and I need to filter out bad algorithms. I don't want to keep trying out huge lists of algorithms when I can simply filter out many algorithms based on move length in QTM. Obviously there's a chance that I might miss out on something decent but it doesn't seem to happen that much for me. But yeah, I find that it speeds up the process of finding good algorithms, I'm sure others will agree e.g. Brest

@Omer I try every single algorithm which I discover and want to share. If an algorithm for speed wasn't fast, why share it? There's no need to mention how fast you can execute the algorithm is the most important thing. (At least to me...)
 
Last edited:

Robert-Y

Member
Joined
Jan 21, 2009
Messages
3,287
Location
England
WCA
2009YAUR01
YouTube
Robert271291
CLL: U no swap

R' F U' R U' R' U2' F2 R
R U' B R' U R B2 U2' R'
(B2 R2' U') (R' U R' F U' R)
(R2 B2) (U R U' B R' U R')

I can get 1 second quite comfortably with these algs. The first two start and end in "standard grip" for both hands which is great (so no need to regrip before starting the algorithm). Before I used to use: R U' R U' R U' R' U R' U R' which is fast but so unreliable in solves. http://www.youtube.com/watch?v=EouQOxfDRKA

I still use Ron' mini cube solver to this day :)
http://www.speedcubing.com/CubeSolver/MiniCubeSolver.html

I generated the algs using his solver then I sorted them in qtm using jj's tool: http://robyau-alglister.herokuapp.com/
Simply copy and paste in the algs from Ron's mini cube solver and click "go" to sort.
 

Force

Member
Joined
Mar 31, 2013
Messages
5
New OLL case Algorthm

Oll.jpg

M U (RUR'U') (R'FRF') U' M'

I have never seen this algorithm before for this particular case. I stumbled across it while experimenting with movements.

Hope it helps ya!

P.S Btw I'm new to this speedsolving forum but have been cubing for almost a year.
 

Force

Member
Joined
Mar 31, 2013
Messages
5
Its for a the Oll case in the picture. It completes the yellow side in one go. Btw what does S mean?
 
Top