LCBM (Long-Comeau Belt Method) Guide and Algorithms

[irontwig]

It isn't; EOa is just orienting one ledge and one redge at the same time, EOb is just LSE. Freestyle finish is probably not the best for speed though.

 

[NaeosPsy]

Yah, some stages are too complex.
Maybe you can do PLL in 2-looks, like, you learn all the cases(and their algs or what) that can be on U or D(if you solve D corners) without separation and then x2 and do normal PLL?

 

[Erzz]

It isn't; EOa is just orienting one ledge and one redge at the same time, EOb is just LSE. Freestyle finish is probably not the best for speed though.

So, like roux, orientating the edges that would be in the blocks if there were blocks, and then LSE?

Yah, some stages are too complex.
Maybe you can do PLL in 2-looks, like, you learn all the cases(and their algs or what) that can be on U or D(if you solve D corners) and then x2 and do another normal PLL?

If you're doing it in two looks, no need to solve the D corners. Just PLL on top, x2, PLL on bottom. People say belt methods aren't practical due to high move count and alg count, this method has reasonable move count (like 60-70, I don't know how to calculate) and only 161 algs (29 of which are Fridrich).


Another example solve in OP.

Spoiler

L' B2 D' L F' R' D U2 B' F2 L' F2 B D L' B2 F2 U' F B2 R' B'
EO: y U D' R2 F [4/4] (3/3 STM)
Belt: U D R D L2 D L' [7/11] (7/10 STM)
Corner Parity: none
EPOBL: U2 x2 R' U L2 U' R2 (U D') L2 R (U' D) R' [13/24] (11/21 STM)
Separation+D Layer Corners: U2 R2 U' R2 L2 U' L2 d' M' U2 M [13/37] (11/32 STM)
PLL Parity: U' M2 U2 M2 [6/43] (4/36 STM)
EPPLL: U' D' l2 U' l2 U' D' L2 U l2 U' l2 U' D' R2 U' L2 U2 R2 U [20/63] (20/56 STM)

 

[OMGitsSolved]

Actually 51 algs are Fridrich and 42 of them are PLL.

Yah, some stages are too complex.
Maybe you can do PLL in 2-looks, like, you learn all the cases(and their algs or what) that can be on U or D(if you solve D corners) without separation and then x2 and do normal PLL?

Actually you could put the D layer corners in place as said and do top layer PLL then do a EPLL.

 

[Hershey]

Another way to reduce to <U,D,R2,L2,F2,B2>:

http://www.speedsolving.com/forum/s...ing-Discussion&p=556670&viewfull=1#post556670

The Human Kociemba method that Thom Barlow did in one video?

 

[irontwig]

The Human Kociemba method that Thom Barlow did in one video?

No, Thom first solves as a three colour cube (treating opposite colours as the same) and then finishes up.

 

[OMGitsSolved]

I think we kinda fixed the corner parity.
Here's a new solve.

B' U F' L' F2 L' D' B U' B2 D2 B2 L2 F' B2 R L' U' D' R2 D B' U L' U'

EO: D' R' U R F
Belt: D' R' D R D L2 D2 L'
Corner Parity: U R2 U R2
EPOCLL: x2 U L U' L' D' L2 U2 L' U' L'
Seperation+ D Corners: R2 D2 U R2 U' R2 U2 R2 S U2 S' U M' U2 M
EPPBL Parity: M2 U2 M2
EPPBL: D' U' L2 U D L2 U l2 U L2 R2 U L2 U' L2 U' D' L2 U' D'

Thanks qq.

 

[Hershey]

No, Thom first solves as a three colour cube (treating opposite colours as the same) and then finishes up.

How do you do that?

EDIT: He was doing it roux style...

 

[qqwref]

We had a lot of trouble with the corner parity. I'm not sure how you would recognize which moves to do for your way. If you figure something out, let us know.

The idea is this: R2 U' R2 basically replaces DRF with ULF. So what you want to do is replace one corner on D with a differently-oriented one, fixing the corner parity. If you want to rotate a bottom corner clockwise, for instance, you could replace solved with clockwise, or clockwise with counterclockwise, or counterclockwise with solved.

Another option (if you're willing to have the belt be either solved or an R2 off, which might be worthwhile for corner separation) is to simply do an R2, moving two corners to the bottom layer. I am not sure this can always create a solvable parity case, but it seems to work most of the time, so it's probably still useful (and hey, one move is better than 3 or 7, eh?). I guess, yeah, if you're going to separate later, it wouldn't hurt to leave the belt up to an R2 off - no point wasting moves keeping it that way when you're just going to intuitively mess it up later.

People say belt methods aren't practical due to high move count and alg count, this method has reasonable move count (like 60-70, I don't know how to calculate) and only 161 algs (29 of which are Fridrich).

Er, actually, I'd consider that both high move count and high alg count. 160 algs is a huge number especially if the majority of them are 20 moves long and totally unintuitive.

 

[Hershey]

Separating pieces in the U and D layers reminds me of 5x5 centers. And it's so fun!

 

[mr. giggums]

I think we kinda fixed the corner parity.
Here's a new solve.

B' U F' L' F2 L' D' B U' B2 D2 B2 L2 F' B2 R L' U' D' R2 D B' U L' U'

EO: D' R' U R F
Belt: D' R' D R D L2 D2 L'
Corner Parity: U R2 U R2
EPOCLL: x2 U L U' L' D' L2 U2 L' U' L'
Seperation+ D Corners: R2 D2 U R2 U' R2 U2 R2 S U2 S' U M' U2 M
EPPBL Parity: M2 U2 M2
EPPBL: D' U' L2 U D L2 U l2 U L2 R2 U L2 U' L2 U' D' L2 U' D'

Thanks qq.

Instead of bolded above you could do it like this.

Bottom layer(domino style, intuitive):F2 D2 R2 U M2 U' L2 U2 L2 F2 U L2 U D2 B2 R2
PLL: U' (J-Perm) U'

This reduces the algs to 56+21=77 (or just 56 if you know PLL) rather than 56+105=161.

 

[Erzz]

The idea is this: R2 U' R2 basically replaces DRF with ULF. So what you want to do is replace one corner on D with a differently-oriented one, fixing the corner parity. If you want to rotate a bottom corner clockwise, for instance, you could replace solved with clockwise, or clockwise with counterclockwise, or counterclockwise with solved.

Another option (if you're willing to have the belt be either solved or an R2 off, which might be worthwhile for corner separation) is to simply do an R2, moving two corners to the bottom layer. I am not sure this can always create a solvable parity case, but it seems to work most of the time, so it's probably still useful (and hey, one move is better than 3 or 7, eh?). I guess, yeah, if you're going to separate later, it wouldn't hurt to leave the belt up to an R2 off - no point wasting moves keeping it that way when you're just going to intuitively mess it up later.


Er, actually, I'd consider that both high move count and high alg count. 160 algs is a huge number especially if the majority of them are 20 moves long and totally unintuitive.

Hm.. I think I get it. I'll quote this in the OP.
It's not unreasonably high though. Only ~10 more than Fridrich, which is the most popular method. Almost the same amount of algs as MLGS, but yeah it is quite a bit. I doubt anyone will ever learn this method. There may be ways to further lower the number of algorithms that hasn't been discovered yet. (you could always just insert the edges in their correct places during separation and do PLL, then there's just ~80 algorithms, but move count is higher by 3-12)

Example solve of what I meant

Spoiler

B' L2 U F D F D U' F' B' D F' U' R2 L' B L2 R D2 L2 F L' U' R' B2
EO: L' D' F R' B R B' (7/7)
Belt: L F2 B2 (3/10)
Corner Parity: U L2 U2 L2 (4/14)
EPOCLL: U x2 U' L U L' U2 L' (U D') L2 U' L (11/25)
Separation: F2 U F2 D' R2 U' R2 U M' U2 M y' M' U2 M2 U2 M' D' M U2 M' D (21/46)
PLL: U' R U R' U' R' F R2 U' R' U' R U R' F' (15/61)

 

[qqwref]

Hm.. I think I get it. I'll quote this in the OP.
It's not unreasonably high though. Only ~10 more than Fridrich, which is the most popular method.

Uh, what? Fridrich has 78 algs including inverses and mirrors - this is about twice that. Even if you add F2L (and you shouldn't) you have about 40-50 more. And your PLL+EPLL algs are both harder to execute and harder to remember than all the Fridrich ones.

You could always just insert the edges in their correct places during separation and do PLL, then there's just ~80 algorithms, but move count is higher by 3-12

I'm not sure move count is higher at all, actually. I don't see any obvious way to save moves by building the separated first layer with the corners intact but the edges not; if you just build blocks, it's actually pretty efficient, and you can actually do the whole thing in <U,R2,D> and get high TPS out of it. No M'U2M inserts needed.

 

[uberCuber]

Uh, what? Fridrich has 78 algs including inverses and mirrors - this is about twice that. Even if you add F2L (and you shouldn't) you have about 40-50 more. And your PLL+EPLL algs are both harder to execute and harder to remember than all the Fridrich ones.

I think that part of his post was directed at movecount, not alg count

 

[Erzz]

Uh, what? Fridrich has 78 algs including inverses and mirrors - this is about twice that. Even if you add F2L (and you shouldn't) you have about 40-50 more. And your PLL+EPLL algs are both harder to execute and harder to remember than all the Fridrich ones.

I think that part of his post was directed at movecount, not alg count

I'm not sure move count is higher at all, actually. I don't see any obvious way to save moves by building the separated first layer with the corners intact but the edges not; if you just build blocks, it's actually pretty efficient, and you can actually do the whole thing in <U,R2,D> and get high TPS out of it. No M'U2M inserts needed.

I just tried this a couple of times, and it does seem to be <= the way we originally came up with (move count wise). However, either I'm bad at building blocks, or it's really hard to block build this quickly. Maybe it would be fast with practice, I'm not sure yet.

 

[Athefre]

The idea in this topic has some appealing steps. It reduces the cube to PLL like so many do (not that it's a bad thing for speed), but I really like the corner orienting. Fewer cases than I expected.

Like has already been discussed many times, the biggest problem with these belt methods is the belt itself. A couple of years ago I was studying these types of orient-all methods, trying to develop a version that removed many of the problems (belt restrictions, number of half-turns, move-count, look-ahead). I eventually arrived at the solution on my site. Half-belt (ZZ), few half-turns, and an average move count of ~45. I've since thought of more variations that are better (better look-ahead), but I lack the web programming knowledge to make attractive pages.

 

[Hershey]

Belt method = square-1 on 3x3?

 

[Erzz]

Belt method = square-1 on 3x3?

after orientation

 

[Kirjava]

00:35:24 <+Kirjava> TFM, Salvia and Belt fall under a method category that I like to call "bad ideas"

 

[Erzz]

00:35:24 <+Kirjava> TFM, Salvia and Belt fall under a method category that I like to call "bad ideas"

At least I've never used Salvia. I think Belt could have a reasonable move count if we used qqwref's block building idea.