# Commutators for r/l edges on big cubes



## blah (Jun 20, 2008)

I did my first 4x4x4 BLD yesterday, with pure r2 for edges, that means the VERY long algs for the r/l edges (at least I consider them long). So I consulted Mike Hughey, and he said he used commutators for r/l edges and r2 for R/L edges.

I wanted to be faster (actually I've only had 2 successful solves till now  and about 10 DNFs ranging from 14 to 17 mins), so I decided to do the same. I sat down for half an hour with a cube, a pen and a piece of paper, and came up with all the commutators I needed for r/l edges 

Actually I sorta Fridrichized them to minimize thinking during an actual solve, so there'll be 2 setup moves (c.f. the ideal 1) for almost all of them (but I guess 2 extra moves, the setup and the 'setdown', compensates for the extra thinking time wasted if I hadn't Fridrichized this).

I memorize in pairs (actually I memorize in six-letter groups, so I know I'm about to finish all the edges when I have ~4 groups, helps me keep track ), and I wanted to do commutators like Mike does, i.e. if _any_ one piece of the next pair is in r/l then I'll do a commutator. So here's my systematic approach:

Notation: [A, B] = ABA'B'; [F] = F/F'/F2 (depending on the situation).

*Case A: one piece in l, the other in R/L.*
1. [l] to bring l-piece to UFl.
2. [R/L] to bring R/L-piece to U.
3a. If R/L-piece on f, commutator [D'[f]D, F2] or inverse.
3b. If R/L-piece on b, commutator [D*D', F2] or inverse.

Case B: one piece in r (not UBr), the other in R/L.
1. [x] to bring DFr (buffer) and r-piece to UFr and DFr.
2. [R/L] to bring R/L piece to U (the new U after the cube rotation).
3a. If R/L piece interchangeable with UFr, commutator [FdF', ] or inverse.
3b. If R/L piece not interchangeable with UFr, commutator [[D](R2/L2)[D], r'] or inverse.

Case C: one piece in r, the other in l. (I almost died thinking how to setup these both-in-r/l cases, then I realized they were easier than Cases A and B -.-")
1. [x] to bring DFr (buffer) and r-piece to UFr and DFr.
2. [l] to bring l-piece to UBl (the new UBl).
3. Commutator [FdF', U2] or inverse.

Case D: both in r.
1. B2 to setup to Case C.

Case E: both in l.
1. If 'adjacent' (hope you get what I mean), [l] to bring both to UFl and UBl, then it's Case C with a cube rotation, commutator [UbU', F2] or inverse.
2. If 'opposite', haven't came up with any solutions with 2 setup moves or less  Suggestions, anyone?

I don't think I'm missing out any cases. Is this a good approach (to Fridrichize the commutators to minimize thinking)? Or are there better commutators for some of these cases? Thanks in advance.

P/S: I just tried to calculate the probability of at least one piece being in r/l, and it turns out to be more than half?! Is there something wrong with my calculation? It's simple: 1 - (16/24) * (15/23) = 0.565. Or from another perspective: 1 - (16C2)/(24C2) = 0.565.

Another question out of the blue, how do you (whoever's reading this) keep track of which edges have been memorized and which haven't? 'Cause if I have a 24-cycle then I have a very fast (sub-6) memo. If I have a 21- or 22-cycle I take all day finding out which are the 2 or 3 edges left to be cycled (and the worst part is finding that they're already permuted), and if it's REALLY bad the memo ends up being more than 10 mins  Any techniques?*


----------



## Mike Hughey (Jun 20, 2008)

blah said:


> I don't think I'm missing out any cases. Is this a good approach (to Fridrichize the commutators to minimize thinking)? Or are there better commutators for some of these cases? Thanks in advance.


These work just fine. They're not all the same ones that I use, but they're generally just as good. For cases A and B, it's never necessary to do more than one setup move (at least I think so - I'm pretty sure I never use more than one setup move for those), and your rules will sometimes require two, but since it's systematic, I doubt that will affect your times much.



blah said:


> P/S: I just tried to calculate the probability of at least one piece being in r/l, and it turns out to be more than half?! Is there something wrong with my calculation? It's simple: 1 - (16/24) * (15/23) = 0.565. Or from another perspective: 1 - (16C2)/(24C2) = 0.565.


Is this taking into account that DFr and UBr don't count? Anyway, I will speak from experience that it is true that a fairly large percentage of the pairs include r/l - it feels like slightly less than half to me, but not a lot less. The nice thing about this method is that, as you have already seen by working this out, the commutators for these cases are actually pretty easy to work out compared to some of the other cases.



blah said:


> Another question out of the blue, how do you (whoever's reading this) keep track of which edges have been memorized and which haven't? 'Cause if I have a 24-cycle then I have a very fast (sub-6) memo. If I have a 21- or 22-cycle I take all day finding out which are the 2 or 3 edges left to be cycled (and the worst part is finding that they're already permuted), and if it's REALLY bad the memo ends up being more than 10 mins  Any techniques?


The answer? Practice. I wish there were a better answer, but I really don't know of one. Let me know if you figure out a good solution. But I have found this to be becoming less and less of a problem for me the more I do them.

I have a spot in my "journey" that I know is the place for a single 24-cycle to end. Then I add one for each cycle I've had to add. So I'll know when I'm done, based on that. If I run out and don't immediately see the next cycle, I will then try to count all the pieces that are already in the correct position, to see if I'm done yet. That will give me a count of the number of pieces I still need to find. But sometimes it does still go bad for me, which is how I can sometimes still wind up with a 15 minute (or even more sometimes!) 4x4x4 BLD solve. I hate those! What's worst is when I accidentally skip or add a piece in my memorization; that can take minutes to figure out.


----------



## masterofthebass (Jun 20, 2008)

What I usually do (if I bother to) is set up a [ ___, r] commutator. If the edge in the l slice, then you just bring it to the UB edge and do a U2 to set-up into the easy commutator. if they are both in the l slice then you just do the l slice omm. My ohly issue is when I have to shoot to DBr because it's annoying for the r slice comm. I just end up doing the long alg that I use for 3x3, as it's still pretty fast.


----------



## deadalnix (Jun 20, 2008)

I'm in trouble with your E cases too. For the second one :

Df' [U2,r'Dr] fD' But I don't like it :S

For the edges, i don"t have any tips to know if they are in a cycle or not, but for centers, just put a finger on each solved center (a finger could be on more than one center if they're adjacent).


----------



## Mike Hughey (Jun 20, 2008)

deadalnix said:


> I'm in trouble with your E cases too. For the second one :
> 
> Df' [U2,r'Dr] fD' But I don't like it :S
> 
> For the edges, i don"t have any tips to know if they are in a cycle or not, but for centers, just put a finger on each solved center (a finger could be on more than one center if they're adjacent).



Yeah, for the centers, Chris made that suggestion several years ago, and I do it. You always solve the centers in a particular order on a given face, and you put one finger on each center on the last piece you've solved on that face. I use 3 fingers from each hand - right hand is U, B, R, left hand is D, F, L. It works really well.

I've thought about this - you could actually do the same with edges, although it's much more complicated. My thought - if you've solved one piece on an edge, but not the other, put your finger on that one piece. If you've solved both pieces on an edge, put it between the two pieces on that edge (on the central edge piece on a 5x5x5, on the crack of a 4x4x4). If you've solved both pieces on two different edges, put your finger on the center piece that is diagonal to those two pieces. Etc. Put your finger on the center of the entire face if all the edges of that face are solved. It gets complicated, but I suspect with some work you could make a system like this work for all cases. It's already awkward enough holding the cube for centers, though - I can't imagine how bad this might get with the edges.


----------



## cmhardw (Jun 20, 2008)

I've also thought about, for edges, a base 5 counting system with my feet in order to count edges.

It works like this:

1) Your left foot is the 5's place, and your right foot is the 1's place.

The digits are:
0: foot flat on floor
1: tilt foot to the left (as seen from your own head, your viewpoint)
2: tilt foot to the right (your viewpoint)
3: tilt foot to the left and flex your toes
4: tilt foot to the right and flex your toes

so to count from 0 to 24 you count:
00, 01, 02, 03, 04, 10, 11, 12, 13, 14, 20, 21, 22, 23, 24, 30, 31, 32, 33, 34, 40, 41, 42, 43, 44

It looks funny to do it, but it keeps track of the counting for you. This would be easier done when sitting and doing big cube BLD, standing and doing this is a bit uncomfortable and looks *really* um....... unique... Not to mention, when counting in the 40's I tend to have to be careful to avoid foot cramps ;-)

Right now I know how many more edges I need to memorize based on where my image line stops in my journey, and I have to account for the number of single letter images too. It's not exactly easy, but it isn't too bad. I have seriously considered several times learning to foot count, but I have never actually practiced it for competition use, only at home.

Chris


----------



## blah (Jun 20, 2008)

I saw (actually, skimmed through only) your (edit: referring to Mike, because Chris made a post while I was typing this ) centers tutorial somewhere on the forum earlier today/yesterday (forgot), and I think you mentioned Chris' suggestion there too, I tried it once, and didn't like it at all because my hand was all over the cube and it was just plain awkward. Good thing is, I don't have this damn-where-are-the-last-two-unswapped-pieces problem with centers, _at all_, for some unknown reason. I always seem to have a gut feeling which piece I last 'used' on each face, I guess it's because there are much fewer centers than edges. And I don't think it's ever been wrong every time I double check (though I don't double check often ).

My current 'solution' for the 'lost' edges is this: First, scan B, U, F, D faces (in that order, so I don't forget any face) for any solved edges (I look out for edge stickers with the same color as the face I'm scanning), this'll take about 2 seconds in total, of the few attempts I've had, most of the time, there's none or one. If the number of solved edges and my memorized cycle(s) adds up to ~24 (just a feeling, because I don't count the buffer and sometimes there are 2 or 3 cycles I've memorize so there'll be more than 24) then there are no 'lost' edges. If it's less than that, look for the lost edges by alphabetical order (this seems the only systematic way to do it), and every time I hit a letter I spend 3 seconds reciting my cycle to see if the letter's in there, sometimes when I'm sick of recalling, I just see where that piece has to go and if the letter pair is familiar than I've already memorized that piece. I really hope you understand what I mean, because it's hard to explain what I do... Is this a good approach?

By the way, my corners take 2 to 3 minutes for memorization, edges take 3 to 4 minutes and corners take ~30 seconds. What's a good target for each of these piece types (centers, edges and corners) if I want to sub-15 sometime soon? (I've had a hell lot of 14:xx and 15:xx DNFs, still have only had 2 successful solves out of more than 20 tries now, and it's getting frustrating  Wonder how you get that 50% accuracy, mine's somewhere in the single-digit region )

Edit: @Chris, I don't have a problem figuring out how many edges left I have to solve (because I memorize in 6-letter groups, as mentioned in the first post of this thread), I have a problem locating them. So foot counting wouldn't really work would it? Though imo, it's such a good idea I'm definitely gonna use/modify it for _something_ else, in the future 

Edit again: @Chris again, can you take a look at Case E2 in the first post of this thread and help me come up with a nice commutator for it? Thanks.


----------



## Mike Hughey (Jun 20, 2008)

blah said:


> I think you mentioned Chris' suggestion there too, I tried it once, and didn't like it at all because my hand was all over the cube and it was just plain awkward.


If you thought it was bad for centers, you certainly don't want to try it for edges. I just gave my suggestion above a try for edges, and while it works, it was absolutely horrible trying to hold the cube while doing it - way worse than for centers. I can't imagine it would be worth it for edges after trying it, so I guess it's a bad idea.

I think your current approach for dealing with lost edges is great. It's not far from what I do. Lately, I've been able to just guess where they are pretty often, though, so generally I fall back to your approach if I don't spot a lost edge immediately.



blah said:


> By the way, my corners [I assume you meant centers here] take 2 to 3 minutes for memorization, edges take 3 to 4 minutes and corners take ~30 seconds. What's a good target for each of these piece types (centers, edges and corners) if I want to sub-15 sometime soon? (I've had a hell lot of 14:xx and 15:xx DNFs, still have only had 2 successful solves out of more than 20 tries now, and it's getting frustrating  Wonder how you get that 50% accuracy, mine's somewhere in the single-digit region )



