Error in the book discovered

[CubeExplorer]

I was playing around and tried to reproduce some things out of the "Permutation Puzzles" book by Jamie Mulholland. The book is great. But just one thing I could not reproduce: the Example on top of page 237. Whatever I do, I see the corners moving cw and not ccw as in the book ist shown. Here is, what I tried in SAGE:

S48 = SymmetricGroup (48)
R=S48(" (25 ,27 ,32 ,30)(26 ,29 ,31 ,28)(3 ,38 ,43 ,19)(5 ,36 ,45 ,21)(8 ,33 ,48 ,24) ")
L=S48(" (9 ,11 ,16 ,14)(10 ,13 ,15 ,12)(1 ,17 ,41 ,40)(4 ,20 ,44 ,37)(6 ,22 ,46 ,35) ")
U=S48(" (1 ,3 ,8 ,6)(2 ,5 ,7 ,4)(9 ,33 ,25 ,17)(10 ,34 ,26 ,18)(11 ,35 ,27 ,19) ")
D=S48(" (41 ,43 ,48 ,46)(42 ,45 ,47 ,44)(14 ,22 ,30 ,38)(15 ,23 ,31 ,39)(16 ,24 ,32 ,40) ")
F=S48(" (17 ,19 ,24 ,22)(18 ,21 ,23 ,20)(6 ,25 ,43 ,16)(7 ,28 ,42 ,13)(8 ,30 ,41 ,11) ")
B=S48(" (33 ,35 ,40 ,38)(34 ,37 ,39 ,36)(3 ,9 ,46 ,32)(2 ,12 ,47 ,29)(1 ,14 ,48 ,27) ")
Ri=R^-1;Li=L^-1;Ui=U^-1;Di=D^-1;Fi=F^-1;Bi=B^-1
R2=R*R;L2=L*L;U2=U*U;D2=D*D;B2=B*B;F2=F*F
#   Example Book Permutation Puzzles p. 237
a=Fi*Di*F*Ri*D2*R*Fi*D*F
print('#   a =',a)
b=U
print('#   b =',b)
ai=a^-1
print('#   ai =',ai)
bi=Ui
print('#   bi =',bi)
abaibi=a*b*ai*bi
print('#   abaibi =',abaibi)

#   Kommutator [a,b] again:
c=a*b*a^-1*b^-1
print('#   c =',c)
#   expanded to single moves
d=Fi*Di*F*Ri*D2*R*Fi*D*F *U *Fi*Di*F*Ri*Di*Di*R*Fi*D*F *Ui
#   The last line translates to F'D'FR'D2RF'DF U F'D'FR'D'D'RF'DF U' for CE input.
#   Result from Test in CE:
#   R2 F2 R' B' R F2 R' B R'
print('#   d =',d)
#   Test CE
e=R2*F2*Ri*Bi*R*F2*Ri*B*Ri
print('#   e =',e)

#   Results in disjoint cycles notation
#   a = (6,8)(11,19)(13,21)(15,23)(17,25)(20,28)(24,38)(30,48)(32,43)(42,44)
#   b = (1,3,8,6)(2,5,7,4)(9,33,25,17)(10,34,26,18)(11,35,27,19)
#   ai = (6,8)(11,19)(13,21)(15,23)(17,25)(20,28)(24,38)(30,48)(32,43)(42,44)
#   bi = (1,6,8,3)(2,4,7,5)(9,17,25,33)(10,18,26,34)(11,19,27,35)
#   abaibi = (3,8,6)(11,27,19)(17,33,25)
#   c = (3,8,6)(11,27,19)(17,33,25)
#   d = (3,8,6)(11,27,19)(17,33,25)
#   e = (3,8,6)(11,27,19)(17,33,25)
#   Three corners move clockwise, not ccw as the picture in the book shows.

Physically applying the maneuver to a cube shows the same result.

The following pic is a screenshot from the Program Cube Explorer. It also shows the move in the other direction.

Can you confirm or correct me please?

EDIT: Yes, it is a little Error in the book. picture and text dont match.

 

[tsmosher]

Not sure what book you're talking about or anything else. But that is an Ab permutation.

The alg in the picture does not work because it appears to be for an Aa permutation. Both permutations are 3-cycles of corners; one cycles corners clockwise, and the other cycles them counter-clockwise.

You can look up an algorithm for it in a number of places. Here is one example:

Ab - PLL (3x3) Speed Cube Database

Algorithms and fingertricks execution videos for Ab (PLL, 3x3)

speedcubedb.com

From that angle, here is one algorithm that will solve the cube:

U' Lw' R' D2 R U R' D2 R U' Lw (U)

Hope this helps!

 

[CubeExplorer]

Hope this helps!

Sorry no, I am not looking for a solution. I know the solution. I asked a different question and showed in detail, what I tried till now.

I reproduced an algorithm from the book, and it moves the corners in the other direction as shown in the book. The question is: Is it an error in the book or do I miss something?

Thank you anyway for answering. I added the links up there.

 

[xyzzy]

It's a mistake in the book.

 

[Bruce MacKenzie]

I'm not familiar with SAGE but in GAP products are evaluated right to left. A left to right turn sequence, R D, must be entered as the product D * R. Might this be cause of the confusion?

Forget it. I applied the turns in reverse order, U' F D F' R D' D' R' F D' F' U F D F' R D2 R' F D' F', and it's not the inverse of the first.

 

