Message #3914

From: Joel Karlsson <>
Subject: Re: [MC4D] Notation
Date: Thu, 04 Jan 2018 22:11:25 +0100

The pictures…

2018-01-04 22:07 GMT+01:00 Joel Karlsson <>:

> The pictures…
> 2018-01-04 21:05 GMT+01:00 Joel Karlsson <>:
>> This got longer than expected… However, there are a lot of examples
>> (including pictures) so I think that it should be quite readable. For those
>> only interested in the notation for the physical puzzle, you can skip
>> "Notation for MC4D" and "Generalisation…" although I encourage you to
>> explore those as well.
>> *Coordinate system and labelling*
>> I’ll use the coordinate system x-right, y-up and z-toward yourself when
>> introducing my notation. Further, I’ll use R for the right half of the
>> puzzle, L for left, U for up, D for down, F for front, B for back, C for
>> center and E for edge. I hope that you are okay with these, the one least
>> intuitive is probably E which refers to the face on the very top and bottom
>> when holding the puzzle vertically and the face on the right and left side
>> of the puzzle when holding the puzzle horizontally. See attached pictures
>> for some examples.
>> We’ll see that it’s very useful to introduce notation for the negative
>> half-axes since rotating a face around the positive half-axis and then
>> around the negative half-axis (both following the right-hand rule described
>> below, i.e counterclockwise rotations) brings you back to where you
>> started. I’ll use ‘ (prime) for this so, x’ is pointing left for example.
>> *Puzzle representation and rotation:*
>> It’s very useful to be able to specify the representation and rotation of
>> the puzzle. I’ll do this by using rep (short for representation) and
>> indicating which faces are inverted (in contrast with the octahedral
>> faces). Note that the inverted faces always are opposite so specifying one
>> is enough although I find it easier to read when both are specified (do as
>> you wish). For example, rep(UD) means that the up and down faces are
>> inverted. This doesn’t completely specify the rotation (which axis is
>> parallel with the long side of the puzzle) in the case that C is inverted.
>> In this case, I’ll just put that axis after the C so rep(Cx) means that the
>> C and E face is inverted and that the puzzle is oriented vertically with
>> the longest side parallel with the x-axis. See attached pictures for some
>> examples (again). If I don’t say anything I will, in later examples, start
>> from rep(UD) as in picture 1.
>> *Basic twists*
>> Starting with rep(UD) (see picture 1) the easiest move might be Uy,
>> rotating the U face around the y-axis in the mathematically positive
>> direction/counterclockwise, following the right-hand rule (right thumb
>> pointing in the positive y-direction, rotate in the direction that your
>> right fingers can curl). Similarly, Ux would rotate the U face around the
>> x-axis, once again, following the right-hand rule. For rotating "clockwise"
>> we use the prime notation: Ux’ would undo Ux. Note that this still follows
>> the right-hand rule; Ux’ is a counterclockwise rotation around the negative
>> half-axis x’ (pointing left). To do 180-degree rotations we can append
>> numbers. For example, Ux2 is simply Ux Ux. Mathematically, (Ux)^2 would be
>> more correct but is often less convenient and hence I, more often than not,
>> don’t use exponent notation. Another example of a possible move from
>> rep(UD), using 180-degree twists, is Rx2 and for the physical cube, this
>> can’t easily be broken down to Rx Rx although they are equal (the physical
>> cube rep(UD) lacks the Rx move).
>> We also need to be able to describe rotations in 3D-space and I use O
>> (capital o) for this. This follows the same rules as other moves so, for
>> example, Oy = Uy Dy (from rep(UD)) is a rotation of the whole cube around
>> the positive y-axis. Stacking moves (reordering two halves or 1/4 and 3/4
>> parts of the puzzle) is also very useful (and many correspond to puzzle
>> rotations that do not change the state of the puzzle) and I use S to denote
>> these. Stacking moves are not (3D) rotations so the notation might need an
>> explanation. From rep(UD) Sy would take the top cap and put it on the
>> bottom, Sy2 would take the upper half (the U face) and put it underneath
>> the D face, Sx would take the right half and put it to the left and Sx2
>> would do nothing. So, from picture 1 Sy would take you to picture 2. I’ll
>> discuss these moves more thoroughly later.
>> *Extensions facilitating twists corresponding to corner- and
>> edge-clicking in MC4D*
>> Often, we want to do twists corresponding to corner- and edge-clicking in
>> MC4D’s 3^4 cube. To facilitate the use of these moves I thought it
>> necessary to extend the notation a bit (although the previous notation is
>> complete). We can use Uxy to rotate the U face in such a way that a
>> face-fix coordinate system swaps x <-> y, corresponding to clicking on the
>> xy-edge (the top right edge) in MC4D. So, Uyz’ flips the top 2x2x2 cube
>> around the top-back edge. As a convention, I prefer to always right in
>> alphabetical order.
>> Twists corresponding to corner-clicking can be achieved similarly. We can
>> use Uxyz for the positive rotation around the xyz corner, corresponding to
>> clicking on the xyz-corner (the right top front). The inverse of Uxyz would
>> be Ux’y’z’ or U(xyz)’ (the latter might be easier to read). If we allow
>> ourselfs to rewrite Ux’y’z’ to U(xyz)’ the three lower case letters can be
>> thought of as specifying which corner to rotate around and the ‘ (prime) to
>> specify the direction of the rotation (non-primed rotations always being
>> positive/counterclockwise) (note that Ux’yz would correspond to
>> left-clicking at the x’yz corner in MC4D and U(x’yz)’ would correspond to a
>> right-click on the same corner or a left click on Uxy’z’). The convention
>> with alphabetical order still applies.
>> *Notation for MC4D*
>> This notation turns out to work flawlessly with the virtual cubes in MC4D
>> as well. There’s only a couple of things that I think should be mentioned
>> and then you can use the same notation for the virtual 2^4, 3^4, 4^4 and so
>> on. The S moves are a bit special for the physical cube so for the virtual
>> ones let Sx be a ctrl-click on the face that lies in the x-direction (R)
>> and similarly for other S moves. Also, to enable deep twists, let U2x be
>> the twist similar to Ux but with the layer beneath the surface (I believe
>> this is achieved by holding down the "2" key in MC4D although that is,
>> oddly, currently only working for right-clicks for me). We can use the same
>> principle for bigger cubes and on a 9^4 you can have Ux, U2x, …, U9x.
>> Note that, just as in MC4D, not using this number sets it to 1 per default
>> (so Ux = U1x).
>> *Generalizing the notation to higher-dimensional and bigger cubes*
>> The notation can be generalized to higher-dimensional cubes. First of
>> all, more face and axis names would be necessary (one option to not run out
>> of these as quick would be to use X for the face in the x-direction (R) and
>> X’ for the face in the x’-direction (L) although I believe that it might be
>> harder to read). Furthermore, rotations in higher dimensions don’t work the
>> same way; objects are not rotated around an axis but a plane or hyperplane.
>> However, no matter the dimension there is always a plane of rotation, a
>> plane in which the points describes circles (this is related to linear
>> algebra, eigenvectors more specifically, and the definition of a rotation).
>> So, we could specify this plane instead of the axis to rotate around. Uy
>> would become Uxz’, Uz’x’, Ux’z or Uzx (taking x -> z’ -> x’ -> z -> x). For
>> the sake of uniqueness we might not want to use primes in this notation and
>> then Uy would become Uzx and Uy’ would become Uxz. Since we now need two
>> lowercase letters to describe a rotation the extension of my notation (with
>> flips and rotations corresponding to edge- and corner-clicks in MC4D) would
>> not be applicable.
>> *Miscellaneous*
>> Regarding folding moves for the physical 2^4: My previous notation
>> included folding moves. I do not include those here since I don’t use them.
>> The reason for not using them is simple: they are not legal elementary
>> twists of a 2^4 (in the sense that they don’t correspond to simply rotating
>> a single face or the whole puzzle) and they are not needed to solve the
>> puzzle. I’m fine with using folding moves to change between different
>> representations with the same state but, as I will demonstrate in an
>> upcoming post, they are not necessary to do this either.
>> Legal moves: There are a few restrictions when using the notation to only
>> get elementary moves (i.e no shortcuts). From rep(UD) (similarly for other
>> representations) these are:
>> - R and L: only Rx2 and Lx2 allowed (could thus simply use R and L
>> without the x2 but I stick with Rx2 and Lx2)
>> - F and B: only Fz2 and Bz2 allowed
>> - C and E: only multiples of Cy and Ey allowed (Cy, Cy’, Cy2, Ey,
>> Ey’ and Ey2)
>> - S: only multiples of Sy (Sy, Sy’ and Sy2)
>> Regarding S moves: The non-elementary S moves are needed to get all
>> states (without them it’s impossible to mix the inverted colours with the
>> others). I think it’s fine to use these S moves to switch between
>> representations even though they do indeed change the state of the puzzle
>> (pure puzzle rotations becomes very slow when speedsolving) although I
>> don’t think that sequences that use the side effects of S moves should be
>> used (preferably). What do you think?
>> Best regards,
>> Joel
>> 2018-01-03 7:49 GMT+01:00 Joel Karlsson <>:
>>> Great input!
>>> Melinda and Marc have convinced me. As a mathematician I strive not to
>>> be bounded by notation so even though I’m more familiar with z-up I’ll go
>>> with x-right, y-up, z-toward yourself. Of course, everyone is free to use
>>> their personal preference personally but when communicating it’s great to
>>> have a convention.
>>> Best regards,
>>> Joel
>>> PS. Notation and more details on my solution upcoming shortly.
>>> Den 3 jan. 2018 12:53 fm skrev "Melinda Green
>>> [4D_Cubing]" <>:
>>>> I must agree with Marc. I didn’t know about the speed solving
>>>> community’s convention, and that’s probably the strongest argument. Coming
>>>> from computer graphics, this has been a perennial discussion. Programmers,
>>>> mathematicians and artist/modelling communities overlap in interests and
>>>> coordinate preferences like a Venn diagram depending upon whether you
>>>> prefer to think in terms of screen space or world space. There’s general
>>>> agreement to begin with +X being to the right. Everything else can cause
>>>> tension, but the one compromise that everyone seems to be able to live with
>>>> is making sure that +Y is always up. (Some world-space people prefer +Z up
>>>> while some graphics people prefer +Y as down.) The phrase "Y is up" has
>>>> therefore become a kind of touchstone. Given that, positive Z can then be
>>>> chosen to produce one’s desired handedness. I have no preference on
>>>> handedness, but since you prefer right-handed, that means +Z should be
>>>> toward yourself.
>>>> -Melinda
>>>> On 1/2/2018 8:46 AM, Joel Karlsson
>>>> [4D_Cubing] wrote:
>>>> > Hello,
>>>> >
>>>> > I’m planning to post a more detailed solution of the physical 2^4 but
>>>> > to do so I need some notation. I understand that my previous post on
>>>> > notation was too long and too complicated. Luckily, I have since
>>>> > realised that a simpler notation is sufficient but before I introduce
>>>> > it I need some input from you. What coordinate system do you prefer?
>>>> >
>>>> > It would be great if we could decide on one coordinate system and then
>>>> > use that as a convention. Personally, I think that the coordinate
>>>> > system should be right-handed but besides that, I can use pretty much
>>>> > any. Two great alternatives are (for the positive half axes):
>>>> > x-right, y-away from yourself, z-up
>>>> > x-right, y-up, z-toward yourself
>>>> >
>>>> > What do you think?
>>>> >
>>>> > Best regards,
>>>> > Joel