• Welcome to the Speedsolving.com, home of the web's largest puzzle community!
    You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

    Registration is fast, simple and absolutely free so please, join our community of 40,000+ people from around the world today!

    If you are already a member, simply login to hide this message and begin participating in the community!

New Two-Corner Swap Algorithm Technique for Big Even Cubes (PLL Parity)

Mike Hughey

Administrator
Staff member
Joined
Jun 7, 2007
Messages
11,303
Location
Indianapolis
WCA
2007HUGH01
SS Competition Results
YouTube
Visit Channel
Without even memorizing it, I can do this one as fast as my current T perm / PLL parity fix approach. I suspect it would be faster if I practiced it a bit.

Now I need to decide whether or not I should bother to learn it. It is interesting what it does on a 5x5x5, but it would take a bit of reworking for me to be able to use it there.

In any event, I'm still surprised the algorithms for this are as long as they are. I was always convinced that there would be some 12 or 14 move algorithm to swap two corners on even cubes, and we were all just missing it. (I didn't have any reason to be convinced; it was just a silly gut feeling.)
 

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,184
Location
Earth
YouTube
Visit Channel
So am I right in saying that you said that there's no alg for swapping two corners and then you presented a series of turns to do just that?

Well, I believe you have an understanding about two-corner swaps, but just to clear things up, view the info in this spoiler.
It appears that we are only swapping two corners, but we also cause PLL parity as well as supercube center distortion. For example, the 19f algorithm I have just shown rotates the right center 180 and the bottom center 90 degrees clockwise.

No matter what algorithm or combination of algorithms you use to swap two corners, PLL parity must be induced (either opposite or adjacent edge swap) as well as rotating at least one center 90 degrees.

The reason for one center turned 90 degrees is due to the odd permutation in the 3X3X3 layers (e.g. any two-corner swap and two edge swap PLL will rotate a supercube center 90 degrees).

The reason for the PLL parity is because on a 3X3X3, it is not possible to swap just two corners (obviously), but if we swap two edges piece by piece on a 4X4X4, then it's possible (hence leaving what appears to be only two corners swapped). Although the fewest move algorithms for PLL parity distort supercube centers, longer ones definitely can preserve them.
However, to answer your question regarding my claims and then later algorithms, the type of OLL parity algorithm I was using before (at the beginning of the thread) didn't affect the center where the dedge flip was. Consequently, 3X3X3 restoration was required for algorithms using a combo of the single slice OLL parity + the wide turn inverse double-parity version (adding an extra r2 in the later portion of it).

The OLL parity algorithm I used this time to find the algorithms just presented affect the center which was on the same face as the flipped dedge. That was the difference. Wide turn versions of double parity algorithms which affect the same center as the dedge and corners also involved, only appear to affect the two corners and dedge.
Take for example, reThinking the Cube's reParity™:
r U2 l' U2 x' r' U2 l U2 r' U2 l U2 l' U2 y' 2m2 y'
Now imagine flipping back just the front dedge. Only two corners will appear to be swapped.
But the double parity I used in the derivation (post 1 in this thread) was:
r2 B2 U2 l' (r2) U2 r U2 r' U2 B2 r' B2 l B2 r2
As you can see, the back two dedges in E are visibly swapped. If I add U2 to that,
r2 B2 U2 l' (r2) U2 r U2 r' U2 B2 r' B2 l B2 r2 U2
then it really appears 4 dedges are swapped along with two corners. So, if I were to flip back the single dedge now, we are in desperate need of 3X3X3 restoration.

See the difference?


Without even memorizing it, I can do this one as fast as my current T perm / PLL parity fix approach. I suspect it would be faster if I practiced it a bit.
Wow, that's great! I memorized it and it seems it is okay in the beginning but finishes really fast (but that's my opinion).

Now I need to decide whether or not I should bother to learn it. It is interesting what it does on a 5x5x5, but it would take a bit of reworking for me to be able to use it there.
Yeah, I didn't really intend for people to use it on the 5X5X5. I was merely just showing that this algorithm does PLL parity to all size cubes (not just to even cubes). This should be an obvious result, as I did create it from a custom double parity algorithm I made.

In any event, I'm still surprised the algorithms for this are as long as they are. I was always convinced that there would be some 12 or 14 move algorithm to swap two corners on even cubes, and we were all just missing it. (I didn't have any reason to be convinced; it was just a silly gut feeling.)
If you go to this link, and go to "Parity PLL.doc", you will see there exists a 15 move algorithm for the diagonal corner swap case:
Rw2 f2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 R2 U2 F2 Rw2 U

