Thread: "2x2x2x2: List of useful algorithms (please add yours)"

Let's start compiling a list of useful 2x2x2x2 algorithms, both physical
and virtual.   Feel free to provide them either written out, or on
video, or as MC4D macros, and in whatever move set you like.

I suggest that we put a fairly strong emphasis on fewest-moves as a
primary criterion for a good algorithm.

Does anybody have a collection of move-efficient algorithms for the
virtual 2^4 or 3^4 ?

My focus is on generally useful algorithms like 3-cycles.   However,
toward the bottom I have put some important "translation" algorithms for
copying virtual moves on the physical puzzle and vice versa.

More, please!!

Cheers
Marc


=============

2x2x2x2 algorithm list v1.00:


3-cycle:  https://www.youtube.com/watch?v=S8hm3CupPJA   (16 moves canonical)
       in Marc's virtual+physical notation:   LF'  (FO2 LO' FO2 LO FO2)
LF  OR2 LF'  (FO2 LO' FO2 LO FO2) LF  OR2
       in ROIL xyz notation:   Lz'  (Fz2 Lx Fz2 Lx' Fz2) Lz  Ox2   Lz' 
(Fz2 Lx Fz2 Lx' Fz2) Lz  Ox2

Two 2-cycles:  (34 moves canonical, by commuting the above 3-cycle with
Ry -- but I'm sure we can do far better)

Two opposite twists:   https://youtu.be/k6ZSu0xOPbQ?t=1m50s  (14 moves
physical using ROIL Zero)
       in ROIL Zero notation:  R [ R U R' U R U2 R'    B U2 B' U' B U' B' ]
       Translated to 28 moves canonical:  Ox Rz Ox Rz' Ox' Rz Ox Rz' Ox
Rz Ox2 Rz' Ox'     Ry    Ox Rz Ox2 Rz' Ox' Rz Ox' Rz' Ox Rz Ox' Rz'
Ox'    Ry'

Monoflip:   https://www.youtube.com/watch?v=k6ZSu0xOPbQ  (35 moves
physical using ROIL Zero, 88 moves virtual)

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)

Exchange a twist between L and R subcubes:
   from Andy F:     Iy2   R [ U' R' U' R U2 ]   Iy2   (7 moves physical
using ROIL Zero, preserves neither L nor R fully, use before first OLL)

Gyros:
    Melinda's gyro (which is a FOro to Marc):
https://www.youtube.com/watch?v=d2Fh_1m0UVY
    ROIL FOro:   Iy Oy' Rx2 Bz2 Uy2 Rx2
https://www.youtube.com/watch?v=3gvrda5fMto
    FUro using double long restack:
https://www.youtube.com/watch?v=htTTn7qY35M

Physical Iy on virtual:  https://www.youtube.com/watch?v=zaYY7T1zwE0
   Based on this from Michael Gottlieb:      Iy (physical) = IU' RO2 IF
RO2 IU RO2 IF' RO2 IU (virtual)

Virtual IU and IF on physical:
    IU (virt) ==  I [ F2 U2 R2 F B ]  (phys) (ROIL Zero, from Michael
Gottlieb)
    IF (virt)  ==  I [ U2 F2 L2 U D ]  (phys) (ROIL Zero, from Michael
Gottlieb)

[end]

I thought I'd re-read Joel Karlsson's message from 12/21/2017 discussing
the commutators that he used to solve the puzzle, and pondering it led
me to this nice short double pair swap.

2x2 cycle:   Uy2 Lx' Uy2 Lx Uy2 Rxy2   Uy2 Lx' Uy2 Lx Uy2 Rxy2   (12
moves canonical)
  (all changes are in the UF quarter of the puzzle, LUFO <--> LUFI, 
RUFO <--> RUFI)

And a related 3-cycle,

3-cycle:  Uy2 Rx' Uy2 Rx'y2 Uy2 Rx Uy2   Ly   Uy2 Rx' Uy2 Rx'y2 Uy2 Rx
Uy2  Ly'   (16 moves canonical)
 (all changes are in the LU quarter of the puzzle, LUFO --> LUBI --> LUBO)

Both of these act on a restricted 1/4 of the puzzle, in contrast to the
3-cycle I gave in yesterday's list, where the pieces involved are widely
distributed around the puzzle, so that there is no half of the puzzle
that does not contain a moved piece.

3-cycle:  Lz'  Fz2 Lx Fz2 Lx' Fz2 Lz  Ox2   Lz'  Fz2 Lx Fz2 Lx' Fz2 Lz 
Ox2  (16 moves canonical)
  (moves LUFI --> RUFO --> RDBO)

Hmm, I wonder if there might be a sensible classification scheme for
cycles and swaps based on the number of dimensions that are twisted, the
number of half-puzzles that are unchanged, and the fraction of the
orientations that can be accessed.   At this point I have no idea.  As I
try to develop an efficient 3-cycle-based solution scheme, maybe it'll
come to me.


On 12/21/2017 2:05 PM, Joel Karlsson joelkarlsson97@gmail.com
[4D_Cubing] wrote:
> The commutators I use are based on one simple idea. Isolate one or two
> pieces (depending on what you want to accomplish) from the bottom half
> on the top half (holding the cube upright), then rotate the top face
> (to accomplish a swap or rotation for example), reverse the first
> step, rotate the bottom face and lastly perform the first three steps
> in reverse. The first step can quite easily be done with 7 and 3 moves
> respectively, resulting in sequences from 7 to 32 moves (sometimes the
> first three steps are enough, depending on how much you want to
> preserve).

--0000000000003c40ba05723f123e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm rejoining discussions after a long break. Can you point me to some post
where you introduce your notation? I can more or less figure it out, but
I'm curious to see whether you described it somewhere. I came up with my
own notation during my independent work, and it seems very similar to
yours. I haven't posted mine anywhere since I figured I'd wait and see
whether a standard notation had been agreed upon by the list first.

On Sun, Jul 29, 2018 at 3:04 PM Marc Ringuette ringuette@solarmirror.com
[4D_Cubing] <4D_Cubing@yahoogroups.com> wrote:

>
>
> I thought I'd re-read Joel Karlsson's message from 12/21/2017 discussing
> the commutators that he used to solve the puzzle, and pondering it led
> me to this nice short double pair swap.
>
> 2x2 cycle: Uy2 Lx' Uy2 Lx Uy2 Rxy2 Uy2 Lx' Uy2 Lx Uy2 Rxy2 (12
> moves canonical)
> (all changes are in the UF quarter of the puzzle, LUFO <--> LUFI,
> RUFO <--> RUFI)
>
> And a related 3-cycle,
>
> 3-cycle: Uy2 Rx' Uy2 Rx'y2 Uy2 Rx Uy2 Ly Uy2 Rx' Uy2 Rx'y2 Uy2 Rx
> Uy2 Ly' (16 moves canonical)
> (all changes are in the LU quarter of the puzzle, LUFO --> LUBI --> LUBO=
)
>
> Both of these act on a restricted 1/4 of the puzzle, in contrast to the
> 3-cycle I gave in yesterday's list, where the pieces involved are widely
> distributed around the puzzle, so that there is no half of the puzzle
> that does not contain a moved piece.
>
> 3-cycle: Lz' Fz2 Lx Fz2 Lx' Fz2 Lz Ox2 Lz' Fz2 Lx Fz2 Lx' Fz2 Lz
> Ox2 (16 moves canonical)
> (moves LUFI --> RUFO --> RDBO)
>
> Hmm, I wonder if there might be a sensible classification scheme for
> cycles and swaps based on the number of dimensions that are twisted, the
> number of half-puzzles that are unchanged, and the fraction of the
> orientations that can be accessed. At this point I have no idea.. As I
> try to develop an efficient 3-cycle-based solution scheme, maybe it'll
> come to me.
>
> On 12/21/2017 2:05 PM, Joel Karlsson joelkarlsson97@gmail.com
> [4D_Cubing] wrote:
> > The commutators I use are based on one simple idea. Isolate one or two
> > pieces (depending on what you want to accomplish) from the bottom half
> > on the top half (holding the cube upright), then rotate the top face
> > (to accomplish a swap or rotation for example), reverse the first
> > step, rotate the bottom face and lastly perform the first three steps
> > in reverse. The first step can quite easily be done with 7 and 3 moves
> > respectively, resulting in sequences from 7 to 32 moves (sometimes the
> > first three steps are enough, depending on how much you want to
> > preserve).
>=20
>

--0000000000003c40ba05723f123e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

--------------6A4E0187878965915F50C974
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jay!

I enjoyed your explanation of your gyro rotation by rolling the pieces
around.
Clearly we think along similar lines; I bet you'll like my sticker-based
physical 2^4 demo.
https://youtu.be/a90NLdJQQSw

For my most recent video, you can check out my own Monoflip, that I
recorded in a spiffy video side-by-side with its clone in MC4D.
https://youtu.be/k6ZSu0xOPbQ

Those two videos, by the way, appear in my "old" and my "new" Youtube
channels, respectively.  I recently started keeping puzzle videos in a
different place than my personal ones.   I should make a playlist or two
ASAP, but meanwhile they can be dug out of my channels, or the links
found in my archived messages.


For notation,  I'll cut and paste this from Michael Gottlieb:

Here's the notation I'll use for 2^4 moves. I call the eight faces I
(in), O (out), and the standard six 3D face names F, R, U, B, L, D. When
discussing the virtual 2^4 cube, I'll label moves as something like
"FR", which means rotating the F(ront) face 90 degrees through an axis
centered at the R(ight) face, clockwise as if you were looking from the
R face. For physical 2^4 turns, I'll instead use a face name followed by
x, y, or z, which follow the speedcubing notation, of rotating the cube
90 degrees clockwise relative to the right, top, or front face
respectively. So "Ry" means rotating the R(ight) cube clockwise relative
to the top of it. A move followed by 2 (e.g. FR2) means doing it twice,
and followed by ' (e.g. FR') means doing it counterclockwise instead of
clockwise.

He's describing exactly what I have been doing, but I have only
explained it in my videos, not in text.

There has been hardly anything written down -- my attempt at an
algorithm collection this week was the first such attempt -- and pretty
much everybody has been just winging it, notation wise.  So, feel free
to just forge blithely ahead and use whatever makes sense to you.

Cheers
Marc


On 7/30/2018 3:34 PM, Jay Berkenbilt ejb@ql.org [4D_Cubing] wrote:
> I'm rejoining discussions after a long break. Can you point me to some
> post where you introduce your notation? I can more or less figure it
> out, but I'm curious to see whether you described it somewhere. I came
> up with my own notation during my independent work, and it seems very
> similar to yours. I haven't posted mine anywhere since I figured I'd
> wait and see whether a standard notation had been agreed upon by the
> list first.
>


--------------6A4E0187878965915F50C974
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit






Hi Jay! 



I enjoyed your explanation of your gyro rotation by rolling the
pieces around.

Clearly we think along similar lines; I bet you'll like my
sticker-based physical 2^4 demo.

https://youtu.be/a90NLdJQQSw



For my most recent video, you can check out my own Monoflip, that I
recorded in a spiffy video side-by-side with its clone in MC4D.

https://youtu.be/k6ZSu0xOPbQ



Those two videos, by the way, appear in my "old" and my "new"
Youtube channels, respectively.  I recently started keeping puzzle
videos in a different place than my personal ones.   I should make a
playlist or two ASAP, but meanwhile they can be dug out of my
channels, or the links found in my archived messages.





For notation,  I'll cut and paste this from Michael Gottlieb:



Here's the notation I'll use for 2^4
moves. I call the eight faces I (in), O (out), and the standard
six 3D face names F, R, U, B, L, D. When discussing the virtual
2^4 cube, I'll label moves as something like "FR", which means
rotating the F(ront) face 90 degrees through an axis centered at
the R(ight) face, clockwise as if you were looking from the R
face. For physical 2^4 turns, I'll instead use a face name
followed by x, y, or z, which follow the speedcubing notation, of
rotating the cube 90 degrees clockwise relative to the right, top,
or front face respectively. So "Ry" means rotating the R(ight)
cube clockwise relative to the top of it. A move followed by 2
(e.g. FR2) means doing it twice, and followed by ' (e.g. FR')
means doing it counterclockwise instead of clockwise.



He's describing exactly what I have been doing, but I have only
explained it in my videos, not in text. 



There has been hardly anything written down -- my attempt at an
algorithm collection this week was the first such attempt -- and
pretty much everybody has been just winging it, notation wise.  So,
feel free to just forge blithely ahead and use whatever makes sense
to you.



Cheers

Marc





On 7/30/2018 3:34 PM, Jay Berkenbilt ejb@ql.org [4D_Cubing] wrote:

cite="mid:CAHpo+v7S2m=6FJE18UMDUyy0s0kTrG3YkJcwT3sSHm2dYjWm4A@mail.gmail.com">

 

I'm rejoining discussions after a long break.
Can you point me to some post where you introduce your
notation? I can more or less figure it out, but I'm
curious to see whether you described it somewhere. I came
up with my own notation during my independent work, and it
seems very similar to yours. I haven't posted mine
anywhere since I figured I'd wait and see whether a
standard notation had been agreed upon by the list first.

