Message #4101

From: Andrew Farkas <ajfarkas12@gmail.com>
Subject: Re: [MC4D] 2x2x2x2: List of useful algorithms (please add yours)
Date: Thu, 02 Aug 2018 01:14:42 -0400

Oh goodness.

You’ve brought up a lot of things to unravel here! I’ll go in order.

But referring to them as "clockwise" and "counterclockwise" relative to I/O
> didn’t help me. Aren’t we going to need to be able to recognize 3 distinct
> cases? I know I needed 3 cases for my sequences for "RUFI by x2/y2/z2
> while keeping the rest of In/Out fully solved".


I think this is a result of a difference in our solving approaches. I find
it easier (and faster) to first consolidate all stickers of the first color
pair in any position except the frame, and only then form faces from them.
Thus by the time I’m encountering the apparent corner twist parity I don’t
need to worry about the *z2* rotation since the *I*/*O* sticker shouldn’t
be on the frame anyway.

Instead of performing a net 180 degree flip on the piece, you give it a net
> 120 degree twist on a different axis, while exchanging some twists with
> other pieces. So, for instance, applying either sequence 2 times to the
> solved state does not lead to an aligned state like mine does. This
> baffled me for a few minutes there. It takes applying it 3 times.


Again taking a speedsolver’s approach here, I focused solely on achieving
the desired effect at the given stage, without regard for the true nature
of the algorithm. I lazily called them "double twist parity algorithms"
simply because they solved an issue which others have called "double twist
parity." I appreciate your analysis of what these algorithms actually
accomplish, though I think I need some more hands-on testing of my own to
fully grasp what you’re saying.

I’ll call your two algs TTA and TTB (for Triple Twist A and B).


Sounds great, if not a bit arbitrary. Generally when mirror cases of an
algorithm are followed by "a" or "b," no one remembers which is which (e.g.
A, G, J, N, R, and U PLL algorithms
<https://www.speedsolving.com/wiki/index.php/PLL>), so if there’s a better
way to distinguish the two, I’d be more satisfied. That said, the only
solution I have (CW/CCW) is based on a very limited view of their effect.

….
> and note the colors of the piece that sits at RUFO (Red R, White U, Green
> F, Pink O).


Interesting that we both chose this as the "default" orientation. I suppose
the red/white/green stems from the standard WCA scramble orientation, and
pink just falls into place (unless one of our puzzles were rotated through
a real fourth dimension!). Even pentaquark394’s scrambler (and thus my own)
use red/orange on the frame with white on the "top" (really *O*) and green
in front, making it easy to reach from the WCA-inspired horizontal
orientation.. (And the unfolded view is equivalent to removing the top half
from our standard horizontal orientation and placing it to the left of the
bottom half with a *z2*.) Anyway, back to the cube theory!

There are two choices of CW and CCW in this alg, in step 1 and step 2, and
> I think we’ll find that we need to use 3 of those 4 combinations in our 3
> cases. At least, that’s what ended up happening when I created my similar
> sequences. It looks like the 3rd case can be handled by applying the
> inverse of the 1st alg.


You know, as I was developing these I noticed that the *I*/*O* sticker
landed on the frame (*R*/*L* face) if I rotated *I* in the opposite
direction or applied the wrong algorithm for either case; I dismissed this
at the time as an undesired result, but in retrospect it could certainly be
useful. In my solution video, I accidentally left an *I*/*O* sticker on the
frame, and had to spend quite some time resolving it when clearly a single
short algorithm would have sufficed.

The next step is to see how these conjugates with *I[…]* can be used to
efficiently orient several pieces at once! I’m not sure whether this would
be any faster than simple 3D moves, but perhaps even some existing 3D
algorithms could take advantage of the extra dimension that the 2^4 has to
offer.

*TTA*: Twist *OFRU* counterclockwise (relative to its Front tetrahedron):
> *[ R[ U’ R’ U2 ]: Iy Ix ]**TTB*: Twist *OBRU* clockwise (relative to its
> Back tetrahedron): *[ R[ U R U2 ]: Iy’ Ix’ ]*


In my 3D mindset at this stage, I prefer to think of these as clockwise and
counterclockwise respectively around the *R* hypersticker, hence my
original naming.

Recognition: put misaligned piece on *OFRU*. If the I/O color is on the
> Front face, perform *Rx* and then *TTB*. Otherwise, the piece can be
> aligned via a twist of the Front tetrahedron. Apply *TTA* (if a
> counterclockwise twist is needed, i.e. the I/O color is on U) or *TTA’* (if
> a clockwise twist is needed, i.e. the I/O color is on the R corner).


I prefer to combine this into one, slightly more complicated step: Hold
left and right subcubes such that all oriented pieces are on the *I* and *O*
faces, and that the misaligned piece is in *ROFU* or *ROBU* with the *I*/*O*
sticker facing *U*. If the piece is in *ROFU*, apply TTA; if it is in *ROBU*,
apply TTB.

The same result is achieved either way.

Thanks for being such a fun co-conspirator.


Right back at ya. 🙃

Theorem: Every combination of three corner twists is equal to one of the
> eight possible single corner twists (clockwise and anticlockwise around any
> of the 4 colors) or the identity. Every combination of two corner twists
> is equal to one of the three monoflips or the identity. (OK, OK, this is
> still just a hypothesis until I enumerate the damn things or otherwise
> prove it more thoroughly than I have done in my head so far.)


Well, so much for sleeping tonight. 😛 I have a strong feeling that both of
those are true, but of course a proof is necessary. Enumeration is pretty
trivial at this scale – there’s probably only a dozen or so cases after
removing mirrors and the like – but of course a rational argument is much
more appealing. I’ll give it a shot.

Random idea: at the beginning of a solve, if we notice that there’s a color
> pair with exactly 1 piece on the corners, we should just probably just go
> ahead and align the other 15 pieces of that color pair, then apply one of
> these algs. Now that it’s so easy to fix this kind of misalignment,
> futzing around with additional gyros doesn’t seem worth it if we’re only 1
> piece off from having a color pair off of the corners.


Certainly! It might even be worth it for two, if we can account for double
tw– er, corner twist (?) parity along the way. I would still like to
develop a general intuitive strategy and/or algorithm set for this stage; I
think it’s the least consistent part of Fourtega and thus the one that
could use the most improvement.

Thank you very much for continued analysis and discussion! It’s fun to be
exploring new territory.

P.S. Counterexample to the first hypothesis: (execute on *ROFU*) CW around
*R *+ CW around *U* + CW around *R* results in *x2*. The second hypothesis
contradicts corner twist parity: two corner twists in the same direction
violates corner twist parity, while monoflips and the identity do not.

On Wed, Aug 1, 2018 at 9:57 PM Marc Ringuette ringuette@solarmirror.com
[4D_Cubing] <4D_Cubing@yahoogroups.com> wrote:

>
>
> Hey, Andy,
>
> I love your maybe-the-shortest-possible monoflip aligners. But referring
> to them as "clockwise" and "counterclockwise" relative to I/O didn’t help
> me. Aren’t we going to need to be able to recognize 3 distinct cases? I
> know I needed 3 cases for my sequences for "RUFI by x2/y2/z2 while keeping
> the rest of In/Out fully solved".
>
> Your algs are a bit more confusing for me to think about than mine were,
> because they do three distinct corner twists on the misaligned piece,
> whereas mine do two. Instead of performing a net 180 degree flip on the
> piece, you give it a net 120 degree twist on a different axis, while
> exchanging some twists with other pieces. So, for instance, applying
> either sequence 2 times to the solved state does not lead to an aligned
> state like mine does. This baffled me for a few minutes there. It takes
> applying it 3 times.
>
> I’ll call your two algs TTA and TTB (for Triple Twist A and B).
>
> In tracing through your first alg, TTA, I found it useful to start from my
> standard solved state and note the colors of the piece that sits at RUFO
> (Red R, White U, Green F, Pink O).
>
> Step 1. R [ U’ R’ U2 ] – twists RUFO CCW around the Right center
> (the red corner of the piece) and then places the piece on RUBI with R[ U2 ]
> Step 2. Iy Ix – twists RUBI CW around the In center
> (the anti-green corner of the piece) and does not permute it
> Step 3. R [ U2 R U ] – places the RUBI piece on RUFO with R [ U2
> ] and then twists it CW around the Right center (the pink corner of the
> piece)
>
> There are two choices of CW and CCW in this alg, in step 1 and step 2, and
> I think we’ll find that we need to use 3 of those 4 combinations in our 3
> cases. At least, that’s what ended up happening when I created my similar
> sequences. It looks like the 3rd case can be handled by applying the
> inverse of the 1st alg..
>
> Note that in TTA three different colors on the piece get twists applied
> (Red CCW, Green CCW, Pink CW). The net result is Green CCW (!), the color
> that was originally Front and still remains Front.
>
> Tracing similarly, TTB twists the Back tetrahedron of OBRU (Blue in this
> case) CW.
>
> So I guess here’s how I’d have described your algs and the recognition:
>
> * TTA*: Twist *OFRU* counterclockwise (relative to its Front
> tetrahedron): *[ R[ U’ R’ U2 ]: Iy Ix ]*
> *TTB*: Twist *OBRU* clockwise (relative to its Back tetrahedron): *[ R[
> U R U2 ]: Iy’ Ix’ ]*
>
> Recognition: put misaligned piece on *OFRU*. If the I/O color is on
> the Front face, perform *Rx* and then *TTB*. Otherwise, the piece can be
> aligned via a twist of the Front tetrahedron. Apply *TTA* (if a
> counterclockwise twist is needed, i.e. the I/O color is on U) or *TTA’*
> (if a clockwise twist is needed, i.e. the I/O color is on the R
> corner).
>
> What do you think?
>
> (The three cases above could also be recognized as the ones where a y2
> flip, z2 flip, and x2 flip are needed, respectively; although we do not
> actually perform that flip, so it would seem a bit odd to do recognition by
> figuring out what 180 degree flip we "could" use, and then not using it.
> I might do it that way anyway.)
>
>
>
> I absolutely love this part of the puzzle-figuring-out process, because
> I’m starting to get the hang of the 12 orientations, and how they divide up
> into 4’s and 3’s, and how corner twists can combine into monoflips, etc.
> Your triple twister algorithms are reminding me that I don’t fully grok it
> yet, but I feel like I’m making good progress. Thanks for being such a fun
> co-conspirator.
>
>
> Theorem: Every combination of three corner twists is equal to one of the
> eight possible single corner twists (clockwise and anticlockwise around any
> of the 4 colors) or the identity. Every combination of two corner twists
> is equal to one of the three monoflips or the identity. (OK, OK, this is
> still just a hypothesis until I enumerate the damn things or otherwise
> prove it more thoroughly than I have done in my head so far.)
>
>
> Random idea: at the beginning of a solve, if we notice that there’s a
> color pair with exactly 1 piece on the corners, we should just probably
> just go ahead and align the other 15 pieces of that color pair, then apply
> one of these algs. Now that it’s so easy to fix this kind of misalignment,
> futzing around with additional gyros doesn’t seem worth it if we’re only 1
> piece off from having a color pair off of the corners.
>
>
> Cheers
> Marc
>
>
> On 7/31/2018 9:59 PM, Andy F legomany3448@gmail.com [4D_Cubing] wrote:
>
> I’ll include my "double twist" algorithms here. The rest are trivial or
> simply 4D use of 3D methods. These algorithms preserve I/O orientation for
> the other seven pieces, but do not preserve orientation on other axes or
> permutation at all.
>
> Twist *OFRU* clockwise (relative to I/O): *[ R[ U’ R’ U2 ]: Iy Ix ]*
> Twist *OBRU* counterclockwise (relative to I/O): *[ R[ U R U2 ]: Iy’ Ix’
> ]*
>
> The *Iy Ix* and *Iy’ Ix’* moves can be executed by moving the right and
> left endcaps around the inner face, as can be seen in my solution video
> <https://youtu.be/Fd9NUaO5AYo?t=5m58s>.
>
>
> On 7/28/2018 2:46 PM, Marc Ringuette ringuette@solarmirror.com
> [4D_Cubing] wrote:
>
> Monoflip, solving In+Out faces only: (12 moves physical using ROIL
> Zero, 3 cases)
> RUFI by x2: Rzy I [ U F U’ F U F2 U’ ] Iy Lx2 Iy’ Rz’
> RUFI by y2: Ry’z’ I [ U F U’ F U F2 U’ ] Iy Lx2 Iy’ Ry
> RUFI by z2: Rzy Iy Lx2 Iy’ I [ U F2 U’ F’ U F’ U’ ] Rz’
> (those are sideways Sune, Sune, and Antisune, inside the brackets)
>
>
>


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