I am not positive, but I think it might have been found by Clement's 4X4X4 solver (since he said he found it). I am not sure why Clement didn't provide a case for two adjacent swapped corners, though.

Just in case you are wondering, yes I have an algorithm for the diagonal case, but the minimum I can get is 21f (as of right now), and that is with a set-up move:
r2 x' R U2 R' U2 3r U2 r2 x' U2 r2 U2 r2 U2 L' x U2 R U2 R' U2 R' r2

Know that these are not the only algorithms I have found (or could find), but I am not sure if there exists algorithms of this form which swap two corners in fewer half turn moves.

EDIT:
(See the portion where I responded to irontwig).
 
Last edited:

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,184
Location
Earth
YouTube
Visit Channel
After some thinking, I decided to try to come up with better algorithms for the diagonal corner swap case. In the process, I also found a good (maybe even better) adjacent corner swap algorithm.

My idea was to reduce the amount of cube rotations needed to perform the algorithm. For example, have all 180 degree face turns be strictly U2.

Although the following diagonal swap algorithm does not fit this category, I believe it might be fast, as it only requires two internal cube rotations.

Rw2 R' U2 R' U2 R U2 Rw2 x' U2 Rw2 U2 Rw2 U2 L' x U2 R U2 R' U2 L Rw2 (21f)


Here is a 22f diagonal case which does not require any cube rotations at all: all 180 degree face turns are U2.
Note: The two bolded moves can be inverted to achieve the same task. Just to let you all know, should that one change make this algorithm more speedsovleable.

Rw2 R U2 R U2 R' U2 Rw U2 Rw2 U2 Rw2 U2 Rw L U2 R' U2 R U2 L' Rw2 (22f)
What's interesting about both of these diagonal cases is that they do not have an obvious conjugate to make them an orientation preservation diagonal swap. This was previously asked by Joey:
Can you make one which keeps the orientation of the corners.

Other than the obvious L (your alg) L', conjugate.


Now, here is 22f adjacent corner swap which has no internal cube rotations (all 180 degree face turns are U2). It does require set-up cube rotations, though.
Note: The two bolded moves can be inverted to achieve the same task. Just to let you all know, should that one change make this algorithm more speedsolveable.

z' x
Rw2 R' U2 Rw U2 Rw2 U2 Rw2 U2 Rw L U2 R' U2 R U2 R L' U2 R U2 Rw2 (22f)
x' z
Finally, here is a 2-corner diagonal swap algorithm which contains moves outside of the set <U2,F2,B2,D2,l,r>, similar to that of cmowlaparity.

IT IS LONG, but it is at least fun to execute at least once:). I suspected by experience that 2-corner swap algorithms of this form with the following move set do not yield ideal algorithms for speedsolving. Of course, this is all just my current understanding and may change later.
z Rw2 U R U' F2 L' U2 Rw2 x U2 Rw2 U2 Rw2 U2 x' U2 L U R' U' L' U2 R U2 L F2 Rw2 z' (25f)

I have one comment on the algorithms using all U2s. Yes, they are longer than other algorithms, but more moves are required to make algorithms like this (all U2s). Even if one or two of the 180 degree face turns were B2 or F2, etc., the algorithm could easily be less turns (even possibly optimal for the conventional move set). As you can observe, there for the adjacent corner swap, it was 3 turns more than the minimum I could get for algorithms of this form; and for the diagonal corner swap, only one more turn than I could get:).

Expanding on this, the comments I gave about inverting the two bolded moves in these two algorithms is caused by the very technique which I use to force the algorithm to only contain U2s. Modifying that one portion of the algorithm generates an identical algorithm with those two moves inverted. That's why I know that those two moves in each 22f algorithm can be inverted and achieve the same task (it wasn't guess work, but two separate calculations).

I have uploaded a video on YouTube which shows these algorithms (not the last one) as well as my original 19f adjacent corner swap which I presented earlier in this thread (for those interested).


Please let me know what you all think about these algorithms!
 

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,184
Location
Earth
YouTube
Visit Channel
Clement's Diagonal Corner Swap Analyzed

Hey everyone,

I have analyzed Clement's Diagonal Corner Swap Algorithm which is 15h/27q:
Rw2 f2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 R2 U2 F2 Rw2 U

and I have figured out how this algorithm works and engineered a 16h/27q algorithm that is much more human comprehensible (probably faster too).