[CubeExplorer]

I'm not familiar with SAGE but in GAP products are evaluated right to left.

Thank you.

In sage, the leftmost move is the move applied first.

S48 = SymmetricGroup (48)
R=S48(" (25 ,27 ,32 ,30)(26 ,29 ,31 ,28)(3 ,38 ,43 ,19)(5 ,36 ,45 ,21)(8 ,33 ,48 ,24) ")
L=S48(" (9 ,11 ,16 ,14)(10 ,13 ,15 ,12)(1 ,17 ,41 ,40)(4 ,20 ,44 ,37)(6 ,22 ,46 ,35) ")
U=S48(" (1 ,3 ,8 ,6)(2 ,5 ,7 ,4)(9 ,33 ,25 ,17)(10 ,34 ,26 ,18)(11 ,35 ,27 ,19) ")
D=S48(" (41 ,43 ,48 ,46)(42 ,45 ,47 ,44)(14 ,22 ,30 ,38)(15 ,23 ,31 ,39)(16 ,24 ,32 ,40) ")
F=S48(" (17 ,19 ,24 ,22)(18 ,21 ,23 ,20)(6 ,25 ,43 ,16)(7 ,28 ,42 ,13)(8 ,30 ,41 ,11) ")
B=S48(" (33 ,35 ,40 ,38)(34 ,37 ,39 ,36)(3 ,9 ,46 ,32)(2 ,12 ,47 ,29)(1 ,14 ,48 ,27) ")
Ri=R^-1;Li=L^-1;Ui=U^-1;Di=D^-1;Fi=F^-1;Bi=B^-1
R2=R*R;L2=L*L;U2=U*U;D2=D*D;B2=B*B;F2=F*F
rubikscube=CubeGroup();
print("clear:");rubikscube.display2d('')#   clear
t=R*U
print('t=R*U')
print("t =", t)
print("order(t) =", order(t))
print("t:");rubikscube.display2d(t)
m1=RubiksCube().move(t);m1.show()

===>

clear:
             +--------------+
             |  1    2    3 |
             |  4   top   5 |
             |  6    7    8 |
+------------+--------------+-------------+------------+
|  9  10  11 | 17   18   19 | 25   26  27 | 33  34  35 |
| 12 left 13 | 20  front 21 | 28 right 29 | 36 rear 37 |
| 14  15  16 | 22   23   24 | 30   31  32 | 38  39  40 |
+------------+--------------+-------------+------------+
             | 41   42   43 |
             | 44 bottom 45 |
             | 46   47   48 |
             +--------------+

t=R*U
t = (1,3,38,43,11,35,27,32,30,17,9,33,48,24,6)(2,5,36,45,21,7,4)(8,25,19)(10,34,26,29,31,28,18)
order(t) = 105
t:
             +--------------+
             |  3    5   38 |
             |  2   top  36 |
             |  1    4   25 |
+------------+--------------+-------------+------------+
| 33  34  35 |  9   10    8 | 19   29  32 | 48  26  27 |
| 12 left 13 | 20  front  7 | 18 right 31 | 45 rear 37 |
| 14  15  16 | 22   23    6 | 17   28  30 | 43  39  40 |
+------------+--------------+-------------+------------+
             | 41   42   11 |
             | 44 bottom 21 |
             | 46   47   24 |
             +--------------+

 

[Bruce MacKenzie]

Thank you.

In sage, the leftmost move is the move applied first.

S48 = SymmetricGroup (48)
R=S48(" (25 ,27 ,32 ,30)(26 ,29 ,31 ,28)(3 ,38 ,43 ,19)(5 ,36 ,45 ,21)(8 ,33 ,48 ,24) ")
L=S48(" (9 ,11 ,16 ,14)(10 ,13 ,15 ,12)(1 ,17 ,41 ,40)(4 ,20 ,44 ,37)(6 ,22 ,46 ,35) ")
U=S48(" (1 ,3 ,8 ,6)(2 ,5 ,7 ,4)(9 ,33 ,25 ,17)(10 ,34 ,26 ,18)(11 ,35 ,27 ,19) ")
D=S48(" (41 ,43 ,48 ,46)(42 ,45 ,47 ,44)(14 ,22 ,30 ,38)(15 ,23 ,31 ,39)(16 ,24 ,32 ,40) ")
F=S48(" (17 ,19 ,24 ,22)(18 ,21 ,23 ,20)(6 ,25 ,43 ,16)(7 ,28 ,42 ,13)(8 ,30 ,41 ,11) ")
B=S48(" (33 ,35 ,40 ,38)(34 ,37 ,39 ,36)(3 ,9 ,46 ,32)(2 ,12 ,47 ,29)(1 ,14 ,48 ,27) ")
Ri=R^-1;Li=L^-1;Ui=U^-1;Di=D^-1;Fi=F^-1;Bi=B^-1
R2=R*R;L2=L*L;U2=U*U;D2=D*D;B2=B*B;F2=F*F
rubikscube=CubeGroup();
print("clear:");rubikscube.display2d('')#   clear
t=R*U
print('t=R*U')
print("t =", t)
print("order(t) =", order(t))
print("t:");rubikscube.display2d(t)
m1=RubiksCube().move(t);m1.show()

===>

clear:
             +--------------+
             |  1    2    3 |
             |  4   top   5 |
             |  6    7    8 |
