From an October 2013 discussion at http://www.speedsolving.com/forum/showthread.php?44398:
What are the shortest possible PLL algs, in terms of how long they are
when written down? This should be more interesting than just finding
move-optimal stuff, and I think there's a lot of room for creativity.
The most common algs may not be the shortest!
To start with, the following notations are OK:
- [P,Q] is a commutator (that is, P Q P' Q')
- [P:Q] is a setup move/conjugate (that is, P Q P')
- (P)n is P repeated n times; parentheses are unnecessary if it's clear what P is
- Any face or slice moves, rotations, or lowercase moves.
Also, the algorithm can do the PLL on any face, and you do not have to
include any adjustment at the end, or rotations at the very start/end.
And the shortest algs we found:
A: L'[F,R'B2R]L, L'[R'd2R,U]L (thanks to Stefan Pochmann)
E: [[RU'L:D2],U2] (thanks to TDM)
F: R'URU'R2F'U'FU[R,F]R2
G: [RL:U2][F'UB':d2], [R'UL',d2][BF:U2], L'R'U2LR[FU'B,d2], [LU'R,d2]B'F'U2BF
H: (M2U)6
J: [[RU'L:d2],U], [[R'UL':d2],U]
N: (r'DrU2)5, (rDr'U2)5
R: R[U2R'U2,UR'F'R]R', R'[U2RU2,U'RBR']R
T: [R2D':F2][B2D:L2]
U: M2uMu2MuM2, B2UMU2M'UB2
V: [F'UBU'F:U][U2,B]
Y: F2[DR2:U][R'U'R:F2]
Z: (UF2)6M'U2M (thanks to Moritz Karl)
20140629
Speedsolving Post: "Shortest" PLL Algs?
Speedsolving Posts: "Cross" Meta-Method for 4x4x4
Posted at http://www.speedsolving.com/forum/showthread.php?17783 on December 18, 2009:
More methods than your cube has room for.
The Theory
The idea behind this meta-method (and I call it that because it
encompasses so many normal methods, as you'll see in a bit) is to divide
the solve into a small number of steps, each of which can be done
relatively efficiently/quicky and in many different ways. There are in
fact only two steps, which are as follows:
- 1: Solve the centers and all 8 of the edge pieces on D (or L, if you prefer).
- 2: Solve the rest of the puzzle.
So, why are these two steps good? The key is that the first step is very
simple to do, while still leaving a lot of freedom to the solver. In
this step, we build a structure similar to the cross from Fridrich;
there is a lot of freedom here, because until the entire step is
completed you have the freedom to do most outer layer turns and a few Rw
U Rw'-type triggers. It may seem constraining, but in practice it is
quite easy to set things up without destroying what you have. There are
many ways to do this, from blockbuilding to a more reduction-oriented
approach.
After we have done the first step, what we are left with is set up quite
well for speedsolving: not only have we paired up the centers (the
pieces that typically require either a lot of freedom or a lot of
moves), but we have also fixed the bottom edges so we can guarantee
never to have to look there. We are now free to do U, Uw, and D moves,
as almost all moves here will keep the orientation of the center blocks
constant, and we can of course use any of the common F2L triggers on the
outer layers. Even though there aren't a lot of layers that we can
freely turn without breaking up the solved pieces, almost everything we
can do has a useful effect on the cube and is also very suitable for
speedcubing.
Step 1: The Cross
There are a lot of ways to do the cross step. Here are some of the ways
I've tried, although they are by no means all of the ways to do this
step:
K4 Style
The actual K4 method sets up some corners as well, so this is a
variation on it. The first step is to set up two opposite centers, one
of which should be your cross color. Next, using the M layer, you pair
up 3 of the cross edges, placing them correctly on the left face (if
you're right-handed). Finally, you finish the centers without disturbing
the cross edges, and then pair up the last cross edge and insert it.
Reduction
First, simply solve all centers like in reduction. Then pair up the four
cross edges (you can do this by pairing two edges at a time, or with a
more 'freestyle' approach where you freely do double layer turns on one
slice) and place them.
Columns
Start by doing only the D center, and place it on the bottom. Then set
up the rest of the pieces by doing eight columns - each column has two
center pieces and one edge piece. You can do the columns in pretty much
any order, but it is important to realize that you can insert a column
with Ru'R' type moves, not just rU2r'.
M-Slice
First, solve two centers and place them on R/L, but make sure they are
not your cross color centers. Next, pair up (using the M slice) and
solve the DL and DR cross edges. Finally, use the M slice to build the
remaining three centers and two edge pairs in whatever order seems most
convenient, making sure not to move the DL/DR edges. Notice that there's
still a lot of freedom since B, U, and F are free, so you can do any
kind of rUr' type triggers, and you shouldn't have to use too many slice
moves.
Step 2: The Rest
Again, there are many ways to finish off the method; here are the ones I've played around with:
Traditional K4
First, place the corners of the first layer (note that it is a bit more
efficient to do this during Step 1 if you can). Next, fill in the second
and third layer by inserting the 8 edge pieces with commutators.
Finally, solve the last layer with CLL and then ELL.
F2L-Style K4
Place the corners of the first layer, using F2L techniques to also place
one edge piece (on average) per slot. Next, fill in the rest of the
second and third layer with commutators, although you should only need
about 4 commutators on average instead of 8. Finally, use CLL and ELL to
finish the last layer.
Reduction (Yau)
First, pair up the edges; 3-2-2 pairing (start with a u, place three
edges and do a u', then do 2-pairing for the rest) is suggested. Next,
solve the F2L and LL with whatever variant of Fridrich you are most
comfortable with.
Commutators
Solve the corners and then finish the rest of the edges two at a time with commutators.
Commutator Fridrich
Place the first layer's corners along with as many edges as you can,
using F2L techniques. Then use OLL and PLL to try to place as many last
layer edge pieces as you can. Finally, solve the remaining edges two at a
time with commutators.
The Method(s) In Practice
The three well-known 4x4 methods built around this are K4 (with two
major variants) and Yau. The standard version of K4 uses the "K4 style"
cross and the "traditional K4" rest, although it has the slight
optimization of doing the four first-layer corners during the cross
step. There is also a variation of K4, sometimes used by Dan Cohen,
which is a "K4 style" cross followed by an "F2L-style K4" rest. Finally,
the Yau method uses a "K4 style" cross with a "reduction" rest.
Sub-minute averages have been achieved with all three of these methods,
and Dan Cohen has even broken the 50-second barrier using Yau. Yau was
also the method he used to achieve the current WR single of 36.46
seconds. It is clear that this meta-method has some serious potential;
all that remains is to practice a lot :)
Speedsolving Posts: Extension to the Tower of Hanoi
Posts from http://www.speedsolving.com/forum/showthread.php?34968, in January 2012.
I didn't know where else to put this, but I'm sure some people here will
find this interesting. Hopefully this is actually new and not an
obvious thing that I somehow couldn't find on Google.
So, you're probably all familiar with the Tower of Hanoi problem. You have three pegs, and n disks of different sizes on one of the pegs, arranged with the largest
disks on the bottom. The goal is to move all the disks to a different
peg; the rules are that (a) you can only move one disk at a time (from
one peg to another peg), and (b) you can't place a disk on top of a
smaller disk. The problem is not too difficult to solve if you are just
trying to finish it, but the mathematically interesting thing is that it
requires O(2^n) moves - roughly doubling for every new disk you add. The reason for this is that, to move n disks, you must first move the smallest n-1 disks to another peg, then move the biggest disk, and finally move the rest of the disks a second time.
For a while I've been casually trying to think of a way to extend this to create puzzles which require O(k^n) moves (for n disks, and for a k as large as we want). I think I've got an idea which will let us do
this. Here is a rough picture of the idea, for a small case:
So, here's what's going on here. Choose some number j. Instead of 3 pegs you have 2j+1 pegs, and instead of disks that cover one peg, they cover j adjacent pegs. The trick is that the only way to move a disk is to move all of the smaller disks to j of the other j+1 pegs - and, even then, this will only allow you to move the remaining disk clockwise or counterclockwise by one peg.
Figuring out the number of moves is a little trickier than in the normal
3-peg version, but at least we know that we can only move the biggest
disk if all of the other disks are in a pile. To move a pile of n disks by one space, we need to (1) move n-1 disks by j spaces, (2) move the biggest disk, and then (3) move n-1 disks by j spaces again. To move a pile of n disks by k spaces, though, we need to (1) move n-1 disks by j spaces, (2) repeat (move the biggest disk, then move n-1 disks one space) k-1 times, (3) move the biggest disk one last time, and then (4) move n-1 disks by j spaces again to finish. Only moves of 1 and j spaces seem to be important here, so if we write those as 
Or, just in terms of the 1-move numbers:
Anyway, it looks like the k constant (the number for which 
Incidentally, if you don't like the idea of disks spanning multiple
pegs, you can get the same effect by using 1-peg disks and adding the
rule that you cannot put a disk onto a peg if a smaller disk is on that
peg or one of the next j-1 pegs in either direction.
Alright guys, I made a sim. Try it here:
http://mzrg.com/js/hanoi/
>Very interesting, didn't read all of it though. Just curious, how did you come up with this idea?
I basically was thinking about how to expand the problem while keeping the restricted feel of the original one (only really one way to move stuff around) and I randomly thought of the idea of disks that would cover more than one peg, and of just barely having enough pegs to move those disks around. I initially had a wrong idea of how the math would turn out (since I didn't realize you could take shortcuts when moving a group of disks more than one space at a time) but the idea turned out to be what I wanted anyway.
PS: Wolfram Alpha gives the following closed form for
:
Speedsolving Posts: Almost-2gen LL Algs
From http://www.speedsolving.com/forum/showthread.php?18539 (January 2010):
From any ZBLL we can easily get to PLL using only 2gen moves. All PLLs
are a U, Z, or H perm away from either solved, R perm, or Y perm.
Therefore, if we can do R and Y perm with at most 2 D-layer moves, we
can do any ZBLL with at most 2 D-layer moves.
So, here is an R perm with exactly 2 D-layer moves:
R U2 R D R' U R D' R' U' R' U R U R' U
And here is a Y perm (but not an efficient one):
R' U' D (R' U' R U)3 D' U R (R U R' U R U2 R')2 U'
I imagine these algs could be very useful for OH - everyone loves 2gen
moves, and keeping D turns to a minimum is very helpful. Unfortunately, I
don't know of any way to generate optimal algs of this type. Does
anyone have an idea?
P.S. You can also do every ZBLL with
F (R U R' U')3 F' U (R U R' U R U2 R')2 U2
From http://www.speedsolving.com/forum/showthread.php?708&p=680961#post680961 (December 2011):
Dumping some optimal 2-F-move PLLs (there are probably a few optimal ones I missed but the optimal lengths should be accurate):
A-perm a HTM-optimal: 11f R U' R F2 R' U R' U' R2 F2 R2 QTM-optimal: 15q R U' R F2 R' U R' U' R2 F2 R2 A-perm a HTM-optimal: 11f R2 F2 R2 U R U' R F2 R' U R' QTM-optimal: 15q R2 F2 R2 U R U' R F2 R' U R'
E-perm
HTM-optimal: 18f R' U2 R U' F' R' U R' U2 R U R' U R2 F R' U' R R' U R F' R2 U' R U' R' U2 R U' R F U R' U2 R R U R' U R' F U' R2 U' R2 U2 R' U' R F' R' U R2 R2 U F' U R' U' R U R' U' R U R' U' R F U' R2 R2 U F' R' U R U' R' U R U' R' U R U' F U' R2 R2 U' R F R' U R U2 R2 U R2 U F' R U' R U' R' R2 U2 F' U' R' U R U' R' U R U' R' U R F U2 R2 R2 U2 F' R' U' R U R' U' R U R' U' R U F U2 R2 F U R2 U' R U R' U R2 U' R' U R' U' R U' R F' F U' R U' R U R' U R U2 R' U R' U' R U2 R' F' F U' R U' R' U2 R U' R' U R' U2 R U R' U R F' F U' R' U R' U' R2 U R' U R U' R2 U R U' R F' F R U2 R' U R U' R U2 R' U' R U' R' U R' U F' F R' U R' U R U' R U R2 U' R U' R' U R2 U' F' F R' U R' U' R2 U R' U' R U' R2 U R U' R U F' F R' U' R U' R' U2 R U' R U R' U2 R U R' U F' QTM-optimal: 20q R2 U F' U R' U' R U R' U' R U R' U' R F U' R2 R2 U F' R' U R U' R' U R U' R' U R U' F U' R2 F U R2 U' R U R' U R2 U' R' U R' U' R U' R F' F U' R U' R U R' U R U2 R' U R' U' R U2 R' F' F U' R U' R' U2 R U' R' U R' U2 R U R' U R F' F U' R' U R' U' R2 U R' U R U' R2 U R U' R F' F R U2 R' U R U' R U2 R' U' R U' R' U R' U F' F R' U R' U R U' R U R2 U' R U' R' U R2 U' F' F R' U R' U' R2 U R' U' R U' R2 U R U' R U F' F R' U' R U' R' U2 R U' R U R' U2 R U R' U F'
F-perm HTM-optimal: 15f R2 U R2 U2 F2 U R2 U2 R2 U R2 U' R2 U2 F2 R2 U R2 U' R2 U2 R2 U' F2 U2 R2 U' R2 U' F2 F2 U R2 U R2 U2 F2 U R2 U2 R2 U R2 U' R2 F2 U2 R2 U R2 U' R2 U2 R2 U' F2 U2 R2 U' R2 R2 U' F2 U2 R2 U' R2 U2 R2 U R2 U F2 U2 R2 R2 U2 F2 U' R2 U' R2 U2 R2 U R2 U2 F2 U R2 QTM-optimal: 19q R U R' U' R' U R U F' U R' U R U2 F R U' R' R U R' F' U2 R' U' R U' F U' R' U' R U R U' R' R U R U F' U' R U R' U' R' U2 F U' R' U2 R' R U2 R U F' U2 R U R U' R' U F U' R' U' R' R' U' R U' R' U R U R2 F' R U R U' R' F U R R' U' F' R U R' U' R' F R2 U' R' U' R U R' U R
G-perm a HTM-optimal: 15f F2 U R U2 R' U' R' U2 R2 U R' F2 R' U R R' U' F2 U R U2 R U2 R' U F2 U2 R U' R' QTM-optimal: 18q R U R' U' R' U F R U R U' R' F' U R' U2 R
G-perm b HTM-optimal: 15f R' U' R F2 R U' R2 U2 R U R U2 R' U' F2 R U R' U2 F2 U' R U2 R' U2 R' U' F2 U R QTM-optimal: 18q R' U2 R U' F R U R' U' R' F' U' R U R U' R'
G-perm c
HTM-optimal: 14f R2 U2 R2 F2 U' R2 U R2 U F2 U2 R2 U' R2 QTM-optimal: 17q R2 U' R U' R U R' U R' F' R' U R U' F R'
G-perm d HTM-optimal: 14f R2 U R2 U2 F2 U' R2 U' R2 U F2 R2 U2 R2 QTM-optimal: 17q R F' U R' U' R F R U' R U' R' U R' U R2
J-perm a HTM-optimal: 13f R' F R' U' R2 U' R2 U R' F' R U R2 R2 U' R' F R U' R2 U R2 U R F' R QTM-optimal: 16q R' F R' U' R2 U' R2 U R' F' R U R2 R2 U' R' F R U' R2 U R2 U R F' R F R' U R U' F' U R' U2 R U' R' U2 R R' U2 R U R' U2 R U' F U R' U' R F' R' U' R U F R U' R' U' R' U R2 U R' F' R' U' R U' R' U F U R' U' R F' R' U R2 R2 U' R F R' U R U' F' U' R U R' U R F R U' R2 U' R U R U R' F' U' R' U R
J-perm b HTM-optimal: 11f R U' F U' R' U' R U F' U2 R' R U2 F U' R' U R U F' U R' QTM-optimal: 12q R U' F U' R' U' R U F' U2 R' R U2 F U' R' U R U F' U R'
N-perm a HTM-optimal: 15f R2 U R2 U' R2 U' F2 U' R2 U R2 U F2 U2 R2 R2 U2 F2 U' R2 U' R2 U F2 U R2 U R2 U' R2 QTM-optimal: 21q R U2 R2 U' R2 F' R U R' U' R' F R' U R U2 R' R U2 R' U' R F' R U R U' R' F R2 U R2 U2 R' R U R' U R U' F U' R' U' R U F' U2 R' U2 R U' R' R U R' U2 R U2 F U' R' U R U F' U R' U' R U' R'
N-perm b HTM-optimal: 15f R2 U F2 U2 R2 U R2 U2 R2 U' R2 U2 F2 U' R2 R2 U' R2 U2 F2 U' R2 U2 R2 U F2 U2 R2 U R2 QTM-optimal: 23q? R U' R' U R' U2 R2 U R2 F2 U R U R U' R' U' F2 F2 U R U R' U' R' U' F2 R2 U' R2 U2 R U' R U R' R' U2 R' U' R2 U F' U' R U R' U' R2 U2 R F R' U R R' U2 F U R2 U2 R' U' R U R' F' R U2 R' U' R' U R R' U' R U R U2 R' F R U' R' U R U2 R2 U' F' U2 R R' U' R F' R' U2 R2 U R U' R' U F U' R2 U R U2 R
R-perm a HTM-optimal: 13f R2 F2 U R U R' U' R' U' F2 R' U R' R U' R F2 U R U R U' R' U' F2 R2 QTM-optimal: 16q R2 F2 U R U R' U' R' U' F2 R' U R' R U' R F2 U R U R U' R' U' F2 R2
R-perm b
HTM-optimal: 13f R2 F R U R U' R' F' R U2 R' U2 R R' U2 R U2 R' F R U R' U' R' F' R2 QTM-optimal: 16q R2 F R U R U' R' F' R U2 R' U2 R R' U2 R U2 R' F R U R' U' R' F' R2
T-perm
HTM-optimal: 14f R U R' U' R' F R2 U' R' U' R U R' F' F R U' R' U R U R2 F' R U R U' R' QTM-optimal: 15q R U R' U' R' F R2 U' R' U' R U R' F' F R U' R' U R U R2 F' R U R U' R'
V-perm HTM-optimal: 15f R2 U2 R2 U R2 U2 F2 U R2 U R2 U2 F2 U' R2 R2 U2 R2 U' F2 U2 R2 U' R2 U' F2 U2 R2 U R2 R2 U F2 U2 R2 U' R2 U' F2 U2 R2 U' R2 U2 R2 R2 U' R2 U2 F2 U R2 U R2 U2 F2 U R2 U2 R2 QTM-optimal: 19q R U' R' U R F R' U' R2 U R U' R U R2 F' R' R F R2 U' R' U R' U' R2 U R F' R' U' R U R'
Y-perm
HTM-optimal: 14f R2 U' R2 U F2 U' R2 U' R2 U F2 R2 U R2 R2 U' R2 F2 U' R2 U R2 U F2 U' R2 U R2 QTM-optimal: 19q R2 U' R2 U' R2 U R' F' R U R2 U' R' F R R' F' R U R2 U' R' F R U' R2 U R2 U R2 R' U' R U' R U' F U' R' U' R U F' U2 R2 U R R' U' R2 U2 F U' R' U R U F' U R' U R' U R
Speedsolving Posts: 2D State Diagrams
The posts here are from January 2009 and can be found in this topic: http://www.speedsolving.com/forum/showthread.php?8628
This is a topic on puzzle theory - specifically, it deals with the theory of symmetrical twisty puzzles. There's no real "theory" section in this forum but it doesn't belong in Off-Topic, so I've put it here so more people will see it. (This does have applications to speedcubing, in terms of solving gelatinbrain puzzles.)
So, as some of you may know, symmetrical twisty puzzles can be described by talking about the shape and the number of separate types of turns in each of the three basic categories (face turns, edge turns, and vertex turns) which are named around where the axis (which the pieces rotate around) points. A 3x3x3, for instance, is a cube with one type of turn (in the face turn category); in my categorization scheme that would make it type Cf (C for cube, f for face turn). The only other type-Cf puzzle is the 2x2x2, which has a deeper turn that just happens to line up with the turn on the opposite face. (The 4x4x4 and 5x5x5 have two face turn types, so they are type Cff. Similarly the 6x6x6 and 7x7x7 are type Cfff.) Note that I'm considering a 3x3 with slightly shallower or deeper cuts to be the same, because it has the same number and types of pieces and the exact same solution, so the only difference is in the shape of the pieces.
If we want to talk about symmetrical puzzles with only one type of turn, it's relatively simple, because we can describe the depth of the turn as a single number. But if we have two types of turns, we need two numbers: for instance, on a 5x5x5, if we imagine a turn of depth 0 to turn nothing and a turn of depth 1 to turn the entire cube, the two turns have depths 1/5 and 2/5. But it's hard to imagine exactly what numbers will give a certain puzzle, and which numbers will give a different one. So the question is this: how many possible puzzles are there of a given type, and, more importantly, how can we understand where one puzzle begins and another ends?
My answer to this is the 2D State Diagram. This particular one describes the Tvv-type polyhedra (that is, tetrahedra with two vertex turn types - note that a vertex turn and a face turn are the same thing on a tetrahedron). The two axes correspond to the two depths of turn, and each one goes from 0 (no part of the puzzle is turned) to 1 (the entire puzzle is turned).
So what are the lines in the diagram? Each one represents some kind of puzzle which only exists for a very specific set of turn depths. The diagonal line from the top-left to bottom-right represents the degenerate case where the two depths are the same (so, type Tv puzzles with only one type of cut). Each of those big spaces between the lines, however, is a specific puzzle, which remains the same anywhere in that space. There are also puzzles on the lines themselves, and each place where lines intersect is another puzzle, albeit a very specific one because even a small change in either of the two depths will make it different. The Pyraminx, for example, is located at the intersection of a horizontal or vertical 2/3 line, and the diagonal line from bottom left to top right.
Finally, I have prepared an interactive simulation (!) of this state diagram, so that you can play with it to see how it works out. It uses the GeoGebra geometry program, which I'm really fond of. You can download it from my website. To use it, just move the red point around inside the square (use the white pointer symbol to move a point around), and watch how the puzzle changes when you cross or move along lines.
I wrote up the state diagram for type Dff puzzles (dodecahedra with two different depths of face turns). The Gigaminx is from this category. Note that this category is MUCH more complicated than the Tvv type I showed in the first post - I'm not completely sure of the count, but I think there are a whopping 98 puzzles of this type!!! I'm really glad I made an interactive simulation, because there is no way I'd ever want to draw all of them out by hand. You can also see that there are 7 puzzles along the diagonal (these are the Df type puzzles).
In the image, I have marked a few lines as green. Those lines are distinctive because, although they separate different puzzles, the puzzles on the lines themselves are equivalent to one of the puzzles on one side of the line. For instance the Megaminx and Supernova, although they look like they might different puzzles, function exactly the same way.The full way to count the number of puzzles is:
- Any open space is a separate puzzle, although you have to make sure to only count puzzles on one side of the main diagonal (for everything here).
- Any line segment (i.e. a line between two intersections) is a separate puzzle, except (i) if the line segment is green; (ii) if the line segment is on the main diagonal; (iii) if the line segment is on the top or left. The second and third cases remove puzzles with essentially only one depth of turn, and the first removes a puzzle that looks like a different puzzle but isn't.
- Any intersection of lines is a separate puzzle, as long as (i) it isn't on the the top or left or the main diagonal, and (ii) it has at least two black lines crossing it.
The Tvv case gives 11+10+2 = 23 puzzles like this (I think). Note that, although I haven't added it in yet, the halfway lines and the bottom-left-to-top-right diagonal in the Tvv diagram should also be green. It's only important to know what lines are green and what are not when you are counting puzzles, though.
Finally, there is a GeoGebra simulation of this, although I have made the two-dimensional slider much larger to compensate for the complexity. That way you can really see what lines you are crossing.
For each polyhedron there are actually six types of second-order puzzles: the familiar vv, ee, and ff, but also fv, ev, and ef. The first three use only one type of cut, so they're symmetrical, but the other three use two different types of cuts and have much more complicated drawings. As an example I've made one for the Cfv group. There are around 50 puzzles in this group, most of which have probably never been seen before. I hope to eventually make an interactive simulation of all 5*6 categories of second-order regular twisty puzzles. I imagine there will be over 1000 puzzles in total!
20130519
Speedsolving Posts: A Huge Cube Method
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!
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).
20090122
How to Solve 6x6+ (on hi-games)
Let's start by saying that I don't really like the "grip shift" controls. Thus, the way I solve big cubes is designed to be somewhat fast (although I'm sure there are faster ways out there) while changing the grip as few times as possible. As it turns out, reduction is the best method for this.
Centers
Obviously, centers require lots of face turns, but also lots of slice turns. So how can we solve them with a small number of grip shifts? As it turns out, we can do a pretty decent job using U, F, D, B, and any r and l slices. Only build and insert rows on the x axis (faces U, F, D, and B), and although this uses a lot of cube rotations it isn't too restrictive. Besides, you can only see U and F anyway. So then the question is what slices we need. Here's how I do it:6x6 and 7x7: shift both right and left in once. Now you can do all of the usual moves (3r, 3R, 2r, 3l, 3L, 2l) with each hand.
8x8 and 9x9: shift right in twice and left in once. The left hand can do 2l, 3l, 3L and the right hand can do 4r, 3r, 4R.
10x10: shift right in three times and left in once. The left hand can do 2l, 3l, 3L and the right hand can do 5r, 4r, 5R. Note that 4R is actually not possible (except by doing 4r y2 3l'), so you should try to work around this when building centers.
Note that in the cases where the right and left hands are asymmetrical, I really suggest pairing from the inside out, since slice moves are not always possible or convenient. The goal is to avoid cube rotations so you can spend all your time actually doing moves. As with other large cubes, by the way, I really suggest pairing up 1x(n-1) rows of centers, and putting them together as soon as they are done.
Edges
My method for edges is worse, but it still works pretty acceptably. The way I do this is to use the D slice to do slice moves and pair up edges on the E slice, since I tend to use the other slices to move edges around. Currently I use WO for moving the D slice in (up) and SL for moving it out (down), but you can use anything you want. Then I pair up edges multislice-style: I start by pairing up the innermost pieces, and then move out. Note that it's also possible to just use the L slice (and pair up edges on M), and use only RUDFB moves to insert edges, but personally this doesn't feel natural to me so I don't use it.My method of pairing up 5x5-style edges is freeslice (the bigcubes.com) style, which means I pair up one edge group (of 3 pieces) at a time and don't fix centers until I have eight edges paired and out of the E slice. Since this normally requires U moves, I end up doing a LOT of z2 moves. As I said, this isn't the best way to pair up edges, but it works. Note that if you end up with a parity case you are better off temporarily moving the edges to the M slice, shifting R and L in by an appropriate amount, and doing the parity normally. This is possible because you don't need to do single-layer R and L turns.
So I pair up edges in two steps on 6x6 and 7x7, three steps on 8x8 and 9x9, and four steps on 10x10. On the last step, I just use the standard 5x5 pairing (which is on M), because if I have the right and left grips on the far outside of the cube I can do slice moves AND R and L turns.
3x3
The 3x3 stage is pretty standard, press space and just solve it normally. On even cubes there are parity issues to deal with. The way I do this is, for OLL parity, shift L and R in until the r and l slices turn half of the cube, and then the algorithm is:r U2 x r U2 r U2 r' U2 l U2 r' U2 r U2 r' U2 r'
and for PLL parity, just shift R in so that the r slice is halfway, and then do:
z r2 z' r2 U2 r2 y2 L2 y2 U2 r2 z r2 z'.
There are a lot of cube rotations so it looks longer than it is, but it's still kinda slow.
So, good luck with bigcubes! Make sure to give each one a try, because for a lot of them you'll get on the top 100 list if you solve it, no matter how long it takes.
20081128
Centers Last (old)
(Disclaimer: I wrote this guide in June 2007, on twistypuzzles.com. Here it is, with just a few edits. I haven't changed up the method much if at all since then.)
This is a method for solving arbitrarily large cubes. I decided to make a topic because I want to keep a permanent reference for this method, and because I just recently improved it a bit and I thought I'd like to share that with you.
From personal experience, it becomes faster than the reduction method for cubes of a certain size or greater, but that size is determined by a lot of factors (such as how fast you can make slice moves and how good you are at finding pieces for reduction). Suffice it to say, though, that if I ever attempt a truly huge cube (say 40x40x40) I'm not going to use reduction. This method does use about 30-50% more moves than a reduction strategy for a given size of cube, though, and although you have better recognition you will need more physical endurance to be able to complete a cube with this strategy.
The basic method is just this:
1) Solve all of the edges and corners. They must be solved relative to the centers on an odd cube.
2) Solve all of the centers without disturbing the edges and corners (much).
There are a lot of subtleties, though. Each step has many different ways to complete it, and there are a lot of small (but very useful) shortcuts. Throughout this guide, I'm going to use the r* notation; what this means is, on an NxNxN cube, to do a clockwise turn on all R-side slices from the second slice to the floor(N/2)th slice. For example, on a 6x6x6 cube r*' would mean to turn the 2nd and 3rd R slices counterclockwise. This is useful for generalized algorithms.
My current step 1 is done by matching up pieces of edge groups. I'll mostly be using 3x3x3-like moves for this part, so think of everything as corners, edge groups, and center groups. Using only the outer layers, move an edge group with a lot of similar pieces to DF (but if you can't find one in 4-5 seconds don't bother), and choose a color pair of edges that you will place in that spot. Make sure to remember which color is on top. Now, looking at the R and L layers, find edge pieces which match that color pair and move them to UF or UB using R/U/L moves, then shoot them down to DF with the appropriate slice move. Once DF is completely grouped up, you can do something like R' L F to move it into the R or L layer; keep doing this, while never disturbing the previously grouped edge groups. When you have 7 of them, you will not be able to do this any more; then, move the M layer to the E layer (just do z), and group another edge group together using horizontal slices. You can use moves like RUR' to get the fifth unfinished edge group into E. When you are done, move the finished group into U or D. At this point, U and D should each have 4 finished edge groups. You can actually finish one more edge group in E quickly (remember, you can do things like R2 because centers are irrelevant) before you have to do moves like (vertical slice) R F' U R' F (vertical slice)' to finish off the remaining edges. Note that you can only be sure of solving 11 of 12 edges like this. Don't try to use last-two-tredges or parity algorithms yet, though.
When you have paired up at least 11 edges, it's time to solve the edges and corners into a cage. Do it like the 3x3x3 step. Make sure it's solved relative to the centers if you're doing an odd cube. Here is a trick: when you get to the orient step (OLL for Fridrich, step 3 for Petrus) it's very helpful if the last edge group, the one which will almost certainly have parities in it, is one of the edges you are going to orient. If you're not color neutral, you can force this easily: for example, I solve Fridrich with a yellow last layer, so I can simply pair up all of the edge groups which don't contain yellow first, which will ensure that my parity edge is in the last layer when I get to it. So fix all of the orientation parities at the same time, then do OLL, then fix the permutation parity if you need to, then do PLL. The permutation parity is very easy, by the way: just do r*2 U2 r*2 U2 r*2.
So edges and corners are all solved; now onto step 2. In this step, we use commutators to solve all of the centers. The goal is to solve one center completely, then the opposite center, and then any other center, an adjacent center, and the last two. But again, there are a lot of subtleties and tricks here. First of all, a lot of people tend to use commutators like r U' r' d r U r' d'. There's nothing wrong with that, but I much prefer commutators in the form of r U l' U' r' U l and r U' l' U r' U' l. These commutators are very fast to execute because all of the interior slices are on the same axis, and you can see what is going on by only looking at two faces (where the centers are coming from and where they are going), leaving you free to look for the next center on an adjacent face. You'll have to experiment with this algorithm to get a feel for it, but you should know a couple things: (a) you can vary the affected centers in the 3-cycle by varying which slices you use (and the r- and l-like slices don't even have to be the same depth, i.e. r U 3r U' r' U 3r works fine); (b) x-centers can only be solved by one of these, but others can be solved by both; (c) the first move of the commutator should move a center piece that you want to move to the U layer into a space in U that does not already have a U-color center in it; (d) it's possible to bring entire blocks up to U by using more than one slice in place of one (or both) of the component slices of the commutator, but the first move has to bring the block to a place in U that is mostly or fully unoccupied, and some blocks are simply too large to do this with; and (e) it's best to only use setup moves involving U and only try to solve one piece or block at a time, so that the edges and corners don't get further than an AUF away from solved.
Now that we've gone over the small-scale details, let's concentrate on the large-scale ones. When you're solving the first center, pieces can come from all five centers, but you will notice that bringing them from the opposite center is time-consuming for a couple of reasons, notably 180-degree turns and slow recognition. There is a solution, however: the move r* F2 r*' l*' F2 l* will swap the F and D centers, completely on an even cube and mostly on an odd cube, although it messes up some edges so you will have to undo it after you solve the U center. So one way you could do the first center group (say white) is to bring every white center cubie from one face into the white face, then swap that face's center group (which contains no white cubies now) with the center group opposite white, and finally just bring all of the white centers (from the center group that used to be on bottom) onto the white face before reswapping the two center groups. Personally I like to hold the target face on U, and then bring all the target center pieces on F and R into the target face before doing y2 and doing it again. Once you have the first center, the opposite center is the same, but this time every center piece you want to bring in will be in an adjacent face, which makes it a little easier.
Now, you have four centers left to do. Pick one and hold it on U, then transfer the target pieces from F to U, swap F and D, transfer the target pieces from F to U, swap F and D, do y2, transfer the target pieces from F to U. If you want to be fast, this should be mostly mechanical, as it's a lot of the same type of move done from more or less the same angle. Now pick an adjacent face and hold it on U, with the just-finished face on B. Transfer the target pieces from F to U, swap F and D, transfer, swap. Remember that if you do one swap, you must do a second one, because otherwise the edges will get messed up. Now hold the last two centers on F and U (the order is irrelevant) and finish the cube. You're done!
By the way, if you want to use this on cubes smaller than 6x6x6, there are a couple of key differences. Depending on how good you are at reduction, it may be faster for you to just hold the edges on the E layer and pair them up normally. If that works for you, do it. Also, on the smaller cubes, you shouldn't bother with swapping centers, because there are not enough centers to swap to make it worthwhile. If you want to reduce the number of centers you have to move from one face to an opposite one, you can try to find a face that has as many centers as possible on that face and the adjacent ones, and start solving there. But unless you are very slow at the centers part of reduction, this will probably be slower for you for small cubes, so I don't recommend it for the small ones.
Solving 4x4x4 and 5x5x5 Supercubes
Although the 4x4 and 5x5 supercubes look much more difficult and impressive than the standard ones (even experienced bigcubers will wonder how you can find pieces so quickly!), they aren't much harder than the normal cubes: all they take is a slightly different method. The following tips and tricks were all gotten through experience and practice. Note that I'm going to describe the reduction method below, for a couple reasons: I think it's the fastest known way to do supercubes (and normal cubes for that matter), I'm most familiar with it, and you're probably most familiar with it. So if you're not a reduction user, then sorry, the only advice I can give you is to go practice :)
Centers
Centers are the only part that's really different about supercubes, although they are not the only part that you have to solve differently. In a supercube, every center has to be solved into the correct spot - they're not interchangeable anymore. Thus, instead of just solving blocks of centers, you have to actually pay attention to what goes where.
In a 4x4, you only have x-centers, which have three colors in the standard Pochmann sticker design (which I really recommend, because just drawing arrows or cutting corners off the stickers makes it very hard to see what goes where). I always put 4x4 centers together by making two 1x2 blocks. This probably doesn't require any explanation at all, although you might find it helpful to know that if you pair up the two yellow centers across a red-yellow 'edge', the other stickers will be paired across an orange-yellow 'edge' (since orange is the opposite of yellow). This can make recognition and setup easier.
If you go to solve centers, you might notice that the last center doesn't automatically solve itself anymore. That should happen 5/6 of the time, but fortunately there are algorithms to fix this quickly. If you want to swap Ufr and Ufl, you can use this A-perm-like algorithm:
x r' U r' d2 r U' r' d2 r2
If you want to do a diagonal swap, on the other hand, the algorithm I currently use comes from the Square-1 and is as follows:
r2 U D r2 U r2 U D r2 U r2 U D r2.
So your centers should be solved and you can now start on the edges step.
In a 5x5, on the other hand, you have many different types of centers, and now the fixed center, although it cannot move, must be oriented along with the rest of them. Again I pretty much solve the centers with my normal method (1x3 blocks, with the first block containing the fixed center) although it takes a bit longer to find the exact pieces I am looking for. If you see any blocks already formed for the first center or two, that will be very helpful, so try to preserve them.
On 5x5 you still have last center problems, but since PLLs are hard to recognize and turning a fixed center (only) by 180 degrees is slow, I prefer the following method. First I solve a 2x3 block on the second to last center, and position it so I can do rUr'-type triggers without messing it up. Then I intuitively solve all of the T-centers on U and F. It's important to solve them relative to the fixed center (not just relative to each other). There is one other case here, that of parity, where you have two edges swapped. The quick solution is just this:
r U2 r U2 r U2 r U2 r.
That algorithm should do an opposite swap of edges on U (a Usl-Usr swap to be exact), so now you can be certain to be able to solve the edges only. Finally, I have six T-centers left; I do an F turn to set them up to a more convenient location, and then finish off the centers with U turns and the Niklas commutator (which has two forms):
r U l' U' r' U l
l' U' r U l U' r'.
Sometimes it is actually more convenient to just solve the F centers with this commutator, and then finish off U with an A perm (which does exactly what you think it does). If you get an E or an H, good luck, you might as well just do two As. The A perms (for 5x5) are:
x r' U r' d2 r U' r' d2 r2
x r2 d2 r U r' d2 r U' r.
Edges
If you got the Eastsheen supercubes, you might notice that your edges and corners have more colors than they need to. The extra colors don't affect anything (although sometimes they can make recognition for PLL a little easier, on 3x3), and after a couple of dozen solves you'll learn to ignore them.
For 4x4, you can do edges exactly as you would on a standard cube. There is no change at all no matter what method you use, so go full speed on this step.
For 5x5, if you use AvG or any other kind of 2-pair edges method, do whatever you normally do. You'll notice that you never get parity - this is because we fixed it during the centers step. Convenient, isn't it? If the T-centers are solved, you can never get parity on the wings. Anyway, if you use the freeslice/bigcubes method, the biggest difference is that during the first 8 edges you can't do half turns of the faces (F2/R2/B2/L2 if you solve in the E slice, for instance) unless the slices are all solved. Just making them parallel isn't enough, because that will actually slightly mess up two centers. You will also notice that, during the last 4 edges, you can't do the m U2 m' U2 algorithm, because that also messes up centers a bit. (If you really want to do it, you should do the inverse algorithm twice.) You should also be careful during the last 2 edges: if you solve this in one step, be very careful about whether your algorithm messes up centers or not, because some will and some won't. If your algorithm does mess up centers, you can always just fix the edges with the r [flip edge] r' algorithm, which is completely center-safe.
3x3x3
The final step on both 4x4 and 5x5 is to solve a supercube 3x3. You don't need to learn any new tricks for this, you just have to be more careful. When you're putting together the cross, make sure that the centers are all oriented the right way; since this takes so much more thought than a normal cross I do not at all expect you to do this in one look. Feel free to do it one or two edges at a time. Now, if the centers on the first two layers are correctly oriented, you are basically home free: almost all F2L algs will keep them solved (the only one I know of that messes them up is the 2-gen edge insert algorithm, but you can always use an alternate algorithm), and most OLL algs will keep them solved as well. Some PLL algs do, and for certain ones (U perm, for instance) it might be helpful to learn alternate algorithms that don't mess up the centers at all, since you have to spend extra time fixing it. Here's one possible alternate U perm:
F2 U (M' U2 M U2 M' U2 M) U F2.
If you do end up with a messed up center, you should twist both it and the U center, because the U center hasn't been fixed to a specific orientation yet anyway. The following (intuitive) algorithm will flip the front center clockwise and the left one counterclockwise (note that here M and E mean every slice together):
M' U M E M' U' M E'.
There are three parity algorithms that you should know. The first two are the standard 4x4 parity algorithms (so of course they only show up on even supercubes). For the orientation parity, you can still use the normal one although that will twist the R or L center by a quarter turn, so I strongly suggest that you use some kind of slice-turn-only parity. My favorite is this one:
2R U2 x 2R U2 2R U2 2R' U2 2L U2 2L' x' U2 2R U2 2R' U2 2R'.
For PLL parity, the normal algorithm will mess up centers pretty badly, so here is one that won't:
x' 2U' R F' U R' F 2U 2D F' R U' F R' 2D' x
Finally, at the very end on both 4x4 and 5x5 supercubes, half of the time the U center will be twisted by 180 degrees. There are two algorithms I use for this, either of which can be faster depending on the cube and your style:
(R L U2 R' L' U)2
(R' U' R U')5.
And with that, you know everything you need to solve the 4x4 and 5x5 supercubes every time. Good luck, and good times!