Those ratios seem very nice for sub-15. Just shave a few more seconds off and you'll be there. Like I said, memorization is usually almost exactly half of my time, so 7:30 for memorization = 15:00 total.

I've always been around 50% accuracy on 4x4x4 (except lately I've actually been more like 70%!!). The catch is, I've always been very slow compared to others with my experience level. When I had done 20 tries, I had 10 successes (I just checked my records), but my fastest solve was 27:05.94, and my fastest DNF was 23:51.74. (My first successful solve was 63:42.73, and my first attempt, which was a DNF, was over 88 minutes!) So you can see I was a LOT slower than you. Going that slow probably helped me to have fewer DNFs. Maybe it just comes from being more careful and not being as focused on super-fast speed.


----------



## cmhardw (Jun 20, 2008)

> Edit again: @Chris again, can you take a look at Case E2 in the first post of this thread and help me come up with a nice commutator for it? Thanks.



[l] to bring the pieces to DFl and UBl
then use U' l2 U l' D2 l U' l' D2 l' U

or if you prefer the other direction do the different [l] turn and do
U' l D2 l U l' D2 l U' l2 U

That alg is a BH alg, it's a commutator and is just a setup into a 9 move commutator (a commutator with a move cancellation).

In pure commutator notation (in all its glory) that alg is
[A : B , C] = A B C B' C' A'

