Big cubes blind

[cmhardw]

Other than the fact that I use r2 for most of the edges and some minor differences in memorization, the method you used in this example really isn't far off of what I do today. So I'm curious, Chris - what in particular is outdated for you?

Hey Mike,

to answer your question I do a couple things differently from back then, though some of them aren't really illustrated by the example.

One really big thing is that I used to always memorize the starting location for centers and wings. Now I just use a fixed buffer, so I always know where I am starting from and I don't waste time to memorize this information. For centers my buffer is on U. When I used to get a U center as the second part of a letter pair, I used to then pick a new buffer on U and start from there for any remaining cycles. This assumes the U face has another unsolved piece on it. Now I just cycle the piece in the buffer (which belongs on U anyway) to the unsolved location on U and continue from there.

Also, I am now in the process of optimizing my x-center commutators as I optimize my corner commutators. So often before when I needed 2 setup moves now I only need 1. I use more "Ferris Wheel" style commutators now in place of optimal commutators in cases where it makes a faster RrUuLl type alg. I didn't really used to do that back when I wrote this example.

I guess those changes aren't that big individually, but taken together they helped me shave off valuable seconds. I should also add that Daniel Beyer is the one who convinced me to make nearly all of these changes to my solving method. Without his help, I certainly don't think I would have improved much since then.

Chris

 

[Lucas Garron]