+------------+--------------+-------------+------------+
|  9  10  11 | 17   18   19 | 25   26  27 | 33  34  35 |
| 12 left 13 | 20  front 21 | 28 right 29 | 36 rear 37 |
| 14  15  16 | 22   23   24 | 30   31  32 | 38  39  40 |
+------------+--------------+-------------+------------+
             | 41   42   43 |
             | 44 bottom 45 |
             | 46   47   48 |
             +--------------+

t=R*U
t = (1,3,38,43,11,35,27,32,30,17,9,33,48,24,6)(2,5,36,45,21,7,4)(8,25,19)(10,34,26,29,31,28,18)
order(t) = 105
t:
             +--------------+
             |  3    5   38 |
             |  2   top  36 |
             |  1    4   25 |
+------------+--------------+-------------+------------+
| 33  34  35 |  9   10    8 | 19   29  32 | 48  26  27 |
| 12 left 13 | 20  front  7 | 18 right 31 | 45 rear 37 |
| 14  15  16 | 22   23    6 | 17   28  30 | 43  39  40 |
+------------+--------------+-------------+------------+
             | 41   42   11 |
             | 44 bottom 21 |
             | 46   47   24 |
             +--------------+

Huh? Your product R*U is actually given by the turn sequence U' R'. U is clockwise, U' is anti-clockwise. First the U' turn moves the 3 facelet to the 1 position, then the R' turn moves the 38 facelet to the 3 position.

I was playing around and tried to reproduce some things out of the "Permutation Puzzles" book by Jamie Mulholland. The book is great. But just one thing I could not reproduce: the Example on top of page 237. Whatever I do, I see the corners moving cw and not ccw as in the book ist shown. Here is, what I tried in SAGE:

S48 = SymmetricGroup (48)
R=S48(" (25 ,27 ,32 ,30)(26 ,29 ,31 ,28)(3 ,38 ,43 ,19)(5 ,36 ,45 ,21)(8 ,33 ,48 ,24) ")
L=S48(" (9 ,11 ,16 ,14)(10 ,13 ,15 ,12)(1 ,17 ,41 ,40)(4 ,20 ,44 ,37)(6 ,22 ,46 ,35) ")
U=S48(" (1 ,3 ,8 ,6)(2 ,5 ,7 ,4)(9 ,33 ,25 ,17)(10 ,34 ,26 ,18)(11 ,35 ,27 ,19) ")
D=S48(" (41 ,43 ,48 ,46)(42 ,45 ,47 ,44)(14 ,22 ,30 ,38)(15 ,23 ,31 ,39)(16 ,24 ,32 ,40) ")
F=S48(" (17 ,19 ,24 ,22)(18 ,21 ,23 ,20)(6 ,25 ,43 ,16)(7 ,28 ,42 ,13)(8 ,30 ,41 ,11) ")
B=S48(" (33 ,35 ,40 ,38)(34 ,37 ,39 ,36)(3 ,9 ,46 ,32)(2 ,12 ,47 ,29)(1 ,14 ,48 ,27) ")
Ri=R^-1;Li=L^-1;Ui=U^-1;Di=D^-1;Fi=F^-1;Bi=B^-1
R2=R*R;L2=L*L;U2=U*U;D2=D*D;B2=B*B;F2=F*F
#   Example Book Permutation Puzzles p. 237
a=Fi*Di*F*Ri*D2*R*Fi*D*F
print('#   a =',a)
b=U
print('#   b =',b)
ai=a^-1
print('#   ai =',ai)
bi=Ui
print('#   bi =',bi)
abaibi=a*b*ai*bi
print('#   abaibi =',abaibi)

#   Kommutator [a,b] again:
c=a*b*a^-1*b^-1
print('#   c =',c)
#   expanded to single moves
d=Fi*Di*F*Ri*D2*R*Fi*D*F *U *Fi*Di*F*Ri*Di*Di*R*Fi*D*F *Ui
#   The last line translates to F'D'FR'D2RF'DF U F'D'FR'D'D'RF'DF U' for CE input.
#   Result from Test in CE:
#   R2 F2 R' B' R F2 R' B R'
print('#   d =',d)
#   Test CE
e=R2*F2*Ri*Bi*R*F2*Ri*B*Ri
print('#   e =',e)

#   Results in disjoint cycles notation
#   a = (6,8)(11,19)(13,21)(15,23)(17,25)(20,28)(24,38)(30,48)(32,43)(42,44)
#   b = (1,3,8,6)(2,5,7,4)(9,33,25,17)(10,34,26,18)(11,35,27,19)
#   ai = (6,8)(11,19)(13,21)(15,23)(17,25)(20,28)(24,38)(30,48)(32,43)(42,44)
#   bi = (1,6,8,3)(2,4,7,5)(9,17,25,33)(10,18,26,34)(11,19,27,35)
#   abaibi = (3,8,6)(11,27,19)(17,33,25)
#   c = (3,8,6)(11,27,19)(17,33,25)
#   d = (3,8,6)(11,27,19)(17,33,25)
#   e = (3,8,6)(11,27,19)(17,33,25)
#   Three corners move clockwise, not ccw as the picture in the book shows.

Physically applying the maneuver to a cube shows the same result.

The following pic is a screenshot from the Program Cube Explorer. It also shows the move in the other direction.

View attachment 17337

Can you confirm or correct me please?