--000000000000e736140572427d5e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Great, thanks for that explanation. I never learned or used any Rubik's
cube notation. I was 11 or 12 when the cube first came out. I first solved
it from what I think was the first solution book, called "You can do the
cube," but shortly thereafter, I developed my own solution method, which I
have applied successfully to every slider puzzle I've ever gotten my hands
on. Of course this was all pre-Internet, so I just lived in my own little
world. It didn't even occur to me to look at standard x^3 or speed cubing
notation. I guess "U" and "D" must be up and down. That's good -- I had
used L, R, I, and O for left, right, inner, and outer, and then I had used
"F" for front, "T" for top, "K" for back, and "M" for bottom to avoid the
ambiguous "B" (bottom/back). I didn't think of up/down. My notation also
involved rotating a given face clockwise about a given axis. I guess it's
the obvious way to do it if you've ever studied any branch of math that
uses 3D coordinate systems.

I'm planning on watching all the videos you recently posted along with
other people's algorithm and solution videos. I'm eager to compare notes. I
didn't put much energy into making my algorithms efficient, but I noticed
when re-viewing my own video that some of my sequences have possibly
useful/exploitable intermediate states. I tend to do setup moves that may
be partially canceled by the actual moves.

I'm looking forward to seeing your videos. I'll reply to the thread in
which you originally posted them.

--Jay

On Mon, Jul 30, 2018 at 8:16 PM Marc Ringuette ringuette@solarmirror.com
[4D_Cubing] <4D_Cubing@yahoogroups.com> wrote:

>
>
> Hi Jay!
>
> I enjoyed your explanation of your gyro rotation by rolling the pieces
> around.
> Clearly we think along similar lines; I bet you'll like my sticker-based
> physical 2^4 demo.
> https://youtu.be/a90NLdJQQSw
>
> For my most recent video, you can check out my own Monoflip, that I
> recorded in a spiffy video side-by-side with its clone in MC4D.
> https://youtu.be/k6ZSu0xOPbQ
>
> Those two videos, by the way, appear in my "old" and my "new" Youtube
> channels, respectively. I recently started keeping puzzle videos in a
> different place than my personal ones. I should make a playlist or two
> ASAP, but meanwhile they can be dug out of my channels, or the links foun=
d
> in my archived messages.
>
>
> For notation, I'll cut and paste this from Michael Gottlieb:
>
> Here's the notation I'll use for 2^4 moves. I call the eight faces I (in)=
,
> O (out), and the standard six 3D face names F, R, U, B, L, D. When
> discussing the virtual 2^4 cube, I'll label moves as something like "FR",
> which means rotating the F(ront) face 90 degrees through an axis centered
> at the R(ight) face, clockwise as if you were looking from the R face. Fo=
r
> physical 2^4 turns, I'll instead use a face name followed by x, y, or z,
> which follow the speedcubing notation, of rotating the cube 90 degrees
> clockwise relative to the right, top, or front face respectively. So "Ry"
> means rotating the R(ight) cube clockwise relative to the top of it. A mo=
ve
> followed by 2 (e.g. FR2) means doing it twice, and followed by ' (e.g. FR=
')
> means doing it counterclockwise instead of clockwise.
>
> He's describing exactly what I have been doing, but I have only explained
> it in my videos, not in text.
>
> There has been hardly anything written down -- my attempt at an algorithm
> collection this week was the first such attempt -- and pretty much
> everybody has been just winging it, notation wise. So, feel free to just
> forge blithely ahead and use whatever makes sense to you.
>
> Cheers
> Marc
>
>
>
>
> On 7/30/2018 3:34 PM, Jay Berkenbilt ejb@ql.org [4D_Cubing] wrote:
>
>
> I'm rejoining discussions after a long break. Can you point me to some
> post where you introduce your notation? I can more or less figure it out,
> but I'm curious to see whether you described it somewhere. I came up with
> my own notation during my independent work, and it seems very similar to
> yours. I haven't posted mine anywhere since I figured I'd wait and see
> whether a standard notation had been agreed upon by the list first.
>
>
>=20
>

--000000000000e736140572427d5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

--000000000000e5fe6f05724db747
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Here's my (still massively incomplete) set of algs for 2^4 OLC. They're
designed for the virtual puzzle, but some can be used easily on the
physical puzzle.

http://wiki.superliminal.com/wiki/2%5E4_algs

Feel free to add your own algs or cases, just try to keep to the system
already there.

~Luna

On Sat, 28 Jul 2018, 22:46 Marc Ringuette ringuette@solarmirror.com
[4D_Cubing], <4D_Cubing@yahoogroups.com> wrote:

>
>
> Let's start compiling a list of useful 2x2x2x2 algorithms, both physical
> and virtual. Feel free to provide them either written out, or on
> video, or as MC4D macros, and in whatever move set you like.
>
> I suggest that we put a fairly strong emphasis on fewest-moves as a
> primary criterion for a good algorithm.
>
> Does anybody have a collection of move-efficient algorithms for the
> virtual 2^4 or 3^4 ?
>
> My focus is on generally useful algorithms like 3-cycles. However,
> toward the bottom I have put some important "translation" algorithms for
> copying virtual moves on the physical puzzle and vice versa.
>
> More, please!!
>
> Cheers
> Marc
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 2x2x2x2 algorithm list v1.00:
>
> 3-cycle: https://www.youtube.com/watch?v=3DS8hm3CupPJA (16 moves
> canonical)
> in Marc's virtual+physical notation: LF' (FO2 LO' FO2 LO FO2)
> LF OR2 LF' (FO2 LO' FO2 LO FO2) LF OR2
> in ROIL xyz notation: Lz' (Fz2 Lx Fz2 Lx' Fz2) Lz Ox2 Lz'
> (Fz2 Lx Fz2 Lx' Fz2) Lz Ox2
>
> Two 2-cycles: (34 moves canonical, by commuting the above 3-cycle with
> Ry -- but I'm sure we can do far better)
>
> Two opposite twists: https://youtu.be/k6ZSu0xOPbQ?t=3D1m50s (14 moves
> physical using ROIL Zero)
> in ROIL Zero notation: R [ R U R' U R U2 R' B U2 B' U' B U' B'=
]
> Translated to 28 moves canonical: Ox Rz Ox Rz' Ox' Rz Ox Rz' Ox
> Rz Ox2 Rz' Ox' Ry Ox Rz Ox2 Rz' Ox' Rz Ox' Rz' Ox Rz Ox' Rz'
> Ox' Ry'
>
> Monoflip: https://www.youtube.com/watch?v=3Dk6ZSu0xOPbQ (35 moves
> physical using ROIL Zero, 88 moves virtual)
>
> 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)
>
> Exchange a twist between L and R subcubes:
> from Andy F: Iy2 R [ U' R' U' R U2 ] Iy2 (7 moves physical
> using ROIL Zero, preserves neither L nor R fully, use before first OLL)
>
> Gyros:
> Melinda's gyro (which is a FOro to Marc):
> https://www.youtube.com/watch?v=3Dd2Fh_1m0UVY
> ROIL FOro: Iy Oy' Rx2 Bz2 Uy2 Rx2
> https://www.youtube.com/watch?v=3D3gvrda5fMto
> FUro using double long restack:
> https://www.youtube.com/watch?v=3DhtTTn7qY35M
>
> Physical Iy on virtual: https://www.youtube.com/watch?v=3DzaYY7T1zwE0
> Based on this from Michael Gottlieb: Iy (physical) =3D IU' RO2 IF
> RO2 IU RO2 IF' RO2 IU (virtual)
>
> Virtual IU and IF on physical:
> IU (virt) =3D=3D I [ F2 U2 R2 F B ] (phys) (ROIL Zero, from Michael
> Gottlieb)
> IF (virt) =3D=3D I [ U2 F2 L2 U D ] (phys) (ROIL Zero, from Michae=
l
> Gottlieb)
>
> [end]
>
>=20
>

--000000000000e5fe6f05724db747
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

--------------292E916776226BC84934FCE0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks, Luna!   OLC seems to mean Orient Last Corners.  That sounds
useful.  :)

I need some help, though, I can't make them work.   Do you have a macro
file you could attach?

Trying to perform them on MC4D, I was able to make "One twist" do the
right thing, but the 7 others I tried (Arm, Half Arm, Twist a, Twist b,
Thumb a, Thumb b, Tick a) all did odd things that did not match the
photos or the desired result.   I wonder if our notations are subtly
different?   But that would make it unlikely that "One twist" would've
worked for me, so probably not.   Hmm.

--Marc

On 7/31/2018 9:03 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing] wrote:
> Here's my (still massively incomplete) set of algs for 2^4 OLC.
> They're designed for the virtual puzzle, but some can be used easily
> on the physical puzzle.
>
> http://wiki.superliminal.com/wiki/2%5E4_algs
>
> Feel free to add your own algs or cases, just try to keep to the
> system already there.
>
> ~Luna
>
  Or

--------------292E916776226BC84934FCE0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit






Thanks, Luna!   OLC seems to mean Orient Last Corners.  That sounds
useful.  :)



I need some help, though, I can't make them work.   Do you have a
macro file you could attach?



Trying to perform them on MC4D, I was able to make "One twist" do
the right thing, but the 7 others I tried (Arm, Half Arm, Twist a,
Twist b, Thumb a, Thumb b, Tick a) all did odd things that did not
match the photos or the desired result.   I wonder if our notations
are subtly different?   But that would make it unlikely that "One
twist" would've worked for me, so probably not.   Hmm.



--Marc

cite="mid:CAK-NJMBYTzkcz6_dwuobNfqpfLOXFhYVkrx=KxVvhRZ_QmXOdg@mail.gmail.com">

 

Here's my (still massively incomplete) set
of algs for 2^4 OLC. They're designed for the virtual
puzzle, but some can be used easily on the physical
puzzle.

href="http://wiki.superliminal.com/wiki/2%5E4_algs"
moz-do-not-send="true">http://wiki.superliminal.com/wiki/2%5E4_algs

Feel free to add your own algs or cases,
just try to keep to the system already there. 

~Luna 

--------------2563B6B019E9D3D4E35C9457
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Luna -- Tabulating what I tried, I can add a bit more troubleshooting of
what I suspect are transcription problems on your collection.

Algs that work for me:   One Twist, Wheel #1
Algs that scramble all faces:  Twist b, Thumb a, Thumb b, Split wheel
Algs that may be upside-down versions of something else (i.e. they leave
U oriented and reorient D):   Arm #1, Half Arm, Twist a, H/
Mislabeled:   Tick a #1 seems to solve Wheel instead.

There are several I didn't try yet.   I'll stop now.

--Marc

On 7/31/2018 10:15 AM, Marc Ringuette ringuette@solarmirror.com
[4D_Cubing] wrote:
>
> Thanks, Luna!   OLC seems to mean Orient Last Corners. That sounds
> useful.  :)
>
> I need some help, though, I can't make them work.   Do you have a
> macro file you could attach?
>
> Trying to perform them on MC4D, I was able to make "One twist" do the
> right thing, but the 7 others I tried (Arm, Half Arm, Twist a, Twist
> b, Thumb a, Thumb b, Tick a) all did odd things that did not match the
> photos or the desired result.   I wonder if our notations are subtly
> different?   But that would make it unlikely that "One twist" would've
> worked for me, so probably not.   Hmm.
>
> --Marc
>
> On 7/31/2018 9:03 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing]
> wrote:
>> Here's my (still massively incomplete) set of algs for 2^4 OLC.
>> They're designed for the virtual puzzle, but some can be used easily
>> on the physical puzzle.
>>
>> http://wiki.superliminal.com/wiki/2%5E4_algs
>>
>> Feel free to add your own algs or cases, just try to keep to the
>> system already there.
>>
>> ~Luna
>>
>   Or
>


--------------2563B6B019E9D3D4E35C9457
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit






Luna -- Tabulating what I tried, I can add a bit more
troubleshooting of what I suspect are transcription problems on your
collection.



Algs that work for me:   One Twist, Wheel #1

Algs that scramble all faces:  Twist b, Thumb a, Thumb b, Split
wheel

Algs that may be upside-down versions of something else (i.e. they
leave U oriented and reorient D):   Arm #1, Half Arm, Twist a, H/

Mislabeled:   Tick a #1 seems to solve Wheel instead.



There are several I didn't try yet.   I'll stop now.



--Marc

cite="mid:1f9c0400-7fe8-b774-2669-0e9193c9b3ca@solarmirror.com">

 

Thanks, Luna!   OLC seems to mean Orient Last Corners. 
That sounds useful.  :)



I need some help, though, I can't make them work.   Do you
have a macro file you could attach?



Trying to perform them on MC4D, I was able to make "One
twist" do the right thing, but the 7 others I tried (Arm,
Half Arm, Twist a, Twist b, Thumb a, Thumb b, Tick a) all
did odd things that did not match the photos or the
desired result.   I wonder if our notations are subtly
different?   But that would make it unlikely that "One
twist" would've worked for me, so probably not.   Hmm.



--Marc

On 7/31/2018 9:03 AM, Luna
Harran href="mailto:scarecrowfish@gmail.com"
moz-do-not-send="true">scarecrowfish@gmail.com
[4D_Cubing] wrote:

cite="mid:CAK-NJMBYTzkcz6_dwuobNfqpfLOXFhYVkrx=KxVvhRZ_QmXOdg@mail.gmail.com">
 

