DIADEM Method

[Marcell]

pre-memorized: you can make up the commutator and still be using BH.
move-optimal: I'm not sure what Chris and Daniel would say but I'd definitely use longer algs over terrible optimal ones. (See Chris's post quoted below for an example) For corners I don't use optimal algorithms for cyclic shifts or columns.
commutator 3-cycles: well I don't think people would say "you don't use BH, liar!" if you solved two 2-cycles with an E/H perm.
fixed buffer location: I'd say someone was still using BH, even if they were using floating buffers.

I disagree. If none if these is a criterium for BH then what is?

 

[aronpm]

I disagree. If none if these is a criterium for BH then what is?

So if you wanted to learn BH you would learn every case individually? You would do an alg like [S'D'S, U2]? You wouldn't take advantage of an easy E perm to solve 4 corners? If your buffer was solved and you could use a different buffer you'd just break into a new cycle instead?

 

[Marcell]

Of couse I'd do all these to make solving faster, easier etc. But then I wouldn't say I'm using BH. Or at least not strict BH.

And my question still stands. How would you define BH?

 

[cmhardw]

Apologies to the thread hijack, any further discussion I will move to an appropriate thread.

So if you wanted to learn BH you would learn every case individually? You would do an alg like [S'D'S, U2]? You wouldn't take advantage of an easy E perm to solve 4 corners? If your buffer was solved and you could use a different buffer you'd just break into a new cycle instead?

Daniel and I intended it to be a method like F2L. There are only a handful of named commutator types, you just need to learn to recognize them from different angles. So I guess saying "pre-memorized" is maybe not the best phrase. I can't think of the best phrase for it, but all the cases can be learned very quickly by memorizing perhaps 10-12 different types of commutators, at most.

As to the alg [S'D'S, U2], I would certainly never execute it this way. I really hope people don't think that we actually execute the way we wrote the algs down on the site. Perhaps one consequence to Daniel and I listing out all of our algs is that people believe we execute them without cube rotations. When deciding to write the algs out, we really were not keen on putting in every nuance to how the algs were executed. It was basically meant as a starting point for people to know at least which turns we do. Daniel didn't really like the idea of the alg list format of the site, and to be honest I am now starting to feel the same way. I'm debating taking the alg lists down, or at least not making it the main part of the site, and putting up more of an organic description of each commutator type and let people learn themselves how to rotate them to different angles.

As to the case [S'D'S, U2] I would probably do:
y' M D' M' U2 M D M' U2 y

I know there are lots of optimizations of this for 3x3x3. Just know that Daniel, and my, goal for these edge algs is to be able to solve the central edges of a 5x5x5 before we have solved the center pieces. If you can come up with an alg on 5x5x5 that can be executed more quickly than this and keeps the centers safe, then to be honest I would probably switch to it even if it was sub-optimal in move count.

Of couse I'd do all these to make solving faster, easier etc. But then I wouldn't say I'm using BH. Or at least not strict BH.

And my question still stands. How would you define BH?

Daniel and I would probably take a similar stance to this. I know I do, but I can't speak fully for Daniel. BH to me is the foundational idea, and any change from that is just a variation to the method. For example, I use floating buffers for edges, but not really for centers. So I would just say that for wings I use floating buffer BH and for everything else fixed buffer. I think the fundamental ideas for BH should just be treated as a starting point, as in here is the way the method is done, and any changes made are just personal variations to this.

Again it's best compared to F2L. All Fridrich solvers consider themselves F2L solvers, but I'll bet that no two people have the exact same approach to every case, and the exact same nuances to their method. Yet they still, all, solve F2L every solve.

Chris

 

[nickvu2]

Sorry for the noob questions. I've read the entire thread but I think I'm missing some of the basic knowledge needed to understand what's going on.

So is DIADEM a supplement or add-on to M2, M2 being a prerequisite? Or is this a distinct, stand-alone method that draws on strategies from M2 and BH? I.E., are you always solving 2 edges at a time, or only when specific cases arise?

Also am I correct that the buffer position in M2 is typically DF, while DIADEM is FD?

 

[Marcell]

are you always solving 2 edges at a time, or only when specific cases arise?

"In this method, edges are solved 2 by 2 by building our own sequences using patterns." (From Deadelnix's tutorial.)
So yes, you are always solving edges in pairs.

Also am I correct that the buffer position in M2 is typically DF, while DIADEM is FD?

The buffer position is independent from the method. Besides, no matter what your buffer is, you'll solve the one case with the same algorithm. You'll just call it differently.

 

[deadalnix]

So is DIADEM a supplement or add-on to M2, M2 being a prerequisite? Or is this a distinct, stand-alone method that draws on strategies from M2 and BH? I.E., are you always solving 2 edges at a time, or only when specific cases arise?

Most of these questions are clearly answered in the tuto. I suggest you to read it because I will not rewrite it here.

Also am I correct that the buffer position in M2 is typically DF, while DIADEM is FD?

I was using FD for M2 too. This is just matter of what you like. Obviously, if you choose DF instead of FD, you'll have to make some translation work.