In light of the discussion below, I think your face turns are defined as their inverses and Sage performs the multiplication in right to left order. So, your calculation gives the inverse of what it should.

 

[CubeExplorer]

I think your face turns are defined as their inverses and Sage performs the multiplication in right to left order.

When I put the following into sage ....

S48 = SymmetricGroup (48)
R=S48(" (25 ,27 ,32 ,30)(26 ,29 ,31 ,28)(3 ,38 ,43 ,19)(5 ,36 ,45 ,21)(8 ,33 ,48 ,24) ")
L=S48(" (9 ,11 ,16 ,14)(10 ,13 ,15 ,12)(1 ,17 ,41 ,40)(4 ,20 ,44 ,37)(6 ,22 ,46 ,35) ")
U=S48(" (1 ,3 ,8 ,6)(2 ,5 ,7 ,4)(9 ,33 ,25 ,17)(10 ,34 ,26 ,18)(11 ,35 ,27 ,19) ")
D=S48(" (41 ,43 ,48 ,46)(42 ,45 ,47 ,44)(14 ,22 ,30 ,38)(15 ,23 ,31 ,39)(16 ,24 ,32 ,40) ")
F=S48(" (17 ,19 ,24 ,22)(18 ,21 ,23 ,20)(6 ,25 ,43 ,16)(7 ,28 ,42 ,13)(8 ,30 ,41 ,11) ")
B=S48(" (33 ,35 ,40 ,38)(34 ,37 ,39 ,36)(3 ,9 ,46 ,32)(2 ,12 ,47 ,29)(1 ,14 ,48 ,27) ")
Ri=R^-1;Li=L^-1;Ui=U^-1;Di=D^-1;Fi=F^-1;Bi=B^-1
R2=R*R;L2=L*L;U2=U*U;D2=D*D;B2=B*B;F2=F*F
rubikscube=CubeGroup();
m0=RubiksCube().move(R*Ri);m0.show()
m2=RubiksCube().move(R*U);m2.show()

... I get the following result in sage. https://sagecell.sagemath.org/



It does not seem to support, what your are thinking about sage. At least I think so .
Executing the movements from right to left does not show this result, regardless of doing the single movements in foreward or in inverted direction.

My mechanical cube in the real world shows exactly the same result.

 

[Bruce MacKenzie]

When I put the following into sage ....

S48 = SymmetricGroup (48)
R=S48(" (25 ,27 ,32 ,30)(26 ,29 ,31 ,28)(3 ,38 ,43 ,19)(5 ,36 ,45 ,21)(8 ,33 ,48 ,24) ")
L=S48(" (9 ,11 ,16 ,14)(10 ,13 ,15 ,12)(1 ,17 ,41 ,40)(4 ,20 ,44 ,37)(6 ,22 ,46 ,35) ")
U=S48(" (1 ,3 ,8 ,6)(2 ,5 ,7 ,4)(9 ,33 ,25 ,17)(10 ,34 ,26 ,18)(11 ,35 ,27 ,19) ")
D=S48(" (41 ,43 ,48 ,46)(42 ,45 ,47 ,44)(14 ,22 ,30 ,38)(15 ,23 ,31 ,39)(16 ,24 ,32 ,40) ")
F=S48(" (17 ,19 ,24 ,22)(18 ,21 ,23 ,20)(6 ,25 ,43 ,16)(7 ,28 ,42 ,13)(8 ,30 ,41 ,11) ")
B=S48(" (33 ,35 ,40 ,38)(34 ,37 ,39 ,36)(3 ,9 ,46 ,32)(2 ,12 ,47 ,29)(1 ,14 ,48 ,27) ")
Ri=R^-1;Li=L^-1;Ui=U^-1;Di=D^-1;Fi=F^-1;Bi=B^-1
R2=R*R;L2=L*L;U2=U*U;D2=D*D;B2=B*B;F2=F*F
rubikscube=CubeGroup();
m0=RubiksCube().move(R*Ri);m0.show()
m2=RubiksCube().move(R*U);m2.show()

... I get the following result in sage. https://sagecell.sagemath.org/

View attachment 17463

It does not seem to support, what your are thinking about sage. At least I think so .
Executing the movements from right to left does not show this result, regardless of doing the single movements in foreward or in inverted direction.

My mechanical cube in the real world shows exactly the same result.

That does look correct. However, that doesn't match the permutation you showed earlier:

t=R*U
t = (1,3,38,43,11,35,27,32,30,17,9,33,48,24,6)(2,5,36,45,21,7,4)(8,25,19)(10,34,26,29,31,28,18)
order(t) = 105
t:
+--------------+
| 3 5 38 |
| 2 top 36 |
| 1 4 25 |
+------------+--------------+-------------+------------+
| 33 34 35 | 9 10 8 | 19 29 32 | 48 26 27 |
| 12 left 13 | 20 front 7 | 18 right 31 | 45 rear 37 |
| 14 15 16 | 22 23 6 | 17 28 30 | 43 39 40 |
+------------+--------------+-------------+------------+
| 41 42 11 |
| 44 bottom 21 |
| 46 47 24 |
+--------------+

Facelet 38 in the 3 position for example comes from the back yellow face but the 3 position is purple above. Facelet 1 in the 6 position is purple but the 6 position is red above. t = R*U and move(R*U) seem to give different permutations.


Addendum
I am pretty sure that the sense of rotation of your face turn generators is wrong.