Rw2 F2 U2 y Rw2 U' Rw2 U D Lw2' U' Lw2' y' r2 U2 F2 Rw2 U


How did I do it? Please study my algorithm before reading. I want you all to at least try to think critically before viewing the solution:).
After A LOT of arithmetic and expansion, I broke this algorithm into 5 pieces. It was difficult to do this since many of the moves in this outline were not within the original algorithm itself, but this IS the outline for this computer-generated algorithm:

Rw2 F2 U2 r2 __________________________Preliminary
r2
___________________________________ Extra turn to induce PLL Parity
U2 Fw2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 Rw2
___Base
r2 U2 F2 Rw2
__________________________Reverse of Preliminary
U
____________________________________Finishing turn to make pure

If you don't believe that the second r2 is the move which induces PLL parity, go ahead and delete it! What we have is an N-Perm which depends on wide turns!
Rw2 F2 U2 r2
(where the r2 used to be)
U2 Fw2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 Rw2
r2 U2 F2 Rw2
U

(None of this was guess work).


Now, analyzing the real base of Clement's algorithm (the algorithm piece in my outline), it does two 2-cycles of 4 blocks in the same half of the cube.
U2 Fw2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 Rw2


By my outline, once you have this 2 2-cycle of 4 1X2X2 blocks, then the extra move which induces PLL parity is executed about the inner-layer slice parallel and adjacent to the blocks.
U2 Fw2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 Rw2
r2


But it does not matter if this move is added at the beginning or end of the base. Trying to match Clement's algorithm (and its effect on the cube) perfectly, the extra turn must come before the base.


After that is added, then the set-up moves are added. Lastly, the U turn to put the corners into position.

--The reason this algorithm was so difficult to see was because many of its moves are not present due to move cancellations!
DONE.
-------------------------------------------------------------------

Now for my algorithm, I used the same set-up moves and incorporated the extra turn to induce PLL parity (I knew about this extra turn before I analyzed Clement's algorithm obviously, as I did invent my own family of corner-swap algorithms).

The base for my algorithm is not complicated at all and is shorter in moves than Clement's solver's:
y z' Uw2 L' Uw2 L R Uw2 R' Uw2 z y'



It is based on the simple algorithm for swapping two centers on a 4X4X4:
Lw' U2 Lw Rw U2 Rw'



Here is the full outline of my algorithm:
Rw2 F2 U2 r2
________________________Preliminary moves found from Clement’s algorithm.
r2
____________ _____________________ Extra turn to induce PLL Parity
y z' Uw2 L' Uw2 L R Uw2 R' Uw2 z y' _______Base
r2 U2 F2 Rw2
_________________________Reverse of preliminary.
U
__________________________________Finishing turn to make pure

And I just did some speed optimization techniques that many know already to transform it into what I presented it as.

The mystery behind this algorithm is revealed!

By Christopher Mowla

July 13, 2010.

Edit: (Off Topic)
The PLL parity 2 2-cycle algorithm: Rw2 Fw2 U2 r2 U2 Fw2 Rw2 (by Stefan Pochmann) does not need the F turns to be wide. That is,
Rw2 F2 U2 r2 U2 F2 Rw2 is sufficient for both even and odd cubes. This should be obvious because of the set-up moves which I used to make my algorithm in this post. In fact, this algorithm is nothing more than the r2 move to induce PLL parity, enclosed by the same set-up moves as Clement's diagonal swap corner algorithm.
 
Last edited:

ryo

Member
Joined
May 21, 2008
Messages
90
Location
France
WCA
2008LAUR01
If someone is interested I have this one :
R2 D Rw2 U2' B2 r2 B2 U2' Lw2 R U' Lw U2 Rw' U Rw U2
(start with right thumb on top, U2' -> double trigger left hand, B2 -> double trigger right hand)
 

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,184
Location
Earth
YouTube
Visit Channel
Derivations of 17 btm Corner Swap Algorithms

How did you use cube explorer to get a 4x4 alg?

I think the best way to explain it to you is to just give you a derivation for that algorithm. It's definitely not direct, but, as you will soon see, Cube Explorer did do most of the work.



Derivation
I am not sure if older versions of cube explorer yield identical solutions, so I need to mention that I am using version 5.00.

1) Start out with the 4-cycle double-parity case:
r U2 r l' U2 r2 U2 r' U2 r U2 r' U2 r' U2 l U2 r'

(I got this algorithm from Thom Barlow's (Kirjava's) ELL page.)