Here, I took a little under two minutes (1:58), and made a single mistake that actually cost me more time (since I did a parity instead of shooting URU'r2UR'U'). Note that I did at least one special commutator (rUr' D2 rU'r' D' rUr' D' rU'r').

I need to deal with the M-slice edges better...
I want to try r2 for centers sometime, too.

 

[Mike Hughey]

Other than the fact that I use r2 for most of the edges and some minor differences in memorization, the method you used in this example really isn't far off of what I do today. So I'm curious, Chris - what in particular is outdated for you?

Hey Mike,

to answer your question I do a couple things differently from back then, though some of them aren't really illustrated by the example.

Thank you, Chris!

One really big thing is that I used to always memorize the starting location for centers and wings. Now I just use a fixed buffer, so I always know where I am starting from and I don't waste time to memorize this information. For centers my buffer is on U. When I used to get a U center as the second part of a letter pair, I used to then pick a new buffer on U and start from there for any remaining cycles. This assumes the U face has another unsolved piece on it. Now I just cycle the piece in the buffer (which belongs on U anyway) to the unsolved location on U and continue from there.

I can understand this, but I'm not convinced it really saves that much to not memorize the starting locations - since it's just a person anyway, and I find those really easy and quick to recall, it seems to help the security of my memorization to have a person associated with the other images. (I may be different from you here because I cram more things into a single location - on average, I have a person plus 3 images in a given memory location, meaning I can be solving up to 7 pieces for a single location - I find it works well for me.) And if you're memorizing the starting locations, then picking a new buffer is pretty easy and means one less piece to move, right? Half the time, that won't matter, but half the time it will mean an extra cycle, won't it? Imagine you have 2 independent three-cycles of centers, each starting from the U face. If you solve it my way (your old way), you do 2 commutators and you're done. If you do it your new way, it takes 3 commutators, doesn't it? For me, that's certainly slower even with memorization than the 2 commutator solution. But maybe it's not for you, because you're faster at moving than me. I'd appreciate it if you let me know if I'm not understanding you correctly about this (I figure there's a good chance I'm not).

Also, I am now in the process of optimizing my x-center commutators as I optimize my corner commutators. So often before when I needed 2 setup moves now I only need 1. I use more "Ferris Wheel" style commutators now in place of optimal commutators in cases where it makes a faster RrUuLl type alg. I didn't really used to do that back when I wrote this example.

I must admit I still don't know the "Ferris Wheel" style commutator. I guess I need to learn it. I currently always use an extra setup move and find something else. There's always something new to learn.

I guess those changes aren't that big individually, but taken together they helped me shave off valuable seconds. I should also add that Daniel Beyer is the one who convinced me to make nearly all of these changes to my solving method. Without his help, I certainly don't think I would have improved much since then.

Chris

I figure when I get under 10 minutes for a 4x4x4, I'll be ready to start thinking about things like this (which is what you originally mentioned anyway - you said your old writeup could get sub-10). In the meantime, I probably mainly need to focus on refining my memorization - I'm starting to really believe that that alone can take me to less than 10 minutes pretty easily. It would be so cool to be able to do a 4x4x4 BLD on a stackmat! (And I know you're thinking the same thing about a 5x5x5!)

 

[alexc]

Matyas uses r2!!!!!!?????? Hmmm.. maybe he uses some variation of M2 for 3x3 then.

 

[Lucas Garron]

Matyas uses r2!!!!!!?????? Hmmm.. maybe he uses some variation of M2 for 3x3 then.

Yeah, let's call it M'.
(It always looks like he's doing a spare M' for edges.)

Actually, his solves look like they use a lot of r2 for centers and edges, but from different angles and in ways that make it hard for me ever to decide.

Expect my r2 center page to be up tomorrow.

 

[dbeyer]

Commutators:
Short Move Count
Solves multiple Pieces
Applicable to other aspects of cubing, such as FMC
Applications to the PLL -- The Corner Cycles
Applications to COLL -- Such as some Sunes and R'FRB'R'F'RB
Versatility** -- Find what works for you

vs

The M2 and it's Variations:
Very fast for those that are great with the M slice moves.
R2 actually has more algs than incomplete-commutators
M2 the irregularities with the M slice
Braindead-edness (Again less cases)
Greater Move count -- hard to integrate optimizations into the cycles.


** Ok Commutators are very versatile. You can find buffers to cycle from so that you can get an overall optimal and personalized fingerfriendly.
Chris and I cycle from different buffers for our different piece-types but we both like the algs that we encounter. Chris is faster than I, and has been doing it longer and more consistently than I. His algs may or may not fit my hands. Anything that Chris and I may come up with may not suit you, but you can find someplace that just fits for you.

M2 and it's variations are very straight forward. Its fast if it works for you. It's not if you're not fast with the M2 slicing. The chances of you being able to make a fast varitations like D2 or S2 is improbable.



To be honest:
Here is the breakdown.
The optimization of M2 and R2 and r2 lies in a very very fast part B of the commutator.

Commutators come in ABA'B' format.
r2 comes in ABA' format

For a normal buffer-bound solve. You'll have to solve 24 wings. 24 pieces. The buffer is solved by default, but you will most likely have to kick out to on average 1 other cycle.

At a rate 1 piece/alg with r2 you will have to execute 24 r2 algs.
You are executing 24 part Bs. Each B is a double turn. r2' or r2, both double turns.
To get the fastest fingertricks for r2, you are advised to rotate, which does take time.
Part A is at the VERY least 3 moves. Ignore the cases that aren't 3 moves.

ABA' >= 3 + 1 + 3 >= 7 solving only 1 piece.

At a rate of solving 2 pieces/commutator, you will have to execute 12 commutators.

ABA'B' * 12 means that there are 24 As and 24 Bs
ABA' * 24 means that there are 48 As and 24 Bs

You are not optimizing the problem of double turns in the Part B
You can not easily find cancelations with R2.
Optimized Buffer-bound Commutators have many cancelations of moves.

On average there are approximately 10 moves in each possible commutator, solving two pieces.
10*12 = 120 (Commutator Average Move Count * number of commutators)
7*24 = 168 (The most optimal execution of an r2 alg * number of executions)

12 * 12 = 144
(Max move count for a commutator (6/506 cases, counting inverses) * number of commutators)
Not to mention because you'll be solving 2 of the pieces of the 3 pieces in the combination. So even if you had to do a cycle and a kick-out and you had two of these cases, you'd never get 12*12 with commutators (optimized).

There are very few cycles that require actual setups that do not cancel in some form with the commutator. There are cases that are Hard, and you may think that there needs to be two setups, and then an 8 move commutator, you can actually setup then find a 9-mover (for a total of 11 moves).

Blindfolded cubing is just like speedsolving. If you have very very fast execution, and poor lookahead, then you'll actually be slower than a cuber with slower finger speed that has fluent lookahead and few pauses.


Quite the same with blindsolving. If you can only recall a piece or two and a time and then a flurry of movements across the cube, and then a large pause. I think it is much more impressive to see somebody continuous moving, than to see the fast fingerspeed and braindead-edness of something like r2.

As Chris would say:
"Just my two cents,"
DB

 

[Stefan]

Daniel, looks to me like you count in STM. What are the numbers in HTM? Or is it called BTM for "block"? I mean where inner layer turns count as two moves, outer layer and double layer turns count as one move. I think that would be more realistic.

Even more realistic would be to look at what moves are used, as for example r2 is faster than b2 and R is faster than D.

Also, I think r2 makes continuous moving *easier*, not harder, because there's pretty much no thinking beside the memory recall. The thinking was done during the design of the method so that its application can be done unconsciously.

 

[Mike Hughey]

I agree with Stefan that r2 makes continuous moving easier. I know that I'm still at pretty much a beginner level with my speed at commutators, but I've worked quite a bit on them and yet I have to pause before most of them. But with r2 if my memory recall is solid (which is probably just half the time, at best, but that's another issue), I can be constantly moving. I was tempted to switch to r2 for edges right before the Virginia Open if for no other reason than that I would have looked more impressive to spectators that way, since once I get to edges, I'm constantly turning. Unfortunately, I'm so slow at turning that the fewer move count on commutators almost compensates for the pauses, so I'm really not that much faster with r2 - just a little bit.

I'm still finding it hard to believe that U2 would be as big an advantage as r2 was with centers, but I'm intrigued enough by it that I will probably at least learn how to do it. The move count advantage of commutators over U2 looks more substantial than it is with r2 to me.

I still can't do M2 very well at all - the problems with misoriented edges in the middle slice just mess me up horribly. I just did about 12 attempts yesterday, with 8 DNFs, and the other 4 averaged about 7 minutes. Bleah. But r2 isn't bad for me.

Edit: Note that I'm not saying that it's not possible to turn continuously just as well with commutators as it is to turn continuously with r2. I'm simply saying that it's easier to learn to turn continuously with r2 than it is to learn to turn continuously with commutators. Within two days, I was turning fairly continuously with r2, and I've been doing commutators for six months (I started with commutators three months before I learned r2) and I'm still not nearly as continuous turning with commutators as I am with r2.

 

[dbeyer]

Yes, the count is in STM. I can't give you an accurate answer about BTM, simply because I would have to count it all by hand for wings. STM is the easiest way to generalize. STM applies to everything. You have to have a mix of inner turns and outter turns to create a commutator, or else you have no cycle-effect. Since one wouldn't be (at least I wouldn't nor do I think Chris would) be doing block turns, and you must do an average mix of inner and consistently.
Looking below:
L'U'Ld2L'ULd2
lF'l' B lFl' B'
DR2D'l2DR2D'l2
UbU' B' Ub'U' B
r2D'r U2 r'Dr U2 r

With practice at a larger system execution of the cases as you recall them is just as easy as when you use a small system.

It's like a 3LLL vs a 2LLL
3LLL is very fast because of the small number of Orientation cases, but it requires more moves.
2LLL is has fewer looks.
Would you not agree that with a poor selection of OLL algs, that perhaps a 3LLL could actually be faster?

Learning all of OLLs, even the fastest, you will still have good cases and bad cases. You take the chances of getting a good average by having a substantial repitiore or fast OLLs and only a few bad OLLs. You'll hate it when you get the bad OLLs, but the chances of you getting them is very small, and not bad enough to truly botch an average.

Being unfamiliar with the optimizations of commutators will cost you move count, and perhaps far too many setups, and then you'll be slower. Then r2 will be faster. I am not saying that you should be able to apply an average commutator as fast as a an r2 execution. I do feel that one can solve a commutator faster than another can do two r2 executions solving the same cycle.

Another thing that Chris and I have talked about is a way to keep moving when you forget the next step. It's easier, and more versatile with commutators. In my opinion at least.

Whatever ... I was just making my point. The way I viewed it.

I had such a hard time moving from my method that worked to another more advanced method. Where you really just set everything up into something familiar. Now Chris and I are working on almost a ZBLL method of big cubes blind.

We will have an alg for every case. It'll be fast, optimized, (in STM for anything 4x4 and 3x3 edges) HTM for Corners.

Mike: You don't see the pay off for optimizing corners, since it's such a small part of the execution. Truly, in the long run with everything optimized (in STM, because you need to make a fair count of slice moves to only cycle 3 pieces). It seems to be a concern because one would think that his methods are fast on 2x2 or on 3x3 so they should be fast on big cubes for corners. There are inconsistencies with most non-commutator Orient first methods, that affect centers. So then one has to solve centers before doing corners.

One won't see the benefits of the low move count of commutators if he is wasting extra moves to setup into one of the few familiar cases that he may know.

I am not saying that Commutators will get everybody fast and world record times. I am just saying that a remedial understanding of commutators will not allow you to reap the benefits of fast times.

Just as one with remedial algebra cannot appreciate calculus. Something beyond what you are comfortable with, is normally just unsettling and uncomfortable to first engage into.
The move counts increase greatly for QTM HTM or BTM if you are solving x-centers. When it's only a 8-9 STM alg.

Also, I view commutators like the F2L of the 3x3 speedsolve.
Commutators are meant to be used optimized, with as few moves as possible to cycle 3 pieces.
Same with F2L, optimized, solving as much as possible, with a good mix of fast moves and few moves.

You may remember when you would do your F2L practice at first, and you were shaky with it, and you would think back to how fast your LBL is relative to the unstable F2L method that you're using. So you go back to LBL to impress some friends. Finally you stick it out and really focus on F2L and then your times cut dramatically once you just get used to it. It's so much better than LBL and when your F2L was shakey and new to you.

Later,
DB

 

[Stefan]

I unfortunately don't have a good 4x4 so my twisting is slow, so I'd really like to know how fast Matyas is with r2. But for 3x3 and my M2 vs Chris's commutators, last time I checked my edges beat his 21.88 to 27.93 on average (and my R2 corners and parity beat his commutator corners and parity, too).

http://www.speedsolving.com/showpost.php?p=18084&postcount=1
http://www.speedsolving.com/showpost.php?p=18264&postcount=16

 

[dbeyer]

Sighted vs Sighted
Or Blind vs Sighted
Or Blind vs Blind

Because, Chris' trials from what I've seen lately have been run by memorizing the solve (just the portions being timed) and then dons a blindfold and executes.

 

[cmhardw]

I unfortunately don't have a good 4x4 so my twisting is slow, so I'd really like to know how fast Matyas is with r2. But for 3x3 and my M2 vs Chris's commutators, last time I checked my edges beat his 21.88 to 27.93 on average (and my R2 corners and parity beat his commutator corners and parity, too).

Hi Stefan,

Here are some updated current averages from me for 3x3 corners and 3x3 edges. I did both of these averages by memorizing as close to my regular speed as I could, then donning the blindfold and timing the solving time only.

I used 25 move random scrambles, and in cases of parity I left the last two pieces swapped when I stopped the timer. I made sure to orient all permuted but disoriented pieces before stopping the timer. I did the corners average first, then the edges average after.

3x3 corner execution with commutators while actually blindfolded:
14.64 21.41 (DNF) 17.25 17.47 13.67 14.01 (7.79) 10.28 10.86 17.58 11.54 = 14.87 average

The 7.79 was a 7 cycle and was made up of 3 super easy toss-up and direct insert commutator cycles. This was a nearly perfect solve, both for memorization and solving for corners for me.

3x3 edges execution with commutators while actually blindfolded:
(18.02) 23.59 24.57 27.80 28.40 21.01 23.48 21.73 (DNF) 26.77 25.10 19.87 = 24.23

I think I average about 10 seconds to execute parity, so if you take the expected value of this to be roughly 5 seconds added onto my average solving time I get that I am averaging 44 seconds roughly for the solving phase. This does seem about right based on my full length solve times. I want to confirm this with some actual full length solve times though.

I tried to attempt some actual solves tonight, so I could give you some times with both in the same solve. However, my brain is just too tired after both of these averages and I DNF'd 3 solves in a row. I'll post some times for full length solves tomorrow or this weekend once I've had the chance to sleep and rest my journeys a bit.

I've fully optimized about 33% of my total corner commutators and my edges commutators are about 10% optimized, so I expect my averages to still get better for each piece type as I continue to work on my algs. My goal is to do exactly what Daniel is doing (and I was inspired by Daniel to do this) and that is to have a prepared alg for every cycle. In my case I am also making sure to associate the 1 syllable name (corners) or associated image (edges) of the cycle with the alg itself. Again that is why I have an algorithm named after Ron van Bruchem ;-)

Chris

P.S. Ron your alg is R' F U2 F' R F R' U2 R F' by the way ;-)

 

[Stefan]

Nice to see an update, Chris, thanks. That was part of the reason I brought that comparison up again. I'm not surprised your corners are much faster than mine now, as I also believe optimized 3-cycles are the best known doable method. Edges I'm still slightly faster but the comparison isn't 100% fair because of the sighted vs blindfolded issue.

 

[cmhardw]

Edges I'm still slightly faster but the comparison isn't 100% fair because of the sighted vs blindfolded issue.

Stefan,

I wouldn't be surprised at all if your blindfolded edges times are still faster than mine for edges. I remember at Worlds 2007 when you, Joey, and myself were all racing BLD solving methods that your M2 was consistently very fast, and noticably faster than my commutators.

Because of the large number of slice moves I don't know if commutator edges could be faster than M2, but I think with optimized algs that it can at least be close.

I think for the same reason (the large number of slice moves) that perhaps a master of r2 methods could be consistently a bit faster than a master of commutator methods. I still think the methods would be quite close in times since commutators uses many fewer moves than r2 as Daniel showed. r2 may come out on top though because it is more "braindead" than commutators (I hate that word to describe it, but you know what I mean). I would of course like to prove this wrong, but I concede that r2 may actually be faster at the top levels than commutators. I just hope this isn't so ;-) Although I am biased in my method, I am not hard headed about it. If r2 does prove to be consistently faster, I will strongly consider switching. So far though no one has posted blindfold trials beating my 1:37 average for 4x4x4 wings. And I think, now that Daniel has convinced me to stop being lazy and optimize my commutators for all pieces, that I can be a slight bit faster than 1:37 on average if I work more at my wing optimizations. I'm not yet convinced to switch to r2, but it's not as if I would never switch. I'm just saying that I'm not yet convinced to do so.

Chris

 

[Swordsman Kirby]

P.S. Ron your alg is R' F U2 F' R F R' U2 R F' by the way ;-)

The Doug Li!

 

[Stefan]

r2 may come out on top though because it is more "braindead" than commutators (I hate that word to describe it, but you know what I mean)

Do you hate that word because you think it could offend its inventors/users? I myself am proud about its braindeadness, that's a core feature. Looking forward to more blindcubers and more data. I'll join you after my diploma.

 

[Mike Hughey]

Chris, I still think you should give yourself about a week with r2, just to see how it does for you. It gets easy so fast, I can't believe you wouldn't at least come kind of close to mastering it in just that one week. Then instead of waiting around for someone else to post faster times than your commutator times, you can see how fast you can do it yourself.

I'd be really curious how fast you'd get in a week's time at the edges with r2. If you're even close to competitive with your commutator times, then you'd know it might be worth the effort to get better at it. I know I'm relatively slow with commutators, but I had been doing commutators for 4 or 5 months when I tried r2 for the first time, and in just 10 r2 solves I was going as fast with r2 as with commutators.

You could also try doing what I do now - if one of the pieces in your next pair is in a middle slice, just do commutators; otherwise do r2. (This was Daniel's suggestion to someone, apparently, and I'm happy I tried it.)

 

[dbeyer]

I do believe I had initially made the comment to Chris, when we were compairing methods at Worlds 07. I then made the passing comment to an r2 user, Lucas Garron.

Stefan, let me also note to you that I am making these posts and comments whilst I don't even blindsolve anymore. It's quite low on the list of priorities at the moment. You and I are both developing methods whilst we aren't actually using them in practice

I would like to say that 100% of my commutators are optimized. Yet they aren't braindead and linked to images yet.

Chris, I can see how another memory system can pay off for corners. That way you can associate the memory mnemonic with one commutator per se.

I've got a lot of work to do, and a lot of catching up to do Chris. I'll be back in the game soon enough (relative to worlds '09).