U perm as a commutator/conjugate

[respho]

Hi all, as a maths lover I recently picked up the Rubik's cube and thoroughly enjoyed the online teachings and maths surrounding the puzzle.

I've been writing down the beginner's algorithms as commutators/conjugates for interest sake and to aid my memory. However the U perm anti clockwise ->
y2 (R U’)(R U)(R U)(R U’)R’ U’ R2 has eluded me.

This is the only alg on my essentials list which seems cannot be broken down, so I am curious.

So is there a way to write it as commutator/conjugates? Is there a method to go about breaking down any algorithm? And the theory to explain which ones can be written in alternate formats or not?

Thanks.

 

[rybaby]

I'm not sure how the RU U perm would be written as a commutator/conjugate, but the HTM optimal one is essentially a setup to U2 S' U2. R2 U' (F B') R2 (F' B) U' R2.

 

[Ollie]

1. R2 U set-up
2. [R, U] commutator + cancels one move from set-up
3. R' set-up
4. [U', R'] commutator
5. Undo step 3 + R to cancel

= R2 U R U R' U' R' U' R' U R'

Not sure where the cancelled move from 1 comes from, just a tired guess

 

[Christopher Mowla]

TMOY broke down the inverse of this algorithm while back, in this post.

Are you looking for a method which breaks down algorithms into a product of commutators and conjugates as all 2-cycle PLLs are in the wiki?

 

[Renslay]

1. R2 U set-up
2. [R, U] commutator + cancels one move from set-up
3. R' set-up
4. [U', R'] commutator
5. Undo step 3 + R to cancel

= R2 U R U R' U' R' U' R' U R'

Not sure where the cancelled move from 1 comes from, just a tired guess

Those steps make no sense to me. It is almost as good as saying R2 U R [U, R'] R2 [U', R'] R2. It does what it does, but I cannot see why (which is not the case for a "normal" commutator, like [R' D' R, U2], which is perfectly understandable).

EDIT: Maybe it cannot be broken into a "reasonable" commutator (I mean where each of the steps are perfectly explainable, and not just "doing this commutator magically solve the U-perm").

EDIT2: A relevant thread: http://www.speedsolving.com/forum/showthread.php?29706-My-ultimate-commutator-challenge

 

[TDM]

y2 (R U’)(R U)(R U)(R U’)R’ U’ R2

I can't explain that alg, but an alternate alg for this case is M2 U M' U2 M U M2. This can be written as [M2 U: [M', U2]], which can be explained simply enough:
M2 U': setup to 3-cycle in the M layer. M2 moves on edge to D, the U aligns the other two edges with the edge in D.
U2 M' U2 M: a 3-cycle. U2 swaps two pieces, M' moves the piece in D up to the U layer, U2 again swaps one of the pieces with the third piece (the one in D) and restores the L/R layers, M restores M slice and finishes the commutator.
U M2: undo setup.

M2 U' U2 M' U2 M U M2 = M2 U M' U2 M U M2.

Sorry if that explanation isn't clear; I'm not great at explaining things.

 

[Christopher Mowla]

EDIT2: A relevant thread: http://www.speedsolving.com/forum/showthread.php?29706-My-ultimate-commutator-challenge

From my research in that thread, I actually found that TMOY's impossibility claim that this algorithm (R U' R U R U R U' R' U' R2) cannot be expressed as a single commutator in term of Rs and Us only (since there are an odd number of Rs and Us) from what I just quoted:

TMOY broke down the inverse of this algorithm while back, in this post.

is ultimately incorrect.

The reason why is too advanced to explain at the moment, but to believe it or not, we can do this in the "imaginary plane" of Rubik's cubes, which my method allows us to do.

Note that I'm not merely claiming that I can create a commutator which solves the same state as R U' R U R U R U' R' U' R2 (as TMOY's does, and for which he mentioned his does in so many words).

I'm claiming that I can create a single commutator that IS algorithmically equivalent to R U' R U R U R U' R' U' R2 both on the regular 3x3x3 cube and the super 3x3x3 cube.

I apologize for mentioning my method again without my proof (which I'm finally ready to send off to a publisher), but I didn't want to mislead anyone by quoting TMOY and not mentioning this, as I would be otherwise implying that he's correct.

 

[goodatthis]

One thing that I wonder in regard to Cmowla's post above:

Obviously a U perm is an edge 3 cycle, and can be solved with a commutator. And from what I'm understanding, the RU U perm is not (at least in the real sense, meaning non imaginary) classifiable as a commutator. I'm going to go out on a limb here and say that not every 3 cycle of corners, edges, or big cube centers, can be solved with an algorithm that is not a commutator. Same with how not every commutator is a 3 cycle, and how not every case that can be solved with a commutator can be solved with a non-commutator. So what is it about a U perm that makes it solvable with a commutator and an alg that is not classifiable as a commutator? Note that some of these are just assumptions, and I am talking about the non-imaginary realm of cube theory.

 

[Lucas Garron]

Those steps make no sense to me. It is almost as good as saying R2 U R [U, R'] R2 [U', R'] R2. It does what it does, but I cannot see why (which is not the case for a "normal" commutator, like [R' D' R, U2], which is perfectly understandable).http://www.speedsolving.com/forum/showthread.php?29706-My-ultimate-commutator-challenge

Yeah, the U-perm is *really* annoying.

The core part of the algorithm is R U R U R U' R' U' R' U' (View [R U': R U R U R U' R' U' R' U'] and press Expand, Simplify, and Invert in that order.)
It's easy to write this as a commutator if you cheat by using rotations: [R U R U R, z' y2]

To see "how" the alg works, perform R U R U on a solved cube and notice that all the U corners end up on R with the same orientation. This is mostly because each R move affects a U corner in the same way. However, it just happens to be that for a cube the fourth corner also faces the same way: R U R U R U R U R' U' R' U' R' U' R' U' R' U twists two corners on Megaminx.
Anyhow, that's why [R U R U: R] preserves CO. Since CP is also preserved, this means that a simple AUF will solve corners again.

Now, if you notice that R U R U also keeps a lot of the corners and edges attached, it's not surprising that enough edges come back to give you a 3-cycle.

But I still have no intuition for "why" it works. Unlike a commutator, there's no indication that all these things *should* line up and give you an efficient 3-cycle.


Also, a simpler way to view the "F2L"-style 3-cycle:[R, U] R' [U', R'] U

 

[Stefan]

I'm claiming that I can create a single commutator that IS algorithmically equivalent to R U' R U R U R U' R' U' R2 both on the regular 3x3x3 cube and the super 3x3x3 cube.

What do you mean with "algorithmically equivalent"? And are you somehow "changing the rules" to achieve it? Cause I really don't see how any <R,U>-commutator affects centers at all.

 

[Christopher Mowla]

What do you mean with "algorithmically equivalent"? And are you somehow "changing the rules" to achieve it? Cause I really don't see how any <R,U>-commutator affects centers at all.

Algorithmically equivalent means that the moves of one move sequence can cancel to become the moves of another algorithm. That is, I have found a way to mathematically expand an algorithm on the nxnxn cube into a larger one without using an identity sequence. An algorithm expansion is not an alternate way to solve the same position: it's a longer way to solve the same position using the exact same path.

Therefore I'm not changing the rules. I cannot express such a commutator in terms of <R,U> alone, but I can show that such a commutator can be algebraically simplified to become <R,U> moves alone, and the exact same <R,U> moves that this U-perm has in this case. Think of math. We can take the integral of Exp[x^2], but we cannot express it with elementary functions.

Recall that the entire cube is 2-gen, so I think that should be a hint that this is possible. I wrote "imaginary plane" to imply that we think outside of the box.

This is only one such application of my theory. It isn't "rocket science", and thus I wouldn't be surprised if someone figures this out without me even further explaining. (It took me just a few hours to figure out the method.)

I just wanted to let you all know what's coming!

Nice to hear from you, Stefan!

 

[Renslay]

Yeah, the U-perm is *really* annoying.

The core part of the algorithm is R U R U R U' R' U' R' U' (View [R U': R U R U R U' R' U' R' U'] and press Expand, Simplify, and Invert in that order.)
It's easy to write this as a commutator if you cheat by using rotations: [R U R U R, z' y2]

To see "how" the alg works, perform R U R U on a solved cube and notice that all the U corners end up on R with the same orientation. This is mostly because each R move affects a U corner in the same way. However, it just happens to be that for a cube the fourth corner also faces the same way: R U R U R U R U R' U' R' U' R' U' R' U' R' U twists two corners on Megaminx.
Anyhow, that's why [R U R U: R] preserves CO. Since CP is also preserved, this means that a simple AUF will solve corners again.

Now, if you notice that R U R U also keeps a lot of the corners and edges attached, it's not surprising that enough edges come back to give you a 3-cycle.

But I still have no intuition for "why" it works. Unlike a commutator, there's no indication that all these things *should* line up and give you an efficient 3-cycle.


Also, a simpler way to view the "F2L"-style 3-cycle:[R, U] R' [U', R'] U

Thank you! That was a really good explanation! :tu

 

[Stefan]

I cannot express such a commutator in terms of <R,U> alone

But that's what he said. So how was it incorrect? And if you allow other moves (particularly cube rotations or slice moves or double layer moves), he already showed in the same post that the argument doesn't apply.

 

[Christopher Mowla]

But that's what he said. So how was it incorrect? And if you allow other moves (particularly cube rotations or slice moves or double layer moves), he already showed in the same post that the argument doesn't apply.

It looks like I didn't think this through.

I made two algorithm expansions of this U-perm.

I was forced to use a z cube rotation in the commutator which works on the supercube (therefore that algorithm expansion doesn't apply).

My algorithm expansion which is supercube safe does not use any slice moves or cube rotations but is algorithmically equivalent to this U-perm on the regular 3x3x3, and therefore if we were speaking of writing this U-perm as a single commutator in terms of a sequence which is equivalent to this U-perm without cube rotations or slice moves for the regular 3x3x3, then my supercube safe algorithm would be a counterexample to his statement.

I apologize for yet another mistake. Thanks Stefan for catching me!

 

[TMOY]

From my research in that thread, I actually found that TMOY's impossibility claim that this algorithm (R U' R U R U R U' R' U' R2) cannot be expressed as a single commutator in term of Rs and Us only (since there are an odd number of Rs and Us) from what I just quoted:
is ultimately incorrect.

The reason why is too advanced to explain at the moment

"I found a really marvellous commutator, but it's too long to fit in this forum". I think I've already seen this somewhere, but where ?

If you can't post it here, in a PDF file, maybe ?

Ps: Of course my post was correct.

 

[Cube Is Life]

I apologize for mentioning my method again without my proof (which I'm finally ready to send off to a publisher), but I didn't want to mislead anyone by quoting TMOY and not mentioning this, as I would be otherwise implying that he's correct.

What is this method you speak of??

 

[IRNjuggle28]

What is this method you speak of??

Read this thread. It will explain what the method is for, even if it doesn't explain the method itself.