Here's my (still massively incomplete)
set of algs for 2^4 OLC. They're designed for the
virtual puzzle, but some can be used easily on the
physical puzzle.

href="http://wiki.superliminal.com/wiki/2%5E4_algs"
moz="true" moz-do-not-send="true">http://wiki.superliminal.com/wiki/2%5E4_algs

Feel free to add your own algs or
cases, just try to keep to the system already
there. 

~Luna 

  Or

--0000000000001fc93005724fed27
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It really means Orient Last Cell, but that works too =F0=9F=98=81=F0=9F=98=
=81

And the algorithms solve that state, rather than generating it. The reverse
of the algorithm should generate it. Some of the algorithms might be wrong
though, I haven't touched it in a while. Try inverting some of the moves
and see if that works.

Macro files will have to wait a while, we're about to go on holiday and I
won't have access to MC4D, sorry. I think the notation is pretty standard
though.

~Luna

On Tue, 31 Jul 2018, 18:32 Marc Ringuette ringuette@solarmirror.com
[4D_Cubing], <4D_Cubing@yahoogroups.com> wrote:

>
>
> Thanks, Luna! OLC seems to mean Orient Last Corners. That sounds
> useful. :)
>
> I need some help, though, I can't make them work. Do you have a macro
> file you could attach?
>
> Trying to perform them on MC4D, I was able to make "One twist" do the
> right thing, but the 7 others I tried (Arm, Half Arm, Twist a, Twist b,
> Thumb a, Thumb b, Tick a) all did odd things that did not match the photo=
s
> or the desired result. I wonder if our notations are subtly different?
> But that would make it unlikely that "One twist" would've worked for me, =
so
> probably not. Hmm.
>
> --Marc
>
> On 7/31/2018 9:03 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing]
> wrote:
>
>
> Here's my (still massively incomplete) set of algs for 2^4 OLC. They're
> designed for the virtual puzzle, but some can be used easily on the
> physical puzzle.
>
> http://wiki.superliminal.com/wiki/2%5E4_algs
>
> Feel free to add your own algs or cases, just try to keep to the system
> already there.
>
> ~Luna
>
> Or
>
>=20
>

--0000000000001fc93005724fed27
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

--000000000000c821cd0572509673
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'll add my algorithms to this thread too.

I don't use very many algorithms per se: really only three (monoflip, gyro,
and generalized isolate/manipulate/reverse). I do use an "algorithm" for
corner orientation on the 2^3, but everyone has one of those. Otherwise, my
approach is to solve in a certain sequence and use ad hoc moves. I'll
repeat the links to my main algorithms from my intro email. By the way, I
don't know where I came up with gyroscopic as an anti-abbreviation of gyro.
Maybe I was trying to keep everyone on balance or something. Or maybe I hit
M-/ and dynamically expanded it. (Sorry, emacs reference....parts of my
brain are written in emacs lisp.)

- 9:19 gyro . My gyro rotation
- 6:00 corner monoflip demo
- 10: 2:30 pair swap demo -- this is just
a special case of the isolate/manipulate/reverse pattern. I use this
pattern all over the place in different variants. Looking at the video,
it's possible that some intermediate states may be useful and may enable=
me
to shorten this. I went for clarity over brevity.

I haven't translated these into any notation.

For what it's worth, I've avoided IY and OY moves (using Marc's rotation)
as well as the temptation to go with mod 2 =3D 0 instead of mod 4 =3D 0 (gi=
ven
that I can produce a fairly easy albeit lengthy series of moves to solve
from a 180 twist on a half slice) and have taken a more purist position of
adhering to canonical twists plus half twists with a cumulative mod 4 =3D 0=
.


On Tue, Jul 31, 2018 at 3:19 PM Luna Harran scarecrowfish@gmail.com
[4D_Cubing] <4D_Cubing@yahoogroups.com> wrote:

>
>
> It really means Orient Last Cell, but that works too =F0=9F=98=81=F0=9F=
=98=81
>
> And the algorithms solve that state, rather than generating it. The
> reverse of the algorithm should generate it. Some of the algorithms might
> be wrong though, I haven't touched it in a while. Try inverting some of t=
he
> moves and see if that works.
>
> Macro files will have to wait a while, we're about to go on holiday and I
> won't have access to MC4D, sorry. I think the notation is pretty standard
> though.
>
> ~Luna
>
> On Tue, 31 Jul 2018, 18:32 Marc Ringuette ringuette@solarmirror.com
> [4D_Cubing], <4D_Cubing@yahoogroups.com> wrote:
>
> Thanks, Luna! OLC seems to mean Orient Last Corners. That sounds
>> useful. :)
>>
>> I need some help, though, I can't make them work. Do you have a macro
>> file you could attach?
>>
>> Trying to perform them on MC4D, I was able to make "One twist" do the
>> right thing, but the 7 others I tried (Arm, Half Arm, Twist a, Twist b,
>> Thumb a, Thumb b, Tick a) all did odd things that did not match the phot=
os
>> or the desired result. I wonder if our notations are subtly different?
>> But that would make it unlikely that "One twist" would've worked for me,=
so
>> probably not. Hmm.
>>
>> --Marc
>>
>> On 7/31/2018 9:03 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing]
>> wrote:
>>
> Here's my (still massively incomplete) set of algs for 2^4 OLC. They're
>> designed for the virtual puzzle, but some can be used easily on the
>> physical puzzle.
>>
>> http://wiki.superliminal..com/wiki/2%5E4_algs
>>
>>
>>
>> Feel free to add your own algs or cases, just try to keep to the system
>> already there.
>>
>> ~Luna
>>
>>
>> Or
>>
>>=20
>

--000000000000c821cd0572509673
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

--000000000000fb2a21057252365c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The list is still very incomplete, only containing cases I found by
generation or by accident. It's only really useful in LBL/Ortega style
methods, and even then, it can be really hard to recognise cases. However,
you can use RKT style setup moves to transform cases and generate new 1
move longer algs for new cases.

When I next get the chance, I'll try and sort out some of the algs if
they're actually broken.

~Luna

On Tue, 31 Jul 2018, 22:02 Marc Ringuette ringuette@solarmirror.com
[4D_Cubing], <4D_Cubing@yahoogroups.com> wrote:

>
>
> Luna,
>
> I already tried reversing the macros I created from the recipes, on the
> assumption that they were solving, rather than generating, the pictured
> situation. That's not my issue.
>
> I'll have to punt on the non-working ones until someone else gets a bette=
r
> success rate than I did. Besides, I don't yet see how to use them myself
> for solving and am unsure just how incomplete the list of cases is.
>
> However, I'll have a look at the "One twist" OLC algorithm that did work
> for me, and see how it compares to my "Monoflip, solving In+Out faces onl=
y"
> for handling the case where I'm trying to finish aligning my first two
> faces.
>
> Cheers
> Marc
>
> On 7/31/2018 11:41 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing]
> wrote:
>
>
> It really means Orient Last Cell, but that works too =F0=9F=98=81=F0=9F=
=98=81
>
> And the algorithms solve that state, rather than generating it. The
> reverse of the algorithm should generate it. Some of the algorithms might
> be wrong though, I haven't touched it in a while. Try inverting some of t=
he
> moves and see if that works.
>
> Macro files will have to wait a while, we're about to go on holiday and I
> won't have access to MC4D, sorry. I think the notation is pretty standard
> though.
>
> ~Luna
>
> On Tue, 31 Jul 2018, 18:32 Marc Ringuette ringuette@solarmirror.com
> [4D_Cubing], <4D_Cubing@yahoogroups.com> wrote:
>
>>
>>
>> Thanks, Luna! OLC seems to mean Orient Last Corners. That sounds
>> useful. :)
>>
>> I need some help, though, I can't make them work. Do you have a macro
>> file you could attach?
>>
>> Trying to perform them on MC4D, I was able to make "One twist" do the
>> right thing, but the 7 others I tried (Arm, Half Arm, Twist a, Twist b,
>> Thumb a, Thumb b, Tick a) all did odd things that did not match the phot=
os
>> or the desired result. I wonder if our notations are subtly different?
>> But that would make it unlikely that "One twist" would've worked for me,=
so
>> probably not. Hmm.
>>
>> --Marc
>>
>> On 7/31/2018 9:03 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing]
>> wrote:
>>
>>
>> Here's my (still massively incomplete) set of algs for 2^4 OLC. They're
>> designed for the virtual puzzle, but some can be used easily on the
>> physical puzzle.
>>
>> http://wiki.superliminal..com/wiki/2%5E4_algs
>>
>>
>> Feel free to add your own algs or cases, just try to keep to the system
>> already there.
>>
>> ~Luna
>>
>>
>>
>
>=20
>

--000000000000fb2a21057252365c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

--0000000000009a9ff005726d22ba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 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 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 fir=
st
>> color pair in any position except the frame, and only then form faces fr=
om
>> 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 th=
e
>>> 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 achievin=
g
>> the desired effect at the given stage, without regard for the true natur=
e
>> of the algorithm. I lazily called them "double twist parity algorithms"
>> simply because they solved an issue which others have called "double twi=
st
>> parity." I appreciate your analysis of what these algorithms actually
>> accomplish, though I think I need some more hands-on testing of my own t=
o
>> 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
>> ), 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 w=
ere
>> rotated through a real fourth dimension!). Even pentaquark394's scramble=
r
>> (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 equivalen=
t
>> 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 applyi=
ng
>>> 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 th=
is
>> 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=E2=80=99 R=E2=80=99 U2 ]: Iy Ix ]**TTB*: Twist *OBRU* clockwis=
e (relative to
>>> its Back tetrahedron): *[ R[ U R U2 ]: Iy=E2=80=99 Ix=E2=80=99 ]*
>>
>>
>> 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. =F0=9F=99=83
>>
>> Theorem: Every combination of three corner twists is equal to one of th=
e
>>> eight possible single corner twists (clockwise and anticlockwise around=
any
>>> of the 4 colors) or the identity. Every combination of two corner twi=
sts
>>> is equal to one of the three monoflips or the identity. (OK, OK, thi=
s 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. =F0=9F=98=9B 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 case=
s
>> 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 ap=
ply
>>> one of these algs. Now that it's so easy to fix this kind of misalignm=
ent,
>>> futzing around with additional gyros doesn't seem worth it if we're onl=
y 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 lik=
e
>> 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 o=
ne
>> that could use the most improvement.
>>
>> Thank you very much for continued analysis and discussion! It's fun to b=
e
>> 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 sam=
e
>> 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 dist=
inct
>>> 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 th=
e
>>> 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 ta=
kes
>>> 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 cente=
r
>>> (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 applyi=
ng
>>> 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 co=
lor
>>> that was originally Front and still remains Front.
>>>
>>> Tracing similarly, TTB twists the Back tetrahedron of OBRU (Blue in thi=
s
>>> 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=E2=80=99 R=E2=80=99 U2 ]: Iy Ix ]*
>>> *TTB*: Twist *OBRU* clockwise (relative to its Back tetrahedron): *[
>>> R[ U R U2 ]: Iy=E2=80=99 Ix=E2=80=99 ]*
>>>
>>> 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 recognitio=
n 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 divid=
e 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 ar=
ound
>>> 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 ap=
ply
>>> one of these algs. Now that it's so easy to fix this kind of misalignm=
ent,
>>> futzing around with additional gyros doesn't seem worth it if we're onl=
y 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 o=
r
>>> permutation at all.
>>>
>>> Twist *OFRU* clockwise (relative to I/O): *[ R[ U=E2=80=99 R=E2=80=99 U=
2 ]: Iy Ix ]*
>>> Twist *OBRU* counterclockwise (relative to I/O): *[ R[ U R U2 ]: Iy=E2=
=80=99
>>> Ix=E2=80=99 ]*
>>>
>>> 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
>>> .
>>>
>>>
>>> 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)
>>>
>>>=20
>>>
>>
>>
>> --
>>
>> "Machines take me by surprise with great frequency." - Alan Turing
>>
>
>
> --
>
> "Machines take me by surprise with great frequency." - Alan Turing
>


--=20

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

--0000000000009a9ff005726d22ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

--

class=3D"gmail_signature" data-smartmail=3D"gmail_signature">

tr">

r>

"1">"Machines take me by surprise with great frequency." - Alan T=
uring

--0000000000009a9ff005726d22ba--

---

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

---

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

---

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

--0000000000007c979a0572744f19
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm enjoying all this discussion, though I don't have the mindspace for all
of the detail at this point. In another life, maybe I'd be diving in with
the proofs and stuff. While I appreciate the friendly spirit with which the
comment about my hacky scramble was made (and seriously, I take it as a
friendly comment), I thought it was pointing out what I was trying to
achieve.

