# DIADEM Method



## deadalnix (Jan 22, 2010)

OK, We have already discussed it here in various thread, and some of you have read some draft versions of the tutorial.

I think the tutorial is good enought now to be published in english. So here it is : http://www.francocube.com/deadalnix/DIADEM_en.php

You can click onimages to get applets. The idea is to not load many applets on the page at first. You'll probably experience some issue with applet with chrome or safari (or webkit's browsers in general) but we have tested it with IE7+, Firefox and Opera.

You can customize the colors you prefers for applets on this page : http://www.francocube.com/deadalnix/config.php but it requier cockies to be effective and this page is in french (the website is supposed to be for french speaking peoples).

Feel free to reuse the method and/or describe it on your own website, as long as you respect CC-BY-SA licence, which is a copyleft licence : http://en.wikipedia.org/wiki/Copyleft .


----------



## PM 1729 (Jan 22, 2010)

I always liked this method, and the tutorial is very good.It's a good stepping stone between M2 and BH/freestyle.
Only problem is that the images of the cube overlap the text on the website.


----------



## deadalnix (Jan 22, 2010)

Can you tell me more about the problem. We are making a new version of the image/applet script solving these problems, but we are not aware of this issue, so we cannot solve it.

PS: maybe we should discuss that using pm to not pollude the thread.


----------



## mazei (Jan 22, 2010)

Shall check it out in the morning.


----------



## Escher (Jan 22, 2010)

Wow, that's a pretty cool method! Good work 
I'll definitely learn this.


----------



## cmhardw (Jan 22, 2010)

Wow this is an extremely detailed tutorial! I like the way you are describing the cases! It seems very similar to how Daniel and I think of stickers on a plane vs. stickers on a slice.

I will have to read this much more thoroughly to see if there are any good algs to use in place of a more awkward BH alg!

Thanks again for the tutorial, this is very well written!
Chis


----------



## Swordsman Kirby (Jan 22, 2010)

Why is the first algorithm so long? U'M'U2MU2M'U2MU' can be done as UM'U2MU.


----------



## cmhardw (Jan 22, 2010)

Swordsman Kirby said:


> Why is the first algorithm so long? U'M'U2MU2M'U2MU' can be done as UM'U2MU.



The one he lists is supercube safe, and can be used before solving centers on larger odd cubes.

Chris


----------



## deadalnix (Jan 22, 2010)

At the begining of the page, you'll find :



> I mention here big cube safe solutions, but also deal with some 3x3x3 specific improvements.



And then come U cases. Particulary this part :


> Some shortcuts usable on 3x3x3 :



You'll find what you are interested in theyre.


----------



## Swordsman Kirby (Jan 22, 2010)

deadalnix said:


> At the begining of the page, you'll find :
> 
> 
> 
> ...



I'm quite certain there is a pure 8-move commutator instead of MUMU2M'U2MU2M'UM' that preserves centers.


----------



## cmhardw (Jan 22, 2010)

Swordsman Kirby said:


> I'm quite certain there is a pure 8-move commutator instead of MUMU2M'U2MU2M'UM' that preserves centers.



S' D' S U2 S' D S U2 does that, though it's not very finger friendly IMO.

Here's a supercube safe "Wide setup into a toss up" which is maybe a bit more finger friendly:
r U L E2 L' U' L E2 L2 x'

Chris


----------



## joey (Jan 22, 2010)

This doesn't really seem like a new method to me. Nice writeup though.


----------



## deadalnix (Jan 22, 2010)

If you are talking about current know M2 improvements, I just want to mention that post : http://www.speedsolving.com/forum/showthread.php?p=62051#post62051

Which is actually the basic concept of the method. These trick then become quite wellknown and come up in many M2 tutorials like macky's one.

I don't want to seems like people having a misplaced ego. But I come-up with this way of improving M2 in the first place and here is the logical conclusion. The fact I have given many of the tricks you can find on this method during the process, and the fact that other people come up with similar ideas (I not crazy enought to believe I'm the only one having ideas here ) is why people are using « patched » versions of M2 which include many of these tricks.

But this is an unified way of assembling everything in a coherent method, not applying some patches on M2 for crappy cases.


----------



## martijn_cube (Jan 24, 2010)

Here is my translation from FD to the DF sticker.

DIADEM-DF


----------



## deadalnix (Sep 23, 2010)

We recently got a problem with our host so we had to disable the image -> applet stuff. Bad news is that the page is quite heavy to load now because of the applets. Good news is that a news version af all that is comming soon (already runnng on a test server) and will solve many problems (for exemple with chrome and safari).


