I really put a lot of thought
into making a method for every part that would scale well - remain easy
even with extremely large cubes. And when I say extremely large, this is the method I solved the 111x111x111 with. It's probably still useful on smaller huge cubes (like 20x20x20) but when you can see a whole face at a time, and count layers, some parts can be done quite a bit faster.

From http://www.speedsolving.com/forum/showthread.php?42084:

First, some basics. I solved most faces in two steps: "cleaning" and
finishing up. The idea of cleaning a face is to solve as many pieces as
possible as quickly as possible. After that step, which typically solves
50% or more of the face, I can go through the longer step of putting
each of the remaining pieces of that color into the center, one at a
time or in blocks. As for notation, I'll be using something like SiGN
(xR means turn the xth layer on the R face, or the first layer if x is
absent), except that I'll also be using lowercase p and q as variables
to better describe classes of commutators.

1) Solve the edges. I do edges first for large computer cubes because
reduction (centers first) scales badly, and because having solved edges
actually lets me use them to keep track what part of the puzzle I'm
working on. A lot of the time I do a pR' move or something to start
working on a row of one center, and the incorrect edge reminds me which
row it is. With so many layers it's impossible to do it by counting or
visual inspection alone. Anyway, for the first 9 edges I did basically
the same thing as with other cubes. For the last three edges I used
moves like pR U2 pR' (for the 10th edge only), pR2 U2 pR U2 pR2, and pR'
F U' R F' U pR. Instead of solving one orbit at a time like on my
keyboard solves, I went for an edge at a time and solved pieces in the
same position in groups. For instance on the last 3 edges there are only
6 possible positions for each piece, so with 109 pieces in each edge
there are a lot of pieces in the same position which can be solved in
the same way, all at once, by replacing a pR move with a whole bunch of
slice moves along the same layer. This took about an hour in total.

2) Clean the first center. I used white. Hold the white face on U, and
then for each row (perpendicular to the F face), we do something like
this: move white centers out of the way on the corresponding row on F
using pU moves, then qR', then solve as many white centers into that
layer as possible using only pU-axis moves, then qR. By "solve as many
white centers ... as possible" I mean I basically look at that row on R,
B, and L, and for every white center I see, move that layer the right
amount. Note that these rows are vertical, which is something I did
because of the way Iso is set up (when zoomed in, it's easy to scroll
through a vertical row on F or R using just the up/down arrow keys). You
could do any of this from a different angle if you wanted. A typical
layer might be something like (2U 4U 7U ...) 3R' y (3U 6U 8U ...) y (U2
4U2 8U2 ...) y (2U' 3U' 4U' ...) y 3R. Each center on white corresponds
to 5 stickers, and a white center on any of those 5 stickers means the
center gets solved. I think roughly 60% of the center ends up solved.

3) Finish the first center. Now I can hold the center on F and look at
R. If I see a white center anywhere, I can solve it using pF qU' pF' qU.
Four-move commutators are fast! However, I can't just do that randomly,
but instead, I have to do it so that the center moves into a place on
the white center that didn't have a solved center already. To check if
there is room I do qU' qU, and if there isn't, I rotate the white center
and repeat as necessary. You'll see this type of checking often as I
continue. Note that this requires centers to be adjacent, and since
we're solving from all five, we have to swap two adjacent centers. On
the 5x5x5 the algorithm for this is 2R U2 2R' 2L' U2 2L U 3R U' 3R',
which you then have to properly undo later.

4) Clean the second center. I used yellow. This is the same idea as the
first center - hold yellow on U (so, white on D) and proceed row by row.
However, instead of using pR' moves to move a row onto the F face, I
used pR U2 pR' moves. This does solve the layers in a different order,
but that's okay. For the middle layer I used U pR U' pR'. Each center on
yellow again corresponds to 5 stickers (any yellow piece in one of
those 5 places means that piece gets solved), and I think roughly 67% of
the center ends up solved after this.

5) Finish the second center. Again I swap yellow with another center, so
I can hold yellow on F, white on U, and the solved center on R. The
commutator this time is pF2 qU' pF2 qU (or pF2 qU pF2 qU' for the
mirror). Since I can't just do x rotations and keep going, I have to do
some extra center swaps to bring each of the four non-white/yellow
centers into the right place. There was also plenty of the qU' qU moves
to check if there's room to put a piece.

6) Clean the third center. I used orange (for visibility). Place orange
on U and white/yellow on L/R. Now we can do pU2 moves but not pU moves.
So I do something like the white center cleaning, where I do pU2 moves
to move orange centers out of the way, then a qR' move to bring the row
down, then do more pU2 moves to solve as many orange centers as
possible, then a qR move. A typical row clean might look something like
(2U2 4U2 7U2 ...) 3R' y2 (2U2 3U2 4U2 ...) y2 3R. Each center on orange
corresponds to only 3 stickers, solving about 57% of the center.

7) Solve the third center. This is just like what I do on yellow, with
the pF2 qU' pF2 qU moves, since they keep U and D solved, and again I
use plenty of qU' qU moves. In fact, there are fewer center swaps than
last time, since the D center can stay where it is.

