M_R,D Group

If (RL' , D) are the generators for the above calculation then I think the numbers are off. The counts I get diverge after depth 7:

 0         1
 1         4
 2        10
 3        24
 4        58
 5       140
 6       338
 7       816
 8      1965
 9      4732
10     11400
11     27464
12     66020
13    158472
14    379834
15    908890
16   2168266
17   5158400

Completely enumerating the group would be a bit of a challenge. With GAP I calculate the size of the group as: 169,305,292,800. One would need to break up the problem into cosets I'd say.

M_R (or what now is usually referred to as M') moves the inner layer, not the outer layers. It is not the same thing as R L' (or L R'). It does not leave centers fixed.

Unless you count two cube states which differ only in a whole cube rotation as two different states, M_R is equivalent to L R'. They give the same cube state. When modeling the 3x3x3 cube it is desirable to use the center cubies as the frame of reference against which the state of the cube is measured. In such a model the center cubies don't move and a M_R move becomes L R'. In such a model the face turns are defined relative to the center cubies. Label the center cubies U,D,R,L,F,B and no matter how the cube as a whole is turned a D turn always turns the face with the D center cubie. If you conceive of M_R as moving the center cubies then after an M_R move which face do you turn with a following D move? The face which was originally "down", or the face which is down after the M_R move? If the latter then your model will not behave as a mathematical group unless you count a whole cube rotation as giving a different state of the cube.

The move M_R moves four centers with respect to some frame of reference for the cube (as well as moving four edge cubies). The use of the move M_R is incompatible with the notion of using the center cubies as a fixed reference. D M_R D is not the same thing as D L R' D.

M_R is not an element of <U,D,L,R,F,B>, a group which does allow the center cubies to serve as fixed points of reference. M_R is an element of the <U,x,y> group (where x and y are two orthogonal whole cube rotations; the speedsolving community has specific definitions for these). And <M_R, D> most definitely is a group.

You should really think of a group element as describing a way of rearranging the pieces of a puzzle, not the actual states of the puzzle. I think because the <U,D,L,R,F,B> group has such an obvious one-to-one correspondence with the instrinsic states of the cube, people often think of the elements as states instead of the effect of actions. The distinction becomes especially important for puzzles that have identical (indistinguishable) pieces. The states of the puzzle may no longer form a group, but the effect of actions on the puzzle (how the pieces can be moved around) might in many cases still be described by a group. And the use of the angle bracket notation by definition defines a (mathematical) group. (Perhaps the speedsolving community may abuse the notation at times, but the notation comes from mathematics, not cubing.)

The use of the move MR is incompatible with the notion of using the center cubies as a fixed reference. D MR D is not the same thing as D L R' D.

I'll have to take issue with that. They are not incompatible. D Mr D is indeed not the same as D L R' D. Rather it's the same as D L R' B. Same moves, just labeled differently.

I played around with this this afternoon. I added slice turns to the generators of a cube solver of mine. Using the generators ( R , U , F , L , D , B , ( R' L ) , ( U' D ) , (F' B) ) here is the output for superflip:

R U R D B (U D') L' (U D') F (U D') B' D' R' B' D' (R' L) (U D') (R' L) (F B')
R U R D B   Y'   F'   Y'   B   Y'   R' D' F' R' D'    Z     X'     Y'     X'

The solver uses the standard, internal, cube relative reference frame and an isomorphic cube group representation. The first line gives the raw output from the solver as a standard Singmaster turn sequence and the second line gives the sequence transposed to an external, observer based reference system with middle slice turns. X corresponds to Mr, Y to Mu and Z to Mf. I labeled them in this way to emphasize that the slice turns rotate the internal reference frame 90° about the indicated axis. The two turn sequences are the same moves, just labeled differently.

Well, of course, you can convert any <M_R,D> sequence to an equivalent <U,D,L,R,F,B> sequence that produces the same intrinsic state of the cube. Consider M_R D M_R D M_R D M_R D. This can be considered equivalent to L R' B L R' U L R' F L R' D. The four D moves get mapped to the moves B, U, F, and D (itself), respectively. The move "D" (as used in the expression M_R D M_R D M_R D M_R D) now has to be defined in terms of some extra state information in order to do the right thing. So if we want to define M_R as an element of the <U, D, L, R, F, B> group (say L R'), then we are forced to redefine (at least) the notion of what "D" means.

If instead we want to have "D" to continue to have its usual meaning, we will need extra state information to define M_R. If we take "D" to always mean turn the yellow layer clockwise, then we can't define M_R in terms of the moves U, D, L, R, F, and B without extra state information, such as how many D turns have been done. [EDIT: Actually, this doesn't even work. In <M_R,D> sequences, the move D doesn't always move the layer identitified by same color center. So to keep "D" defined as "moving the layer with the yellow center clockwise, we would need to recolor the cube with each M_R move. <U,D,L,R,F,B> has no provision for recoloring centers, so again we have incompatibility.]

If we take "D" as always moving the "bottom" layer clockwise, we still need some sort of extra state information (such as where the centers are with respect to the frame of reference we have chosen for the bottom and other faces). [EDIT: Again, my explanation here is bad. To take "D" as always moving the "bottom" layer of the cube would require applying a cube rotation with each M_R move or redefining what "bottom" means in some way. Either way we are violating the fixed centers of the <U, D, L, R, F, B> group model.]

Hence, anyway you look at it, to define the <M_R,D> group, you need some type of extra state information that was not required for the <U, D, L, R, F, B> group.

Since a model of the <M_R,D> group requires extra state information that was not needed for the <U,D,L,R,F,B> group, and D is obviously part of <U,D,L,R,F,B>, then it makes sense to regard that it is the M_R move that requires the extra state information. This is what I meant in claiming that the move M_R is incompatible with the <U,D,L,R,F,B> group.

You make some very good points. There are subtleties here which I had not considered.

Let me think this through. We have the <U,x,y> group where U is an Up face turn, x is a 90° rotation about the x axis and y is a 90° rotation about the y axis. This group is the product of the cube group and the 24 rotation symmetries. The rotation symmetries form a subgroup of the <U,x,y> group and one can partition the group into cosets of this subgroup. The elements of the cube group may be mapped 1:1 to these cosets. Each coset contains the orientations an element of the cube group can be placed in by the rotation symmetries. This is to say that all the elements of a coset are the same cube state. It doesn't matter how the cube as a whole is turned, the state of the cube is the same.

The set of elements, one from each coset, having the identity orientation form a subgroup of the <U,x,y> group. This is the cube group. Mapped in this way the elements have the properties of a mathematical group. The product of two group elements is an element of the group, the inverse of an element is an element of group, etc. Which is to say that in order for the 4.3 x 10¹⁹states of the cube to behave as the elements of a group they must all be properly oriented.

Now we come to the middle slice turns. The M_R operation and the (L R') operation both give the same cube state but the M_R operation also rotates the cube. In light of the above, M_R and (L R') are elements of the same coset. (L R') is the coset member which is also a member of the cube group. M_R is not a member of the cube group.

This is a subtle but important distinction. Turn sequences composed of normal face turns combine like members of the cube group. Turn sequences incorporating middle slice turns do not. Consider as an example two turn sequences which twist the UFR and URB cubies:

a = R U' L ( U D' ) R' D L' D' L U' ( R L' ) D R' U 
b = R U' L   Y'     B' D F' D' F U'   Z      L B' R 

The second of these incorporates middle slice turns and as it happens also rotates the cube as a whole. Two applications of the first turn sequence impart two twists to the UFR and URB cubies. This is how a cube group element should behave. Two applications of the second turn sequence has a different effect. When the sequence is applied the second time the twist is not applied to the UFR and URB cubies, but rather to the two cubies rotated into the UFR and URB positions by the first application.

So, middle slice turns are not compatible with the cube group treated as a mathematical group. When middle slice turns are involved one is into the realm of a coset space of the <U,x,y> group and the rules are different.

type #1: face style turning of < F B' , R L', U D' >
type #2: slice style where the corners never move and only the edges and centres move.

Now notice with type #2 I never can really do a cube rotation... the corners stay fixed. To my mind I'm not doing two opposite face turns followed by a full cube rotation in space. In both cases I feel like the cube _IS_ fixed in space.

Surely these two groups must also be the same size and isomorphic to each other?

Similarly I think of < M_R, D > as a mathematical group too. GAP says it is... I totally get it's not the same deal as faces turns only, but it is a group right?

Email admin at cubexyz at gmail dot com

If type #2 is the group < M_R , M_U , M_F > then I don't think one gets the whole cube group. This would give one the subgroup of the <U,x,y> group with the identity corner facelet permutation.

An intriguing thought just occured to me. There are alternative schemes for mapping the cube group onto the <U,x,y> group. Rather than picking the rotation coset member with the identity center facelet permutation to represent the cube state, pick the member with the identity UBL facelet permutation. In other words, fix the UBL cubie in place. This would give one an isomorphic representation of the cube group in which the middle slice turns would be members. The U, B, L face turns on the other hand would not be group elements. The < M_R , D > group would then be a subgroup of this representation of the cube group.

Further thoughts appended

1. fixed center:
   < R , U , F , L , D , B >
2. fixed corner:
   < R , U , F , M_R , M_U , M_F > eight variations
3. fixed edge:
   < R , U , F , L , M_U , M_F > twelve variations

Quoting B MacKenzie:

"There are alternative schemes for mapping the cube group onto the <U,x,y> group. Rather than picking the rotation coset member with the identity center facelet permutation to represent the cube state, pick the member with the identity UBL facelet permutation. In other words, fix the UBL cubie in place. This would give one an isomorphic representation of the cube group in which the middle slice turns would be members."

It's easy to see that the "fixed UBL cubie" group can generate all the same "cube states" using generators { U, R, F, (U M_U), (R M_R), (F M_F) }. However, a presentation of the cube group that works for the ordered set of generators { U, R, F, D, L, B } is clearly not going to work for the ordered set of generators { U, R, F, (U M_U), (R M_R), (F M_F) }.

If there exists an isomorphism between the groups, there would need to be a set of 5 generators for the "fixed UBL cubie" group for which a presentation of the cube group that works for generators { U, R, F, D, L } also works for that set of "fixed UBL cubie" group generators. (We could use 6 generators if we want to, but these 5 are sufficient.) I don't see any reason that such a set of 5 generators for the "fixed UBL cubie" group must exist. I'll venture to guess that no such set exists and that therefore there would be no isomorphism between the groups.

My initial reaction to your post was "of course the two groups are isomorphic, they are simply two different ways of describing the same thing." The relationship between the fixed center representation and the fixed corner representation is clearly an intimate one. M_R R is an L' turn except instead of holding the middle right and right slices rigid and turning the left slice, one holds the left slice rigid and turns the middle-right and right slices. Freed of any set reference frame and looking at the relations of cubies one to another the generators for the two representation are exactly the same. And it is demonstrably true that any turn sequence in one representation may be transposed to an equivalent turn sequence in the other which will give the same cube state save for a whole cube rotation.

Be that as it may, when I sat down and tried to demonstrate an isomorphism between the two representations I ran into problems. I would guess that your arguments concerning presentations of the groups would involve demonstrating that the two representations belong to the same abstract group. Here you've gone beyond my depth. At my level of understanding an isomorphism means that there is a one to one mapping of the elements of the two groups and a one to one mapping of their multiplication tables.

The obvious mapping of the elements of one group to the other is by a whole cube rotation. Taking a cube and rotating it until the up center cubie is on top, the right center cubie is to the right and the front center cubie is to the front gives one the fixed center representation. Rotate it until the DBL cubie is properly oriented in the DBL cubicle and you have the fixed corner representation. An isomorphism could be demonstrated if this mapping carries over to the multiplication table. Take three elements in the fixed center group such that:

• a₁ * b₁ = p₁

By applying a rotation to b₁ and p₁ their counterparts in the fixed corner group may be found:

• b₂ = r₁ * b₁
• p₂ = r₂ * p₁

There will be an action in the fixed corner group such that:

• a₂ * b₂ = p₂

Cranking out the algebra:

• a₂ * r₁ * b₁ = r₂ * p₁
• a₂ * r₁ * b₁ = r₂ * a₁ * b₁
• a₂ * r₁ = r₂ * a₁
• a₂ = r₂ * a₁ * r'₁
• a₂ = r₃ * (r₁ * a₁ * r'₁)

So, the bijection fails. The two actions are in general not in the same rotation coset of the <U,x,y> group. One must do a similarity transform with a whole cube rotation to get them in the same coset. So, although I've shown a distinct relationship between the two groups as to how products are formed it falls short of the direct bijection required of an isomorphism. It's an open question whether there might be another mapping of the elements of the two groups which would make the similarity transform go away. If there is I can't see it. Which leaves me very puzzled that two groups so intimately related might not be isomorphic.

I find that the three types of cube groups previously mentioned (fixed centers, fixed corner, fixed edge) can not be isomorphic to one another. The fixed DB edge group has elements of order 2520, so it can not be isomorphic to the fixed centers cube group, for which the maximum order of an element 1260. One such element is U R' U² L' (F M_F). The fixed DLB corner cube group has elements of order 396, while the fixed centers cube group does not. One such element is U R F² (R M_R)² (F M_F). It appears to me that the fixed DLB corner cube group doesn't not have any elements of order 2520, so that would mean it is not isomorphic to the fixed DB edge group either.

I note that the Cayley graphs of these three types of cube groups (if we use the generators that I mentioned previously) will look the same, as long as we ignore the labeling of the edges (arrows) of the graph. But labeling the Cayley graph edges with the appropriate generators can not be done so that we have a 1:1 correspondence of labels between the graphs.

# Using BMacK permutation reps. posted below
MU := (17,22,23,20)(18,21,24,19)(49,54,50,53);
MF := (3,8,15,12)(4,7,16,11)(49,51,50,52);
MR := (1,10,13,6)(2,9,14,5)(51,53,52,54);
FixedCorner := Group(U,F,R,MU,MF,MR);
FixedCenter := Group(U,F,R,D,B,L);

for i in [1..10000] do;
  g := Random(FixedCorner);
  if Order(g) = 396 then Print(g, "\n");
  fi;
od;
# now try with FixedCenter

I didn't think about the fact that superflip would not be in the center of the fixed edge cube group. Since superflip in that group swaps the U and F centers (for instance), then clearly superflip in that group does not commute with U, so it is not in the center.

The number of elements of each order in the fixed center cube group is listed at http://www.jaapsch.net/puzzles/cubic3.htm. That is what I based my assumption on that there are no elements of order 396 in that group.

For a simple way of showing fixed center and fixed corner cube groups are not isomorphic using GAP, how about this?

gap> Size(CommutatorSubgroup(FixedCenter,FixedCenter));
21626001637244928000
gap> Size(CommutatorSubgroup(FixedCorner,FixedCorner));
10813000818622464000

gap> Size(CommutatorFactorGroup(FixedCenter));
2

gap> Size(CommutatorFactorGroup(FixedCorner));
4

In the ordinary cube group i.e. (FixedCentre) the commutators generate all positions with an even corner and edge permutations. Therefore G/[G,G] consists of two elements, namely [G,G] = {even cube perms} and x[G,G] = {odd cube perms}, where x is any odd permutation such as a single quarter face turn.

In the FixedCorner cube group it is also obviously the case that commutators only generate even permutations of all piece types. So corners, edges, and centres all have even permutations. A single face turn changes the corner permutation parity, and a single middle slice turn the centre permutation parity. They both change the edge parity, but the edge parity cannot be changed independently of the other piece parities. Therefore G/[G,G] for G=FixedCorner contains the elements [G,G], x[G,G], y[G,G], and xy[G,G], where x is a single face turn, and y a single middle slice turn.

Jaap
Jaap's Puzzle Page: http://www.jaapsch.net/puzzles/

I'm convinced and I find this amazing. I now have four ways to generate the states of the cube:

1. fixed center cubie (the 27th cubie at cube center):
   < R , U , F , L , D , B >
2. fixed face center cubie:
   < R , U , F , L , D , M_F > six variations
3. fixed edge cubie:
   < R , U , F , L , M_U , M_F > twelve variations
4. fixed corner cubie:
   < R , U , F , M_R , M_U , M_F > eight variations

Consider four imps, "Rubik's demons" if you will. One we sit in a chair at cube center, the second in a chair in a face center cubie, the third in a chair in an edge cubie and the fourth in a chair in a corner cubie. Each numbers the 54 facelets on the surface of the cube and writes down permutations from his perspective describing the 4.3 x 10¹⁹ distinct states of the cube arrived at by turning the faces of the cube. We find that the four sets of permutations, predicated on the same physical system, form not merely four representations of the same underlying group but rather four fundamentally different groups. Pick two cube states and ask what their product is. The four demons will give you four different answers and they will all be right. What is the "cube group"? There are four of them now.

Correction:

Group B above introduces a preferred orientation for one of the center facelets. This gives a group 4 times larger than the "cube group".

Appended:

GAP facelet permutations pertaining to the above. The facelets are numbered in line with the Singmaster-Reid convention (UF UR UB UL DF DR DB DL FR FL BR BL UFR URB UBL ULF DRF DFL DLB DBR) with the center facelets added in the order RLUDFB.

• R := (3,17,11,21)(4,18,12,22)(25,39,46,30)(26,37,47,28)(27,38,48,29);
• U := (1,3,5,7)(2,4,6,8)(25,28,31,34)(26,29,32,35)(27,30,33,36);
• F := (1,20,9,18)(2,19,10,17)(25,35,40,38)(26,36,41,39)(27,34,42,37);
• L := (7,23,15,19)(8,24,16,20)(31,45,40,36)(32,43,41,34)(33,44,42,35);
• D := (9,15,13,11)(10,16,14,12)(37,40,43,46)(38,41,44,47)(39,42,45,48);
• B := (5,22,13,24)(6,21,14,23)(28,48,43,33)(29,46,44,31)(30,47,45,32);

• M_R := (1,10,13,6)(2,9,14,5)(51,53,52,54);
• M_U := (17,22,23,20)(18,21,24,19)(49,54,50,53);
• M_F := (3,8,15,12)(4,7,16,11)(49,51,50,52);

• FixedCenter := Group(R,U,F,L,D,B);
• FixedEdge := Group(R,U,F,L,M_U,M_F);
• FixedCorner := Group(R,U,F,M_R,M_U,M_F);

This discussion made me go and check whether I was careful enough not to say there were isomorphisms between these groups, and indeed I was:

"Some of the groups on this list have in a way already been encountered on the first list. For example the square group <U2, D2, F2, B2, R2, L2> is similar to the groups <U2, F2, R2, D2, Rm2, Fm2> and <U2, R2, F2, Um2, Rm2, Fm2>. Their permutations lead to exactly the same cube positions, even though the puzzle is held in a different orientation."

In making that page I found a non-trivial case of the reverse - two groups that were isomorphic but did not contain the same cube positions. The groups <U, D2, R, F2> = <U, D, R, F2> and <U2, D2, R, F> allow for the same piece permutations and corner orientations. The edge orientations are fixed, but differently in the two groups.

Jaap
Jaap's Puzzle Page: http://www.jaapsch.net/puzzles/

<U,x,y> is a mathematical group but one 24 times larger than the cube group. In the <U,x,y> group the state x and identity are two distinct states whereas in the cube group they are both solved cubes. For the human solver this is not a problem since the two states are easily seen as being identical. And I can see that framing turn sequences in this way could very well make them more "finger friendly". But, in a mathematical model of the cube group it is better that there be a 1 : 1 mapping of the states of the cube and their representations.

I was concerned that in the <M_R,D> group there would be this same ambiguity between the state of the cube and its representation. This concern was unjustified as may be seen from the results above. As cubex points out, the down facelets of the down corner cubies provide the frame of reference which I thought would be missing.

Your mention of puzzles with indistinguishable pieces brings things to mind. I recently put together an optimal cube solver which uses a pruning table listing the depths for all the arrangements of the eight cubies originating on the Up face of the identity cube. These arrangements may be looked upon as the states of a cube puzzle in which the other 12 cubies are indistinguishable since one doesn't care what state they are in. This set of arrangements do not form a mathematical group. I can't see how one would define the inverse of an arrangement or a consistent definition of the product of two arrangements. I was thinking of this set as defining a coset space but then I can't see what subgroup of the cube group they might be cosets of. So, I don't know what I'm dealing with. The pruning table does its job in any event.

After sleeping on it, I've decided that my pruning table is indeed based on a coset space of the cube group. The subgroup used as the basis of the cosets is the subgroup of the cube group with a solved Up face. The cosets are the left cosets of this subgroup defined by:

g<Gu>  

where g is any element of the cube group and <Gu> is the subgroup of the cube group with the up face solved. The elements of each coset are characterized by having the same arrangement of the cubies from the Up face. I would think any permutation puzzle with indistiguishable tokens could be viewed in this way. Solving the puzzle involves taking an arbitrary permutation to a member of the "solved" subgroup of the permutation group.

Ok, I added the center cubies to my model and allowed the MR turns to redefine the D turns to turns of the face turned down by the middle slice turns. My numbers now jive with the database:

Depth whole cube   total    unique     total
 0         1         1         1         1
 1         4         5         4         5
 2        10        15        10        15
 3        24        39        24        39
 4        58        97        58        97
 5       140       237       140       237
 6       338       575       338       575
 7       816      1391       816      1391
 8      1909      3300      1909      3300
 9      4296      7596      4296      7596
10      8893     16489      8893     16489
11     17160     33649     17160     33649
12     28891     62540     28891     62540
13     37996    100536     37996    100536
14     37678    138214     37678    138214
15     27186    165400     27186    165400
16     13051    178451     13051    178451
17      4128    182579      4128    182579
18      1199    183778      1199    183778
19       372    184150       372    184150
20       122    184272       122    184272
21        36    184308        36    184308
22        10    184318        10    184318
23         2    184320         2    184320
24         0    184320         0    184320

The "whole cube" column gives the states at depth counts where two states differing only by a whole cube rotation are counted as two different states. The total of 184,320 is confirmed by GAP. The unique column filters out whole cube rotation duplicates. I am surprised to find that no states are duplicated and the states do form a mathematical group. This begs the question that given an arbitrary state from the group, how does one decide which is the down face? Anyway, here are the antipodal positions.

F' L R D' B' F R F2 L B2 R' D U' F U2
B' D B R' D R' B' F D' B' F L B' U F R' U R'

mrd := Group
((1,4,7,10)(2,5,8,11)(3,6,9,12),(1,13,9,14)(12,15,10,16)(17,18,19,20));
Size (mrd);

M_R D table for QSTM:
Level     |          | SO       | GO       | cumul    | SO cumul | GO cumul |
----------+----------+----------+----------+----------+----------+----------+
    0     |        1 |        1 |        1 |        1 |        1 |        1 | 
    1     |        4 |        3 |        2 |        5 |        4 |        3 | 
    2     |       10 |        6 |        4 |       15 |       10 |        7 | 
    3     |       24 |       14 |        8 |       39 |       24 |       15 | 
    4     |       58 |       32 |       18 |       97 |       56 |       33 | 
    5     |      140 |       73 |       38 |      237 |      129 |       71 | 
    6     |      338 |      174 |       90 |      575 |      303 |      161 | 
    7     |      816 |      416 |      212 |     1391 |      719 |      373 | 
    8     |     1909 |      963 |      487 |     3300 |     1682 |      860 | 
    9     |     4296 |     2161 |     1088 |     7596 |     3843 |     1948 | 
   10     |     8893 |     4463 |     2251 |    16489 |     8306 |     4199 | 
   11     |    17160 |     8602 |     4338 |    33649 |    16908 |     8537 | 
   12     |    28891 |    14501 |     7321 |    62540 |    31409 |    15858 | 
   13     |    37996 |    19100 |     9660 |   100536 |    50509 |    25518 | 
   14     |    37678 |    18962 |     9658 |   138214 |    69471 |    35176 | 
   15     |    27186 |    13738 |     7038 |   165400 |    83209 |    42214 | 
   16     |    13051 |     6645 |     3453 |   178451 |    89854 |    45667 | 
   17     |     4128 |     2128 |     1101 |   182579 |    91982 |    46768 | 
   18     |     1199 |      640 |      352 |   183778 |    92622 |    47120 | 
   19     |      372 |      204 |      116 |   184150 |    92826 |    47236 | 
   20     |      122 |       71 |       40 |   184272 |    92897 |    47276 | 
   21     |       36 |       24 |       14 |   184308 |    92921 |    47290 | 
   22     |       10 |        6 |        5 |   184318 |    92927 |    47295 | 
   23     |        2 |        1 |        1 |   184320 |    92928 |    47296 | 

M_R D table for STM:
Level     |          | SO       | GO       | cumul    | SO cumul | GO cumul |
----------+----------+----------+----------+----------+----------+----------+
    0     |        1 |        1 |        1 |        1 |        1 |        1 | 
    1     |        6 |        5 |        4 |        7 |        6 |        5 | 
    2     |       18 |       12 |        8 |       25 |       18 |       13 | 
    3     |       54 |       33 |       20 |       79 |       51 |       33 | 
    4     |      161 |       89 |       49 |      240 |      140 |       82 | 
    5     |      472 |      251 |      134 |      712 |      391 |      216 | 
    6     |     1346 |      690 |      355 |     2058 |     1081 |      571 | 
    7     |     3523 |     1776 |      898 |     5581 |     2857 |     1469 | 
    8     |     8374 |     4209 |     2126 |    13955 |     7066 |     3595 | 
    9     |    17254 |     8633 |     4356 |    31209 |    15699 |     7951 | 
   10     |    31575 |    15789 |     7984 |    62784 |    31488 |    15935 | 
   11     |    40622 |    20371 |    10343 |   103406 |    51859 |    26278 | 
   12     |    40200 |    20274 |    10324 |   143606 |    72133 |    36602 | 
   13     |    25959 |    13211 |     6713 |   169565 |    85344 |    43315 | 
   14     |    10643 |     5416 |     2783 |   180208 |    90760 |    46098 | 
   15     |     2816 |     1452 |      784 |   183024 |    92212 |    46882 | 
   16     |      882 |      480 |      272 |   183906 |    92692 |    47154 | 
   17     |      320 |      184 |      106 |   184226 |    92876 |    47260 | 
   18     |       80 |       45 |       30 |   184306 |    92921 |    47290 | 
   19     |       12 |        6 |        5 |   184318 |    92927 |    47295 | 
   20     |        2 |        1 |        1 |   184320 |    92928 |    47296 | 

No problem—just plug in the generators and let 'er rip:

C2v Three Face States at Depth
 0         1
 1         6
 2        23
 3        84
 4       309
 5      1136
 6      4176
 7     15320
 8     56151
 9    205718
10    752757
11   2752128
12  10054045

The size of this group is only slightly smaller than the C_3v Three Face Group. It is composed of two more cubies which would make it a larger group save that edge flip is constrained in like manner to the C_2v Two Face Group.