Though I have a (somewhat rusty) math degree, my goal is not mathematical
rigor. My goal is intuitive understanding. I definitely appreciate the
concept of a full scramble and the fact that it takes a certain number of
moves to ensure that the probability of the minimum path to solution is
sufficiently long and that the twists are sufficiently random, but when it
comes to presenting an approach for how to solve the puzzle and how to
understand why that solution works from an intuitive standpoint, a short,
simple, ad hoc scramble totally does the job, and just having the puzzle
"look" scrambled is sufficient to demonstrate the approach. I like how your
work can probably demonstrate mathematically how certain steps of a
solution are sufficient to cover all possible scrambles. My approach is
more a demonstration of how a solution can be reduced to a very small
number of intuitively clear steps. While I am a strong believer in
mathematical rigor, ultimately I feel that the best test of true
understanding is to be able to explain things in simple terms that a
non-mathematition can understand. I'm not defending myself...just
explaining what my goals are and where I'm coming from. :-) I'm quite
certain that if I were to put this puzzle down for years and pick it up
again, I would still be able to solve it. All I need is the general
strategy of using gyro moves to get certain stickers on the outer corners,
the mod 4 =3D 0 technique, and the super-general isolate/manipulate/reverse
approach. The rest of the algorithms can be generated from those basic
principles. The combination of this intuitive approach and the more
rigorous approach along with optimizing algorithms, etc., I think
contributes to the broadest understanding of this amazingly elegant puzzle.

--Jay

On Thu, Aug 2, 2018 at 9:26 AM Andrew Farkas ajfarkas12@gmail.com
[4D_Cubing] <4D_Cubing@yahoogroups.com> wrote:

>
>
> 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 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
>> 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 b=
y
>>>> 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 fi=
rst
>>> color pair in any position except the frame, and only then form faces f=
rom
>>> them. Thus by the time I'm encountering the apparent corner twist parit=
y 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 t=
he
>>>> 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 calle=
d
>>> "double twist parity." I appreciate your analysis of what these algorit=
hms
>>> actually accomplish, though I think I need some more hands-on testing o=
f 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
>>> ), so if there's a
>>> better way to distinguish the two, I'd be more satisfied. That said, th=
e
>>> 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 scrambl=
er
>>> (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 equivale=
nt
>>> 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 i=
n 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 apply=
ing
>>>> 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 t=
his
>>> at the time as an undesired result, but in retrospect it could certainl=
y 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 existin=
g 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=E2=80=99 R=E2=80=99 U2 ]: Iy Ix ]**TTB*: Twist *OBRU* clockwi=
se (relative to
>>>> its Back tetrahedron): *[ R[ U R U2 ]: Iy=E2=80=99 Ix=E2=80=99 ]*
>>>
>>>
>>> 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. =F0=9F=99=83
>>>
>>> Theorem: Every combination of three corner twists is equal to one of
>>>> the eight possible single corner twists (clockwise and anticlockwise a=
round
>>>> any of the 4 colors) or the identity. Every combination of two corne=
r
>>>> 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. =F0=9F=98=9B I have a strong feelin=
g 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 cas=
es
>>> after removing mirrors and the like -- but of course a rational argumen=
t 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 probabl=
y
>>>> just go ahead and align the other 15 pieces of that color pair, then a=
pply
>>>> one of these algs. Now that it's so easy to fix this kind of misalign=
ment,
>>>> futzing around with additional gyros doesn't seem worth it if we're on=
ly 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 li=
ke
>>> 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 sa=
me
>>> direction violates corner twist parity, while monoflips and the identit=
y 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 dis=
tinct
>>>> cases? I know I needed 3 cases for my sequences for "RUFI by x2/y2/z=
2
>>>> 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 p=
iece,
>>>> whereas mine do two. Instead of performing a net 180 degree flip on t=
he
>>>> 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 aligne=
d
>>>> state like mine does. This baffled me for a few minutes there. It t=
akes
>>>> 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 fro=
m
>>>> 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 i=
n 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 apply=
ing
>>>> the inverse of the 1st alg.
>>>>
>>>> Note that in TTA three different colors on the piece get twists applie=
d
>>>> (Red CCW, Green CCW, Pink CW). The net result is Green CCW (!), the c=
olor
>>>> 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=E2=80=99 R=E2=80=99 U2 ]: Iy Ix ]*
>>>> *TTB*: Twist *OBRU* clockwise (relative to its Back tetrahedron): *[
>>>> R[ U R U2 ]: Iy=E2=80=99 Ix=E2=80=99 ]*
>>>>
>>>> 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 no=
t
>>>> actually perform that flip, so it would seem a bit odd to do recogniti=
on by
>>>> figuring out what 180 degree flip we "could" use, and then not using i=
t.
>>>> I might do it that way anyway.)
>>>>
>>>>
>>>>
>>>> I absolutely love this part of the puzzle-figuring-out process, becaus=
e
>>>> I'm starting to get the hang of the 12 orientations, and how they divi=
de up
>>>> into 4's and 3's, and how corner twists can combine into monoflips, et=
c.
>>>> Your triple twister algorithms are reminding me that I don't fully gro=
k 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 a=
round
>>>> any of the 4 colors) or the identity. Every combination of two corne=
r
>>>> 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 probabl=
y
>>>> just go ahead and align the other 15 pieces of that color pair, then a=
pply
>>>> one of these algs. Now that it's so easy to fix this kind of misalign=
ment,
>>>> futzing around with additional gyros doesn't seem worth it if we're on=
ly 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 o=
r
>>>> 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=E2=80=99 R=E2=80=99 =
U2 ]: Iy Ix ]*
>>>> Twist *OBRU* counterclockwise (relative to I/O): *[ R[ U R U2 ]: Iy=E2=
=80=99
>>>> Ix=E2=80=99 ]*
>>>>
>>>> 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 .
>>>>
>>>>
>>>> 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
>=20
>

--0000000000007c979a0572744f19
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm enjoying all this discussion, though I don't h=
ave the mindspace for all of the detail at this point. In another life, may=
be I'd be diving in with the proofs and stuff. While I appreciate the f=
riendly spirit with which the comment about my hacky scramble was made (and=
seriously, I take it as a friendly comment), I thought it was pointing out=
what I was trying to achieve.

Though I have a (somewhat=
rusty) math degree, my goal is not mathematical rigor. My goal is intuitiv=
e understanding. I definitely appreciate the concept of a full scramble and=
the fact that it takes a certain number of moves to ensure that the probab=
ility of the minimum path to solution is sufficiently long and that the twi=
sts are sufficiently random, but when it comes to presenting an approach fo=
r how to solve the puzzle and how to understand why that solution works fro=
m an intuitive standpoint, a short, simple, ad hoc scramble totally does th=
e job, and just having the puzzle "look" scrambled is sufficient =
to demonstrate the approach. I like how your work can probably demonstrate =
mathematically how certain steps of a solution are sufficient to cover all =
possible scrambles. My approach is more a demonstration of how a solution c=
an be reduced to a very small number of intuitively clear steps. While I am=
a strong believer in mathematical rigor, ultimately I feel that the best t=
est of true understanding is to be able to explain things in simple terms t=
hat a non-mathematition can understand. I'm not defending myself...just=
explaining what my goals are and where I'm coming from. :-) I'm qu=
ite certain that if I were to put this puzzle down for years and pick it up=
again, I would still be able to solve it. All I need is the general strate=
gy of using gyro moves to get certain stickers on the outer corners, the mo=
d 4 =3D 0 technique, and the super-general isolate/manipulate/reverse appro=
ach. The rest of the algorithms can be generated from those basic principle=
s. The combination of this intuitive approach and the more rigorous approac=
h along with optimizing algorithms, etc., I think contributes to the broade=
st understanding of this amazingly elegant puzzle.

>--Jay

On Thu, A=
ug 2, 2018 at 9:26 AM Andrew Farkas >ajfarkas12@gmail.com [4D_Cubing] <groups.com">4D_Cubing@yahoogroups.com> wrote:

lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">












=20

=C2=A0

=20=20=20=20=20=20
=20=20=20=20=20=20

:"trebuchet ms",sans-serif">P.P.S.

iv>

5695ygrp-mlmsg">

06578790928435695ygrp-text">

" style=3D"font-family:"trebuchet ms",sans-serif">

kquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204)" class=3D"gmail_quote">(And the unfolded view is equivalent to removin=
g the top half from our standard horizontal orientation and placing it to t=
he left of the bottom half with a=C2=A0z2.)

=3D"gmail_default" style=3D"font-family:"trebuchet ms",sans-serif=
">

r:#fff">

90928435695ygrp-msg">

r=3D"ltr">

ms",sans-serif">This is incorrect; an Rz Lz' is required b=
efore the z2.

ackground-color:#fff">

=3D"m_-8906578790928435695ygrp-msg">

ext">

On Thu, Aug 2, 2018=
at 1:17 AM Andrew Farkas <t=3D"_blank">ajfarkas12@gmail.com> wrote:

=3D"gmail_quote" style=3D"border-left:1px #ccc solid">

class=3D"gmail_default" style=3D"font-family:"trebuchet ms",sans=
-serif">Gah, I mistyped

ily:"trebuchet ms",sans-serif">

gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)" class=3D"gmai=
l_quote">Thus by the time I'm encountering the apparent corner twist pa=
rity I don't need to worry about the=C2=A0z2=C2=A0rotation since=
the=C2=A0I/O=C2=A0sticker shouldn't be on the frame anyw=
ay.

buchet ms",sans-serif">

"font-family:"trebuchet ms",sans-serif">That should read x2>, not z2.

">On Thu, Aug 2, 2018 at 1:14 AM Andrew Farkas <as12@gmail.com" target=3D"_blank">ajfarkas12@gmail.com> wrote:
div>

=

ebuchet ms",sans-serif">

nt-family:"trebuchet ms",sans-serif">Oh goodness.

=3D"gmail_default" style=3D"font-family:"trebuchet ms",sans-serif=
">

rebuchet ms",sans-serif">You've brought up a lot of things to an>unravel here! I'll go in ord=
er.

ns-serif">

n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)">rebuchet ms, sans-serif">

"trebuchet ms",sans-serif">

y:Georgia;font-size:13px">But referring to them as "clockwise" an=
d "counterclockwise" relative to I/O didn't help me.=C2=A0 Ar=
en't we going to need to be able to recognize 3 distinct cases?=C2=A0=
=C2=A0 I know I needed 3 cases for my sequences for "RUFI by x2/y2/z2 =
while keeping the rest of In/Out fully solved".=C2=A0e=3D"font-family:Georgia;font-size:13px">=C2=A0

nt face=3D"trebuchet ms, sans-serif">

ebuchet ms, sans-serif">

quot;trebuchet ms",sans-serif">I think this is a result of a differenc=
e in our solving approaches. I find it easier (and faster) to first consoli=
date 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<=
/b> rotation since the I/O sticker shouldn't be on the fr=
ame anyway.

=

sans-serif">

=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)">style=3D"font-family:Georgia;font-size:13px">Instead of performing a net 18=
0 degree flip on the piece, you give it a net 120 degree twist on a differe=
nt axis, while exchanging some twists with other pieces.=C2=A0 So, for inst=
ance, applying either sequence 2 times to the solved state does not lead to=
an aligned state like mine does.=C2=A0 This baffled me for a few minutes t=
here.=C2=A0=C2=A0 It takes applying it 3 times..

ont face=3D"trebuchet ms, sans-serif">

"font-family:"trebuchet ms",sans-serif">

iv>

le=3D"font-family:"trebuchet ms",sans-serif">Again taking a speed=
solver's approach here, I focused solely on achieving the desired effec=
t at the given stage, without regard for the true nature of the algorithm. =
I lazily called them "double twist parity algorithms" simply beca=
use they solved an issue which others have called "double twist parity=
." I appreciate your analysis of what these algorithms actually accomp=
lish, though I think I need some more hands-on testing of my own to fully g=
rasp what you're saying.

ms, sans-serif">

ebuchet ms",sans-serif">

ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204)">I'll call =
your two algs TTA and TTB (for Triple Twist A and B).

iv>

le=3D"font-family:"trebuchet ms",sans-serif">

iv>

s",sans-serif">Sounds great, if not a bit arbitrary. Generally when mi=
rror 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 ://www.speedsolving.com/wiki/index.php/PLL" target=3D"_blank">PLL algorithm=
s), so if there's a better way to distinguish the two, I'd be m=
ore satisfied. That said, the only solution I have (CW/CCW) is based on a v=
ery limited view of their effect.

=3D"font-family:"trebuchet ms",sans-serif">

style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)" c=
lass=3D"gmail_quote">v class=3D"gmail_default" style=3D"font-family:"trebuchet ms",san=
s-serif">...

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

t" style=3D"font-family:"trebuchet ms",sans-serif">

