Message #4133

From: Melinda Green <melinda@superliminal.com>
Subject: Re: [MC4D] Notation and turn metrics for the 2x2x2x2
Date: Fri, 14 Sep 2018 19:14:06 -0700

This all sounds great to me. Comments in-line.

On 9/13/2018 2:19 PM, Andrew Farkas ajfarkas12@gmail.com [4D_Cubing] wrote:
>
> Hey everyone!
>
> I’ve been working on the random-state scrambler/solver and discussing things with Marc over the past few days, and I’ve come up with some things that I think are worth sharing.
>
> Notation
> I’ve yet to see a proper compendium of notation for the 2^4, so here’s my proposal for moves in the horizontal orientation:
>
> * A face *R*, *L*, *I*, or *O*, followed by one of the following:
> o Any letter *r*, *l*, *u*, *d*, *f*, *b*, *x*, *y*, *z* (plus an optional *‘* or *2*).
>

I get the x,y,z moves but what do the r,l,u,d,f,b moves mean? For instance I get *Rz *but not *Ru*.

> o A pair of square brackets containing any sequence of 3D moves <https://www.speedsolving.com/wiki/index.php/Notation> that are valid on a 2x2x2.
> + Most of the time, of course, these moves should be 0-mod-4.
> * The moves *U2*, *D2*, *F2*, and *B2*.
> * The full puzzle rotations *x*, *x’*, *x2*, *y2*, and *z2*.
> * The stacking moves *M*, *M’*, *M2*, *E*, and *S*.
> o *M* moves the right endcap over to the left of the puzzle; *M’* does the opposite, and *M2* swaps the left and right halves of the puzzle.
> o *E* swaps the top and bottom halves of the puzzle.
> o *S* swaps the front and back halves of the puzzle.
>

Sounds fine though where did the names *M*, *E*, and *S *come from? I probably just missed it, but I need mnemonics for them. Or maybe something a little more self-descriptive might help, like *Sd *where *S *means "Stack" and ‘d’ is the direction *x, y, *or *z*. Or following your ‘*clam*’ suggestion, they could be *x stack*, *y’ stack*, etc.

> * *z clam* and *z’ clam*.
> o *z clam* is a *z* rotation followed by a clamshell move.
> o *z’ clam* is a *z’* rotation followed by a clamshell move.
> o *z clam* and *z’ clam* are inverses.
>
> * Parentheses can be used for grouping, and numbers can follow parentheses to repeat a sequence.
> * Commutator notation <https://www.speedsolving.com/wiki/index.php/Commutators_and_Conjugates> is allowed when useful.
>
> The use of lowercase letters in moves like *Rr* may be controversial; if they are deemed confusing, *R[R]* could be encouraged instead.
>
> Here’s an equivalent of Melinda’s original gyro sequence in this notation:
> *M E z’ clam (x z’ clam)2 *
>

It’s nice that you included the clamshell move but does it belong here since we decided to not call it canonical? Maybe we could use some form of macro notation for naming sequences built from canonical moves and previously defined sequences. For instance perhaps I could define

*let clam = R2 U2 R2*

and then use *clam *and *clam’* wherever I like. Someone following my sequences would be free to use the above canonical moves or perform the clamshell move as a shortcut since the results are identical. I could then define my gyro as

*let gyro = M E clam**(x clam')2*

And of course if someone prefers a different gyro move they can just use that since again the results are identical. Or is this all just overkill?

> I’ll briefly digress to discuss a WCA-inspired <https://www.worldcubeassociation.org/regulations/#4d1> "standard orientation" that Marc and I have been using. WCA regulations state that white face should be on top (Y axis) and the green face should be on the front (Z axis). On a standard NxNxN, this will result in the red face on the right (X axis). […]
>

Makes sense.

>
> Metric
> As for counting numbers of moves, I’d like to propose the "snap" metric. Each separation and reattachment of pieces is a single move.. This can be very dependent on how a move is executed, but I think it makes the most sense for the purpose of solving and speedsolving.
>
> A single move like *Iy* could be executed in three snaps as *M Ry M’* or in just two snaps by rearranging the right and left endcaps around the *I* layer. A sequence like *x’ Rz Lz’ M2* may seem like a lot of moves, but it can be executed in one snap. (The *x’* is actually zero snaps, regardless of context.) The sequence *z’ clam* is two snaps, while the equivalent *Rx2 U2 (R[x2 y’] Ly)* is three snaps. *Ix* can be executed as three snaps with *M Rx M’*, two snaps with *Rr Ll’ x’*, or one snap by holding the endcaps with one hand and rotating the *I* layer with the other. (In an actual solve, the two-snap method is probably fastest.) While *Rr* is pretty clearly one snap, *Ru* could be executed in two snaps (by separating the left and right halves, performing *Ru*, and then reattaching them) or one snap (by removing the four pieces of *Ru* directly, rotating them, and replacing them).

I like the snap metric a lot for quantifying the amount of work or physical complexity of some sequence. I don’t know if it makes sense to use for fewest-moves contests for example, but it could be very helpful for comparing and streamlining algorithms.

-Melinda