I had a look at the book you're following and found Mulholland's treatment of cycle notation on page 51 confused and misleading. He discusses the permutation:

Position 1 2 3 4 5
permutation 2 3 4 5 1

and gives the correct cycle representation.

(1 2 3 4 5)

This should be read as: The element in position 2 goes to position 1, the element in position 3 goes to position 2, the element in position 4 goes to position 3, the element in position 5 goes to position 4 and the element in position 1 goes to position 5. This corresponds to the written out permutation.

Mulholland says to read it as: "1 goes to 2, 2 goes to 3, 3 goes to 4, 4 goes to 5, and 5 goes to 1." This as well as the arrows in his diagrams implies that the elements are swapped around in the opposite sense. i.e element 1 goes to position 2, etc. Which is not correct. His cycle-arrow form looks like the elements are swapped around in a clockwise direction when the permutation actually swaps them around in an anti-clockwise direction.

Addendum

On further thought, there are two ways to interpret a permutation as specifying an arrangement of objects: a position based permutation and an object based permutation. A position based permutation lists the objects in order of position. Which book is in each position going in order left to right on a bookshelf say. An object based permutation lists which position each object is in.

Position 1 2 3 4 5
permutation 2 3 4 5 1

Position based: object 2 is in position 1, object 3 is in position 2 ...

object 1 2 3 4 5
permutation 2 3 4 5 1

Object based: position 2 holds object 1, position 3 holds object 2, position 4 holds object 3 ...

Mulholland's discussion makes more sense if one interprets the permutation as object based rather than position based. I don't know if he makes that distinction in the previous discussion. Scanning through it, the examples I saw were all position based.

When using permutations to represent something like the Cube one must take care to know which type of permutation one is using.

One thing, given a position based permutation, its inverse is the same arrangement represented as an object based permutation.

 

[xyzzy]

Set aside thinking of permutations as rearrangements for a second, and just treat a permutation as a bijective function from a set to itself.
\( S_X:=\{\pi:X\to X\text{ bijective}\} \)

The group operation here is the usual function composition: \( \sigma\tau:=\sigma\circ\tau \). (Or more explicitly, define \( (\sigma\tau):X\to X \) as \( (\sigma\tau)(x):=\sigma(\tau(x)) \) for all \( x\in X \).)