class=3D"gmail_default" style=3D"font-family:"trebuchet ms",sans=
-serif">Interesting that we both chose this as the "default" orie=
ntation. I suppose the red/white/green stems from the standard WCA scramble=
orientation, and pink just falls into place (unless one of our puzzles wer=
e rotated through a real fourth dimension!). Even pentaquark394's scram=
bler (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 fro=
m the WCA-inspired horizontal orientation. (And the unfolded view is equiva=
lent 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 t=
o the cube theory!

quot;trebuchet ms",sans-serif">

px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)" class=3D"gmail_quo=
te">There are two choice=
s of CW and CCW in this alg, in step 1 and step 2, and I think we'll fi=
nd that we need to use 3 of those 4 combinations in our 3 cases.=C2=A0=C2=
=A0 At least, that's what ended up happening when I created my similar =
sequences.=C2=A0 It looks like the 3rd case can be handled by applying the =
inverse of the 1st alg.

il_default" style=3D"font-family:"trebuchet ms",sans-serif">You k=
now, as I was developing these I noticed that the I/O sticker=
landed on the frame (R/L face) if I rotated I=C2=A0in=
the opposite direction or applied the wrong algorithm for either case; I d=
ismissed this at the time as an undesired result, but in retrospect it coul=
d 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.

<=
div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s=
ans-serif">

t;trebuchet ms",sans-serif">The next step is to see how these conjugat=
es with I[...] can be used to efficiently orient several pieces at o=
nce! 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.

" style=3D"font-family:"trebuchet ms",sans-serif">

kquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204)" class=3D"gmail_quote">TTA:=C2=A0=
Twist=C2=A0OFRU=C2=A0counterclockwise (relative to its Front tetrah=
edron):=C2=A0[ R[ U=E2=80=99 R=E2=80=99 U2 ]: Iy Ix ]
t face=3D"georgia, serif">TTB:=C2=A0 Twist=C2=A0OBRU=C2=A0clo=
ckwise (relative to its Back tetrahedron):=C2=A0[ R[ U R U2 ]: Iy=E2=80=
=99 Ix=E2=80=99 ]

=3D"font-family:"trebuchet ms",sans-serif">

=3D"gmail_default" style=3D"font-family:"trebuchet ms",sans-serif=
">In my 3D mindset at this stage, I prefer to think of these as clockwise a=
nd counterclockwise respectively around the R hypersticker, hence my=
original naming.

uot;trebuchet ms",sans-serif">

x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)" class=3D"gmail_quot=
e">Recognition:=C2=A0=C2=
=A0 put misaligned piece on=C2=A0t-size:13px">OFRU.=
=C2=A0 If the I/O color is on the Front face, perform=C2=A0=3D"font-family:Georgia;font-size:13px">Rxorgia;font-size:13px">=C2=A0and then=C2=A0orgia;font-size:13px">TTB3px">.=C2=A0 Otherwise, the piece can be aligned via a twist of the Front t=
etrahedron.=C2=A0 Apply=C2=A0ze:13px">TTA=C2=A0(i=
f a counterclockwise twist is needed, i.e. the I/O color is on U) or=C2=A0<=
/span>TTA'le=3D"font-family:Georgia;font-size:13px">=C2=A0(if a clockwise twist is ne=
eded, i.e. the I/O color is on the R corner).

=3D"gmail_default" style=3D"font-family:"trebuchet ms",sans-serif=
">

et ms",sans-serif">I prefer to combine this into one, slightly more co=
mplicated 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<=
/b>. If the piece is in ROFU, apply TTA; if it is in ROBU, ap=
ply TTB.

chet ms",sans-serif">

ont-family:"trebuchet ms",sans-serif">The same result is achieved=
either way.

rebuchet ms",sans-serif">

0px 0.8ex;border-left:1px solid rgb(204,204,204)" class=3D"gmail_quote">pan style=3D"font-family:Georgia;font-size:13px">Thanks for being such a fu=
n co-conspirator.

font-family:"trebuchet ms",sans-serif">

ail_default" style=3D"font-family:"trebuchet ms",sans-serif">Righ=
t back at ya.=C2=A0=F0=9F=99=83

font-family:"trebuchet ms",sans-serif">

e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)" class=
=3D"gmail_quote">Theorem=
:=C2=A0 Every combination of three corner twists is equal to one of the eig=
ht possible single corner twists (clockwise and anticlockwise around any of=
the 4 colors) or the identity.=C2=A0=C2=A0 Every combination of two corner=
twists is equal to one of the three monoflips or the identity.=C2=A0=C2=A0=
=C2=A0 (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.)

:"trebuchet ms",sans-serif">

" style=3D"font-family:"trebuchet ms",sans-serif">Well, so much f=
or sleeping tonight.=C2=A0=F0=9F=98=9B=C2=A0I have a strong feeling that bo=
th of those are true, but of course a proof is necessary. Enumeration is pr=
etty 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 i=
s much more appealing. I'll give it a shot.

l_default" style=3D"font-family:"trebuchet ms",sans-serif">
div>

(204,204,204)" class=3D"gmail_quote">t-size:13px">Random idea: at the beginning of a solve, if we notice that th=
ere'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, th=
en apply one of these algs.=C2=A0 Now that it's so easy to fix this kin=
d of misalignment, futzing around with additional gyros doesn't seem wo=
rth it if we're only 1 piece off from having a color pair off of the co=
rners.

:"trebuchet ms",sans-serif">

" style=3D"font-family:"trebuchet ms",sans-serif">Certainly! It m=
ight 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 in=
tuitive 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.

rebuchet ms",sans-serif">

=3D"font-family:"trebuchet ms",sans-serif">Thank you very much fo=
r continued analysis and discussion! It's fun to be exploring new terri=
tory.

t ms",sans-serif">

-family:"trebuchet ms",sans-serif">- Andy

l_default" style=3D"font-family:"trebuchet ms",sans-serif">
div>

ot;,sans-serif">P.S. Counterexample to the first hypothesis: (execute on >ROFU) CW around R=C2=A0+ CW around U=C2=A0ail_plusreply" id=3D"m_-8906578790928435695m_7120958872501902029m_808561906=
8734802381gmail-plusReplyChip-2">+ CW around R=C2=A0results in <=
b>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.

r=3D"ltr">On Wed, Aug 1, 2018 at 9:57 PM Marc Ringuette inguette@solarmirror.com" target=3D"_blank">ringuette@solarmirror.com [=
4D_Cubing] <k">4D_Cubing@yahoogroups.com> wrote:

mail_quote" style=3D"border-left:1px #ccc solid">












=20

=C2=A0

m_-141151263044942439ygrp-mlmsg">

81m_-141151263044942439ygrp-msg">

2381m_-141151263044942439ygrp-text">
=20=20=20=20=20=20
=20=20=20=20=20=20

=20=20
=20=20
Hey, Andy,



I love your maybe-the-shortest-possible monoflip aligners.=C2=A0 But
referring to them as "clockwise" and "counterclockwise&q=
uot; relative to
I/O didn't help me.=C2=A0 Aren't we going to need to be able to=
recognize
3 distinct cases?=C2=A0=C2=A0 I know I needed 3 cases for my sequences =
for
"RUFI by x2/y2/z2 while keeping the rest of
In/Out fully solved".=C2=A0



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.=C2=A0 Instead of performing a net 180 degre=
e
flip on the piece, you give it a net 120 degree twist on a different
axis, while exchanging some twists with other pieces.=C2=A0 So, for
instance, applying either sequence 2 times to the solved state does
not lead to an aligned state like mine does.=C2=A0 This baffled me for =
a
few minutes there.=C2=A0=C2=A0 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).



=C2=A0=C2=A0 Step 1.=C2=A0=C2=A0 R [ U' R' U2 ]=C2=A0=C2=A0 -- =
twists RUFO CCW around the Right
center (the red corner of the piece) and then places the piece on
RUBI with R[ U2 ]

=C2=A0=C2=A0 Step 2.=C2=A0=C2=A0 Iy Ix=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 -- twists RUBI CW ar=
ound the In
center (the anti-green corner of the piece) and does not permute it

=C2=A0=C2=A0 Step 3.=C2=A0=C2=A0 R [ U2 R U ]=C2=A0=C2=A0=C2=A0=C2=A0 -=
- 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.=C2=A0=C2=A0 At least, that's what ende=
d up
happening when I created my similar sequences.=C2=A0 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).=C2=A0 The net result is Green CC=
W
(!), 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:=C2=A0 Twist OFRU counterclockwise (relative to its
Front tetrahedron): [ R[ U=E2=80=99 R=E2=80=99 U2 ]: Iy Ix ]

TTB:=C2=A0 Twist OBRU clockwise (relative to its Bac=
k
tetrahedron): [ R[ U R U2 ]: Iy=E2=80=99 Ix=E2=80=99 ]

Recognition:=C2=A0=C2=A0 put misaligned piece on OFRU.=C2=A0 If =
the I/O
color is on the Front face, perform Rx and then TTB.=C2=
=A0
Otherwise, the piece can be aligned via a twist of the Front
tetrahedron.=C2=A0 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).=C2=A0=C2=A0=C2=
=A0=C2=A0



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" u=
se, and
then not using it.=C2=A0=C2=A0 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 ho=
w
they divide up into 4's and 3's, and how corner twists can comb=
ine
into monoflips, etc.=C2=A0=C2=A0 Your triple twister algorithms are rem=
inding
me that I don't fully grok it yet, but I feel like I'm making g=
ood
progress.=C2=A0 Thanks for being such a fun co-conspirator.





Theorem:=C2=A0 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.=C2=A0=C2=A0 =
Every
combination of two corner twists is equal to one of the three
monoflips or the identity.=C2=A0=C2=A0=C2=A0 (OK, OK, this is still jus=
t 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.=C2=A0 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 c=
olor
pair off of the corners.





Cheers

Marc

4802381m_-141151263044942439moz-cite-prefix">On 7/31/2018 9:59 PM, Andy F
4802381m_-141151263044942439moz-txt-link-abbreviated" href=3D"mailto:legoma=
ny3448@gmail.com" target=3D"_blank">legomany3448@gmail.com [4D_Cubing] =
wrote:

I'll include my "double twist" algorithms here. Th=
e 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=E2=80=
=99
R=E2=80=99 U2 ]: Iy Ix ]

Twist OBRU counterclockwise (relative to I/O): [
R[ U R U2 ]: Iy=E2=80=99 Ix=E2=80=99 ]

The Iy Ix=C2=A0and Iy' Ix'=C2=A0moves can =
be executed
by moving the right and left endcaps around the inner face, =3D"https://youtu.be/Fd9NUaO5AYo?t=3D5m58s" target=3D"_blank">as can be see=
n in my solution video.

4802381m_-141151263044942439moz-cite-prefix">On 7/28/2018 2:46 PM, Marc Rin=
guette
4802381m_-141151263044942439moz-txt-link-abbreviated" href=3D"mailto:ringue=
tte@solarmirror.com" target=3D"_blank">ringuette@solarmirror.com [4D_Cu=
bing] wrote:

Monoflip,
solving In+Out faces only:=C2=A0=C2=A0 (12 moves physical using ROIL =


Zero, 3 cases)

=C2=A0=C2=A0 RUFI by x2:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rzy=C2=
=A0 I [ U F U' F U F2 U' ] Iy Lx2 Iy'=C2=A0 Rz'

=C2=A0=C2=A0 RUFI by y2:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 Ry'z'=
=C2=A0 I [ U F U' F U F2 U' ] Iy Lx2 Iy'=C2=A0 Ry

=C2=A0=C2=A0 RUFI by z2:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rzy=C2=
=A0 Iy Lx2 Iy'=C2=A0 I [ U F2 U' F' U F' U' ]=C2=A0
Rz'

=C2=A0=C2=A0=C2=A0 (those are sideways Sune, Sune, and Antisune, insi=
de the
brackets)

=20=20

=20=20=20=20=20

=20=20=20=20

=20=20

--
dir=3D"ltr" class=3D"m_-8906578790928435695m_7120958872501902029m_80856190=
68734802381gmail_signature" data=3D"https://ci6.googleusercontent.com/proxy=
/aya5v5NybogpBh1u-qsi36skYYgRapm463_SNN10-unYwK3bkDHKF5m_dH4=3Ds0-d-e1-ft#h=
ttp://gmail_signature">

"monospace, monospace" size=3D"1">

ace=3D"monospace, monospace" size=3D"1">"Machines take me by surprise =
with great frequency." - Alan Turing

--

class=3D"m_-8906578790928435695m_7120958872501902029gmail_signature" data=
=3D"https://ci6.googleusercontent.com/proxy/aya5v5NybogpBh1u-qsi36skYYgRapm=
463_SNN10-unYwK3bkDHKF5m_dH4=3Ds0-d-e1-ft#http://gmail_signature">

=3D"ltr">

1">

ze=3D"1">"Machines take me by surprise with great frequency." - A=
lan Turing

--

class=3D"m_-8906578790928435695gmail_signature" data=3D"https://ci6.google=
usercontent.com/proxy/aya5v5NybogpBh1u-qsi36skYYgRapm463_SNN10-unYwK3bkDHKF=
5m_dH4=3Ds0-d-e1-ft#http://gmail_signature">

=3D"ltr">

iv dir=3D"ltr">"Machine=
s take me by surprise with great frequency." - Alan Turing>

"m_-8906578790928435695ygrp-mlmsg">

g">
=20=20=20=20=20

=20=20=20=20

=20=20

--0000000000007c979a0572744f19--

---

From: Luna Harran <scarecrowfish@gmail.com>
Date: Sun, 5 Aug 2018 02:38:38 +0100
Subject: Re: [MC4D] 2x2x2x2: List of useful algorithms (please add yours)

--0000000000001b9a6f0572a63944
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I now think I've quick fixed the algs on the page. I have a separate file
on my computer somewhere that I'll retranscribe from later, but for now
what's there works for me. The main problem was that I'd mixed up FO and
FO' =F0=9F=98=85=F0=9F=98=85=F0=9F=98=85. The algs you said were upside dow=
n work fine for me, so I'm not
sure what's wrong there, and Tick a is definitely Tick a for me too. Try
these out again when you get a chance, and see if it's sorted out.

~Luna

