A Collection of Algorithms

[teller]

Is there a Sledgehammer or similar for the first F2L case? Some nice tight low move count way to insert the last f2l pair when split and change the LL edge orientation a little bit? Besides stopping short on correcting the first case and then doing the sledgehammer?

All I can come up with is F' U2 F U (F R' F' R) That's almost as long as the VHF2L for it that will put up all four edges.

Edit added URLs and an example to try to be clear.

Hmm...you could use an actual sledgehammer: U' (R' F R F') U' (R U R')

 

[mark49152]

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.

FR'F R2U'R'U' RUR'F' RUR'U'F' - still 16 moves but flows nice like a T-perm.

 

[kunparekh18]

FR'F R2U'R'U' RUR'F' RUR'U'F' - still 16 moves but flows nice like a T-perm.

Is there a way I can do that regripless? (For the first 3 moves F R' F).

Also elrog's alg is great, maybe I will use that in the future.

Sent from my A75 using Tapatalk 2

 

[Robert-Y]

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...

 

[mark49152]

Is there a way I can do that regripless? (For the first 3 moves F R' F).

Yes - index for first F, middle for second. Jskyler91 has a video on his channel.

 

[elrog]

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]

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]

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]

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]

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]

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]

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...)

 

[Escher]

Is there a way I can do that regripless? (For the first 3 moves F R' F).

I prefer using my LH thumb to push up from DFL sticker, roughly speaking. Vid on my youtube channel ("Ask and ye shall receive").

 

[Robert-Y]

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.

 

[Julian]

CLL: U no swap

A looong time ago I came up with x' R2 U2 R' F' R U' F R' F' R L by hand, but I think I like your 4th one better.

 

[Robert-Y]

Thanks.

Hmm, they're both very similar but differ by a few moves...

 

[Julian]

Hmm, they're both very similar but differ by a few moves...

Yeah, I noticed that too. Which makes me wonder about short non-trivial sequences which do nothing.

 

[Force]

New OLL case Algorthm



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.

 

[antoineccantin]

Basically the same thing as S R U R' U' R' F R Fw'

 

[Force]

Its for a the Oll case in the picture. It completes the yellow side in one go. Btw what does S mean?