# Why are the T Y and Jb perms related by cyclic shift?



## ray5 (Jan 17, 2021)

Is there a mathematical reason why these algorithms are so similar?

T perm: R U R' U' R' F R2 U' R' U' R U R' F'
Y perm: F R U' R' U' R U R' F' R U R' U' R' F R F'
Jb perm: R U R' F' R U R' U' R' F R2 U' R' U'

I understand the F perm is just a conjugated T perm, but I don't really know about these 3. They all belong to a similar class: PLL, swaps 2 corners and 2 edges.

I was shown that Y = (F R U' R' U' R' F') (R U R' U' R' F R F')
and that T = (R U R' U' R' F R F') (F R U' R' U' R' F')
but I still don't know why a cycle shift of an algorithm would lead to another useful algorithm.

If we take out the conjugation by F in Y perm we have the following blocks:

T: (R U R' U' R' F R) (R U' R' U') (R U R' F')
Jb: (R U R' F') (R U R' U' R' F R) (R U' R' U')
Y': (R U' R' U') (R U R' F') (R U R' U' R' F R)


----------



## salamandra (Jan 17, 2021)

A cyclic shift is a special form of conjugation. Since J perm transposes two corners and two edges, all of its conjugates transpose two corners and two edges as well. T, Y and F perm just happen to be conjugates that only act on the last layer.


----------



## xyzzy (Jan 18, 2021)

ray5 said:


> but I still don't know why a cycle shift of an algorithm would lead to another useful algorithm.


What salamandra said, but also, it doesn't _always_ lead to useful algorithms. Like, R' U' R' F R2 U R' U' R U R' F' R U doesn't seem particularly useful to me.

(Why cyclic shift is a special case of conjugation: A B = A (B A) A^−1, so A B and B A are always conjugates of each other.)

---

On that note, (R' F R2 U' R' U' R U R' F') (R U R' U') happens to do the same thing as your Y' = (R U' R' U' R U R' F') (R U R' U' R' F R), so we can in fact also conjugate that by F and get this other relatively common Y perm alg: F R' F R2 … R U R' U' F'.

Or if we conjugate by F U' instead, we get a Ja perm: F U' R' F R2 … R U R' F'. (This alg isn't great for normal 3×3×3 speedsolving, but I hear some people use it on megaminx.)


----------



## Christopher Mowla (Jan 18, 2021)

ray5 said:


> but I still don't know why a cycle shift of an algorithm would lead to another useful algorithm.


I am not sure that I understand what the "concern" is here. If an algorithm's first and last moves are not inverses of each other, it can *always* be cyclically shifted into another case. Not all non-symmetrical algorithms (which I define on the 4x4x4 parity algorithms wiki page) will "shift well" (be what I called a good seed/base).

I can see that you used the phrase "useful algorithm", and so I digress and ask that, _why not_ it be the case that shifting of one useful algorithm will produce another useful algorithm? It's definitely not always the case, but it ought to happen sometime! And it's not something you have to make sense of. *It will happen if it's possible and won't if it's not*. But I think you will find that algorithms generated from software such as Cube Explorer will "do cyclic shifts" quite often.

And not that the large percentage of them are "useful" (for any reasonable criteria), but conjugating and shifting just *2 dozen* algorithms produced 350,000 4x4x4 2-cycle parity algorithms. (Here's a video on the story, but basically with that "search", I found what appears to be every move-optimal 2-cycle of wing edges algorithm (in the block quarter turn move metric) that I found over a period of 9 years by hand . . . and a few new ones that I did not find.) So if you were _by any chance_ asking if cyclic shifting will commonly produce algorithms, the answer is obviously yes from this _extreme_ example.


----------



## qwr (Jan 18, 2021)

I think I accidentally generated new 2x2 PBL algs by moving around moves in the alg and shifting things.


----------



## Christopher Mowla (Jan 18, 2021)

I know this may seem redundant, but some people may just miss it!

If you were perhaps looking to find a way to "predict" or "detect" what cyclic shifts of an algorithm will do without actually doing them, then this may be pretty neat for you to see.

With T, Jb and Y' algs example, their seed algorithm (base) can be represented as [F' R U, R'] [R U' R': *U'*], where the bold move is the extra quarter turn.

If we expand this, we have:
F' R U R' U' R' F R R U' R' U' R U R'

(Always remember to break up half turns into two quarter turns . . . because you will not be able to get as many potential algorithms out of a seed if you don't!)

By looking at the cube with this applied, we know that if the front bottom right corner was in the front top right corner slot, we could potentially have a T-Perm. ("Potentially" as in, if we can somehow move it there and keep this algorithm as close to what it is as possible, the corners may not be oriented.)

But you can observe that just by looking at the cube in the above state, if we take the first move and put it at the end of the algorithm
R U R' U' R' F R R U' R' U' R U R' F', it's the same as if we were to first visualize doing the move F' (doing the move that we shifted to the end of the algorithm) *without having to undo it afterwards*. (This is true because we technically applied the setup move F and undid it with F'.)

You can just "trace" the movements of all unsolved pieces this way without even observing the cube after each shift. As long as you observe the cube at one of the possible shifts, then you can "trace" it this way for all possible shifts.


----------



## DNF_Cuber (Jan 19, 2021)

ray5 said:


> Is there a mathematical reason why these algorithms are so similar?
> 
> T perm: R U R' U' R' F R2 U' R' U' R U R' F'
> Y perm: F R U' R' U' R U R' F' R U R' U' R' F R F'
> ...


they are doing an OLL and then another to solve it back again. (Genius science terminology LOL)


----------



## Florentin (May 21, 2021)

I might be a bit late on the subject but I think you can make sense of that cyclic pattern by first understanding how to recreate those PLLs:

To create a Jb perm you basically do a setup move into a pair 3-cycle:
The classic pair 3-cycle algorithm is [U R U' R', d'] (if not convinced see this), if performed on the right side it becomes : [R U R' U', l']
You then do a smart (= that cancels a fair amount of moves) setup move to place the three pairs in the right spots : R U R' F' and you got your Jb perm :
Jb = [R U R' F' : [ R U R' U', l' ] ] U' = (R U R' F') (R U R' U') l' (U R U' R') l (F R U' R') U' = (R U R' F') (R U R' U') R' (F R F' R') R (F R U' R') U' = standard alg

And the T and Y (and Y') can therefore be seen as follows (setup move into Jb perm):
T = [ F R U' R' : Jb ]
Y = [ F R U' R' U' : Jb ]
(Y' = [ R U' R' U' : Jb ])


If you think of it this way the similarity becomes obvious.

If you name your 3 blocks of moves:
A = (R U R' F')
B = (R U R' U' R' F R)
C = (R U' R' U')
and start from: Jb = A B C

You can deduce with the previous construct the cyclic pattern :

T = [ A⁻¹ : Jb ] = [ A⁻¹ : A B C ] = B C A
Jb = A B C
Y' = [ C : Jb ] = [ C : A B C ] = C A B


----------



## Christopher Mowla (May 22, 2021)

Florentin said:


> If you think of it this way the similarity becomes obvious.


The original poster already knew that they looked similar, and he was already aware of conjugation.

You used mathematical constructs to represent the algorithms' decompositions, but a mathematical representation of *what is *does not explain *why* it is possible to write them all that way mathematically to begin with. (That's what he was asking.)

And writing their decompositions was unnecessary. They are all clearly cyclic shifts of each other, and therefore if you choose to express any one of them as a conjugate of some base B then, by definition of cyclic shifts*, *they all can be written as a conjugate of that base B.


----------



## Florentin (May 22, 2021)

The question was literally :


ray5 said:


> Is there a mathematical reason why these algorithms are so similar?



If the question is "why something ?" then the something has to be the conclusion of the reasoning, you can't criticize the fact that my answer ends on that conclusion.

In the same fashion :


Christopher Mowla said:


> And writing their decompositions was unnecessary. They are all clearly cyclic shifts of each other, and therefore if you choose to express any one of them as a conjugate of some base B then, by definition of cyclic shifts*, *they all can be written as a conjugate of that base B.


If you take the fact that they are cyclic shifts of each other as your starting point then I hardly see how you can provide an adequate answer :

- Is there a reason why they are cyclic shifts of each other ?
- Yes because "They are all clearly cyclic shifts of each other".
isn't very satisfying to me.

The answer I provided follows this reasoning :
If I were to recreate intuitively a J, T and Y perm then I could do it so that they are similar in a cyclic fashion.
The fact that they happen to be the standard algorithms is attributed to luck.

Which is very different from the answers provided above :
I can always cycle an algorithm and by chance in that case it gives me useful sequences of moves.

I may not have answered thoroughly the question, but I am still convinced that I gave some elements of understanding that aren't "unnecessary" or without link to the question.


----------



## Christopher Mowla (May 22, 2021)

Florentin said:


> If you take the fact that they are cyclic shifts of each other as your starting point then I hardly see how you can provide an adequate answer :


Yes, that's the point. There is no adequate answer because . . .



Florentin said:


> The answer I provided follows this reasoning :
> If I were to recreate intuitively a J, T and Y perm then I could do it so that they are similar in a cyclic fashion.
> *The fact that they happen to be the standard algorithms is attributed to luck*.


Yes. That's the keyword. LUCK. You can't mathematically describe luck now can you? At least, you *cannot do that by expressing the algorithms in commutator-conjugate notation!*



Florentin said:


> - Is there a reason why they are cyclic shifts of each other ?
> - Yes because "They are all clearly cyclic shifts of each other".
> isn't very satisfying to me.


I agree. But making up an explanation that isn't an explanation doesn't help either. Your post served no other purpose but to show *that you* know how to decompose algorithms (on some level, at least).



Florentin said:


> Which is very different from the answers provided above :
> I can always cycle an algorithm and by chance in that case it gives me useful sequences of moves.


What's wrong with that? Did you miss the fact that by being content with that concept has been very fruitful for finding A LOT of algorithms?



Florentin said:


> I may not have answered thoroughly the question, but I am still convinced that I gave some elements of understanding that aren't "unnecessary" or without link to the question.


Sorry, but again, you have not answered the question at all. Neither have I. There is no answer!

Have you forgotten in that "no solution" is also a possible answer in math?


----------



## qwr (May 22, 2021)

they're standard because they happen to be fingertrickable, which is greatly aided by being RUF gen


----------