On Tue, 31 Jul 2018, 22:02 Marc Ringuette ringuette@solarmirror.com
[4D_Cubing], <4D_Cubing@yahoogroups.com> wrote:

>
>
> Luna,
>
> I already tried reversing the macros I created from the recipes, on the
> assumption that they were solving, rather than generating, the pictured
> situation. That's not my issue.
>
> I'll have to punt on the non-working ones until someone else gets a bette=
r
> success rate than I did. Besides, I don't yet see how to use them myself
> for solving and am unsure just how incomplete the list of cases is.
>
> However, I'll have a look at the "One twist" OLC algorithm that did work
> for me, and see how it compares to my "Monoflip, solving In+Out faces onl=
y"
> for handling the case where I'm trying to finish aligning my first two
> faces.
>
> Cheers
> Marc
>
> On 7/31/2018 11:41 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing]
> wrote:
>
>
> It really means Orient Last Cell, but that works too =F0=9F=98=81=F0=9F=
=98=81
>
> And the algorithms solve that state, rather than generating it. The
> reverse of the algorithm should generate it. Some of the algorithms might
> be wrong though, I haven't touched it in a while. Try inverting some of t=
he
> moves and see if that works.
>
> Macro files will have to wait a while, we're about to go on holiday and I
> won't have access to MC4D, sorry. I think the notation is pretty standard
> though.
>
> ~Luna
>
> On Tue, 31 Jul 2018, 18:32 Marc Ringuette ringuette@solarmirror.com
> [4D_Cubing], <4D_Cubing@yahoogroups.com> wrote:
>
>>
>>
>> Thanks, Luna! OLC seems to mean Orient Last Corners. That sounds
>> useful. :)
>>
>> I need some help, though, I can't make them work. Do you have a macro
>> file you could attach?
>>
>> Trying to perform them on MC4D, I was able to make "One twist" do the
>> right thing, but the 7 others I tried (Arm, Half Arm, Twist a, Twist b,
>> Thumb a, Thumb b, Tick a) all did odd things that did not match the phot=
os
>> or the desired result. I wonder if our notations are subtly different?
>> But that would make it unlikely that "One twist" would've worked for me,=
so
>> probably not. Hmm.
>>
>> --Marc
>>
>> On 7/31/2018 9:03 AM, Luna Harran scarecrowfish@gmail.com [4D_Cubing]
>> wrote:
>>
>>
>> Here's my (still massively incomplete) set of algs for 2^4 OLC. They're
>> designed for the virtual puzzle, but some can be used easily on the
>> physical puzzle.
>>
>> http://wiki.superliminal..com/wiki/2%5E4_algs
>>
>>
>> Feel free to add your own algs or cases, just try to keep to the system
>> already there.
>>
>> ~Luna
>>
>>
>>
>
>=20
>

--0000000000001b9a6f0572a63944
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I now think I've quick fixed the algs on the pag=
e. I have a separate file on my computer somewhere that I'll retranscri=
be from later, but for now what's there works for me. The main problem =
was that I'd mixed up FO and FO' =F0=9F=98=85=F0=9F=98=85=F0=9F=98=
=85. The algs you said were upside down work fine for me, so I'm not su=
re what's wrong there, and Tick a is definitely Tick a for me too. Try =
these out again when you get a chance, and see if it's sorted out.=C2=
=A0

~Luna=C2=A0

<=
div class=3D"gmail_quote" dir=3D"auto">

On Tue, 31 Jul 2018=
, 22:02 Marc Ringuette ringuet=
te@solarmirror.com [4D_Cubing], <oups.com">4D_Cubing@yahoogroups.com> wrote:

ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">












=20

=C2=A0

=20=20=20=20=20=20
=20=20=20=20=20=20

=20=20
=20=20
Luna,



I already tried reversing the macros I created from the recipes, on
the assumption that they were solving, rather than generating, the
pictured situation.=C2=A0 That's not my issue.



I'll have to punt on the non-working ones until someone else gets a
better success rate than I did.=C2=A0 Besides, I don't yet see how =
to use
them myself for solving and am unsure just how incomplete the list
of cases is.=C2=A0



However, I'll have a look at the "One twist" OLC algorith=
m that did
work for me, and see how it compares to my "Monoflip, solving In+O=
ut
faces only" for handling the case where I'm trying to finish
aligning my first two faces.



Cheers

Marc

On 7/31/2018 11=
:41 AM, Luna Harran ed" href=3D"mailto:scarecrowfish@gmail.com" target=3D"_blank" rel=3D"norefe=
rrer">scarecrowfish@gmail.com
[4D_Cubing] wrote:

=20=20=20=20=20=20
=C2=A0
=20=20=20=20=20=20

It really means Orient Last Cell, but that works too
=F0=9F=98=81=F0=9F=98=81

And the algorithms solve that state,
rather than generating it. The reverse of the algorithm
should generate it. Some of the algorithms might be
wrong though, I haven't touched it in a while. Try
inverting some of the moves and see if that works.=C2=A0>


Macro files will have to wait a while, we're about to g=
o
on holiday and I won't have access to MC4D, sorry. I
think the notation is pretty standard though.=C2=A0

~Luna=C2=A0

On Tue, 31 Jul 2018, 18:32 Marc
Ringuette target=3D"_blank" rel=3D"noreferrer">ringuette@solarmirror.com
[4D_Cubing], <s.com" target=3D"_blank" rel=3D"noreferrer">4D_Cubing@yahoogroups.com&g=
t;
wrote:

x #ccc solid">

=C2=A0n>

ygrp-mlmsg">

98ygrp-msg">

0498ygrp-text">

Thanks, Luna!=C2=A0=C2=A0 OLC seems to mean=
Orient
Last Corners.=C2=A0 That sounds useful.=C2=A0=
:)



I need some help, though, I can't make
them work.=C2=A0=C2=A0 Do you have a macro fi=
le you
could attach?



Trying to perform them on MC4D, I was able
to make "One twist" do the right th=
ing,
but the 7 others I tried (Arm, Half Arm,
Twist a, Twist b, Thumb a, Thumb b, Tick
a) all did odd things that did not match
the photos or the desired result. =C2=A0 I
wonder if our notations are subtly
different?=C2=A0=C2=A0 But that would make it
unlikely that "One twist" would'=
;ve worked
for me, so probably not.=C2=A0=C2=A0 Hmm.



--Marc

595620498moz-cite-prefix">On
7/31/2018 9:03 AM, Luna Harran 3622209120952051937m_4513123360595620498moz-txt-link-abbreviated" href=3D"m=
ailto:scarecrowfish@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_bla=
nk">scarecrowfish@gmail.com
[4D_Cubing] wrote:

=C2=A0

95620498ygrp-text">

Here's my (still
massively incomplete) set of algs for
2^4 OLC. They're designed for the
virtual puzzle, but some can be used
easily on the physical puzzle.

superliminal.com/wiki/2%5E4_algs" rel=3D"noreferrer noreferrer" target=3D"_=
blank">http://wiki.superliminal..com/wiki/2%5E4_algs

Feel free to add your
own algs or cases, just try to keep
to the system already there.=C2=A0>

~Luna=C2=A0

=C2=A0

=20=20=20=20=20=20=20=20
=20=20=20=20=20=20

=20=20

=20=20=20=20=20

=20=20=20=20

=20=20

--0000000000001b9a6f0572a63944--

---

From: lucas.denhof.58@gmail.com
Date: 13 Sep 2018 15:40:25 +0000
Subject: Re: 2x2x2x2: List of useful algorithms (please add yours)

---

From: lucas.denhof.58@gmail.com
Date: 13 Sep 2018 16:01:58 +0000
Subject: Re: 2x2x2x2: List of useful algorithms (please add yours)

---

From: Andrew Farkas <ajfarkas12@gmail.com>
Date: Thu, 13 Sep 2018 21:26:37 -0400
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yours)

--0000000000003a38430575cab9c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello, Lucas! I've been using an RTK-adapted equivalent of *(R2 F2 R2 U)2*,
an 8-move algorithm that can resolve a 180-degree twist; no gyros necessary=
!

On Thu, Sep 13, 2018 at 9:15 PM lucas.denhof.58@gmail.com [4D_Cubing] <
4D_Cubing@yahoogroups.com> wrote:

>
>
> Hey there, I am the ninth solver of the physical 2x2x2x2 and have just
> joined this group. I wanted to show a new algorithm that I found that doe=
s
> a 180=CB=9A twist on just one of the cubes. I think it will be quite usef=
ul but
> probably also can be very much shortened.
> Counting the gyro move as 0 and counting turns it is 39 moves long. I hav=
e
> a video about it here: https://youtu.be/ru_OgVwlfKE
>
>=20
>


--=20

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

--0000000000003a38430575cab9c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

t ms,sans-serif">Hello, Lucas! I've been using an RTK-adapted equivalen=
t of (R2 F2 R2 U)2, an 8-move algorithm that can resolve a 180-degre=
e twist; no gyros necessary!

dir=3D"ltr">On Thu, Sep 13, 2018 at 9:15 PM .58@gmail.com">lucas.denhof.58@gmail.com [4D_Cubing] <lto:4D_Cubing@yahoogroups.com">4D_Cubing@yahoogroups.com> wrote:
=

eft:1px #ccc solid;padding-left:1ex">












=20

=C2=A0

=20=20=20=20=20=20
=20=20=20=20=20=20

Hey there, I am the ninth solver of the physical=C2=A02x2x2x2 and =
have just joined this group. I wanted to show a new algorithm that I found =
that does a 180=CB=9A twist on just one of the cubes. I think it will be qu=
ite useful but probably also can be very much shortened.

Counting the g=
yro move as 0 and counting turns it is 39 moves long. I have a video about =
it here:=C2=A0get=3D"_blank">https://youtu.be/ru_OgVwlfKE

=C2=A0

=20=20=20=20=20

=20=20=20=20

=20=20

--

class=3D"gmail_signature" data-smartmail=3D"gmail_signature">

tr">

r>

"1">"Machines take me by surprise with great frequency." - Alan T=
uring

--0000000000003a38430575cab9c9--

---

From: Marc Ringuette <ringuette@solarmirror.com>
Date: Thu, 13 Sep 2018 20:29:10 -0700
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yours)

--------------D22F983BF55B2790FEB744A4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Lucas, good job finding your own way through!   As you suspected,
though, your method is far more complicated than necessary.  Using
gyros, indeed.  :-b

Andy is great with these little sequences, and his method can do exactly
what you want using canonical moves.  Andy left it as an exercise for
the reader, but I'll take on that exercise!   In the RKT style, I think
I'd adapt it like this (using the notation R [ R2 ] to represent your

                 ( R2      F2     R2     U      )2
     R [ R2 ] == ( Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz' )2   Ox2     and
cancelling the first and last Ox2 leaves the 15 move alg

     R [ R2 ] == Ry' Ox2 Ry Ox2 Rz Ox Rz'   Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz'

I think I'll make sure to keep Andy's nicely understandable method
tucked away as my go-to solution to this issue.

However, we can go 5 moves better!

Just yesterday I finished creating a valid definition of the 2x2x2x2
puzzle encoded into the optimal algorithm finder Ksolve+.  The one good
algorithm I've found so far is for a version of exactly this situation,
and it turns out that 10 moves is optimal for the case I had plugged in.

     R [ U2 ] == Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2

Whoa!

Cheers
Marc

On 9/13/2018 6:26 PM, Andrew Farkas ajfarkas12@gmail.com [4D_Cubing] wrote:
> Hello, Lucas! I've been using an RTK-adapted equivalent of *(R2 F2 R2
> U)2*, an 8-move algorithm that can resolve a 180-degree twist; no
> gyros necessary!
>
> On Thu, Sep 13, 2018 at 9:15 PM lucas.denhof.58@gmail.com
> [4D_Cubing]
> <4D_Cubing@yahoogroups.com > wrote:
>
> Hey there, I am the ninth solver of the physical 2x2x2x2 and have
> just joined this group. I wanted to show a new algorithm that I
> found that does a 180˚ twist on just one of the cubes. I think it
> will be quite useful but probably also can be very much shortened.
>
> Counting the gyro move as 0 and counting turns it is 39 moves
> long. I have a video about it here: https://youtu.be/ru_OgVwlfKE
>
>


--------------D22F983BF55B2790FEB744A4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit






Hi Lucas, good job finding your own way through!   As you suspected,
though, your method is far more complicated than necessary.  Using
gyros, indeed.  :-b



