DIADEM Method

[deadalnix]

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]

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]

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]

Shall check it out in the morning.

 

[Escher]

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

 

[cmhardw]

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]

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

 

[cmhardw]

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]

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]

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.

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

 

[cmhardw]

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]

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

 

[deadalnix]

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]

Here is my translation from FD to the DF sticker.

DIADEM-DF

 

[deadalnix]

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]

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]

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

 

[Mike Hughey]

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.

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]

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]

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

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

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.