2) Convert all inner-layer slices to outer-layers (to match the 3x3x3)
R U2 R L' U2 R2 U2 R' U2 R U2 R' U2 R' U2 L U2 R' (18 f)

3) Type (or copy and paste) this into cube explorer, apply to a solved 3x3x3 cube, and hit the "add and solve" button. Then click the green arrow until you get the following 15f solution:
F2 R F2 R F2 R' U2 R2 U2 F2 L' U2 L U2 R2 (15 f)

Cube Explorer's work is done. From here, it is all up to us to make this into what we want.

4) By experimentation, we can find out to convert both double turns of R into wide turns.

So that you have a set-up like this:

F2 R F2 R F2 R' U2 Rw2 U2 F2 L' U2 L U2 Rw2, where

a) the cube isn't totally scrambled
b) the inner layers are affected, but the net result is a "half turn" away from being "solved", as opposed to if we tried to convert an even number of the quarter turns to wide too.

For example, the following are very bad because they don't give us much to work with AND, it is making this algorithm more on the inner-layer odd parity algorithm's side (by really affecting the wings).

F2 R F2 R F2 R' U2 R2 U2 F2 Lw' U2 Lw U2 R2
or
F2 R F2 Rw F2 Rw' U2 R2 U2 F2 Lw' U2 Lw U2 R2
or
F2 R F2 Rw F2 Rw' U2 R2 U2 F2 L' U2 L U2 Rw2
...etc.

5) Although it might seem to be a mess, what we have
http://alg.garron.us/?alg=F2_R_F2_R_F2_R-_U2_Rw2_U2_F2_L-_U2_L_U2_Rw2_U2&cube=4x4x4&notation=WCA F2 R F2 R F2 R' U2 Rw2 U2 F2 L' U2 L U2 Rw2
will work out just fine.

Adding the algorithm piece, U2 r2,
This is based off of r2 U2 r2 U2 r2, which is can be related to
r2 U2 r2 Uw2 r2 u2, because r2 U2 r2 Uw2 r2 u2 = r2 U2 r2 U2 r2 + r2 u2 r2 u2)

The reason I say, "based off of" is because r2 U2 r2 U2 r2 affects opposite 1x2 center blocks and hence leaves the cube with PLL parity (our goal).

So we have
F2 R F2 R F2 R' U2 Rw2 U2 F2 L' U2 L U2 Rw2 + U2 r2
=
F2 R F2 R F2 R' U2 Rw2 U2 F2 L' U2 L U2 Rw2 U2 r2

This swaps two corners and two 1x2 center blocks (it also turns another center 90 degrees due to swapping two corners: that is related to regular PLLs).

From here, we can just add one set-up move to swap the same-color centers with each other:

r2
F2 R F2 R F2 R' U2 Rw2 U2 F2 L' U2 L U2 Rw2 U2 r2
r2


= r2 F2 R F2 R F2 R' U2 Rw2 U2 F2 L' U2 L U2 Rw2 U2 (17 btm)

6) Now for optimization (which is totally up to the individual, but this is how I made it into the algorithm I presented),

a) Rotating about y2 and taking the mirror image of that,
r2 B2 R' B2 R' B2 R U2 Rw2 U2 B2 L U2 L' U2 Rw2 U2

b) Adding an x cube rotation (for faster execution)
x' r2 U2 R' U2 R' U2 R x U2 Rw2 U2 B2 L U2 L' U2 Rw2 U2

c) More cube rotation "conjugates" to move the two swapped corners in the top-front,
z x
x' r2 U2 R' U2 R' U2 R x U2 Rw2 U2 B2 L U2 L' U2 Rw2 U2
x' z'


= z r2 U2 R' U2 R' U2 R x U2 Rw2 U2 B2 L U2 L' U2 Rw2 U2 x' z'

DONE

Also,
Here is a 17 btm diagonal corner swap algorithm I made last night when I saw this thread was bumped. It really took little effort, (but I guess my understanding is improving as time goes on).


Derivation
For a relatively decent set-up I had to create a set-up to swap two diagonal edge pieces on a 4x4x4 cube for Cube Explorer. It turned out to be the inverse of the algorithm on rachmaninovian's fantastic web-page:

"r2 B2 U2 r' U2 r2 B2 r' U2 r2 U2 B2 r' B2 [pure, modified from an alg found with Clement Gallet's solver]"

(So this algorithm can be created by both solvers independently).

