Message #4099

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

P.P.S.

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

This is incorrect; an *Rz Lz’* is required before the *z2*.

On Thu, Aug 2, 2018 at 1:17 AM Andrew Farkas <ajfarkas12@gmail.com> wrote:

> Gah, I mistyped
>
> 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.
>
>
> That should read *x2*, not *z2*.
>
> On Thu, Aug 2, 2018 at 1:14 AM Andrew Farkas <ajfarkas12@gmail.com> wrote:
>
>> 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.
>>
>> - Andy
>>
>> 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
>>
>
>
> –
>
> "Machines take me by surprise with great frequency." - Alan Turing
>

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