[U' : [l : l U l' , D2] ] = U' l2 U l' D2 l U' l' D2 l' U
[U' : [l : D2 , l U l'] ] = U' l D2 l U l' D2 l U' l2 U

That's one of my favorite 11 move cases btw. A bit weird to see how it works at first, but if you take a look at it, it's really cool.

Chris

P.S. There are really only 2 cases here, both of which can just be solved with a BH alg or its inverse.

Case 1) 
[U' : [l : l U l' , D2] ] = U' l2 U l' D2 l U' l' D2 l' U
or
[U' : [l : D2 , l U l'] ] = U' l D2 l U l' D2 l U' l2 U

Case 2)
[U L : B' u B , D2] = U L B' u B D2 B' u' B D2 L' U'
or
[U L : D2 , B' u B] = U L D2 B' u B D2 B' u' B L' U'


----------



## blah (Jun 20, 2008)

I did it! I did it! I did it! I completed 3 out of 4 attempts, all sub-18! And the third one which was a DNF was only 2 edges off (though I still have no idea why). Thanks Mike, going slow and being careful really helps! I'll stick to this principle from now on, the speed will come with practice, hopefully  The second to fourth ones are on Cubemania by the way, I did the first one on CCT.

@Chris: What does BH stand for and what is it? And wow, I've never been able to figure out how to do commutators involving 2 adjacent pieces. I'm too tired to figure out so many setup moves now though, I'll understand the whole thing intuitively by tomorrow, hopefully 

By the way, how can you have 11 favorite cases when there are just about that many types? (I think, or are there more?) And it took me long enough to realize [A : B , C] actually means [ A : [B , C] ] instead of [ [A : B] , C ]


----------



## deadalnix (Jun 20, 2008)

Chris, you are an inspiration


----------



## dbeyer (Jun 21, 2008)

Blah:

BH = Beyer-Hardwick, our commutator method. Its basically a documentation process of every optimal algorithm for every possible cycle buffer bound. Like from the URb, or the UBl and every possible combination of 3 pieces with that buffer. In documenting these things we studied trends and characteristics. We noticed that there is sort of a relationship between the pieces in the cylce that determines the move count and the method of approach to solving the cycle.

Its just like the corner edge pairs in F2L, but 3 pieces, in freespace on the cube.


----------



## blah (Jun 21, 2008)

Thanks. Err... is this list of commutators available anywhere on the Internet? I've checked Chris' website but I couldn't find a link.


----------



## shelley (Jun 22, 2008)

Haha Chris, I see I'm not the only one who uses feet to keep track of things during BLD. My system's not nearly as complex as yours of course; I use r2 for edges and use my right foot to keep track of when my r slice is off. It's one less thing to keep track of in my head.


----------



## dbeyer (Jun 22, 2008)

Parts of it are online, but not available quite yet, because we simply want to publish it as a whole.

1/3 or so is done available and thats quite a milestone, but thats not even half the battle ... over one thousand cycles left. Like we said though, its really intuitive, and moreso a recognition of relationships in freespace, and methods of approach rather than "algorithms."

Later,
DB


----------



## blah (Jun 22, 2008)

There are that many?! But even 23C2 = 253 _only_ (and that's including all isomorphic cases). And you could always rotate your buffer to a fixed position, e.g. UFr, so I don't see how there can be over one thousand cycles left...

Anyway, I've got a new question about commutators, but it's for centers. Almost all my DNFs are because 2 or 3 centers are off, and I absolutely hate that feeling of taking off the blindfold, thinking the cube is solved, only to do a little rotation and find 2 centers at B and D swapped 

I'm not sure but I think it's because I do too many cube rotations during center commutators, I never have more than 2 setup moves, but there's usually at least 1 cube rotation for every 3-cycle. Thing is, I don't forget to rotate them back (that's why my edges and corners are still solved), I just keep making stupid mistakes thinking that one piece is another after a rotation, e.g. say ABCD are 4 different pieces on my U face, but after I do a complex cube rotation, say xyz, I tend to confuse which piece is which, anyone have the same problem? Or am I just supposed to stick to awkward turns (like b' or something like that) and keep cube rotations to a minimum? If I don't do cube rotations I find it very hard to visualize the commutators, is this something I've gotta start getting used to, seeing commutators from any direction?

By the way, are most people's DNFs the same as mine (center screw-ups)? I think of the 20+ DNFs I've had, only 1 or 2 are corner screw-ups, and probably 2 or 3 are edge screw-ups, and another 1 or 2 major DNFs where the cube looks nowhere near the solved state, other than these the rest are center swaps


----------



## Mike Hughey (Jun 22, 2008)

I think I just use a different approach, so it's hard to compare. I never rotate the cube for commutators. I'm slow enough of a "speed"cuber that it really doesn't make that much difference for me as to whether or not the move is awkward. And I've worked hard to get where I can see the commutator anywhere. I've worked for that so that I can always maximize solved centers on the 4x4x4 when orienting it, even if that means the top is completely solved and the bottom is completely unsolved. I'm not afraid of commutators to move pieces on the D and B faces, simply because I've gotten used to doing them.

But this has been a reasonably successful strategy for me because I'm not a fast cuber anyway, so having finger-friendly moves just doesn't mean that much to me. I doubt you should follow my lead on that.

Looking over the past 50 4x4x4 solves other than the ones for the weekly competitions that I've done, I have 1 where I was interrupted and had to stop, one where I did one move in a commutator the wrong direction (r instead of r'), 4 with only centers messed up, 3 with only edges messed up, 1 with only corners messed up (forgot parity), and 3 with centers, edges, and corners all messed up (apparently undid setup moves incorrectly - that's what usually causes that). So it's a fairly even distribution, really.


----------



## masterofthebass (Jun 22, 2008)

Hmm.... I think i may try a couple of solves without rotating for centers. I always seem to struggle seeing the rotation, but I do see what I need when I don't rotate.


----------



## joey (Jun 22, 2008)

Whenever I've done 4x4 sighted, I don't really rotate. Maybe cos I've been using a buffer?


----------



## blah (Jun 22, 2008)

@DanCohen: Don't really get what you mean by 'struggle seeing the rotation', do you mean you struggle to follow where the center pieces go after a rotation (like me), or do you mean something else? And what do you mean by 'you see what you need when you don't rotate', if you mean what I think you mean, why do you need to rotate at all?

@joey: Buffer? You use a fixed buffer for centers? How?


----------



## Henrik (Jun 22, 2008)

blah said:


> @joey: Buffer? You use a fixed buffer for centers? How?



You could use Stefan Pochmann's idea of the U2 method where Ufl is the buffer and Ubr is target then you can shoot to most centers.
For D centers you need to do setup to Dbr and then (rFd2F'r') U2 (rFd2F'r')
And for Fur, Lub, Rdb and Bdr you could do a U turn as setup. 
For U-centers you can use a normal 3-cycle of corners using only inner slices and then U2 in the end.

I don't use this method but I looked at it yesterday 
I use switching buffer target for centers Ubr and Ubl are my buffer's/target's

Henrik

Edit:/
forgot the link 
http://speedsolving.com/showthread.php?t=2860&highlight=U2+for+centers


----------



## blah (Jun 22, 2008)

Do you know of anyone who uses U2? 'Cause as far as I'm concerned, I think all big cube BLD guys use commutators for centers.


----------



## masterofthebass (Jun 22, 2008)

Most of them do, but I know Tim Sun uses U2 centers. They are pretty easy, and fairly simple. Also, Lucas came up with r2 centers, which can work too.


----------



## Henrik (Jun 22, 2008)

Sorry I don't know anyone using U2 for centers.
But I have thought about it.
It works on 5x5 too so I might adapt it for T-centers and still use my X-center system for the x-centers. I hope I don't get confused.


----------



## blah (Jun 22, 2008)

You'd probably be less confused, because I just did a 5x5 BLD and while I was doing one cycle of T-centers, I subconsciously cycled the X-centers that were assigned the same letters. Luckily I realized and reversed the commutator before going on to the next one!


----------



## Henrik (Jun 22, 2008)

That might be then 
I will have to give it a try when I get time this summmer.


----------



## deadalnix (Jun 22, 2008)

In a first time, I have used some alg and set-ups for center, but i switch to commutators now. It's realy easy on centers (I have more trouble for edges ).


----------



## dbeyer (Jun 23, 2008)

This of algs to solve every cycle, buffer bound on a 5x5. 2204 cases.

378 for Corners
440 for Edges
440 for x-Centers
440 for t-Centers
506 for Wings

Later,
DB


----------



## deadalnix (Jun 23, 2008)

You can't learn every cases. But like for F2L, you can get one for some tricky cases.


----------



## cmhardw (Jun 23, 2008)

> You can't learn every cases. But like for F2L, you can get one for some tricky cases.



Well, actually our goal is exactly to learn every case. You don't need to think of it as 2204 unrelated algorithms that have to be learned by rote memory. Really it's something like 20-30 different types of commutators that you must learn to see from any angle, and to be done on any face.

For example, Daniel and I both know all the corner commutators by now. I think Daniel knows all the edges commutators, and I'm probably at about 70%-80%. Currently I know about 70% of all the x-center and t-center commutators, and I would argue that Daniel and I both know nearly all of the wing commutators, if he doesn't know 100% already (I'm at probably 95%).

Again these are estimates as to the amount we know, but we have both done quite a bit of work to categorize and name each type of commutator, and learn how to recognize them on other faces, and from multiple angles.

Chris


----------



## deadalnix (Jun 23, 2008)

what position do you use as buffer ?


----------



## blah (Jun 23, 2008)

@Chris: Are you and Daniel the only two people in the world who actively using commutators for corners? Assuming 7 corners are wrong on average (I'm not sure, it's just a feel), and assuming you use 8-move commutators for every cycle, that's 3*8 = 24 moves to solve all corners, that is holy-crap-efficient!


----------



## deadalnix (Jun 23, 2008)

You forget set-ups, but the idea is here 

Some cases are tricky : when you get a 2*2-cycle for exemple, or a corner well placed but misoriented. And pray for not having a parity corner-edges !

I think that Clement gallet is using this method too. I'm thinking at switching for this method. I'm actulay learning 5-cycles, whitch is realy effiscient too, especialy if youy have a 2*2-cycles or parity. The move count is bigger, but main can be done in RU style so it's realy fast.


----------



## masterofthebass (Jun 23, 2008)

Chris and Dan,

good luck learning that many more center commutators for the new 6x6 and 7x7


----------



## Stefan (Jun 23, 2008)

I'm going to use U2, I did a few sighted solves with it the last days and it feels good so I'll try blindfolded with it soon.


----------



## tim (Jun 24, 2008)

masterofthebass said:


> Chris and Dan,
> 
> good luck learning that many more center commutators for the new 6x6 and 7x7



There's nothing new to learn for cubes > 5x5. All centers are either edge or corner centers. So the same rules apply to them.


----------



## deadalnix (Jun 24, 2008)

Theyre is no real difference between edges center and corner center to find commutator on them.


----------



## blah (Jun 24, 2008)

deadalnix said:


> diff*é*rence


French? 

Anybody considered using Lucas' r2 for centers?


----------



## deadalnix (Jun 24, 2008)

blah said:


> deadalnix said:
> 
> 
> > diff*é*rence
> ...



Right.


----------



## dbeyer (Jun 24, 2008)

I guess, dude, you're looking at a 36 move avg to solve corners.

8.7 moves on avg for a corner commutator, and 4 commutators for corners.
Approximately a 9 move avg for an edge commutator, and 6 commutators for corners.
On a 5x5 the average for centers as a whole is I believe 170-180 moves? Right Chris?

Based on a 9 move average, and 10 centers expected to be solved of the 48 centers. That is to say you could have 10 x-centers solved, and no t-centers. You could have 5/5, 4/6, 2/8, or 8/2 but the expected total is 10. And there could be variations. Not to say you couldn't have maybe only 7 centers solved on a bad solve, of 15-20 on a really nice solve like there was a few weeks ago during the weekly competition.

Here is what our standards and subset goals are:
Most optimal HTM/STM/BTM, depending on the situation. Edges and wings are STM. Corners are HTM.
Now we look to see if we can find a solution that uses quarter turns rather than double turns.

Rd'R' U' RdR' U -vs- U Fd2F' U' Fd2F'

Now we question execution. Is this practical?
If its an akward solution, we may subsitute the optimal akward solution for a faster suboptimal solution, still a commutator, normally only one extra move.

Its just a system ... thats all there is to it. Its not a complex system, where you have to look up algs like ZBLL. Its rather intuitive, just a few hints here and there, and you can notice the patterns and trends.

Mike Hughey liked the corner commutator system, I think he's learning it right now.
Later,
dB


----------



## dbeyer (Jun 24, 2008)

Here is a really sweet algorithm that Chris and I love:

x-center cycle: Urb -> Dbr -> Ulf
Notice how the Urb is directly above the Dbr?
Now the Ulf is opposite of the Urb on the U face?

This trick is applicable to corners as well.
We call this a columns case:
Urb is the focus point.
Both the Ulf and Dbr have positional relationships with the Urb.
Opposite on the face, and Directly beneath.

Now drop the Opposite x-center out of the U layer.


Setup: l2
Urb and Dbr aren't interchangeable quite yet. 
Perhaps:
U' will give the interchangeability.:

Setup: l U'* corrected
Commutator: b2 rF'r' b2 rFr'
=> l U' b2 rF'r' b2 rFr' U l'
12 moves, not bad. Now there is a cancelation that most will miss out on

Why not: l2 U as the setup?
Now Urb and Dbr are interchangeable on the r slice.
So now the commutator would be: Ul2U' r2 Ul2U' r2

Writing it all out: l2 U Ul2U' r2 Ul2U' r2 U' l2 => l2 U2l2U' r2 Ul2U' r2 U' l2
Now like I said before, Chris and I used to use this alg, which we thought was just friggin fast. One of our sub-goals is to use quarter turns rather than double turns. We then further analyzed it, and I realized, (maybe only two weeks ago) that you can actually turn the l slice a quarter turn rather than a double turn.

l U2l'U' r2 UlU' r2 U' l'

I bet you can blaze right through that now can't ya?


----------



## Mike Hughey (Jun 24, 2008)

dbeyer said:


> Mike Hughey liked the corner commutator system, I think he's learning it right now.



Very slowly; I'm not making as much progress as I'd like. But I am making a bit of progress on it.

I doubt I'll be able to use it at all at the US Open yet.

But I definitely like it. I want to switch, but I'm not sure how fast it will happen.

Oh, and Daniel, that columns algorithm above is very nice.


----------



## joey (Jun 24, 2008)

I want corner comms. UBL please. Or does UBR have finger friendlier algs?

btw, I'm calling my method G^-1.


----------



## Stefan (Jun 24, 2008)

dbeyer said:


> Setup: l2 U'
> Commutator: b2 rF'r' b2 rFr'


That doesn't do what you want.

Thanks for the other alg, I'll use that for the U2 method so solving one D center doesn't take me ten seconds anymore. I should've seen that myself, but was too dumb.


----------



## cmhardw (Jun 25, 2008)

joey said:


> I want corner comms. UBL please. Or does UBR have finger friendlier algs?
> 
> btw, I'm calling my method G^-1.



Joey,

I also use UBL as my corner buffer, but we decided to standardize BH to have UBR as the buffer. We figured that, in general, us UBL corner buffer users are weirdos and that more often people would use UBR ;-)

(BH corners) http://dbeyer.110mb.com/BHcorners.txt

(reflecting to UBL buffer) http://www.speedcubing.com/chris/algconversion.html

I'm sure you already know how to reflect algs, so I am not implying that you need the above page. But if others who don't know are also reading this post, then I include it for completeness.

Chris

P.S. Should we read G^-1 as "G inverse" ? I assume the G is for Gouly ;-)


----------



## joey (Jun 25, 2008)

cmhardw said:


> Joey,
> 
> I also use UBL as my corner buffer, but we decided to standardize BH to have UBR as the buffer. We figured that, in general, us UBL corner buffer users are weirdos and that more often people would use UBR ;-)


Well, I'm trying to move to non-fixed buffer anyway 



cmhardw said:


> (BH corners) http://dbeyer.110mb.com/BHcorners.txt
> 
> (reflecting to UBL buffer) http://www.speedcubing.com/chris/algconversion.html


Hmm, I think dbeyer already sent me this, but at the time there were some problems with it, I'll check it now though. Hand pick some nice algs for ugly cases!



cmhardw said:


> P.S. Should we read G^-1 as "G inverse" ? I assume the G is for Gouly ;-)