WARNING: Some sources (notably, GAP) use the opposite operation, with the group operation instead being \( \sigma\tau:=\tau\circ\sigma \). This is still a group (it's the opposite group), and there's an isomorphism between a group and its opposite given by taking each element to its inverse.

The usual way cycle notation is defined is that if \( \pi=(a_0,a_1,a_2,a_3,\cdots,a_{k-1}) \), then we have
\( \pi(a_i)=a_{(i+1)\mod k} \) and
\( \pi(x)=x \) if \( x\notin\{a_0,\cdots,a_{k-1}\} \).

------

There are multiple ways of interpreting the abstract definition of a permutation group (given above) as rearrangements and vice versa.

position	A	B	C	D	E	F	G
object	F	C	G	E	D	A	B

position	F	G	B	E	D	A	C
object	A	B	C	D	E	F	G

As it doesn't matter how we swap the columns around, these tables still define the same arrangement. From this, we get two functions: one that takes the position and tells you what object is there (call this \( \alpha \)); one that takes the object and tells you where it is (call this \( \beta \)).

\( \alpha(A):=F,\alpha(B):=C,\alpha(C):=G,\alpha(D):=E,\alpha(E):=D,\alpha(F):=A,\alpha(G):=B \)
\( \beta(A):=F,\beta(B):=G,\beta(C):=B,\beta(D):=E,\beta(E):=D,\beta(F):=A,\beta(G):=C \)

Written in cycle notation, we have \( \alpha=(A,F)(D,E)(B,C,G) \) and \( \beta=(A,F)(D,E)(B,G,C) \).

The position-to-object convention (like \( \alpha \)) works directly with right actions. If the initial position-to-object map is given by \( f \), then applying the rearrangement corresponding to the permutation \( \alpha \) results in the final position-to-object map \( f\circ\alpha \).

A cycle notation of \( (a,b,c,d,e) \) means that the object at \( a \) moves to \( e \), the object at \( b \) moves to \( a \), etc. Applying a rearrangement \( \alpha_1 \) then another rearrangement \( \alpha_2 \) is equivalent to applying the rearrangement \( \alpha_1\alpha_2 \) (i.e. read left to right).

(Notably, this works even if \( f \) is not itself a permutation! It just needs the domain to be the same. This is convenient when describing puzzles with identical pieces, e.g. big cubes, or the first phase of Kociemba.)

The object-to-position convention (like \( \beta \)) works directly with left actions. If the initial object-to-position map is given by \( g \), then applying the rearrangement corresponding to the permutation \( \beta \) results in the final object-to-position map \( \beta\circ g \).

A cycle notation of \( (a,b,c,d,e) \) means that the object at \( a \) moves to \( b \), the object at \( b \) moves to \( c \), etc. Applying a rearrangement \( \beta_1 \) then another rearrangement \( \beta_2 \) is equivalent to applying the rearrangement \( \beta_2\beta_1 \) (i.e. read right to left).

------

Now, if we're using GAP's weirdo opposite convention, then the position-to-object convention now leads to a left action, since \( f\circ\alpha=\alpha f \); sequences of rearrangements are read right to left.

Conversely, the object-to-position convention leads to a right action, since \( \beta\circ g=g\beta \); sequences of rearrangements are read left to right.

 

[Bruce MacKenzie]

Set aside thinking of permutations as rearrangements for a second, and just treat a permutation as a bijective function from a set to itself.
\( S_X:=\{\pi:X\to X\text{ bijective}\} \)

The group operation here is the usual function composition: \( \sigma\tau:=\sigma\circ\tau \). (Or more explicitly, define \( (\sigma\tau):X\to X \) as \( (\sigma\tau)(x):=\sigma(\tau(x)) \) for all \( x\in X \).)

WARNING: Some sources (notably, GAP) use the opposite operation, with the group operation instead being \( \sigma\tau:=\tau\circ\sigma \). This is still a group (it's the opposite group), and there's an isomorphism between a group and its opposite given by taking each element to its inverse.

The usual way cycle notation is defined is that if \( \pi=(a_0,a_1,a_2,a_3,\cdots,a_{k-1}) \), then we have
\( \pi(a_i)=a_{(i+1)\mod k} \) and
\( \pi(x)=x \) if \( x\notin\{a_0,\cdots,a_{k-1}\} \).

------

There are multiple ways of interpreting the abstract definition of a permutation group (given above) as rearrangements and vice versa.

position	A	B	C	D	E	F	G
object	F	C	G	E	D	A	B

position	F	G	B	E	D	A	C
object	A	B	C	D	E	F	G

As it doesn't matter how we swap the columns around, these tables still define the same arrangement. From this, we get two functions: one that takes the position and tells you what object is there (call this \( \alpha \)); one that takes the object and tells you where it is (call this \( \beta \)).

\( \alpha(A):=F,\alpha(B):=C,\alpha(C):=G,\alpha(D):=E,\alpha(E):=D,\alpha(F):=A,\alpha(G):=B \)
\( \beta(A):=F,\beta(B):=G,\beta(C):=B,\beta(D):=E,\beta(E):=D,\beta(F):=A,\beta(G):=C \)

Written in cycle notation, we have \( \alpha=(A,F)(D,E)(B,C,G) \) and \( \beta=(A,F)(D,E)(B,G,C) \).

The position-to-object convention (like \( \alpha \)) works directly with right actions. If the initial position-to-object map is given by \( f \), then applying the rearrangement corresponding to the permutation \( \alpha \) results in the final position-to-object map \( f\circ\alpha \).

A cycle notation of \( (a,b,c,d,e) \) means that the object at \( a \) moves to \( e \), the object at \( b \) moves to \( a \), etc. Applying a rearrangement \( \alpha_1 \) then another rearrangement \( \alpha_2 \) is equivalent to applying the rearrangement \( \alpha_1\alpha_2 \) (i.e. read left to right).

(Notably, this works even if \( f \) is not itself a permutation! It just needs the domain to be the same. This is convenient when describing puzzles with identical pieces, e.g. big cubes, or the first phase of Kociemba.)

The object-to-position convention (like \( \beta \)) works directly with left actions. If the initial object-to-position map is given by \( g \), then applying the rearrangement corresponding to the permutation \( \beta \) results in the final object-to-position map \( \beta\circ g \).

A cycle notation of \( (a,b,c,d,e) \) means that the object at \( a \) moves to \( b \), the object at \( b \) moves to \( c \), etc. Applying a rearrangement \( \beta_1 \) then another rearrangement \( \beta_2 \) is equivalent to applying the rearrangement \( \beta_2\beta_1 \) (i.e. read right to left).

------

Now, if we're using GAP's weirdo opposite convention, then the position-to-object convention now leads to a left action, since \( f\circ\alpha=\alpha f \); sequences of rearrangements are read right to left.

Conversely, the object-to-position convention leads to a right action, since \( \beta\circ g=g\beta \); sequences of rearrangements are read left to right.

I agree that it doesn't matter whether one represents cube states as position based or object based. You get the same group using the same algorithm for permutation multiplication. There is a one to one mapping of the two through the inversion operation. However it becomes important when one translates the permutation representation into the physical arrangement of the facelets on the cube and visa versa. In most of the work I've done with the cube I have used a Cubie based representation. Kociemba and Rockiki use a Cubical based representation. It doesn't matter. You get the same answers as long as you keep things straight.

Every book I've read on group theory uses the convention that group multiplication is defined as

[action] * [state]

The turn sequence U R applies a R action to the cube in the state given by an U turn.
So [R] * [U] follows the standard convention.

 

[CubeExplorer]

Some seperate topics appeared in this thread.

Jamie Mulholland wrote in in his book:

Warning: Notice that the composition is opposite to the way functions were combined in
calculus. In calculus, and in most branches of mathematics, there is a long standing tradition that
variables are to appear to the right of the function: f (x). The composition, ( f g)(x) is then read
from right-to-left: f (g(x)). So why are we defining the composition of permutations as left-to-right,
and going against long standing mathematical tradition? Imagine you were asked to apply the move
sequence RF^-1 to a Rubik’s cube. What move would you do first, R or F^-1? Popular convention is
to read from left-to-right and apply R first, then F^-1. For example, this is how you are reading the
words on the page right now, from left-to-right. This is precisely the convention we are using to
combine permutations, we combine them from left-to-right.

Thats a fact and I do not judge it, when I use the book. I read the sequence of multiplying permutations in his book from left to right.

The next one is the behaviour of sage math.

cg=CubeGroup();
normcolors=[(1,1,0),(0,0,1),(1,0,0),(0,1,0),(1,0.6,0.3),(.9,.9,.9)]
cg.plot_cube("", colors=normcolors).show()
cg.plot_cube("R*U", colors=normcolors).show()

===>>

As we can see, sage did execute the multiplication form left to right. Good to know when reading output of sage.

So finally it can be seen clearly, that there is an little error in the book. Text and picture dont match:

S48 = SymmetricGroup (48)
R=S48(" (25 ,27 ,32 ,30)(26 ,29 ,31 ,28)(3 ,38 ,43 ,19)(5 ,36 ,45 ,21)(8 ,33 ,48 ,24) ")
L=S48(" (9 ,11 ,16 ,14)(10 ,13 ,15 ,12)(1 ,17 ,41 ,40)(4 ,20 ,44 ,37)(6 ,22 ,46 ,35) ")
U=S48(" (1 ,3 ,8 ,6)(2 ,5 ,7 ,4)(9 ,33 ,25 ,17)(10 ,34 ,26 ,18)(11 ,35 ,27 ,19) ")
D=S48(" (41 ,43 ,48 ,46)(42 ,45 ,47 ,44)(14 ,22 ,30 ,38)(15 ,23 ,31 ,39)(16 ,24 ,32 ,40) ")
F=S48(" (17 ,19 ,24 ,22)(18 ,21 ,23 ,20)(6 ,25 ,43 ,16)(7 ,28 ,42 ,13)(8 ,30 ,41 ,11) ")
B=S48(" (33 ,35 ,40 ,38)(34 ,37 ,39 ,36)(3 ,9 ,46 ,32)(2 ,12 ,47 ,29)(1 ,14 ,48 ,27) ")
Ri=R^-1;Li=L^-1;Ui=U^-1;Di=D^-1;Fi=F^-1;Bi=B^-1
R2=R*R;L2=L*L;U2=U*U;D2=D*D;B2=B*B;F2=F*F
#   Example Book Permutation Puzzles p. 237
a=Fi*Di*F*Ri*D2*R*Fi*D*F
print('#   a =',a)
b=U
print('#   b =',b)
ai=a^-1
print('#   ai =',ai)
bi=Ui
print('#   bi =',bi)
abaibi=a*b*ai*bi
print('#   abaibi =',abaibi)

#   Kommutator [a,b] again:
c=a*b*a^-1*b^-1
print('#   c =',c)
#   expanded to single moves
d=Fi*Di*F*Ri*D2*R*Fi*D*F *U *Fi*Di*F*Ri*Di*Di*R*Fi*D*F *Ui
##########################################################
print('#   d =',d)
cg=CubeGroup();
normcolors=[(1,1,0),(0,0,1),(1,0,0),(0,1,0),(1,0.6,0.3),(.9,.9,.9)]
cg.plot_cube(d, colors=normcolors).show()

I hope the picture output is more clear now:

The three corners are moved clockwise.

 

[Bruce MacKenzie]

Some thoughts on the right to left convention for group element composition. I was introduced to group theory through point group symmetry. A point group is a group of geometric transforms which will map a set of (x,y,z) points back on itself. The set of points is invariant by the operation of the elements of the symmetry point group. The elements of a point group are best represented as 3x3 geometric transform matrixes and their composition is by matrix multiplication. The order of the operands in the composition of two matrix elements is dictated by the rules of matrix multiplication. If you rotate a set of points 90˚ about the X axis then 90˚ about the Y axis the proper composition of the matrixes is:


\[ \left ( \begin{matrix} 0 & 0 & -1 \\ 0 & 1 & 0 \\ 1 & 0 & 0 \end{matrix} \right ) *\left ( \begin{matrix} 1 & 0 & 0 \\ 0 & 0 & 1 \\ 0 & -1 & 0 \end{matrix} \right )= \left ( \begin{matrix} 0 & 1 & 0 \\ 0 & 0 & 1 \\ 1 & 0 & 0 \end{matrix} \right ) *\left ( \begin{matrix} R \\ U \\ F \end{matrix} \right ) =\left ( \begin{matrix} U \\ F \\ R \end{matrix} \right ) \]
\[ {C4}_{y} * {C4}_{x} = {C3}_{x,y,z} \]

This results in a 120˚ rotation about the (1,1,1) vector. The right operand is the first rotation and the left is the second. Done in the opposite order:

\[ \left ( \begin{matrix} 1 & 0 & 0 \\ 0 & 0 & 1 \\ 0 & -1 & 0 \end{matrix} \right ) *\left ( \begin{matrix} 0 & 0 & -1 \\ 0 & 1 & 0 \\ 1 & 0 & 0 \end{matrix} \right ) =\left ( \begin{matrix} 0 & 0 & -1 \\ 1 & 0 & 0 \\ 0 & -1 & 0 \end{matrix} \right ) *\left ( \begin{matrix} R \\ U \\ F \end{matrix} \right ) = \left ( \begin{matrix} -F \\ R \\ -U \end{matrix} \right ) \]
\[ {C4}_{x} * {C4}_{y} = {C3}_{x,y,-z} \]

This results in a 120˚ rotation about a different axis, the (1,1,-1) vector.

Performed on the set of points comprising the Cube:

With the Right face on the X axis, the Up face on the Y axis and the Front face on the Z axis, the (1,1,1) axis vector comes out of the UFR corner. A 120˚cw rotation about this axis rotates the yellow Up face onto the Right face, the blue Front face onto the Up face, and the orange Right face onto the Front face. This result is given by the first matrix equation where the rotation matrixes are combined in right to left order. Done in the wrong order and the rotation is about the URB vector and gives the wrong result.

I think matrix groups were important in the early development of group theory and matrix multiplication is the origin of the right to left convention.


Addendum

While I'm playing around with the equation editor I thought I would give my definition for the composition of two permutations.

\[ ({a}_{1} , {a}_{2} , {a}_{3} • • • {a}_{n}) * ({b}_{1} , {b}_{2} , {b}_{3} • • • {b}_{n}) = ({c}_{1} , {c}_{2} , {c}_{3} • • • {c}_{n}) \]

\[ {c}_{i} = {b}_{{a}_{i}} \]

This follows the paradigm of [action] * [state]. A is treated as a recipe for reordering the B list. The order is again reversed: B is applied first, then A. I don't know if there is any consensus on this. I looked around on my bookshelf and all I found is in Humphrey's "A Course in Group Theory". On page 12 he constructs the multiplication table for the S3 permutation group and it looks like he's doing the composition opposite to the above.

One very good rationale for my definition is that permutations may be represented by matrixes. For example the S3 permutation group may be represented as the closure of the group generated by these two 3x3 matrixes.

\[ \left ( \begin{matrix} 1 & 0 & 0 \\ 0 & 0 & 1 \\ 0 & 1 & 0 \end{matrix} \right )* \left ( \begin{matrix} 1 \\ 2 \\ 3 \end{matrix} \right ) = \left ( \begin{matrix} 1 \\ 3 \\ 2 \end{matrix} \right ) \]

\[ \left ( \begin{matrix} 0 & 1 & 0 \\ 0 & 0 & 1 \\ 1 & 0 & 0 \end{matrix} \right )* \left ( \begin{matrix} 1 \\ 2 \\ 3 \end{matrix} \right ) = \left ( \begin{matrix} 2 \\ 3 \\ 1 \end{matrix} \right ) \]

Represented as matrixes the right to left precedence is required by the rules of matrix multiplication. It makes sense for the precedence rule for the two representations to be the same.

 

[CubeExplorer]

At the present time I will not switch between conventions or between definitions. As long, as I am using Jamie Mulhollands book and sage math, I will use their conventions. Pros and cons of the different viewpoints are beyond the topic of this thread and I do not comment them here.

Independently of the conventions the cube shows the following behavior in the real world:

 

[Bruce MacKenzie]

I've looked it over and as I see it Mulholland is a bit messed up. On page 38 he defines permutation composition as:

(α ◦β )(k) = β (α(k)), for k ∈[n]

Apply this definition to the product, A*B, of these permutations (not in cycle notation):

A = (2,3,1)
B = (1,3,2)

A(1) = 2
C(1) = B( A(1) ) = B(2) = 3

A(2) = 3
C(2) = B(3) = 2

A(3) = 1;
C(3) = B(1) = 1

A * B = (2,3,1) * (1,3,2) = (3,2,1)

similarly

B * A = (2,1,3)

This is in fact how SAGE composits A * B which you may confirm. Mulholland goes on to say that this definition means that A is applied first, then B. Here he is dead wrong.

Take a list:

Apple(1), Pear(2) , Orange(3)

Apply permutation A, which rolls the three to the left

Pear(2) , Orange(3), Apple(1)

Then apply permutation B which swaps what's in positions 2 and 3

Pear(2) , Apple(1), Orange(3) = (2,1,3)

The result of first performing A followed by B is not given by A * B but rather by the product B * A. So, SAGE actually performs permutation multiplication right to left.

So how does Mulholland get away with evaluating turn sequence left to right rather than right to left as they should be with SAGE's definition of permutation multiplication? First he defines his face turns as their inverses. Take an U turn for example which rotates the facets around in a clockwise manner. The Up facet permutation should be (1,6,8,3)(2,4,7,5):

\[ \begin{pmatrix}1&2&3\\4&X&5\\6&7&8\end{pmatrix}\xrightarrow U\begin{pmatrix}6&4&1\\7&e&2\\8&5&3\end{pmatrix} \]

But in his definition of U it is the anti-clockwise rotation (1 ,3 ,8 ,6)(2 ,5 ,7 ,4):
\[ \begin{pmatrix}3&5&8\\2&X&7\\1&4&6\end{pmatrix} \]

(Now this wrong only if one uses a position based coordinating definition. As position based this last permutation places the 3 sticker in the 1 slot. As object based it is reversed: the 1 sticker is in the 3 slot. Whether position based or object based the permutations are applied in reverse order: A * B means apply B first and then A.)

So when Sage evaluates R * U the result is really for the sequence U' R' (position based). The inverse of what it ought to be. Then when he plots out the colored graphical representation he takes the inverse again by interpreting the permutation as object based.

Bottom line: In Sage (and GAP) the product A * B gives the product found by first applying B then A. If one's coordinating definition is position based (which is the more natural way IMO), then the turn sequence R U should be entered as U * R. i.e. apply R first then U. If one's coordinating definition is object based then R U should be entered as R * U since applying U first and then R is correct in the backward world of object based permutations.