Andy is great with these little sequences, and his method can do
exactly what you want using canonical moves.  Andy left it as an
exercise for the reader, but I'll take on that exercise!   In the
RKT style, I think I'd adapt it like this (using the notation R [ R2
] to represent your



                 ( R2      F2     R2     U      )2


     R [ R2 ] == ( Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz' )2   Ox2     and
cancelling the first and last Ox2 leaves the 15 move alg



     R [ R2 ] == Ry' Ox2 Ry Ox2 Rz Ox Rz'   Ox2 Ry'
Ox2 Ry Ox2 Rz Ox Rz'



I think I'll make sure to keep Andy's nicely understandable method
tucked away as my go-to solution to this issue.



However, we can go 5 moves better!



Just yesterday I finished creating a valid definition of the 2x2x2x2
puzzle encoded into the optimal algorithm finder Ksolve+.  The one
good algorithm I've found so far is for a version of exactly this
situation, and it turns out that 10 moves is optimal for the case I
had plugged in.



     R [ U2 ] == Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2



Whoa!



Cheers

Marc

On 9/13/2018 6:26 PM, Andrew Farkas
ajfarkas12@gmail.com [4D_Cubing] wrote:

cite="mid:CALmdYqqHHPSOzOz4FQ-f36=zEk+Zurd7n204jNpzCmn35H97-Q@mail.gmail.com">

 

Hello, Lucas! I've been using an
RTK-adapted equivalent of (R2 F2 R2 U)2, an
8-move algorithm that can resolve a 180-degree twist; no
gyros necessary!

On Thu, Sep 13, 2018 at 9:15 PM href="mailto:lucas.denhof.58@gmail.com"
moz-do-not-send="true">lucas.denhof.58@gmail.com
[4D_Cubing] < href="mailto:4D_Cubing@yahoogroups.com"
moz-do-not-send="true">4D_Cubing@yahoogroups.com>
wrote:

 

Hey there, I am the ninth solver of the
physical 2x2x2x2 and have just joined this
group. I wanted to show a new algorithm that I
found that does a 180˚ twist on just one of
the cubes. I think it will be quite useful but
probably also can be very much shortened.

Counting the gyro move as 0 and counting
turns it is 39 moves long. I have a video
about it here:  href="https://youtu.be/ru_OgVwlfKE"
target="_blank" moz-do-not-send="true">https://youtu.be/ru_OgVwlfKE

 

--------------D22F983BF55B2790FEB744A4--

---

From: "Eduard Baumann" <ed.baumann@bluewin.ch>
Date: Fri, 14 Sep 2018 15:31:34 +0200
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yours)

------=_NextPart_000_004B_01D44C40.0657EAF0
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_004C_01D44C40.065C7ED0"

------=_NextPart_001_004C_01D44C40.065C7ED0
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

When I do the marvelous 10-move sequence
R [ U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2

following my picture



the Down half of the right cube ist turned by 180=C2=B0
Hence R [ D2 ].

Why?

Kind regards
Ed


----- Original Message -----=20
From: Marc Ringuette ringuette@solarmirror.com [4D_Cubing]=20
To: 4D_Cubing@yahoogroups.com=20
Sent: Friday, September 14, 2018 5:29 AM
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yo=
urs)


=20=20=20=20
Hi Lucas, good job finding your own way through! As you suspected, thou=
gh, your method is far more complicated than necessary. Using gyros, indee=
d. :-b

