# Message #4139

From: Andrew Farkas <ajfarkas12@gmail.com>

Subject: Re: [MC4D] Notation and turn metrics for the 2x2x2x2

Date: Sat, 15 Sep 2018 20:12:18 -0400

I tried to include every move I’ve heard of, whether or not it is

considered canonical, since they may be useful in scrambling or describing

gyro sequences. *Ru* and similar are equivalent to their bracketed forms;

e.g. *R[U]*. (These are ROIL-style 3D moves) *M*, *E*, and *S* are the

letters used for slice moves

<https://www.speedsolving.com/wiki/index.php/3x3x3_notation#Slice_Turns> on

(n>2)^3 puzzles, which I noticed Marc had used to describe stacking moves

on the twisty-stacky 2^3.

I entirely agree that the snap metric should not be used for any

fewest-moves competition, since it’s rather subjective (as I pointed out);

I only intend for it to be used in the context of quantifying the

difficulty of an algorithm.

Speaking of canonical moves, is there a consensus on those 3D moves (other

than the 0-mod-4 restriction)? Fourtega as it exists right now (which I’d

like to call "Parallel Fourtega," since there may be a 4D Ortega variant in

the future that does not solve the two halves in parallel/separately 😉) is

highly dependent on them, but there could surely be other methods that

solve the puzzle more holistically.

- Andy

On Sat, Sep 15, 2018 at 3:55 PM ‘Eduard Baumann’ ed.baumann@bluewin.ch

[4D_Cubing] <4D_Cubing@yahoogroups.com> wrote:

>

>

>

> More pictures for the notation for 2x2x2x2

>

>

>

>

>

>

>

>

>

>

> Best regards

> Ed

>

>

> —– Original Message —–

> *From:* Melinda Green melinda@superliminal.com [4D_Cubing]

> <melinda@superliminal.com+[4D_Cubing]>

> *To:* 4D_Cubing@yahoogroups.com

> *Sent:* Saturday, September 15, 2018 4:14 AM

> *Subject:* Re: [MC4D] Notation and turn metrics for the 2x2x2x2

>

>

>

> 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:

> - 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*.

>

>

> - 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*.

> - *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.

> - *E* swaps the top and bottom halves of the puzzle.

> - *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*.

> - *z clam* is a *z* rotation followed by a clamshell move.

> - *z’ clam* is a *z’* rotation followed by a clamshell move.

> - *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

>

>

>

"Machines take me by surprise with great frequency." - Alan Turing