Well, that's how it would read properly. But really G^-1 is my method, my alg-set, so I only need one setup move per cycle. It's not as hardcore as BH, nor is it full commutators. Nor have I really found all the algs I need for it yet.


----------



## blah (Jun 25, 2008)

dbeyer said:


> Now we look to see if we can find a solution that uses quarter turns rather than double turns.



Now I really don't get this. I, with my limited knowledge of commutators and very limited brainspace to keep track of too many things, like double turns *way* more than quarter turns, so I always try to setup my commutators for double turns if possible (even if it means one more setup move, no kidding, no exaggeration), because I'm much less prone to mistakes when I do double turns. I think I need to illustrate what I mean with an example: (I only use commutators for centers)

Check out this cycle: Ubl > Fur > Rdb

There are 2 commutators I 'see' instantly (though there are probably more that I don't).

Commutator 1: F rU2r' d' rU2r' d F'
Commutator 2: R' rUr' u rU'r' u' R

Obviously, the main difference is how I do my setup moves (the commutators themselves are pretty much the same). I'd pick Commutator 1 over Commutator 2 any day, because then I'd only have to keep track of one thing (F), because I don't have to bother about the direction of the U turn since it's a U2 either way. For Commutator 2, I'd have to keep track of two things (R' and U), and I execute my commutator much slower because I want to make sure I don't make a stupid mistake. So in fact for me, a quarter turn is not only more dangerous, but also slower than a double turn (I use a double trigger) in practice. For C1, I can execute the whole thing smoothly non-stop in practice, but for C2, I just _have to_ pause before each U turn.

