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