Andy is great with these little sequences, and his method can do exactly =
what you want using canonical moves. Andy left it as an exercise for the r=
eader, but I'll take on that exercise! In the RKT style, I think I'd adap=
t it like this (using the notation R [ R2 ] to represent your=20

( R2 F2 R2 U )2
R [ R2 ] =3D=3D ( Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz' )2 Ox2 and canc=
elling the first and last Ox2 leaves the 15 move alg=20

R [ R2 ] =3D=3D Ry' Ox2 Ry Ox2 Rz Ox Rz' Ox2 Ry' Ox2 Ry Ox2 Rz Ox =
Rz'

I think I'll make sure to keep Andy's nicely understandable method tucked=
away as my go-to solution to this issue.

However, we can go 5 moves better!

Just yesterday I finished creating a valid definition of the 2x2x2x2 puzz=
le encoded into the optimal algorithm finder Ksolve+. The one good algorit=
hm I've found so far is for a version of exactly this situation, and it tur=
ns out that 10 moves is optimal for the case I had plugged in.

R [ U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2

Whoa!=20

Cheers
Marc



On 9/13/2018 6:26 PM, Andrew Farkas ajfarkas12@gmail.com [4D_Cubing] wrot=
e:

=20=20=20=20=20=20
Hello, Lucas! I've been using an RTK-adapted equivalent of (R2 F2 R2 U)=
2, an 8-move algorithm that can resolve a 180-degree twist; no gyros necess=
ary!


On Thu, Sep 13, 2018 at 9:15 PM lucas.denhof.58@gmail.com [4D_Cubing] <=
4D_Cubing@yahoogroups.com> wrote:

=20=20=20=20=20=20=20=20
Hey there, I am the ninth solver of the physical 2x2x2x2 and have jus=
t joined this group. I wanted to show a new algorithm that I found that doe=
s a 180=CB=9A twist on just one of the cubes. I think it will be quite usef=
ul but probably also can be very much shortened.

Counting the gyro move as 0 and counting turns it is 39 moves long. I=
have a video about it here: https://youtu.be/ru_OgVwlfKE






=20=20
------=_NextPart_001_004C_01D44C40.065C7ED0
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF

Hi all,

 

When I do the marvelous 10-move=20
sequence

R [ U2 ] =3D=3D Iy2=
Rz Uy2 Iy2 Lz=20
Ix2 Uy2 Rz Ix2 Dy2

following my picture

 

alt=3D""=20
align=3Dbaseline src=3D"cid:E43CFBF87147401BB48B82A93A8F8C94@LAB">DIV>

 

the Down half of the right cube ist=
turned=20
by 180=C2=B0

Hence R [ D2 ].

 

Why?

 

Kind regards

Ed

 

 

style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: =
0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">

----- Original Message -----

style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black">Fro=
m:=20
href=3D"mailto:ringuette@solarmirror.com [4D_Cubing]">Marc Ringuette=20
ringuette@solarmirror.com [4D_Cubing]

To: ps.com=20
href=3D"mailto:4D_Cubing@yahoogroups.com">4D_Cubing@yahoogroups.com <=
/DIV>

Sent: Friday, September 14, 2018 5=
:29=20
AM

Subject: Re: [MC4D] Re: 2x2x2x2: L=
ist of=20
useful algorithms (please add yours)

 =20

Hi Lucas, good job finding your own way through!   As you=20
suspected, though, your method is far more complicated than necessary.&nb=
sp;=20
Using gyros, indeed.  :-b

Andy is great with these little=20
sequences, and his method can do exactly what you want using canonical=20
moves.  Andy left it as an exercise for the reader, but I'll take on=
that=20
exercise!   In the RKT style, I think I'd adapt it like this (u=
sing=20
the notation R [ R2 ] to represent your=20


          &=
nbsp;     =20
( R2      F2    =20
R2     U     =20
)2
     R [ R2 ] =3D=3D ( Ox2 Ry=
' Ox2 Ry=20
Ox2 Rz Ox Rz' )2   Ox2     and cancelling the fi=
rst=20
and last Ox2 leaves the 15 move alg=20


     R [ R2 ] =3D=3D <=
TT>Ry'=20
Ox2 Ry Ox2 Rz Ox Rz'   Ox2 Ry' Ox2 Ry Ox2 Rz Ox=20
Rz'

I think I'll make sure to keep Andy's nicely=20
understandable method tucked away as my go-to solution to this=20
issue.

However, we can go 5 moves better!

Just yesterday I=
=20
finished creating a valid definition of the 2x2x2x2 puzzle encoded into t=
he=20
optimal algorithm finder Ksolve+.  The one good algorithm I've found=
so=20
far is for a version of exactly this situation, and it turns out that 10 =
moves=20
is optimal for the case I had plugged in.

     =
R [=20
U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2

Who=
a!=20


Cheers
Marc

On 9/13/2018 6:26 PM, Andrew Farkas class=3Dmoz-txt-link-abbreviated=20
href=3D"mailto:ajfarkas12@gmail.com">ajfarkas12@gmail.com [4D_Cubing]=
=20
wrote:

cite=3Dmid:CALmdYqqHHPSOzOz4FQ-f36=3DzEk+Zurd7n204jNpzCmn35H97-Q@mail.gma=
il.com=20
type=3D"cite"> =20

class=3Dgmail_default>Hello, Lucas! I've been using an RTK-adapted equi=
valent=20
of (R2 F2 R2 U)2, an 8-move algorithm that can resolve a 180-deg=
ree=20
twist; no gyros necessary!

On Thu, Sep 13, 2018 at 9:15 PM href=3D"mailto:lucas.denhof.58@gmail.com"=20
moz=3D"true">lucas.denhof.58@gmail.com [4D_Cubing] < href=3D"mailto:4D_Cubing@yahoogroups.com"=20
moz=3D"true">4D_Cubing@yahoogroups.com> wrote:

 =20

Hey there, I am the ninth solver of the physical 2x2x2x2 and =
have=20
just joined this group. I wanted to show a new algorithm that I found=
that=20
does a 180=CB=9A twist on just one of the cubes. I think it will be q=
uite=20
useful but probably also can be very much shortened.

Counting the gyro move as 0 and counting turns it is 39 moves lo=
ng. I=20
have a video about it here: fKE"=20
rel=3Dnofollow target=3D_blank=20
moz=3D"true">https://youtu.be/ru_OgVwlfKE

 

>

------=_NextPart_001_004C_01D44C40.065C7ED0--

------=_NextPart_000_004B_01D44C40.0657EAF0
Content-Type: application/x-ygp-stripped
Content-Transfer-Encoding: 7bit
Content-ID:

Content-Type: image/jpeg;
name="2x2x2x2 skizze.JPG"
Content-Transfer-Encoding: base64
Content-ID:

------=_NextPart_000_004B_01D44C40.0657EAF0--

---

From: "Eduard Baumann" <ed.baumann@bluewin.ch>
Date: Fri, 14 Sep 2018 20:19:08 +0200
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yours)

------=_NextPart_000_000E_01D44C68.338CC400
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry.

I was wrong.

The result of the 10-move sequence is effectively
R [ U2 ]

Best regards
Ed


----- Original Message -----=20
From: Marc Ringuette ringuette@solarmirror.com [4D_Cubing]=20
To: 4D_Cubing@yahoogroups.com=20
Sent: Friday, September 14, 2018 5:29 AM
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yo=
urs)


=20=20=20=20
Hi Lucas, good job finding your own way through! As you suspected, thou=
gh, your method is far more complicated than necessary. Using gyros, indee=
d. :-b

Andy is great with these little sequences, and his method can do exactly =
what you want using canonical moves. Andy left it as an exercise for the r=
eader, but I'll take on that exercise! In the RKT style, I think I'd adap=
t it like this (using the notation R [ R2 ] to represent your=20

( R2 F2 R2 U )2
R [ R2 ] =3D=3D ( Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz' )2 Ox2 and canc=
elling the first and last Ox2 leaves the 15 move alg=20

R [ R2 ] =3D=3D Ry' Ox2 Ry Ox2 Rz Ox Rz' Ox2 Ry' Ox2 Ry Ox2 Rz Ox =
Rz'

I think I'll make sure to keep Andy's nicely understandable method tucked=
away as my go-to solution to this issue.

However, we can go 5 moves better!

Just yesterday I finished creating a valid definition of the 2x2x2x2 puzz=
le encoded into the optimal algorithm finder Ksolve+. The one good algorit=
hm I've found so far is for a version of exactly this situation, and it tur=
ns out that 10 moves is optimal for the case I had plugged in.

R [ U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2

Whoa!=20

Cheers
Marc



On 9/13/2018 6:26 PM, Andrew Farkas ajfarkas12@gmail.com [4D_Cubing] wrot=
e:

=20=20=20=20=20=20
Hello, Lucas! I've been using an RTK-adapted equivalent of (R2 F2 R2 U)=
2, an 8-move algorithm that can resolve a 180-degree twist; no gyros necess=
ary!


On Thu, Sep 13, 2018 at 9:15 PM lucas.denhof.58@gmail.com [4D_Cubing] <=
4D_Cubing@yahoogroups.com> wrote:

=20=20=20=20=20=20=20=20
Hey there, I am the ninth solver of the physical 2x2x2x2 and have jus=
t joined this group. I wanted to show a new algorithm that I found that doe=
s a 180=CB=9A twist on just one of the cubes. I think it will be quite usef=
ul but probably also can be very much shortened.

Counting the gyro move as 0 and counting turns it is 39 moves long. I=
have a video about it here: https://youtu.be/ru_OgVwlfKE






=20=20
------=_NextPart_000_000E_01D44C68.338CC400
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF

Sorry.

 

I was wrong.

 

The result of the 10-move sequence is=20
effectively

R [ U2 ]

 

Best regards

Ed

 

 

style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: =
0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">

----- Original Message -----

style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black">Fro=
m:=20
href=3D"mailto:ringuette@solarmirror.com [4D_Cubing]">Marc Ringuette=20
ringuette@solarmirror.com [4D_Cubing]

To: ps.com=20
href=3D"mailto:4D_Cubing@yahoogroups.com">4D_Cubing@yahoogroups.com <=
/DIV>

Sent: Friday, September 14, 2018 5=
:29=20
AM

Subject: Re: [MC4D] Re: 2x2x2x2: L=
ist of=20
useful algorithms (please add yours)

 =20

Hi Lucas, good job finding your own way through!   As you=20
suspected, though, your method is far more complicated than necessary.&nb=
sp;=20
Using gyros, indeed.  :-b

Andy is great with these little=20
sequences, and his method can do exactly what you want using canonical=20
moves.  Andy left it as an exercise for the reader, but I'll take on=
that=20
exercise!   In the RKT style, I think I'd adapt it like this (u=
sing=20
the notation R [ R2 ] to represent your=20


          &=
nbsp;     =20
( R2      F2    =20
R2     U     =20
)2
     R [ R2 ] =3D=3D ( Ox2 Ry=
' Ox2 Ry=20
Ox2 Rz Ox Rz' )2   Ox2     and cancelling the fi=
rst=20
and last Ox2 leaves the 15 move alg=20


     R [ R2 ] =3D=3D <=
TT>Ry'=20
Ox2 Ry Ox2 Rz Ox Rz'   Ox2 Ry' Ox2 Ry Ox2 Rz Ox=20
Rz'

I think I'll make sure to keep Andy's nicely=20
understandable method tucked away as my go-to solution to this=20
issue.

However, we can go 5 moves better!

Just yesterday I=
=20
finished creating a valid definition of the 2x2x2x2 puzzle encoded into t=
he=20
optimal algorithm finder Ksolve+.  The one good algorithm I've found=
so=20
far is for a version of exactly this situation, and it turns out that 10 =
moves=20
is optimal for the case I had plugged in.

     =
R [=20
U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2

Who=
a!=20


Cheers
Marc

On 9/13/2018 6:26 PM, Andrew Farkas class=3Dmoz-txt-link-abbreviated=20
href=3D"mailto:ajfarkas12@gmail.com">ajfarkas12@gmail.com [4D_Cubing]=
=20
wrote:

cite=3Dmid:CALmdYqqHHPSOzOz4FQ-f36=3DzEk+Zurd7n204jNpzCmn35H97-Q@mail.gma=
il.com=20
type=3D"cite"> =20

class=3Dgmail_default>Hello, Lucas! I've been using an RTK-adapted equi=
valent=20
of (R2 F2 R2 U)2, an 8-move algorithm that can resolve a 180-deg=
ree=20
twist; no gyros necessary!

On Thu, Sep 13, 2018 at 9:15 PM href=3D"mailto:lucas.denhof.58@gmail.com"=20
moz=3D"true">lucas.denhof.58@gmail.com [4D_Cubing] < href=3D"mailto:4D_Cubing@yahoogroups.com"=20
moz=3D"true">4D_Cubing@yahoogroups.com> wrote:

 =20

Hey there, I am the ninth solver of the physical 2x2x2x2 and =
have=20
just joined this group. I wanted to show a new algorithm that I found=
that=20
does a 180=CB=9A twist on just one of the cubes. I think it will be q=
uite=20
useful but probably also can be very much shortened.

Counting the gyro move as 0 and counting turns it is 39 moves lo=
ng. I=20
have a video about it here: fKE"=20
rel=3Dnofollow target=3D_blank=20
moz=3D"true">https://youtu.be/ru_OgVwlfKE

 

>

------=_NextPart_000_000E_01D44C68.338CC400--

---

From: Melinda Green <melinda@superliminal.com>
Date: Sat, 15 Sep 2018 02:02:09 -0700
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yours)

--------------F335DA99EFAC9979F07ED398
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Whoa indeed, Marc! Look at you hoovering the 4th dimension to find algorith=
mic gems!

Now maybe I'm doing something wrong but when I finish your 10 move sequence=
it's still one clamshell move (3 canonical twists) away from R[U2].

Also, Ed: I love your coordinate system diagram! It belongs in the wiki in =
an entry for this puzzle. What software did you use to make it?

-Melinda

On 9/13/2018 8:29 PM, Marc Ringuette ringuette@solarmirror.com [4D_Cubing] =
wrote:
>
> Hi Lucas, good job finding your own way through!=C2=A0=C2=A0 As you suspe=
cted, though, your method is far more complicated than necessary.=C2=A0 Usi=
ng gyros, indeed.=C2=A0 :-b
>
> Andy is great with these little sequences, and his method can do exactly =
what you want using canonical moves.=C2=A0 Andy left it as an exercise for =
the reader, but I'll take on that exercise!=C2=A0=C2=A0 In the RKT style, I=
think I'd adapt it like this (using the notation R [ R2 ] to represent you=
r
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 ( R2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 F2=C2=A0=C2=A0=
=C2=A0=C2=A0 R2=C2=A0=C2=A0=C2=A0=C2=A0 U=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 )2
> =C2=A0=C2=A0=C2=A0=C2=A0 R [ R2 ] =3D=3D ( Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz' )=
2 Ox2=C2=A0 =C2=A0=C2=A0 and cancelling the first and last Ox2 leaves the 1=
5 move alg
>
> =C2=A0=C2=A0=C2=A0=C2=A0 R [ R2 ] =3D=3D Ry' Ox2 Ry Ox2 Rz Ox Rz'=C2=A0=
=C2=A0 Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz'
>
> I think I'll make sure to keep Andy's nicely understandable method tucked=
away as my go-to solution to this issue.
>
> However, we can go 5 moves better!
>
> Just yesterday I finished creating a valid definition of the 2x2x2x2 puzz=
le encoded into the optimal algorithm finder Ksolve+. The one good algorith=
m I've found so far is for a version of exactly this situation, and it turn=
s out that 10 moves is optimal for the case I had plugged in.
>
> =C2=A0=C2=A0 =C2=A0 R [ U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2
>
> Whoa!



--------------F335DA99EFAC9979F07ED398
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable



">


Whoa indeed, Marc! Look at you hoovering the 4th dimension to find
algorithmic gems!



Now maybe I'm doing something wrong but when I finish your 10 move
sequence it's still one clamshell move (3 canonical twists) away
from R[U2].



Also, Ed: I love your coordinate system diagram! It belongs in the
wiki in an entry for this puzzle. What software did you use to make
it?



-Melinda



On 9/13/2018 8:29 PM, Marc Ringuette ed" href=3D"mailto:ringuette@solarmirror.com">ringuette@solarmirror.com
[4D_Cubing] wrote:

cite=3D"mid:75275cb9-0db3-0f85-6468-69e5ed944a35@solarmirror.com">

-8">
Hi Lucas, good job finding
your own way through!=C2=A0=C2=A0 As you suspected, though, your meth=
od is
far more complicated than necessary.=C2=A0 Using gyros, indeed.=C2=A0=
:-b



Andy is great with these little sequences, and his method can do
exactly what you want using canonical moves.=C2=A0 Andy left it as an
exercise for the reader, but I'll take on that exercise!=C2=A0=C2=A0 =
In the
RKT style, I think I'd adapt it like this (using the notation R [
R2 ] to represent your



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ( R2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 F2=C2=
=A0=C2=A0=C2=A0=C2=A0 R2=C2=A0=C2=A0=C2=A0=C2=A0 U=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 )2

=C2=A0=C2=A0=C2=A0=C2=A0 R [ R2 ] =3D=3D ( Ox2 Ry' Ox2 Ry O=
x2 Rz Ox Rz' )2=C2=A0=C2=A0
Ox2=C2=A0 =C2=A0=C2=A0 and cancelling the first and last Ox2 leaves=
the 15 move
alg



=C2=A0=C2=A0=C2=A0=C2=A0 R [ R2 ] =3D=3D Ry' Ox2 Ry Ox2 =
Rz Ox Rz'=C2=A0=C2=A0 Ox2 Ry'
Ox2 Ry Ox2 Rz Ox Rz'



I think I'll make sure to keep Andy's nicely understandable method
tucked away as my go-to solution to this issue.



However, we can go 5 moves better!



Just yesterday I finished creating a valid definition of the
2x2x2x2 puzzle encoded into the optimal algorithm finder Ksolve+.=C2=
=A0
The one good algorithm I've found so far is for a version of
exactly this situation, and it turns out that 10 moves is optimal
for the case I had plugged in.



=C2=A0=C2=A0 =C2=A0 R [ U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz =
Ix2 Dy2



Whoa!

--------------F335DA99EFAC9979F07ED398--

---

From: "Eduard Baumann" <ed.baumann@bluewin.ch>
Date: Sun, 16 Sep 2018 18:24:47 +0200
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yours)

------=_NextPart_000_0016_01D44DEA.8D886800
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Nothing else than MS-Excel (then screen capture and MS-Paint for trimming).
Best regards
Ed

----- Original Message -----=20
From: Melinda Green melinda@superliminal.com [4D_Cubing]=20
To: 4D_Cubing@yahoogroups.com=20
Sent: Saturday, September 15, 2018 11:02 AM
Subject: Re: [MC4D] Re: 2x2x2x2: List of useful algorithms (please add yo=
urs)


=20=20=20=20
Whoa indeed, Marc! Look at you hoovering the 4th dimension to find algori=
thmic gems!

Now maybe I'm doing something wrong but when I finish your 10 move sequen=
ce it's still one clamshell move (3 canonical twists) away from R[U2].

Also, Ed: I love your coordinate system diagram! It belongs in the wiki i=
n an entry for this puzzle. What software did you use to make it?

-Melinda

On 9/13/2018 8:29 PM, Marc Ringuette ringuette@solarmirror.com [4D_Cubing=
] wrote:


Hi Lucas, good job finding your own way through! As you suspected, th=
ough, your method is far more complicated than necessary. Using gyros, ind=
eed. :-b

Andy is great with these little sequences, and his method can do exactl=
y what you want using canonical moves. Andy left it as an exercise for the=
reader, but I'll take on that exercise! In the RKT style, I think I'd ad=
apt it like this (using the notation R [ R2 ] to represent your=20

( R2 F2 R2 U )2
R [ R2 ] =3D=3D ( Ox2 Ry' Ox2 Ry Ox2 Rz Ox Rz' )2 Ox2 and ca=
ncelling the first and last Ox2 leaves the 15 move alg=20

R [ R2 ] =3D=3D Ry' Ox2 Ry Ox2 Rz Ox Rz' Ox2 Ry' Ox2 Ry Ox2 Rz O=
x Rz'

I think I'll make sure to keep Andy's nicely understandable method tuck=
ed away as my go-to solution to this issue.

However, we can go 5 moves better!

Just yesterday I finished creating a valid definition of the 2x2x2x2 pu=
zzle encoded into the optimal algorithm finder Ksolve+. The one good algor=
ithm I've found so far is for a version of exactly this situation, and it t=
urns out that 10 moves is optimal for the case I had plugged in.

R [ U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2 Dy2

Whoa!=20





=20=20
------=_NextPart_000_0016_01D44DEA.8D886800
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF

 

Nothing else than MS-Excel (then screen ca=
pture and=20
MS-Paint for trimming).

Best regards

Ed

 

style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: =
0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">

----- Original Message -----

style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black">Fro=
m:=20
href=3D"mailto:melinda@superliminal.com [4D_Cubing]">Melinda Green=20
melinda@superliminal.com [4D_Cubing]

To: ps.com=20
href=3D"mailto:4D_Cubing@yahoogroups.com">4D_Cubing@yahoogroups.com <=
/DIV>

Sent: Saturday, September 15, 2018=
11:02=20
AM

Subject: Re: [MC4D] Re: 2x2x2x2: L=
ist of=20
useful algorithms (please add yours)

 =20

Whoa indeed, Marc! Look at you hoovering the 4th dimension to find=20
algorithmic gems!

Now maybe I'm doing something wrong but when I f=
inish=20
your 10 move sequence it's still one clamshell move (3 canonical twists) =
away=20
from R[U2].

Also, Ed: I love your coordinate system diagram! It be=
longs=20
in the wiki in an entry for this puzzle. What software did you use to mak=
e=20
it?

-Melinda

On 9/13/2018 8:29 PM, Marc Ringuette class=3Dmoz-txt-link-abbreviated=20
href=3D"mailto:ringuette@solarmirror.com">ringuette@solarmirror.com=20
[4D_Cubing] wrote:

om=20
type=3D"cite">Hi Lucas, good job finding your own way through!  =
; As=20
you suspected, though, your method is far more complicated than=20
necessary.  Using gyros, indeed.  :-b

Andy is great wi=
th=20
these little sequences, and his method can do exactly what you want usi=
ng=20
canonical moves.  Andy left it as an exercise for the reader, but =
I'll=20
take on that exercise!   In the RKT style, I think I'd adapt =
it=20
like this (using the notation R [ R2 ] to represent your=20


          =
;      =20
( R2      F2    =20
R2     U     =20
)2
     R [ R2 ] =3D=3D ( Ox2 =
Ry' Ox2=20
Ry Ox2 Rz Ox Rz' )2   Ox2     and cancelling t=
he=20
first and last Ox2 leaves the 15 move alg=20


     R [ R2 ] =3D=3D >Ry'=20
Ox2 Ry Ox2 Rz Ox Rz'   Ox2 Ry' Ox2 Ry Ox2 Rz Ox=20
Rz'

I think I'll make sure to keep Andy's nicely=20
understandable method tucked away as my go-to solution to this=20
issue.

However, we can go 5 moves better!

Just yesterday =
I=20
finished creating a valid definition of the 2x2x2x2 puzzle encoded into=
the=20
optimal algorithm finder Ksolve+.  The one good algorithm I've fou=
nd so=20
far is for a version of exactly this situation, and it turns out that 1=
0=20
moves is optimal for the case I had plugged in.

  =
=20
  R [ U2 ] =3D=3D Iy2 Rz Uy2 Iy2 Lz Ix2 Uy2 Rz Ix2=20
Dy2

Whoa!

------=_NextPart_000_0016_01D44DEA.8D886800--

---

Return to MagicCube4D main page
Return to the Superliminal home page