M2-extension for shooting to BU

[Sakarie]

I'm using DF as buffer, but you who use FD, you have to convert everything (= change place of the two letters).

I don't know if this idea have been published, but I hadn't heard of it, so I might as well write it down.

I really like m2, that's a great method. The only bad thing about it is when you shoot to BU, which for me means 6 setupmoves (B' R2 B U R U') , and 6 resetupmoves, which means that for example DF > BU > FR would be 20 moves, way too much!

I thought about deciding setupmoves for BU so that the setupmove for piece number two (if your solving them in pairs) would cancel with the resetup for BU, but I didn't like it.

---

(This is where the actuall "method" begins
I decided to solve pairs where one of the piece is BU with a commutator, optimized for speed, not moves. There are 32 possibilities, but without mirrors (on the R/L-plane) and inverses, just 8. those 8 will be cut down to 4, so there are almost only four of them to learn.

The algorithms are:

DF > BU > RF, RD or RB: U2 M' U' [R] U M U' [R]' U'
DF > BU > RU: y U M D M' U' M D' M' y'

DF > BU > FR, UR or BR: D [R] D M' D' [R]' D M D2
DF > BU > DR: y M' U M D M' U' M D' y'

[R] means R, R' or R2, and [R]' means the invers of the [R].

All of those four are used mirrored, if the other piece is on the L-slice. All of those are also meant to be used backwards (=inversed), if the cycle is DF > xx > BU.

---

What do you think? Is it useful, or just harder (not very hard, but hardER)?

I know that there are 8-move commutators for DF > BU > BR, but I can't find them faster, since you need an annoying cube rotation, or a lot of E-slice moves.

 

[deadalnix]

It's the basic idea of my method, but I have pushed thing much more far.

If you are comming to swedish cube day, we can discuss this if you want.

 

[Sakarie]

Yes, I'm coming, and that would be great!

What part of this is the basic idea in your method?

 

[mazei]

I have yet to find out deadalnix's M2 variation.

 

[cmhardw]

DF > BU > RF, RD or RB: U2 M' U' [R] U M U' [R]' U'

I use y E R' E' L' E R E' L y' for this personally (1 fewer move than your alg).

Overall I think the method is a good idea. Commutators are quite fast for cases like these.

Chris

 

[Sakarie]

DF > BU > RF, RD or RB: U2 M' U' [R] U M U' [R]' U'

I use y E R' E' L' E R E' L y' for this personally (1 fewer move than your alg).

Overall I think the method is a good idea. Commutators are quite fast for cases like these.

Chris

Do you use that because you automatically find the 8-moves faster, or because when you choose between the two, you find yours faster? Personally, I find "my" algorithm faster to execute, even if I predid the y. Adding your cuberotation, makes me much slower on "yours".

 

[Micael]

I just use the simplest way: first orient the edges, then shoot. It is very easy and required nothing special during memorization (you have to take it into account, because if you need couple seconds to memorize a special case, then that may cancel any benefit of using it).

So for shooting to BU, I orient it with:
F2 (M U M U M U2 M' U M' U M' U2) F2 (F2 is a setup move for the buffer)
Then I just do:
M2

 

[cmhardw]

DF > BU > RF, RD or RB: U2 M' U' [R] U M U' [R]' U'

I use y E R' E' L' E R E' L y' for this personally (1 fewer move than your alg).

Do you use that because you automatically find the 8-moves faster, or because when you choose between the two, you find yours faster? Personally, I find "my" algorithm faster to execute, even if I predid the y. Adding your cuberotation, makes me much slower on "yours".

Part of the reason is I am biased on edges towards algs that are fast on a 5x5x5. The goal of BH is to create a method for solving any sized cube blindfolded, so for odd cubes the focus is on a super efficient method for 5x5x5 and up. The fact that BH edges happens to also work on a 3x3x3 is just a lucky coincidence in Daniel and my opinions.

On 5x5x5 I would certainly choose the 8 move alg over the 9 move alg in this particular case because inner e turns can be a bit easier to do than inner m turns when trying to go very fast IMO.

For 3x3x3 I do agree that your alg is much faster to execute than the 8 move version, mostly because it avoids the cube rotation.

Chris

 

[dbeyer]

BH is a set of concepts. Its a system. Not a list of algorithms. However, it's a very effient system. Your applications are only limited by your own imagination.

I have an interesting thought. Most blindfold cubist would want to change systems, but not change their habits. I believe I have found a way to compile a very fast alg list for BH edges.

The key is, every 3-cycle in the edge system can be solved in 10 moves or less. Cubist have used DF/FD as their buffer or U layer edges because of M2 and Orient First methods prior to the BH concept.

I believe the M2 mentality is limited by the move count, and solving one piece at a time. Orient First methods are limited by the extra step of orienting. Freestyle methods using U layer cubies aren't the friendliest of algs.

Well ... something better might be out there. I'll work on that very soon.

 

[Sakarie]

I just use the simplest way: first orient the edges, then shoot. It is very easy and required nothing special during memorization (you have to take it into account, because if you need couple seconds to memorize a special case, then that may cancel any benefit of using it).

So for shooting to BU, I orient it with:
F2 (M U M U M U2 M' U M' U M' U2) F2 (F2 is a setup move for the buffer)
Then I just do:
M2

My memorization will be exactly the same, since I memorixe the cycles, and not the algorithms to solve it. Your way is also good, but the goal would be to not have to spend the extra seconds, but know them instantly.

DF > BU > RF, RD or RB: U2 M' U' [R] U M U' [R]' U'

I use y E R' E' L' E R E' L y' for this personally (1 fewer move than your alg).

Do you use that because you automatically find the 8-moves faster, or because when you choose between the two, you find yours faster? Personally, I find "my" algorithm faster to execute, even if I predid the y. Adding your cuberotation, makes me much slower on "yours".

Part of the reason is I am biased on edges towards algs that are fast on a 5x5x5. The goal of BH is to create a method for solving any sized cube blindfolded, so for odd cubes the focus is on a super efficient method for 5x5x5 and up. The fact that BH edges happens to also work on a 3x3x3 is just a lucky coincidence in Daniel and my opinions.

On 5x5x5 I would certainly choose the 8 move alg over the 9 move alg in this particular case because inner e turns can be a bit easier to do than inner m turns when trying to go very fast IMO.

For 3x3x3 I do agree that your alg is much faster to execute than the 8 move version, mostly because it avoids the cube rotation.

Chris

Yes, now I understand how you mean. I agree that the u-moves on 5x5 is fast, much faster than E-moves on 3x3. But I'm not sure that the algorithms is faster anyway. But we don't have to have the same opinion, and we both might be best on "our own" algorithms.

 

[Mike Hughey]

Sakarie, I thought I'd mention - I started using what was essentially the method you first described here (my algorithms were a little different, but conceptually the same) a year and a half ago or so when I started using M2. Before I made that modification, I found M2 to be terrible for me, but that one change made it quite usable.

Since then I've moved to a system very similar to what deadalnix uses. I think your version is a great stepping stone to it.

I'm convinced that the ultimate result of this method is for it to eventually become essentially BH, with some alternate algorithms (probably M2-like) used for speed instead of optimal move count in some cases. I'm very happy with this approach; occasionally I start doing a "time attack" similar to what I did with BH corners, trying to solve every possible edge pair. I've never made it all the way through, but it's always instructive because I usually wind up getting stuck somewhere thinking, "Hey, that's a better way to do that pair", and then I go and learn it and add it to my repertoire.

 

[yoruichi]

if u memorize a few commus, why not more?
that is to say just 3 cycle everything that way u save moves

 

[Mike Hughey]

I guess I'm just too lazy to go for all of them at once. I'm picking up a few at a time. Eventually I'll have them all. Perhaps someday my solving method will be almost identical to yours - it will just take a while to get there.

And you can consider M2 to be 3 cycling everything anyway - it's just more moves than you need for most of the 3 cycles.

Your perspective on all of this is a little different from everyone else's, since you've probably spent much more time solving 3x3x3 BLD than any of the rest of us on this thread.

 

[mazei]

Can somebody explain to me deadalnix's variation? In a PM?

 

[dbeyer]

I must agree with yoruichi. I compared a move count on the scale of a 5x5. The margin of error, which would be extra moves used solving 1 piece at a time, pans out to 350 plus moves!

BH commutators compared to the M2/Pochmann methods.

M2, its variations, and 2-cycles have their place. In my opinion though its not to solve every single cycle!