# Enumerating the Conjugacy Classes of the Rubik's Cube Permutation Group



## Lucas Garron (Mar 3, 2010)

So, I'm currently writing a group theory paper on enumerating the conjugacy classes of the cube group. Thought about doing it on showing that every element of the commutator group is a generator, and maybe I should have... 

Anyhow, there is a discussion here, I think. But the server is down, and I was incredibly lucky to think of saving a backup copy: http://archive.garron.us/temp/Conjugacy%20classes%20of%20the%20cube%20|%20Domain%20of%20the%20Cube%20Forum.html

So, in a simple world, we'd just calculate all the possible partitions of 8 and 12, assign each cycle a net parity in all possible ways (so that parity is satisfied), and multiply.

For 8 pieces, 3 orientations, you get {140, 130} positions for {odd, even} permutations.
For 12 pieces, 2 orientations, it's {302, 286}.

So, odd total permutations + even permutations of the entire cube: "140*302+130*286 = 79460."


...except that's wrong.

1) For edges, the totals are apparently {308, 291}. There are 11=IntegerPartitions(6) more permutations with all even-length no-net-twist cycles These only happen once each (index 0 or 1). For corners, nothing happens, by luck.

2) In addition, 10 of the even corner position and 17 of the even edge permutations are "parity-sensitive" and we need to add a category for that.

So we have {140, 130, 10, 0}.{308, 291, 17, 0} = 81120 total classes.

I haven't tried to explain that thoroughly, because it's in the linked thread. But does anyone here understand where these numbers actually come from? It seems like someone just threw in two wrenches before the final sum. After staring at the reasons for a long while, I somewhat understand why they exist, and why they happen to be the way they are. But I don't understand why exactly those two things come up, why they should happen only and exactly the way they do, and why nothing else goes wrong.

Is there some unified general understanding from which these happen to fall into confusing cases?

I'm writing a paper an this, and I don't really like the idea of saying twice "Oh, wait! Let's take a mandatory, confusing detour!" twice, with esoteric reasons for each, and no clean, intuitive motivation for them.


----------



## rokicki (Mar 6, 2010)

*No responses?*

I'm surprised there's no responses to this yet.

It's a tough problem, but one that people have solved on in the past.

Surely someone is giving it a shot?

(I admit to not being able to solve it up until now.)


----------



## Cielo (May 17, 2010)

Still no responses?

Curious to know the answer…


----------



## qqwref (May 17, 2010)

Sounds interesting, but I don't fully understand what's going on here and it seems like most of your numbers are random digits spewed out of a Mathematica calculation. I have no clue where numbers like {140, 130} are coming from, and I can't exactly look at the cycle structures or whatever to see what's up. I suggest looking at the calculation that gives the "wrong" numbers to try to figure out what's wrong about them - if they are too small there must be some specific case not considered, and you can either add that to the function or deal with it separately, but you have to really understand what's going on first. The "parity sensitive" stuff makes no sense to me, unfortunately.


----------



## Sir E Brum (May 17, 2010)

Would you also have to include a value for centers? 
Example of center "parity" would be E2 M E2 M'


----------

