Message #4140

From: Melinda Green <melinda@superliminal.com>
Subject: Re: [MC4D] Notation and turn metrics for the 2x2x2x2
Date: Sat, 15 Sep 2018 17:29:17 -0700

Regarding 0 mod 4, I would only say that any sequence of 2^3 twists on one half of the puzzle should be accounted for on the other half. That can be done with every twist using the axial move, or by keeping track of the mod 4 count and applying the reverse of any remainder at the end of the sequence. 0 mod 4 sequences are therefore nice because you don’t need to keep track, but other sequences are fine too, just more work.

-Melinda

On 9/15/2018 5:12 PM, Andrew Farkas ajfarkas12@gmail.com [4D_Cubing] wrote:
>
>
> 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 <mailto:ed.baumann@bluewin.ch> [4D_Cubing] <4D_Cubing@yahoogroups.com <mailto: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] <mailto:melinda@superliminal.com+[4D_Cubing]>
> *To:* 4D_Cubing@yahoogroups.com <mailto: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 <mailto: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
>