----------



## MrMoney (Sep 23, 2010)

I might not be seeing this, but how is this better then BH edges? This seems like a transition between M2 and BH, with some better cases and some really bad. I think going for BH edges is alot better then this, as the cases almost speak for themselves and are eather pure 8move-comms or 10move-1cancel=9movers.


----------



## qqwref (Sep 23, 2010)

I don't quite understand how this differs from a variation of BH edges with fewer algs and a few more setups.


----------



## Mike Hughey (Sep 23, 2010)

MrMoney said:


> I might not be seeing this, but how is this better then BH edges? This seems like a transition between M2 and BH, with some better cases and some really bad. I think going for BH edges is alot better then this, as the cases almost speak for themselves and are eather pure 8move-comms or 10move-1cancel=9movers.


I think you're right. But I see it as a really nice transition between M2 and BH, allowing you to get some of the benefits of BH with very little work.



qqwref said:


> I don't quite understand how this differs from a variation of BH edges with fewer algs and a few more setups.


I think that's very much what it is.

I use something very similar to DIADEM. I saw deadalnix's original post where he mentioned his idea for it, and I thought it sounded like a good idea, so I started doing something similar. For the really bad cases, I just use BH-type algs instead. For the good cases, the move count is the same as BH, but you have lots of M slice moves, so it's easy to get in a rhythm solving. I found it was really nice to learn, because you can just transition cases one at a time from regular M2 into this approach without having to go through the work to change your overall solving style.


----------



## deadalnix (Sep 23, 2010)

IMO, algs are usually more finger firendly than BH's. In BH, you have to use many S or E slice, or regrip a lot. Also, cases are quite straightforward. You recognize the pattern and apply it. In BH edges, you have many differnt patterns, and each of them can show up with different « recognition ».

However, choose whatever you like as a method. If you think BH edges is better for you, then you should definitively go for it. I don't think the move you win using BH really worth it because it's less finger friendly, require way more work to master and are harder to « recognize ». Don't focus too much on the move count. For exemple, we had a pretty move optimal set of algs for PLL few years ago. Now, we have many others that are not as move effiscient, but can be performed faster. This is pretty the same here : you usually loose 1 or 2 moves for a pair of pieces compared to BH, but you get stick with the M slice and almost no regrip. This is a nice trade.

Anyway, I'm really interested to know which cases you don't like and if you have suggestion for a better solution.

NB: by recognize, i mean figure out in which case you are, as long as you cannot recognize so much when you are blindfolded.


----------



## aronpm (Sep 24, 2010)

deadalnix said:


> IMO, algs are usually more finger firendly than BH's. In BH, you have to use many S or E slice, or regrip a lot. Also, cases are quite straightforward. You recognize the pattern and apply it. In BH edges, you have many differnt patterns, and each of them can show up with different « recognition ».



I don't know the 'official' stance but I don't think it's necessary to stick exactly to what BH is to still say you use BH.

The Wiki says this:


> The fundamental idea behind the BH method is to use pre-memorized, move optimal, commutator 3-cycles for all possible 3-cycles starting from a fixed buffer location.


_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 also don't think it's necessary for BH algorithms (especially edges) to be supercube safe. I solve centers first always so it would be unnecessary for me to use algs that preserve center position. The only thing that needs to be watched out for is 'mixing the colours', such as (M' U)*4 U (M' U)*4 U' which does that if you use center M slices (not sure about notation).



cmhardw said:


> S' D' S U2 S' D S U2 does that, though it's not very finger friendly IMO.
> 
> Here's a supercube safe "Wide setup into a toss up" which is maybe a bit more finger friendly:
> r U L E2 L' U' L E2 L2 x'
> ...


 
Here's a non-supercube-safe alg which I think is even nicer:
M U' M U2 M' U' M'
or (U2) M U M U2 M' U M' (U2)

I'd do that latter because it's easier for me even thought it has more moves.


----------



## Marcell (Sep 24, 2010)

aronpm said:


> _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 (Sep 24, 2010)

Marcell said:


> 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 (Sep 24, 2010)

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 (Sep 24, 2010)

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



aronpm said:


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



Marcell said:


> 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 (Oct 10, 2010)

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 (Oct 10, 2010)

nickvu2 said:


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



nickvu2 said:


> 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 (Oct 10, 2010)

nickvu2 said:


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



nickvu2 said:


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


----------