Making the following adjustment (for the same reasons as the 17 btm adjacent corner swap alg),
Rw2 B2 U2 R' U2 R2 B2 R' U2 Rw2 U2 B2 R' B2

Adding two half turns,
Rw2 B2 U2 R' U2 R2 B2 R' U2 Rw2 U2 B2 R' B2 r2 U2

Shift
R2 B2 R' U2 Rw2 U2 B2 R' B2 r2 U2
Rw2 B2 U2 R' U2


Add one set-up move to swap same-color 1x2 center blocks with each other (and it luckily moves both corners into the U-layer for us)
Rw2
R2 B2 R' U2 Rw2 U2 B2 R' B2 r2 U2
Rw2 B2 U2 R' U2
Rw2

= r2 B2 R' U2 Rw2 U2 B2 R' B2 r2 U2 Rw2 B2 U2 R' U2 Rw2 (17 btm)
DONE

Other Notes
After all of this time, I have not been able to achieve algorithms less than 17 btm for these two cases (with this type of algorithm, of course). Hence, I believe these could in fact be optimal for this move set.

I plan on taking some time to make derivation videos for my 19-22 btm algorithms I presented earlier in this thread, as I did make those without any help from a solver. I will provide very convincing evidence that 19 btm IS optimal for that algorithm type.
 
Last edited:
Joined
Dec 11, 2009
Messages
294
Swaps 2 diagonal corners, UFL<->UBR, (BD) in Speffz notation.

reCornerX(BD)™ = U2 Rw2 U2 R U2 F2 R2 F2 R' F2 U2 Rw2 U2 R' F2 r2 (16 btm)
 
Joined
Dec 11, 2009
Messages
294
NEW Diagonal Corner Swap for 4x4x4 (UFL<->UBR, (BD) Speffz)