8) Clean the fourth center. As a general rule you want this to be
adjacent to the third center, so I chose green (since it was brighter).
Unfortunately the cleaning setup I use only really lets us clean a
center opposite of the third one, so we place orange on D and green on
F, then swap F and U, and begin. The cleaning itself is just like the
third center except, again, we use pR U2 pR' rather than pR'. Each
center on green corresponds to 3 stickers, solving about 70% of the
center.

9) Solve the fourth center. Things got pretty messy here and it took a
lot longer than I expected; most of that was probably because I can't
use 4-move commutators any more and thus had to switch to 8-move ones. I
held green on F and orange on D, and then did commutators like [pU2, qR
U qR']. In fact I did all of the pU2 moves ahead of time, so that for
each row I could immediately do a qR move for each piece I wanted to
solve (using pU2 pu2 to check), and then solve many piece in that row at
once. The problem, apart from the large number of qR moves, is that I
couldn't stray too far from U, because I had to do U turns. So I ended
up having to stay on the top half of F, and doing a lot of F and B moves
to be able to solve things. Oh yeah, and once I got rid of all the
green pieces on B, I had to swap U and B and do it again.

10) Solve the last two centers. No cleaning here - I couldn't see any
way to quickly solve most of the center. I held the two centers on F and
R, and solved one vertical row of R at a time. The commutator looks
something like [pU', R' qU' R]. Basically, I would do a pU' for every
center in that row that I could solve, then do the R' qU' R, undo the pU
moves, and finish the commutator. Then rotate F and go again - in at
most 4 separate block commutators I would solve all pieces in that row.
(With one caveat - if the x-center closer to D is unsolved, this
commutator won't work on it. When that happened I had to do it
individually.) After each finished row I did a qF2 move to get it out of
the way and make the next row easy to see; since I had blue on R, I
ended up with a whole bunch of green rows on that face. Since I had to
be in view of the F-R edge to do R tuns, I only did the first half of
the blue face before undoing all those green rows, turning that center
by 180 degrees, and doing it again.

And that's it! It might sound kind of complicated, but each step is
pretty straightforward once you know what's going on, and I spent the
vast majority of my time doing the same kind of thing over and over. The
low move/piece count was mostly due to the cleaning stages, where I
could solve a ton of pieces in one or two moves each. Those stages would
have an absurdly low movecount in axial turn metric / snyder metric,
with something like 400 moves solving 5000+ pieces. And in fact, you can
do a cleaning stage on the same center more than once - just turn the
center to a different orientation and continue. With four of these
cleaning stages you should be able to solve every piece on the affected
centers. I didn't do this because the returns do diminish, and so I
don't think it's worth it to clean more than once for any individual
center. Maybe for the fourth center it's worth it though!

## 20130519

### Speedsolving Posts: A Huge Cube Method

Labels:
methods,
speedsolving

## 20130515

### Speedsolving Posts: Parity Errors

I'm going to be posting some of my longer posts on speedsolving.com here. I think I've written some very useful things down there, but it's a kinda big forum (and I've made a lot of posts!) so it's easy for stuff to get lost. The plan is to copy some of them here, with a link to the original post (for those who want to view the thread). Here goes...

From http://www.speedsolving.com/forum/showthread.php?p=852756:

In speedcubing there are two things we think of as parity: "reduction parity" and mathematical parity. Some things we call parity fall into both categories, but others only fall into one of them, and you will often see people disagree on whether certain things count as parity, because they disagree that both of these two definitions are valid.

Reduction parity occurs when you try to reduce the puzzle so it can be solved by a constrained set of moves, putting it into some subset of the positions. However, you can often reach a position which seems like it is in your subset, but which is actually not, and to solve the puzzle you have to briefly go outside your constrained set of moves to bring the puzzle back into the subset you want. Typically the number of positions you can encounter is some small multiple of the number of positions you expect. The obvious example is PLL parity in 4x4x4: all the centers and edges are properly paired, so you expect to be able to finish the puzzle with only outer layer turns, but this isn't quite possible. OLL parity falls under this definition too (so the reduced 4x4x4 has four times as many positions as you would expect). Square-1 parity also falls under this definition - your constrained set of moves are any moves that keep the puzzle in cubeshape. BLD parity is not of this type (the solver has not reduced the puzzle).

Mathematical parity is based on the idea of the mathematical definition of an odd permutation. Basically, at least one orbit of pieces has an odd permutation, and thus cannot be solved with just 3-cycles. You see this type of parity crop up in blindfolded solves, because blindfolded solvers attempt to solve most or all of the puzzle with 3-cycles and thus an odd permutation is very noticeable. OLL parity on 4x4x4 and Square-1 parity can also be thought of as this way, as they originate from some kind of 2-cycle. PLL parity on 4x4x4 is not of this type (it can be solved with 3-cycles).

Labels:
parity,
speedsolving,
theory

Subscribe to:
Posts (Atom)