If you're wondering why the u and d turns are not double turns, well, I don't really know why, but I just have less of a problem keeping track of the slice turns, it's more the direction of the face turns that bugs me. But I'd still pick a double slice turn over a quarter one any day, I just don't 'need' it as badly as a double face turn, so if I have a choice of making my face turn a double or my slice turn a double, I'd pick face.

Here's why I'd rather do one more setup move than keep track of whether it's a clockwise or counterclockwise turn: In my head, I see 8-move commutators as one 'unit' and setup moves as another (let's call them 'memory compartments' A and B respectively). (Is this bad? It's quick for processing information though, at least I think it is.)

Case 1: If setup moves are needed, I'd _always_ setup the commutator to involve at least one double turn (preferably face rather than slice).
Case 2: If I 'see' a commutator that doesn't need setup moves, then I'll just do that commutator without setup moves, even if it means there are no double turns.

Analysis: By doing what I do for case 1, I only use one memory compartment: B. If I do one less setup move and a quarter turn in my commutator, I use both memory compartments A and B. Somehow, I don't know why, the amount of information stored in each memory compartment isn't as important as the number of memory compartments used. For case 2, without a setup move, I'm only using memory compartment A; with a setup move, I'm using both A and B. And I think using only one memory compartment is a good tradeoff for a double turn. Somehow, slice turns are not involved in any of the memory compartments, as I've said, I've got less of a problem with these.

This is just what I feel after less than a week of big cube BLD  So it might be pretty worthless information that leads people in the wrong direction, I dunno. But just out of curiosity, has anyone ever thought of it this way before?


----------



## deadalnix (Jun 25, 2008)

Il do the same. If a solution existe without setup, i choose this one.


----------



## Mike Hughey (Jun 25, 2008)

@Chris: When I'm practicing BH, I use UBL as my corner buffer as well, so I always have to adjust your algorithms correspondingly when I'm practicing. I chose that simply because that corresponds to the piece I label "A" and start with on 5x5x5 X centers.

It looks like UBL isn't as weird as you think it is.


@Blah: When I was starting out (and for quite many months, actually), I preferred double turns over quarter turns as well. In fact, I think I mentioned that in my "How I solve centers on a 4x4x4" post. But with experience, I've gotten where I prefer quarter turns. I suspect that's just something that happens with practice. It gets where you see the whole thing at once, so it's not extra information any more to remember which direction to go. But I totally sympathize with your perspective. I still probably occasionally make mistakes with quarter turn moves that I wouldn't make with double turn moves. (I think I remember one from just last week.)

Oh, and I'm sure my double triggers are a lot slower than yours, which probably has something to do with it. I really stink at double triggers.


----------



## deadalnix (Jun 25, 2008)

Chris, you make me smarter again !

I just understand what you mean by doing the corners like X centers. It's sometime more complicated for set-ups but very clever !


----------



## blah (Jun 28, 2008)

I've decided to make my life easier, now I don't care about pairs anymore, I'll use commutators only if I hit an r/l slice edge 'directly', i.e. if it's the second part of my pair (indirect), I'll do the first part normally with r2 then I'll pair the slice piece and the first part of my next pair together, and do them as a commutator. Though I still memorize in pairs to facilitate of memorization, not execution. I don't know why but I'm just not comfortable with inverse commutators  How do I cure this disease?

Any major disadvantage to doing this rather than the approach I described in the first post of this thread? (i.e. if any one of the next two pieces is an r/l-slice piece I'll do a commutator)


----------



## cmhardw (Jun 29, 2008)

blah said:


> I don't know why but I'm just not comfortable with inverse commutators  How do I cure this disease?



For BH, Daniel and I define a commutator to be ABA'B' where A is the "insertion" part of the alg, and B is the "interchanging" part of the alg.

So for example: r' d r U2 r' d' r U2 is a commutator for x-centers where,
A = r' d r
B = U2

Notice that A is 3 moves (sometimes 5, or 4) and that B is 1 move. B is always one move, which is a way to think about a freestyle commutator (a commutator where the B part of the alg, the interchange move, is exactly 1 turn in HTM).

So to do the inverse of a commutator, you are simply executing the commutator as BAB'A'

What this means is, interchange first, then do the insertion part. So in my head, when applying a commutator (ABA'B') I first picture the insertion move, and how that affects the main/interchanging slice. After applying the insertion move, I imagine in my head how the interchanging move affects the pieces on the main slice, then I apply the interchanging move. After that I stop visualizing anything, and just do the inverse of the insertion move, followed by the inverse of the interchanging move.

So in essence, the first 2 parts of any commutator are very visual, and I picture everything about the 3 pieces affected. The last 2 parts of the alg are 100% abstract, with no visualization. I simply invert the previously applied sequences in the correct order. To do the inverse of a commutator, simply interchange first while picturing how this affects your 3 pieces. Then, picture the insertion move, and apply it. Then, in the abstract sense only, apply the inverse of the interchange move, followed by the inverse of the insertion move.

Simple, when thought of this way at least.

Chris


----------



## deadalnix (Jun 29, 2008)

I think in the same way !

But I never use 5 moves A. Maximum 4, and set-up if needed.

So you have a list of the wing alg like for corners ? (even if the list isn't finish, it give an idea).


----------



## cmhardw (Jun 29, 2008)

deadalnix said:


> I think in the same way !
> 
> But I never use 5 moves A. Maximum 4, and set-up if needed.
> 
> So you have a list of the wing alg like for corners ? (even if the list isn't finish, it give an idea).



If you don't use 5 move A algs, you might want to consider it, at least for 1 case. What do you do for Ubl->Dfl->Ufr ?

I use:
A: U' f2 U f2 U
B: l2

There is another alg, that Daniel found, which is very fast but I am absolutely mystified as to how it works. If I don't understand an alg, I'm afraid to use it in a BLD solve. I understand how that 5 move A works as the insertion alg, so I prefer the above alg.

As for the list for x-centers, yes I am about 30%-40% done writing it. Daniel and I are splitting up the job of writing up all the algs, and x-centers are my responsibility. I'm still working on it, but with work and practicing for Nationals I honestly haven't worked on the list at all in about a week.

Chris


----------



## deadalnix (Jun 29, 2008)

I will not do this alg because Ubl and Ufr are interchangables centers. Theyre is need to do this kind of cycles.

But As I said, i user set-ups, and if I have tu solve this, I wil probably set up with r'F' and then [l2,UrU']. It's not shorter, but easier to do. And useless !


----------



## blah (Jun 29, 2008)

cmhardw said:


> What do you do for Ubl->Dfl->Ufr ?


Setup: r' D2
A: l F2 l'
B: b2

Is this bad? Or worse, plain weird?
It's the same number of moves as whatever you're doing, though it's much harder to perform on a real cube.



deadalnix said:


> And useless !


Uh-huh... Wait, uh-huh?


----------



## dbeyer (Jul 1, 2008)

I made the correction to the algorithm. I guess I copy and pasted or something. Anyway, it should be l (or l' for that matter) U' then a commutator on the F or B face, (which ever one you decide to put the Ulf on).

The point is though, to see the 11 mover.

Here is another solution its the Conjugated Cyclic Shift.

l2D b2 D'lDl' b2 lD' l
Later,
DB


----------