reCornerX(BD)™= (U2 Rw2 U2 R U2)x(U2 R2 U2 R' U2)x'(U2 Rw2 U2 (Lw' r)U2) r2


Inspired from cmowla's ingenious idea of imbedding (r2 U2 r2 U2 r2) into the main alg, with piggybacked Rw turns - to simultaneously

achieve edge PLL and r-slice center swaps alongside the corner permutation. TMALSS - Cube Explorer helped me find some *fertile*

N-perm candidates, but I still had to do a considerable amount of experimentation to get that result. Please take the time to compare the

alg above, to the other diagonal corner swappers that I have listed below:


fbCornerX(BD) = R Rw2 F2 L U L' B D L D' B2 U B r2 U2 F2 Rw2 R' U2 (Frédérick Badie)
cgCornerX(BD) = Rw2 f2 U2 Fw2 D Rw2 U2 Fw2 U' Fw2 L2 U2 B2 Lw2 U (Clément Gallet)
mfCornerX(BD) = Rw2 f2 U2 Fw2 U' Rw2 U2 Fw2 U Fw2 R2 U2 F2 Rw2 U (Michael Fung var.CG14)
rtcCornerX(BD) = x' Uw2 r2 F2 Rw2 F' Uw2 F2 Rw2 F Rw2 U2 F2 R2 Uw2 F (reThinker var.MF14)
cm1CornerX(BD) = y' Rw2 F2 U2 y Rw2 U' Rw2 U D Lw2' U' Lw2' y' r2 U2 F2 Rw2 U (Christopher Mowla1)
cm2CornerX(BD) = r2 B2 R' U2 Rw2 U2 B2 R' B2 r2 U2 Rw2 B2 U2 R' U2 Rw2 (Christopher Mowla2)
 
Last edited:

ryo

Member
Joined
May 21, 2008
Messages
90
Location
France
WCA
2008LAUR01
If someone is interested I have this one :
R2 D Rw2 U2' B2 r2 B2 U2' Lw2 R U' Lw U2 Rw' U Rw U2
(start with right thumb on top, U2' -> double trigger left hand, B2 -> double trigger right hand)

Sorry, I made a notation mistake, the correct one is :
R2 D Rw2 U2' B2 r2 B2 U2' Lw2 R U' (Lw r') U2 (Rw' l) U (Rw l') U2
 

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,184
Location
Earth
YouTube
Visit Channel
Derivation Video is Finally Here!

As promised, I have made a derivation video which gives the general procedures I do to make the 2-corner swap algorithms in this thread (besides the most recent 17 btm ones, which I have already shown how to do using a 3x3x3 solver).

The video is not short, but I cover all of the necessary information to become a master! Note that ANYONE can pick up on how to do this even if he/she doesn't know how to make OLL Parity algorithms by hand because I just show how to manipulate them to make the 2-corner swap algorithms. (Of course, it always can help if you can!)
 
Last edited by a moderator:

Christopher Mowla

Premium Member
Joined
Sep 17, 2009
Messages
1,184
Location
Earth
YouTube
Visit Channel
In the video above, I said that it wasn't possible to create a 2-corner swap algorithm from Frédérick Badie's algorithm:

r' U2 l F2 l' F2 r2 U2 r U2 r' U2 F2 r2 F2

A few days ago, I found it IS possible.
This is my newest decomposition of Frédérick Badie's algorithm.

r' U2 l F2 l' F2 r2 U2 r U2 r' U2 F2 r2 F2
=
r' U2 l F2 l' F2 r U2
U2 r U2 r'
r2 U2 (r') U2 r2
r2 F2 r2 F2

(View what each line of moves does separately to see how this algorithm works).

I'm considering this to be even better than the decomposition at the end of my methods thread in this post.
REASON: My previous decomposition:
r' U2 l F2 l' F2 r2 U2 r U2 r' U2 F2 r2 F2
=
r' U2 l F2 l' F2 r U2
U2 r2
r' U2 (r) U2 r
r2 U2 F2 r2 F2 U2 r2
r2 U2

is false because, if you execute the algorithm in SiGN on the 4x4x4 supercube, the R center is rotated 90 degrees anti-clockwise (in the direction of R', not in the direction of R...so the true extra quarter turn must be the move r').
My new decomposition supports this.

In addition, if we insert r2 at the point where the extra quarter turn is in this representation, we get a double parity.

r' U2 l F2 l' F2 r U2
U2 r U2 r'
r2 U2 (r') r2 U2 r2
r2 F2 r2 F2
Therefore, following the "formula" I presented in the video to make a 2-corner swap alg. (the process is almost exactly the same), we do:
[1]We:
a) Write the inverse (in single slice turns)
b) Write the second algorithm in wide turns
c) Put Rw2 next to the extra quarter turn (wide turn version)
d) Add 3x3x3 moves to have just two corners (besides the effects on the centers of the supercube) exchanged.

F2 r2 F2 r2
r2 U2 r U2 r2
r U2 r' U2
U2 r' F2 l F2 l' U2 r

Rw' U2 Lw F2 Lw' F2 Rw U2
U2 Rw U2 Rw'
Rw2 U2 (Rw') Rw2 U2 Rw2
Rw2 F2 Rw2 F2

U2 F2 U2



[2] Delete the inner layer turns from the entire algorithm after the quarter turn (in the first half) and before the quarter turn (in the second half)

F2 r2 F2 r2
r2 U2 r U2
U2 U2
U2 F2 F2 U2

R' U2 L F2 L' F2 R U2
U2 R U2 R'
R2 U2 (Rw') Rw2 U2 Rw2
Rw2 F2 Rw2 F2

U2 F2 U2


[3] Cancel moves:
F2 r2 F2 U2 r U2 R' U2 L F2 L' F2 R2 U2 R U2 Rw U2 F2 Rw2 F2 U2 F2 U2 (24)

Although it was a lucky guess,

[4] If we take the move R' and move it to the end (it was just a guess), then we have a 22 move oriented diagonal case.
F2 r2 F2 U2 r U2 U2 L F2 L' F2 R2 U2 R U2 Rw U2 F2 Rw2 F2 U2 F2 U2 R'
=
F2 r2 F2 U2 r L F2 L' F2 R2 U2 R U2 Rw U2 F2 Rw2 F2 U2 F2 U2 R' (22)
Algorithm Structure
If we just move F2 to the end of the algorithm (shift),
r2 F2 U2 r L F2 L' F2 R2 U2 R U2 Rw U2 F2 Rw2 F2 U2 F2 U2 R' F2

...and then rewrite as:
r2 F2 U2
r
L F2 L' F2 R2 U2 R U2 R
r U2 F2 r2
R2 F2 U2 F2 U2 R' F2


We can visualize this as just being an algorithm where we insert moves inside of the PLL Parity algorithm r2 F2 U2 r2 U2 F2 r2.
Diagonal corner swap
=
r2 F2 U2
r
(3x3x3 moves here)
r U2 F2 r2
(3x3x3 moves here)
This algorithm is definitely not optimal, but it appears to have a new structure.
 
Last edited:
Top