From mreid@ptc.com Sat Jan 14 17:07:00 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA28724; Sat, 14 Jan 95 17:07:00 EST Received: from ducie.ptc.com by ptc.com (5.0/SMI-SVR4-NN) id AA14825; Sat, 14 Jan 95 17:05:36 EST Received: by ducie.ptc.com (1.38.193.4/sendmail.28-May-87) id AA27289; Sat, 14 Jan 1995 17:18:30 -0500 Date: Sat, 14 Jan 1995 17:18:30 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9501142218.AA27289@ducie.ptc.com> To: cube-lovers@ai.mit.edu Subject: more on superflip Content-Length: 3294 recently i said: > when searching for superflip in the face turn metric, it's > sufficient to search through depth 17 in stage 1! since posting this, i've realized that we can do much better. here's my current approach. everything below refers to the face turn metric. (i have similar reductions for quarter turns, but they're not quite as good.) proposition 1. there is a minimal sequence for superflip of the form sequence_1 sequence_2 where sequence_1 is in stage 1, sequence_2 is in stage 2, and sequence_1 is at most 17f long. proof. consider the different possibilities for the length of a minimal sequence for superflip: 20f, 19f, 18f, 17f or less. in the first case, we already know a maneuver of the form. in the second case, my discussion on thursday shows that we'll have such a maneuver. in the case of 18f , we may suppose that the last face turned is U , so we'll have such a maneuver. and in the last case, we may take sequence_2 to be the empty sequence. this proves prop. 1. proposition 2. there is a minimal sequence for superflip of the form R1 sequence_1 sequence_2 where sequence_1 is in stage 1, sequence_2 is in stage 2, and sequence_1 is at most 16f long. proof. consider the maneuver given by prop. 1. by applying one of the 16 symmetries that fix the U - D axis, we may suppose that the first turn of sequence_1 is either U1, U2, R1, or R2. in the case of U1 sequence_1 sequence_2, replace this by sequence_1 sequence_2 U1, and try again. handle the cases starting with U2 and R2 similarly. we will either exhaust the stage 1 part of the sequence (which is impossible, since superflip isn't in the subgroup of stage 2) or we'll wind up with a manuever starting with R1 , as desired. this proves prop. 2. there's still some more symmetry left to exploit. proposition 3. there is a minimal sequence for superflip of one of the forms R1 F1 sequence_1 sequence_2, R1 F2 sequence_1 sequence_2, R1 F3 sequence_1 sequence_2, R1 U1 sequence_1 sequence_2, R1 U2 sequence_1 sequence_2, R1 U3 sequence_1 sequence_2, R1 L1 sequence_1 sequence_2, or R1 L3 sequence_1 sequence_2, where sequence_1 is in stage 1, sequence_2 is in stage 2, and sequence_1 is at most 15f long. proof. by applying the symmetry C_R2 if necessary, we may suppose that the second turn of the maneuver given by prop. 2 is one of F1, F2, F3, U1, U2, U3, L1, L2 or L3. this gives nine cases. in the case R1 L2 sequence_1 sequence_2, replace this by R1 sequence_1 sequence_2 L2 and try again. this proves prop. 3. i have these cases running right now, and i hope to have results soon! mike From mschoene@math.rwth-aachen.de Sat Jan 14 19:20:51 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA03767; Sat, 14 Jan 95 19:20:51 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rTIfA-000MP6C; Sun, 15 Jan 95 01:17 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rTIf9-00025cC; Sun, 15 Jan 95 01:17 WET Message-Id: Date: Sun, 15 Jan 95 01:17 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu, ishius@ishius.com In-Reply-To: der Mouse's message of Tue, 10 Jan 1995 18:14:15 -0500 <199501102314.SAA10516@Collatz.McRCIM.McGill.EDU> Subject: Re: Difficulty of Skewb Der Mouse wrote in his e-mail message of 1995/01/10 The size of the thing is thus somewhere on the order of 500 million configurations. This is why I called it trivial next to the 3x3x3. :-) The group structure in terms of facicles, for what's-his-name to sic GAP on should he care to, derived from the following facicle labeling Of course ``what's-his-name'' couldn't resist ;-). Here are my findings about the SKEWB. The SKEWB Puzzle ================ I took the liberty to renumber the points. This makes the orbits easier recognizable. up +----------+ | 9 10 | | 27 | left | 12 11 | right back +----------+----------+----------+----------+ | 5 6 | 18 17 | 1 2 | 22 21 | | 26 | 29 | 25 | 30 | | 8 7 | 19 20 | 4 3 | 23 24 | +----------+----------+----------+----------+ | 13 14 | | 28 | | 16 15 | +----------+ down I call the 8 possible turns LUB, LUF, RUB, RUF, LDB, LDF, RDB, RDB. Here LUB denotes the turn around the corner common to the L(eft), U(p), and B(ack) faces that turns L to U, U to B, and B back to L. Those turns all have order 3, and I denote the inverses with ^-1 (at least there is no question which metric to use for the SKEWB ;-). With respect to the above numbering, the generators are the following permutations. ## corner other corners centers RUF := ( 1,11,17) ( 2,12,20)( 4,10,18)(22, 6,14) (25,27,29); RUB := ( 2,10,22) ( 1, 9,23)( 3,11,21)(17, 5,15) (25,27,30); LUF := ( 6,12,18) ( 5,11,19)( 7, 9,17)(21, 1,13) (26,27,29); LUB := ( 5, 9,21) ( 6,10,24)( 8,12,22)(18, 2,16) (26,27,30); RDF := ( 4,14,20) ( 1,15,19)( 3,13,17)( 7,11,23) (25,28,29); RDB := ( 3,15,23) ( 2,14,24)( 4,16,22)( 8,10,20) (25,28,30); LDF := ( 7,13,19) ( 6,16,20)( 8,14,18)( 4,12,24) (26,28,29); LDB := ( 8,16,24) ( 5,13,23)( 7,15,21)( 3, 9,19) (26,28,30); With r, u, and f I denote the 3 rotations of the rigid cube, which generate the full automorphism group of the cube. Here r means the rotation around the axis going through the r and l faces, turning the r face in clockwise direction. ## corners opposite centers r := ( 1, 2, 3, 4) ( 6, 5, 8, 7) (27,30,28,29) (11,22,15,20)(12,21,16,19)(10,23,14,17)( 9,24,13,18); u := ( 9,10,11,12) (16,15,14,13) (30,25,29,26) (22, 1,18, 5)(23, 4,19, 8)(21, 2,17, 6)(24, 3,20, 7); f := (17,20,19,18) (21,22,23,24) (25,28,26,27) ( 1,14, 7,12)( 2,15, 8, 9)( 3,16, 5,10)( 4,13, 6,11); Let G be the group generated by the 8 turns; G = < LUB, LUF, RUB, RUF, LDB, LDF, RDB, RDF >. Let C be the group generated by the 3 rotations; C = < r, u, f >. Obviously |C| = 24 and C ~ S_4. Let C' be the derived subgroup of C; C' = . Obviously |C'| = 12 and C' ~ A_4. Then the group CG = < C, G > is the set of all positions a puzzler could observate. There are 24 solved position in CG (solved up to rotations). The group CG has size 2 * 6!/2 * ((3^4*4!/2) * (3^4*4!/2) / 3^2). The group G has size 6!/2 * ((3^4*4!/2) * (3^4*4!/2) / 3^2) (and is a normal subgroup of CG, since |CG/G| = 2). Note that this implies that |C G| = 12. This is not suprising, since G obviously contains all the commutators: Comm(u,f) = LUB * RDF, Comm(r,u) = LUF * RDB, Comm(f,r) = RUB * LDF, Comm(u,f^-1) = RUF * LDB, (those are the rotations of the entire cube around the 4 diagonals), and so G must contain the derived subgroup C' of C. The numbers imply that of the 6! * 3^8 * 8! position one can obtain by taking the puzzle apart and randomly reassembling it, only ~ 0.04% are solvable. Much less than the ~ 8.3% one gets for Rubik's cube. If you choose to puzzle that way, it is certainly a lot more difficult than Rubik's cube ;-). The Structure of the SKEWB Group ================================ G has three orbits on [1..30]. Namely the six face centers F = [25..30], the odd corners C1 = [1,3..23], and the even corners C2 = [2,4..24]. C shall denote the set of all corners, i.e., the union of C1 and C2. The two orbits on the corners are the two tetrahedral sets of corners mentioned by der Mouse. Let G[F] be the operation of G on the faces centers, i.e., G[F] = G/G_F, where G_F is the stabilizer in G of the face centers (the subgroup of those elements of G that fix all face centers). Let G[C] be the operation of G on the corners, i.e., G[C] = G/G_C, where G_C is the stabilizer in G of the corners. As usual with the operation of a group on several orbits, the stabilizers are normal subgroups, and they intersect trivially. On the other hand the size of G_C is 6!/2 and the size of G_F is (3^4*4!/2 * 3^4*4!/2)/3^2. So |G|=|G_C||G_F| and we see that G is the direct product of G_C and G_F. What that means puzzle-wise is that there are no dependencies between the operations on the faces and corners. So take any achivable position x[F] of the faces and any achivable position y[C] of the corners. Then there is a position z that has simultaineously z[F] = x[F] and z[C] = y[C] (in the case of Rubik's cube this is not possible, you can flip a single edge if you ignore what happens at the corners, but you cannot combine this flip of a single edge with a trivial operation on the corners). So we can fully understand the structure of G simply by understanding the structures of G_C and G_F. Of course we can also analyse G[F] and G[C], since the isomorphism theorem tells us that G_C ~ G[F] and G_F ~ G[C]. Obviously G[F] is simply the alternating group A_6. That means we can achieve any even permutation on the center faces. This is not suprising. All 8 generators effect 3-cylces on the center faces. And with 8 3-cycles, one expects the full alternating group to pop up. G[C] has the 2 orbits C1 and C2. Clearly G[C1] and G[C2] are isomorphic. G[C1] is the wreath product of the cyclic group C_3 and the alternating group A_4. That means you can twist each corner independently and achieve any even permutation on the four corners. That you can only achieve even permutations is obvious, since all generators of G[C] permute 3 corners in a 3-cycle. So |G[C1]| = |G[C2]| = 3^4*4!/2. Now G[C] is the subdirect product of G[C1] and G[C1]. That means it is isomorphic to a subgroup of the direct product of G[C1] and G[C2]. It is a subgroup of index 9. That means |G[C]| = |G[C1]| |G[C2]| / 9 = (3^4*4!/2 * 3^4*4!/2) / 3^2. G[C] is the subgroup of G[C1] * G[C2] of those permutations where each (anti)clockwise twist of a corner in C1 is combined with a (anti)clockwise 3-cycle of corners in C2 and each (anti)clockwise twist of a corner in C2 is combined with a (anti)clockwise 3-cycle of corners in C1. This was the most surprising observation for me, so allow me to talk a little bit more about this aspect. The subdirect product G[C] is a product where we ``glue'' together a common factor group of G[C1] and G[C2]. Now this common factor group is the direct product C_3*C_3 of two cyclic groups of size 3. One of them, K say, comes from the normal subgroup C_3^4 of those elements that only twist the corners. The other, L say, comes from the alternating group A_4. Now those factor groups are glued together crosswise, that is, K of G[C1] is glued to L of G[C2], and L of G[C1] is glued to K of G[C2]. In case anybody cares, G has trivial center. This is because the central elements of G[C1] must be combined in G[C] with non-central elements of G[C2] and vice versa. And of course G[F] has trivial center. The Normal Subgroups of the SKEWB Group ======================================= I have also computed the lattice of normal subgroups of the SKEWB group. Since the group is so small, I don't need any complicated argument. G is a little bit too large to simply try 'NormalSubgroups(G);' in GAP. But G[F] and G[C] are both small enough. G[F] is almost trivial (GAP finds in a few seconds that G[F] has no proper normal subgroups). G[C] is a little bit more difficult (but it took me much longer to draw a reasonable picture, then it took GAP to compute the normal subgroups). Anyhow, allow me to first present the normal subgroups lattice of G[C1], which is of course identical to the normal subgroups lattice of G[C2]. G[C1] (972) //|\ / / | \ L1 L2 L3 K[C1] (324) \ \ | / \ \\|/ \ (108) G[C1]' \ \ V[C1] (81) \ / \ \ / \ (27) W[C1] \ \ \ \ \ \ \ \ Z[C1] (3) \ / \ / <1> Here V[C1] is elementary abelian subgroup (the vector space) of those 3^4 elements of G[C1] that only twist the corners, but do not permute them. G[C1]/V[C1] is the A_4 permuting the corners. K[C1]/V[C1] is the subgroup of G[C1]/V[C1] of the double transpositions, i.e, the elements that permute the corners in two pairs of two corners each. G[C1]' is the derived subgroup of G[C1], i.e., G[C1]/G[C1]' is the largest abelian factor group of G[C1] (b.t.w. note that the fact that G is a direct product implies that G[C1]' = G'[C1]). L1, L2, and L3 are three more normal subgroups of index 3, which I don't know how to describe easily. Z[C1] is the center of G[C1]. And now the lattice of normal subgroups of G[C]. G[C] (104976) //|\ / / | \ L1 L2 L3 K[C] (34992) \ \ | / \_ \\|/ | \ (11664) G[C]' \ \ \_ V1 V2 (8748) | \ / X \ \ X / \ \ (2916) W1 W2 \ \ / X \ \ \ |_/ \ \ \ \ / \ \ \ \ (729) W[C] \ \ \ \ \ \ \ \ \ \ \ \ Z1 Z2 (324) \ \ \ / / \_ \ X / | \ S1 S2 (108) \ \ / / \ \ / / \ X / T1 T2 (27) / / / / / / |_/ / / / / <1> S1 and S2 are the stabilizers G[C]_C1 and G[C]_C2, so the normal subgroup lattices above S1 and S2 are identical to the normal subgroup lattices of G[C1] (= G[C2]). Those two lattices over S1 and S2 share the normal subgroups over G[C]' (this is where G[C1] and G[C2] are glued together). W[C] (the intersection of W1 and W2) is the elementary abelian subgroups (the vectorspace) of those elements of G[C] that only twist the 8 corners, but do not permute them. G[C]/W[C] is the A_4*A_4 permuting the two sets of corners. G[C]' is the derived subgroup of G[C], i.e., G[C]/G[C]' is the largest abelian subgroup of G[C]. Now we get the normal subgroup lattice of G by taking the above picture twice, once below G_F (because G_F ~ G[C]), and once above G_C (because G/G_C ~ G[C]). G_______ //|\ \ LLL K \ D \ \ \ VV \ WW \\ G_F W \\ \\ //|\ \ \\ ZZ LLL K \\ SS D \ TT \ VV // WW \\ / W \\ \\ G_C \ \\ ZZ \ \\ SS \ TT \ // \_______ / <1> God's algorithm for the SKEWB ============================= The next was to compute God's algorithm for the SKEWB. G is not very large, but is is easier to use a smaller model. Let H be the subgroup generated by the 4 turns LUB, LUF, RUB, and RUF. Repeated application of the rules -> , LDB -> Comm(u,f^-1) * RUF^-1, LDF -> Comm(f,r) * RUB^-1, RDB -> Comm(r,u) * LUF^-1, RDF -> Comm(u,f) * LUB^-1, allows us to translate any process in CG to one that starts with a single rotation and continues with a process in H, i.e., it starts with a rotation and continues with a process that involves only LUB, LUF, RUB, and RUF and their inverses. Note however, that H is *not* a supplement for C in CG. This is because the intersection of H and C is not trivial. Namely H contains d^2, i.e., the rotation by 180 degree around the axis through the down face (which is fixed by H) and the up face. That means that H contains 2 solved positions, and each position of H contains to 12 positions of CG. In other word H has index 12 in CG. Here is the table for H. The first column contains the lenght. The second column contains the number of positions of that length in H. The third column contains the number of positions of that length that are local maxima, i.e., the number of positions such that for no generator the position * is longer. The fourth column contains the number of positions such that for one generator the position * is longer. And so on. So the eleventh column contains the number of positions such that for all eight generators * is longer (this happens of course only for the 2 solutions). length #pos #loc max 0 2 0 0 0 0 0 0 0 0 2 1 16 0 0 0 0 0 0 16 0 0 2 96 0 0 0 0 0 0 96 0 0 3 576 0 0 0 0 0 0 576 0 0 4 3456 0 0 0 0 0 240 3216 0 0 5 20496 0 0 0 48 729 2766 16953 0 0 6 118608 48 161 1231 4228 14779 32993 65168 0 0 7 630396 8266 33358 76349 121363 153892 137755 99413 0 0 8 2450966 1025322 621763 381098 234661 128570 47822 11730 0 0 9 2911712 2768641 126056 15344 1422 199 50 0 0 0 10 162056 161876 180 0 0 0 0 0 0 0 11 180 180 0 0 0 0 0 0 0 0 To get the table for CG, simply multiply each number by 12. This was computed with a small C program in 200 seconds on a Pentium 90 system using approx 16 MByte of memory. Since this is my first computation of this kind, I would be glad if somebody could independently verify this table. The SuperSKEWB ============== If we do not ignore the orientation of the face centers we obtain the SuperSKEWB. This could for example be done by drawing a line over one corner and the center for each face of the cube. Mathematically I modelled the SuperSKEWB by representing each face center with a set of four numbers (instead of a single number). That pushed the total number of moved points from 30 to 48 (still pretty small). The size of the SuperSKEWB group SG is a factor 32 greater than G's size, i.e., it is (2^5*6!/2) * ((3^4*4!/2) * (3^4*4!/2) / 3^2). The size of CSG (closure of C and SG) is also a factor 32 greater than CG's size, i.e., it is 2*(2^5*6!/2) * ((3^4*4!/2) * (3^4*4!/2) / 3^2). It is easy to see that you cannot turn a face center by 90 degrees in SG. Namely the corner pieces fall into two tetrahedral sets, which are not interchanged by SG. Now a given edge of a face center will always be adjacent to corners in one of those two sets of corner pieces. Simply by looking at the generators of SG, we see that each element of SG must turn an even number of face centers. So we can turn at most five of the six face centers independently; after that the orientation of the sixth face center is determined. So there are at most 2^5 different orientations possible. Since |SG| = 2^5 |G|, we see that all 2^5 orientations are indeed achievable. The structure of SG is of course very similar to the structure of G. SG[C] is identical to G[C]. Remember that G[F] was A_6. SG[F] is a subgroup of index 2 in the wreath product 2 A_6. The index 2 is because one cannot turn a single face. Note that SG has a nontrivial center, namely the element that turns all face centers at once. Thus the lattice of normal subgroups of SG is very similar to the lattice of G. The only difference is that SG_C (and of course also SG/SG_F) has two nontrivial normal subgroups with sizes 32 and 2 (resp. with sizes 32*104976 and 2*104976). I cannot compute God's algorithm for the SuperSKEWB. Would I use the same approach that I used for the SKEWB, I would need 32 times as much memory, i.e., ~ 1/2 GByte. Does anybody have an idea how to tackle the SuperSKEWB (provided anybody cares, I certainly don't)? Have a nice day. Martin. PS: No, I don't own a SKEWB. Yes, I intent to order one. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From mreid@ptc.com Wed Jan 18 10:02:03 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA20530; Wed, 18 Jan 95 10:02:03 EST Received: from ducie.ptc.com by ptc.com (5.0/SMI-SVR4-NN) id AA06914; Wed, 18 Jan 95 10:00:38 EST Received: by ducie.ptc.com (1.38.193.4/sendmail.28-May-87) id AA00811; Wed, 18 Jan 1995 10:13:45 -0500 Date: Wed, 18 Jan 1995 10:13:45 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9501181513.AA00811@ducie.ptc.com> To: cube-lovers@ai.mit.edu Subject: superflip requires 20 face turns Content-Length: 3124 superflip is now known to require 20 face turns. in particular, the diameter of the cube group is at least 20 face turns (and i conjecture that it's larger). as far as i can tell, this is the first improvement to the lower bound (18f) given by a simple counting argument. in my previous two messages, i gave a proof of the fact that there is a minimal sequence for superflip in one of the following forms: R1 F1 sequence_1 sequence_2, R1 F2 sequence_1 sequence_2, R1 F3 sequence_1 sequence_2, R1 U1 sequence_1 sequence_2, R1 U2 sequence_1 sequence_2, R1 U3 sequence_1 sequence_2, R1 L1 sequence_1 sequence_2, or R1 L3 sequence_1 sequence_2, where sequence_2 is in the subgroup of stage 2 of kociemba's algorithm, and sequence_1 is at most 15f long. as of monday morning, the first six cases were completely searched, but the final two seemed to be much slower. fortunately, there is more symmetry available here (which is at least part of the reason that these cases are so slow). in the case starting with R1 L1, we have four symmetries (generated by C_R2 and C_U2) which fix the subgroup of stage 2. using these symmetries, we may suppose that the third face turn is one of U1, U2, U3, F1, F2 or F3. in the case starting with R1 L3, we again have four symmetries which fix the subgroup of stage 2. in this case, the symmetries are generated by C_R2 and reflection through the R - L plane. using these symmetries, we may suppose that the third face turn is one of U1, U2, F1 or F2. even with these reductions, the last two cases are still somewhat stubborn. finally they were completed this morning. here's a summary of what i tested: position tested: depth tested superflip R1 F1: 15f deep in stage 1 best solution found: 15 + 3 = 18f superflip R1 F2: 15f deep in stage 1 best solution found: 15 + 3 = 18f superflip R1 F3: 15f deep in stage 1 best solution found: 15 + 3 = 18f superflip R1 U1: 15f deep in stage 1 best solution found: 11 + 8 = 19f superflip R1 U2: 15f deep in stage 1 best solution found: 13 + 5 = 18f superflip R1 U3: 15f deep in stage 1 best solution found: 12 + 7 = 19f superflip R1 L1 U1: 14f deep in stage 1 best solution found: 11 + 7 = 18f superflip R1 L1 U2: 14f deep in stage 1 best solution found: 10 + 7 = 17f superflip R1 L1 U3: 14f deep in stage 1 best solution found: 11 + 7 = 18f superflip R1 L1 F1: 14f deep in stage 1 best solution found: 12 + 5 = 17f superflip R1 L1 F2: 14f deep in stage 1 best solution found: 10 + 8 = 18f superflip R1 L1 F3: 14f deep in stage 1 best solution found: 12 + 5 = 17f superflip R1 L3 U1: 14f deep in stage 1 best solution found: 14 + 3 = 17f superflip R1 L3 U2: 14f deep in stage 1 best solution found: 10 + 8 = 18f superflip R1 L3 F1: 14f deep in stage 1 best solution found: 12 + 5 = 17f superflip R1 L3 F2: 14f deep in stage 1 best solution found: 13 + 5 = 18f total run time was about 210 cpu hours (somewhat more than i'd hoped for) distributed across several machines of varying ability. mike From mreid@ptc.com Wed Jan 18 10:39:55 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA22619; Wed, 18 Jan 95 10:39:55 EST Received: from ducie.ptc.com by ptc.com (5.0/SMI-SVR4-NN) id AA07119; Wed, 18 Jan 95 10:38:31 EST Received: by ducie.ptc.com (1.38.193.4/sendmail.28-May-87) id AA00837; Wed, 18 Jan 1995 10:51:39 -0500 Date: Wed, 18 Jan 1995 10:51:39 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9501181551.AA00837@ducie.ptc.com> To: cube-lovers@ai.mit.edu Subject: searching for superflip in quarter turn metric Content-Length: 3083 here's my approach to searching for superflip in the quarter turn metric. i gave a maneuver of length 24q for superflip on january 10. suppose there is a maneuver of length 22q (or shorter). consider three cases: case 1. there is a minimal maneuver which contains a half-turn. case 2. no minimal maneuver contains a half-turn, but there is a minimal maneuver which contains consecutive turns of opposite faces. case 3. neither case 1 nor case 2 hold. in case 1, we may find a minimal sequence of the form sequence_1 sequence_2, where sequence_2 is at least 3q long. as in the face turn metric, we may also suppose that sequence_1 starts with one of R1 F1, R1 F2, R1 F3, R1 U1, R1 U2, R1 U3, R1 L1 U1, R1 L1 U2, R1 L1 U3, R1 L1 F1, R1 L1 F2, R1 L1 F3, R1 L3 U1, R1 L3 U2, R1 L3 F1, R1 L3 F2. furthermore, the case starting with R1 F2 may be included in the case starting with R1 F1, and similarly for other cases. thus we may suppose that sequence_1 starts with one of R1 F1, R1 F3, R1 U1, R1 U3, R1 L1 U1, R1 L1 U3, R1 L1 F1, R1 L1 F3, R1 L3 U1, R1 L3 F1. in case 2, we may find a minimal sequence of the form sequence_1 sequence_2, where sequence_2 is at least 2q long. as in case 1, we may suppose that sequence_1 starts with one of the ten sequences above. in case 3, the best we can do is 1q in stage 2. however, i claim that we can find three consecutive turns of mutual adjacent faces. otherwise, we'd have a maneuver for superflip using only the four faces F, R, B, L, (for example) which is ridiculous, because edges can't change orientation using only these turns. therefore, we may suppose that a minimal sequence starts with three consecutive turns of mutual adjacent faces. up to symmetry, there are eight cases for these turns: U1 R1 F1, U1 R1 F3, U3 R1 F1, U3 R1 F3, D1 R1 F1, D1 R1 F3, D3 R1 F1, D3 R1 F3. replace U1 R1 F1 sequence by R1 F1 sequence U1 , and similarly for the other seven cases. thus we have a minimal maneuver in the form sequence_1 sequence_2 , where sequence_2 is 1q long and sequence_1 starts with either R1 F1 or R1 F3. combining all the above cases, a maneuver for superflip in 22q or less (assuming one exists) may be found in one of the forms: R1 L1 U1 sequence_1 sequence_2, R1 L1 U3 sequence_1 sequence_2, R1 L1 F1 sequence_1 sequence_2, R1 L1 F3 sequence_1 sequence_2, R1 L3 U1 sequence_1 sequence_2, R1 L3 F1 sequence_1 sequence_2, where sequence_1 is at most 17q long, R1 U1 sequence_1 sequence_2, R1 U3 sequence_1 sequence_2, where sequence_1 is at most 18q long, R1 F1 sequence_1 sequence_2, R1 F3 sequence_1 sequence_2, where sequence_1 is at most 19q long. i don't know how feasible this is (but it sure looks formidable). to get some idea, first i'll test for 20q or less. mike From BRYAN@wvnvm.wvnet.edu Wed Jan 18 11:54:12 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27651; Wed, 18 Jan 95 11:54:12 EST Message-Id: <9501181654.AA27651@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 5427; Wed, 18 Jan 95 11:53:36 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 7576; Wed, 18 Jan 1995 11:53:35 -0500 X-Acknowledge-To: Date: Wed, 18 Jan 1995 11:53:21 EST From: "Jerry Bryan" To: Subject: Re: Re: Models for the Cube In-Reply-To: Message of 12/10/94 at 15:12:00 from , Martin.Schoenert@math.rwth-aachen.de Both the original note and the reply were rather lengthy, so I will not quote the whole thing. We were at the point where we were discussing models for cubes with edges only. Such a cube can be modeled as a set of cosets of C, or as a subset of G or of CG. We arrived at the following dialog which discussed the correspondence between the two kinds of models. On 12/10/94 at 15:12:00 Martin Schoenert said: >Jerry continued > A similar argument applies to G[E]/C[E] except that we have to fix > an edge cubie instead of a corner cubie. >Almost. But there is a tricky problem here. Again G[E] = CG[E], >so it doesn't matter whether we talk about G[E]/C[E] (as you prefer) >or about CG[E]/C[E] (as I prefer). Again we can find a supplement >for C[E] in CG[E], namely the subgroup of all elements of CG[E] >that leave a particular edge cubie fixed. Assume that we fix the >upper-right edge cubie, then this supplement is . >But this does *not* respect costs. That is take an element e of CG[E]. >Let r be its representative in , i.e., c e = r, >where c is a rotation of the entire cube. The the costs of the two >elements, viewed as elements of CG[E] is clearly the same (remember, >rotations cost nothing). But the cost of r, viewed as an element of > *with this generating system*, may be higher. Indeed, *is* higher a large percentage of the time, I think. >For example take R[E] * r[E]' (where r is the rotation of the entire >cube). In CG[E] this element has cost 1. And this element lies in >, since it fixes the upper-right edge cubie. >But the cost of this element *with respect to the generating system >L[E],D[E],F[E],B[E]* is not 1. >We can repair this by choosing a different generating system for >, for example the system >L[E],D[E],F[E],B[E],R[E]*r[E]',U[E]*u[E]'. >So in general a model for the solution up to rotations for a >certain set , is a supplement of C[] in CG[], >with a generating system that respects costs. I guess I need to understand a little more precisely what we mean by "respecting costs", but I have a question here. I was thinking about this issue of representing edges only cubes by cosets vs. representing edges only cubes as subsets of G before your note arrived, and I thought I saw a problem. It is well known that G[E] must have an equal number of even and odd permutations. If we generate G[E] as , it is also the case that there are just as many positions an even distance from Start as an odd distance from Start because the parity of the distance from Start is the same as the parity of the permutation if we restrict ourselves to quarter turns. But in the computer search for God's Algorithm for edges only cubes, there were not equal numbers of positions an even distance from Start as an odd distance from Start. The computer search used the coset model G[E]/C[E], where this notation means the set of cosets of C, *not* the factor group. In and of itself, the mismatch between the number of positions at an even distance from Start and at an odd distance from Start should not pose a problem. It is not clear to me what it means to speak of the "parity" of a coset of C, and half of each coset will be even and the other half will be odd. Hence, it is not clear that a particular coset must *a priori* be an odd or even distance from Start. But if we map each coset to an element of G[E], it is meaningful to speak of the parity of the element of G[E]. And if the elements of G[E] to which we map the cosets form a subgroup, then there must be an equal number of odd and even elements in the subgroup (unless they are all even?!). If the mapping respects costs in the sense of maintaining the same distance from Start, then I don't understand how we can avoid a conflict between the equal number of even and odd permutations in the subgroup of G[E] and the unequal number of even and odd distances from Start in the coset model G[E]/C[E]. Perhaps you could clarify your generating system and its respecting of costs a bit further? = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From @mail.uunet.ca:mark.longridge@canrem.com Thu Jan 19 01:02:38 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA10634; Thu, 19 Jan 95 01:02:38 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <159428-2>; Thu, 19 Jan 1995 00:35:27 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA00872; Thu, 19 Jan 95 00:21:59 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1CA56D; Thu, 19 Jan 95 00:11:23 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Shift Invariance Recap From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1003.5834.0C1CA56D@canrem.com> Date: Thu, 19 Jan 1995 00:08:00 -0500 Organization: CRS Online (Toronto, Ontario) Shift Invariance the Final Chapter?? ------------------------------------ 2 x Order 2 (the diagonal square element) Subgroup , order = 2 D2 F2 T2 F2 B2 T2 F2 T2 2 Swap (the single square element) Subgroup , order = 2 D2 R2 D2 R2 D2 R2 2 H (the edge square element) Subgroup , order = 2 L2 R2 B2 L2 R2 F2 12 flip (the central element) Subgroup , order = 2 R1 L1 D2 B3 L2 F2 R2 U3 D1 R3 D2 F3 B3 D3 F2 D3 R2 U3 F2 D3 Special Property: Effects all edges the same 6 Counterclockwise twist (the odd element) Subgroup , order = 3 U2 R1 U1 R1 U1 R3 U1 R3 U1 R3 U2 R1 U1 R1 U1 R3 U1 R3 U1 R3 Special Property: Effects all corners the same Martin's message about the SuperSkewb having a non-trivial centre reminded me that the SuperCube should have 3 more positions which are also shift invariant: 3x3x3 cube with 6 centre pieces rotated 90, 180 and 270 degrees, with orders 4, 2 and 4 respectively. This time all the centres are effected the same! Naturally there are 3 more positions in SG's as well. A pity there is no "Centre All-Twist" process in any of the cube literature. -> Mark <- I'll leave a superflip process for the Magic Dodecahedron as a 'exercise for the reader' ;-) From @mail.uunet.ca:mark.longridge@canrem.com Thu Jan 19 01:33:07 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA11196; Thu, 19 Jan 95 01:33:07 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <159426-5>; Thu, 19 Jan 1995 00:35:26 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA00868; Thu, 19 Jan 95 00:21:57 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1CA56C; Thu, 19 Jan 95 00:11:23 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Superflip 24q From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1002.5834.0C1CA56C@canrem.com> Date: Thu, 19 Jan 1995 00:06:00 -0500 Organization: CRS Online (Toronto, Ontario) > this just appeared today, after a lot of searching: > > R3 U2 B1 L3 F1 U3 B1 D1 F1 U1 D3, L1 D2 F3 R1 B3 D1 F3 U3 B3 U1 D3 > 24q > > mike Sm = Central Reflection i.e. for operators F1 = B3, F2 = B2, F3 = B1 L1 = R3, L2 = R2, L3 = R1 U1 = D3, U2 = D2, U3 = D1 p = R3 U2 B1 L3 F1 U3 B1 D1 F1 U1 D3 (12 q) Then p + (p * Sm) = Superflip This is Mike's process slightly patched, with the last two (commuting) cube turns swapped in position. -> Mark <- From acoles@mnsinc.com Thu Jan 19 12:55:11 1995 Return-Path: Received: from news1.mnsinc.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA18201; Thu, 19 Jan 95 12:55:11 EST Received: from localhost (mail@localhost) by news1.mnsinc.com (8.6.5/8.6.5) id MAA07610 for ; Thu, 19 Jan 1995 12:57:14 -0500 Received: from mnsnet.mnsinc.com(199.164.210.10) by news1.mnsinc.com via smap (V1.3) id sma007608; Thu Jan 19 12:57:07 1995 Received: by mnsinc.com (5.65/1.35) id AA10459; Thu, 19 Jan 95 12:54:10 -0500 Date: Thu, 19 Jan 1995 12:54:09 -0500 (EST) From: Aaron Coles To: cube-lovers@life.ai.mit.edu Subject: Masterball Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Have anyone had any experience or even heard of "Masterball". I picked this "Mind Boggling 3-D puzzle with over 350 Quadrillion possible combinations" from a store out here is Washington, DC. From dlitwin@fusion.geoworks.com Thu Jan 19 13:41:25 1995 Return-Path: Received: from quark.geoworks.com ([198.211.201.100]) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA21484; Thu, 19 Jan 95 13:41:25 EST Received: from radium.geoworks.com by quark.geoworks.com (4.1/SMI-4.0) id AA25914; Thu, 19 Jan 95 10:36:51 PST Date: Thu, 19 Jan 95 10:36:51 PST From: dlitwin@fusion.geoworks.com Message-Id: <9501191836.AA25914@quark.geoworks.com> To: Aaron Coles Cc: cube-lovers@life.ai.mit.edu In-Reply-To: Subject: Masterball Aaron Coles writes: > Have anyone had any experience or even heard of "Masterball". I picked this > "Mind Boggling 3-D puzzle with over 350 Quadrillion possible > combinations" from a store out here is Washington, DC. I've seen a bunch of them around, in all sorts of different color patterns. The two standard ones (that I bought) are black and white stripes and a rainbow colored striped one. I like the way they color the plastic instead of using stickers. Dave Litwin From mreid@ptc.com Thu Jan 19 18:30:05 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA09088; Thu, 19 Jan 95 18:30:05 EST Received: from ducie.ptc.com by ptc.com (5.0/SMI-SVR4-NN) id AA15016; Thu, 19 Jan 95 18:28:35 EST Received: by ducie.ptc.com (1.38.193.4/sendmail.28-May-87) id AA09110; Thu, 19 Jan 1995 18:41:47 -0500 Date: Thu, 19 Jan 1995 18:41:47 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9501192341.AA09110@ducie.ptc.com> To: cube-lovers@ai.mit.edu Subject: symmetric maneuvers Content-Length: 1504 mark writes > p = R3 U2 B1 L3 F1 U3 B1 D1 F1 U1 D3 (12 q) > > Then p + (p * Sm) = Superflip > > This is Mike's process slightly patched, with the last two (commuting) > cube turns swapped in position. i'm surprised this hasn't been pointed out previously. however, i would write the above as (R3 U2 B1 L3 F1 U3 B1 D1 F1 U1 D3 C_X)^2 where i use C_X for central reflection. this fits in with mark's idea of "cyclic decomposition". i've noticed that a number of minimal (or presumed to be minimal) maneuvers for pretty patterns have some symmetry. here i'll use commutator notation: [ A , B ] refers to A B A' B' also i'll use bandelow's notation for rotations of the whole cube: C_U , C_RF , C_URF , denote rotation about a face-face axis, edge-edge axis, corner-corner axis, respectively. now some patterns: anaconda: B1 R1 D3 R3 F1 B3 D1 F3 U1 D3 L1 F1 L3 U3 = [ B1 R1 D3 R3 F1 B3 D1 , C_UB ] python: D2 F3 U3 L1 F3 B1 D3 B1 U1 D3 R3 F1 U1 B2 = [ D2 F3 U3 L1 F3 B1 D3 , C_UF ] 6 x's (order 3): R2 L3 D1 F2 R3 D3 F1 B3 U1 D3 F1 L1 D2 F3 R1 L2 = [ R2 L3 D1 F2 R3 D3 F1 B3 , C_UB ] my favorite example is four twisted peaks: U3 D1 B1 R3 F1 R1 B3 L3 F3 B1 L1 F1 R3 B3 R1 F3 U3 D1 = [ U3 D1 B1 R3 F1 R1 B3 L3 F3 , C_R2 ] i'd hoped to find maneuvers for "cube within a cube" and "cube within a cube within a cube", but no such luck. mike From mreid@ptc.com Fri Jan 20 15:46:17 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA12414; Fri, 20 Jan 95 15:46:17 EST Received: from ducie.ptc.com by ptc.com (5.0/SMI-SVR4-NN) id AA19444; Fri, 20 Jan 95 15:44:52 EST Received: by ducie.ptc.com (1.38.193.4/sendmail.28-May-87) id AA10072; Fri, 20 Jan 1995 15:58:08 -0500 Date: Fri, 20 Jan 1995 15:58:08 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9501202058.AA10072@ducie.ptc.com> To: cube-lovers@ai.mit.edu Subject: superflip in quarter turn metric Content-Length: 3456 i've finished searching for superflip in 20q , and no solutions were found. thus superflip requires at least 22q , which gives a new lower bound for the diameter of the cube group in the quarter turn metric. total cpu spent on the search was 29 cpu hours. based on this, i would make a rough estimate of 2.5 to 3 months cpu time for an exhaustive search through depth 22q. this time i collected some statistics the way dik did. this should be helpful for troubleshooting. it's not foolproof, but it's a reasonable start. i will rerun the face turn search and collect the same data along the way. mike statistics follow: depth in number of times solutions stage 1 stage 2 is reached found superflip R1 L1 U1: 9q 64 33q, 31q, 29q 10q 272 11q 3728 27q 12q 26440 13q 164664 25q 14q 911112 15q 5516208 superflip R1 L1 U3: 9q 64 31q, 29q, 27q 10q 272 11q 3728 12q 26440 13q 164664 14q 911112 25q 15q 5516208 superflip R1 L1 F1: 9q 288 31q, 29q, 27q 10q 2192 11q 13496 12q 65280 13q 352056 25q, 23q 14q 1810744 15q 9753608 superflip R1 L1 F3: 9q 288 31q, 29q, 27q 10q 2192 11q 13496 12q 65280 25q 13q 352056 14q 1810744 15q 9753608 superflip R1 L3 U1: 9q 64 33q, 31q, 29q, 27q 10q 272 11q 3728 12q 26440 25q 13q 164664 14q 911112 23q 15q 5516208 superflip R1 L3 F1: 9q 288 33q, 31q, 29q 10q 2192 27q 11q 13496 25q 12q 65280 13q 352056 14q 1810744 15q 9753608 superflip R1 U1: 10q 6 32q 11q 106 28q 12q 4216 26q 13q 30318 14q 212208 15q 1414882 16q 9807890 superflip R1 U3: 10q 6 32q 11q 106 30q, 28q 12q 4216 26q 13q 30318 14q 212208 24q 15q 1414882 16q 9807890 superflip R1 F1: 10q 78 32q, 30q, 28q 11q 352 12q 5338 26q, 24q 13q 35996 14q 241230 15q 1549382 16q 10531798 17q 71358512 superflip R1 F3: 10q 78 28q 11q 352 12q 5338 26q, 24q 13q 35996 14q 241230 15q 1549382 16q 10531798 17q 71358512 From BRYAN@wvnvm.wvnet.edu Fri Jan 20 20:41:10 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27138; Fri, 20 Jan 95 20:41:10 EST Message-Id: <9501210141.AA27138@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 0675; Fri, 20 Jan 95 17:07:06 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 0198; Fri, 20 Jan 1995 17:07:06 -0500 X-Acknowledge-To: Date: Fri, 20 Jan 1995 17:07:05 EST From: "Jerry Bryan" To: , "Cube Lovers List" Subject: Re: superflip in quarter turn metric In-Reply-To: Message of 01/20/95 at 15:58:08 from mreid@ptc.com On 01/20/95 at 15:58:08 mreid@ptc.com said: >i've finished searching for superflip in 20q , and no solutions were >found. thus superflip requires at least 22q , which gives a new lower >bound for the diameter of the cube group in the quarter turn metric. >total cpu spent on the search was 29 cpu hours. based on this, i would >make a rough estimate of 2.5 to 3 months cpu time for an exhaustive >search through depth 22q. Rats. You beat me by about a half hour. I just finished comparing Level 10 of my data base with the same Level 10 superflipped. There were no matches. I just about have Level 11 completed. This will provide interesting new information in and of itself, because previously there has only been an exhaustive search through level 10. Once I complete Level 11, I will superflip it and see what happens. The superflip is especially amenable to a "two half depth search". Normally, you would have to build one tree with Start at the root, and a second tree with X at the root, where X is the position you were testing. But a search tree with superflip at the root is identical to a search tree with Start at the root except that the superflip tree has each element superflipped as compared to the respective element of the tree with Start at the root. Hence, building the tree with Superflip at the root is quite easy once the tree with Start at the root is in hand. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From BRYAN@wvnvm.wvnet.edu Sat Jan 21 17:03:15 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA05451; Sat, 21 Jan 95 17:03:15 EST Message-Id: <9501212203.AA05451@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 3609; Sat, 21 Jan 95 12:46:20 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 3611; Sat, 21 Jan 1995 12:46:20 -0500 X-Acknowledge-To: Date: Sat, 21 Jan 1995 12:44:42 EST From: "Jerry Bryan" To: "der Mouse" Cc: "Cube Lovers List" Subject: Re: superflip in quarter turn metric In-Reply-To: Message of 01/21/95 at 09:05:55 from , mouse@Collatz.McRCIM.McGill.EDU On 01/21/95 at 09:05:55 der Mouse said: >> The superflip is especially amenable to a "two half depth search". >> Normally, you would have to build one tree with Start at the root, >> and a second tree with X at the root, where X is the position you >> were testing. But a search tree with superflip at the root is >> identical to a search tree with Start at the root except that the >> superflip tree has each element superflipped as compared to the >> respective element of the tree with Start at the root. >Isn't this equally true of any other position, except that the >conversion from a Start-rooted tree's position to an X-rooted tree's >position is more complicated than just superflipping? Just think of >your tree, instead of describing positions as "cubie in cubicle >", as describing positions as "cubie that started in cubicle in >cubicle ". I am taking the liberty of CC'ing Cube-Lovers as well. A search tree giving distances from Start calculates d(I,IY) for all positions IY in the domain of inquiry. With an X-rooted tree, distances are of the form d(X,XZ) for all positions XZ in the domain of inquiry. In general, it is not the case that d(I,IY)=d(X,XY). Hence, we cannot simply take Z=Y, and elements of the form XY do not produce the X-rooted tree. Therefore, to perform two half-depth searches to connect I and X, you really do have to construct a standard Start-rooted tree as well as an X-rooted tree. You are looking for a position IY=XZ such that |IY|=|XZ|=|X|/2. However, in the case of the Superflip E, it is the case that d(I,IY)=d(E,EY). Hence, in order to construct an E-rooted tree, it is sufficient to calculate all elements of the form EY from your existing I-rooted tree of the form IY. >Or are you storing only M-conjugate-class representatives, and I'm >exposing my ignorance of basic group theory? :-) Yes, I am storing only M-conjugate-class representatives, but that isn't the problem (see above). However, it does make the processing a bit less trivial than I have indicated. For every Y in the Start-rooted tree, I first form EY, then {m'(EY)m}, and finally Repr{m'(EY)m}. These representatives are sorted and then compared against all the Y's (which are themselves representative elements, of course). We are looking for some V and W such that Repr{m'(IV)m}=Repr{m'(EW)m}, and this will be a "half-way" position. What I *really* want is some V such that Repr{m'(IV)m}=Repr{m'(EV)m}. It seems to me that all half way positions should be "symmetric" in this fashion, but I cannot prove it. The recent discussions by Mike Reid and Mark Longridge about the 24q superflips are suggestive in this regard. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From @uconnvm.uconn.edu:dmoews@xraysgi.ims.uconn.edu Sun Jan 22 01:25:28 1995 Return-Path: <@uconnvm.uconn.edu:dmoews@xraysgi.ims.uconn.edu> Received: from UConnVM.UConn.Edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA25252; Sun, 22 Jan 95 01:25:28 EST Received: from venus.ims.uconn.edu by UConnVM.UConn.Edu (IBM VM SMTP V2R2) with TCP; Sun, 22 Jan 95 01:25:48 EST Received: from xraysgi.ims.uconn.edu by venus.ims.uconn.edu (4.1/SMI-4.1) id AA05317; Sat, 27 Apr 02 04:47:10 EST Received: by xraysgi.ims.uconn.edu (920330.SGI/911001.SGI) for @venus.ims.uconn.edu:cube-lovers@ai.mit.edu id AA25808; Mon, 23 Jan 95 01:24:21 -0500 Date: Mon, 23 Jan 95 01:24:21 -0500 From: dmoews@xraysgi.ims.uconn.edu (David Moews) Message-Id: <9501230624.AA25808@xraysgi.ims.uconn.edu> To: cube-lovers@ai.mit.edu, dmoews@xraysgi.ims.uconn.edu Subject: Shamir's method on the superflip I can also report that the superflip requires at least 19 face turns. I got this result using Shamir's algorithm, which Mike Reid describes briefly in his message <9412162233.AA27627@ducie.ptc.com>. To repeat him: Shamir's method allows you to generate in lexicographic order all permutations st, where s and t are elements of lists S and T of permutations, respectively, while using only space proportional to the sum of the sizes of the lists. What I did was to first check that the superflip f couldn't be done in 11 or fewer face turns (easy) and to then try to solve f=stuv, where s and v have 4 face turns and t and u have 2 to 5 face turns. This is done by scanning through the (ordered) lists of all st's and all f v^(-1) u^(-1)'s and checking to see if there is a common element. Shamir's method then has to be applied to S and T and to V and T, where T is a list of permutations with 2 to 5 face turns, S is a list of permutations s with 4 face turns, and V is a list of permutations f v^(-1), where v has 4 face turns. The number of candidates for s and v can be reduced by making use of the fact that f is central, has order 2, and is invariant under conjugation by the symmetry group of the cube. The computation took 52 hours of CPU time on an SGI Crimson (R4000 50/100 MHz CPU.) More than half the CPU time is spent composing permutations and updating priority queues (see below.) Some have expressed concern that Shamir's method is a memory hog. Applying it to S and T requires a rather complicated tree of permutations in T and a priority queue of permutations in S. I used the wreath product representation of the cube group (so `permutation' is something of a misnomer,) and my memory usage was then as follows: Per element of S: 48 bytes permutation s in S (can be shared with other S's and T's) 40 bytes composition st (not absolutely necessary, but speeds things up) 16 bytes pointers internal to the queue and to an element t of T --------- 104 bytes Per element of T: 48 bytes permutation t in T (can be shared, as before) 8 bytes pointer immediately above t <=16 bytes Amortized cost of higher-up regions of the tree ---------- <=72 bytes The T tree is not altered during traversal, so if you are applying the method to S and T and V and T simultaneously you just need one T tree. All told, my memory usage was around 46M. Looking for a 20 face turn representation by this method would probably take around 59M of memory and 710 hours of CPU time (on this machine.) -- David Moews dmoews@xraysgi.ims.uconn.edu From @uconnvm.uconn.edu:dmoews@xraysgi.ims.uconn.edu Sun Jan 22 17:06:42 1995 Return-Path: <@uconnvm.uconn.edu:dmoews@xraysgi.ims.uconn.edu> Received: from UConnVM.UConn.Edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA23273; Sun, 22 Jan 95 17:06:42 EST Received: from venus.ims.uconn.edu by UConnVM.UConn.Edu (IBM VM SMTP V2R2) with TCP; Sun, 22 Jan 95 17:07:00 EST Received: from xraysgi.ims.uconn.edu by venus.ims.uconn.edu (4.1/SMI-4.1) id AA05345; Sat, 27 Apr 02 20:28:20 EST Received: by xraysgi.ims.uconn.edu (920330.SGI/911001.SGI) for @venus.ims.uconn.edu:cube-lovers@ai.mit.edu id AA27851; Mon, 23 Jan 95 17:05:33 -0500 Date: Mon, 23 Jan 95 17:05:33 -0500 From: dmoews@xraysgi.ims.uconn.edu (David Moews) Message-Id: <9501232205.AA27851@xraysgi.ims.uconn.edu> To: cube-lovers@ai.mit.edu, dmoews@xraysgi.ims.uconn.edu Subject: Symmetry reductions of the superflip As I mentioned in my last message, I used symmetries to reduce the number of candidate sequences for the superflip. Here's how: Suppose we have a sequence for the superflip that has at least 4 syllables. (Here, a syllable is a maximal sequence of commuting face turns, i.e., a maximal sequence of face turns on the same axis.) The sequence of axes in these syllables must look like (1) Z X ... X Y, (2) Z Y ... X Y, (3) X Z ... X Y, or (4) X Y ... X Y, for some distinct axes X, Y, and Z. Remember that the superflip is central, so we can cyclically permute the sequence of syllables. If doing this always results in pattern (4), we only use two axes, but this can't flip any edges; hence, we can get (1), (2) or (3). By inverting the (order 2) superflip we can change (2) to (3). Then we have (1) or (3). By applying a symmetry of the cube, we can let X, Y and Z be the FB, UD, and LR axes, respectively. We still have some of the symmetry group to work with, namely the set of the eight symmetries of the cube that fix all cube axes. If we need to, we can apply a 180-degree rotation of the cube about the UD or LR axes, which lets us restrict the first FB syllable to 9 of the 15 possibilities; then, rotating about the FB axis, we can do the same for the last UD syllable. Finally, we can reflect the cube through the plane between R and L; this lets us restrict the first LR syllable to 9 possibilities, although it expands the number of possibilities for the last UD and first FB syllables to 10 each. Some more estimated runtimes for my Shamir implementation: 20 CPU hr for a 20 qtw superflip; 190 CPU hr for a 22 qtw superflip. -- David Moews dmoews@xraysgi.ims.uconn.edu From @uconnvm.uconn.edu:dmoews@xraysgi.ims.uconn.edu Sun Jan 22 17:22:51 1995 Return-Path: <@uconnvm.uconn.edu:dmoews@xraysgi.ims.uconn.edu> Received: from UConnVM.UConn.Edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA23692; Sun, 22 Jan 95 17:22:51 EST Received: from venus.ims.uconn.edu by UConnVM.UConn.Edu (IBM VM SMTP V2R2) with TCP; Sun, 22 Jan 95 17:23:11 EST Received: from xraysgi.ims.uconn.edu by venus.ims.uconn.edu (4.1/SMI-4.1) id AA05349; Sat, 27 Apr 02 20:44:33 EST Received: by xraysgi.ims.uconn.edu (920330.SGI/911001.SGI) for @venus.ims.uconn.edu:cube-lovers@ai.mit.edu id AA27990; Mon, 23 Jan 95 17:21:46 -0500 Date: Mon, 23 Jan 95 17:21:46 -0500 From: dmoews@xraysgi.ims.uconn.edu (David Moews) Message-Id: <9501232221.AA27990@xraysgi.ims.uconn.edu> To: cube-lovers@ai.mit.edu, dmoews@xraysgi.ims.uconn.edu Subject: Symmetry reductions of the superflip (oops) I forgot to say: You should cyclically permute the sequence of face turns in the superflip to begin with to ensure that the sequence does not begin and end with turns on the same axis. Only then can you be sure that you have one of the forms (1)...(4). -- David Moews dmoews@xraysgi.ims.uconn.edu From mschoene@math.rwth-aachen.de Tue Jan 24 17:15:49 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA10382; Tue, 24 Jan 95 17:15:49 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rWtTe-000MPHC; Tue, 24 Jan 95 23:12 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rWtTd-00025hC; Tue, 24 Jan 95 23:12 WET Message-Id: Date: Tue, 24 Jan 95 23:12 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu In-Reply-To: "Jerry Bryan"'s message of Wed, 18 Jan 1995 11:53:21 EST <9501181654.AA27651@life.ai.mit.edu> Subject: Re: Re: Re: Models for the Cube Jerry Bryan wrote in his message of 1995/01/18 Perhaps you could clarify your generating system and its respecting of costs a bit further? I shall try. This is partly to clarify things for myself. So excuse me if it is a bit long and formal. The Puzzle ---------- First let me formalize what kind of puzzles we are talking about. Assume that we have a set G of *basic states* with a unique basic solved state (we may need to add further marks to distuingish all states). Assume that we have a set S of *simple operations*, such that each transforms each basic state into another, which we write as . Assume that for each simple operation there is an *inverse operation* ' in S, such that if = then ' = . A *process* is simply a sequence ... of simple operations. It induces an operation on the set G of basic states, i.e., it again transforms each basic state into another, through the definition ( ... ) := ((...( ) ... ) ). I say that a process

*solves* a basic stage , if

= . Assume that G and S are such that for each basic state there is a process

that solves (technically this means that the group of operations on G operates transitively on the set G of basic states). The goal of the puzzle is to find such a process for each basic state. If a process

solves a basic state , then the inverse process

', that we get by reversing the sequence and replacing each simple operation by its inverse, transforms into , and I say

' *effects* . Finally assume that G and S are such that if processes and effect the same basic state , then they induce the same operations, i.e., then = for any other basic state in G (technically this means that the group of operations on G operates regularly on the set G of basic states). This then allows us to identify the set G of basic states and the group of operations on G. This in turn allows us to view G as a group, with the generating system S. Sometimes it is necessary to distuingish between a process, the operation it induces, and the basic state it effects. When such a distinction is unnecessary, I shall simply talk about the *element* of G. I call the group G a model for the *basic puzzle*. For an example take Rubik's cube. There are 24 * 43252003274489856000 basic states. The simple operations are the face turns (or quarter face turns if you prefer) and the rotations of the rigid cube. Obviously each state can be solved and it is easy to verify that two processes that effect the same basic state induce the same operation. The group CG is the model for the basic Rubik's cube. The Essential Puzzle -------------------- Next we need to add the notion that, while all basic elements (states) are different, some are more different than others. Assume that there is a subgroup of *essentially free elements* F. Assume that we shall consider two elements and to be *essentially equal*, if there is an essentially free element in F such that = . Then the sets of essentially equal elements are of course exactely the (left) cosets ( F). We shall call such a coset an *essential element*. Assume that we have selected for each coset ( F) a representative r( F). Define the operation '*' on the set of left cosets by ( F) * ( F) := (r( F) r( F) F), i.e., the product of two cosets is the coset containing the product of the representatives. If the set of essential elements with this operations is a group, then I call this group a model for the *essential puzzle*. Note that there is no guarantee that we can select the representatives such that '*' defines a group. That is, for some puzzles there may not be a group model for the essential puzzle. This for example happens if G = < (1,2), (1,2,3,4) > is the symmetric group on four points and F = < (1,2)(3,4) >. Furthermore there is no guarantee that each selection that gives us a group, gives us the same group. That is, for some puzzles there may be different nonisomorphic group models for the essential puzzle. This for example happens if G = < (1,2), (1,2,3,4) > and F = < (1,2), (1,2,3) > is the stabilizer of one point, in which case C4 = < (1,2,3,4) > and V4 = < (1,2)(3,4), (1,3)(2,4) > are models. But if F is a normal subgroup, then it doesn't matter how we select the representatives; the operation '*' always gives us the factor group. Also if there is a supplement E of F (i.e., a subgroup E, such that G = E F and E F = { }), then selecting the elements of E as the representatives of the cosets gives us a group model for the essential puzzle. This group model is of course isomorphic to E (but note that there can be nonisomorphic supplements). But there can be group models for the essential puzzle that come neither from the factor group nor from a supplement. This for example happens if G = < (1,2,3,4,5,6,7,8), (2,8)(3,7)(4,6) > is the dihedral group of size 16 and F = < (1,2)(3,8)(4,7)(5,6), (1,5)(2,6)(3,7)(4,8) >, in which case there are again two nonisomorphic models. For example in the case of Rubik's cube we usually consider two basic states to be equal if they are related by a rotation of the rigid cube. That is the subgroup F of essentially free elements is the subgroup C of rotations of the rigid cube in this case. The usual group model for the essential Rubik's cube is the supplement G of C. The Costs --------- Finally we need the notion of costs, both for the basic puzzle and the essential puzzle. In general let G be an arbitrary group, X a generating system for G that is closed under taking inverses (that is, for each in X, ^-1 is also in X), and Z a subgroup of G. Then roughly the cost of an element in G wrt. X and Z is the length of a shortest process effecting , where we only count the generators in X, not the terms in Z. More formally define G_(0) := Z and G_(l+1) := G_(l) (G_(l) X Z). Since X is a generating system, there is a finite d such that G = G_(d) (and the smallest such d is called the diameter of G wrt. X and Z). We say that elements which lie in G_(l) but not in G_(l-1) have *cost* l. For the basic puzzle group G, we obviously use the cost function cost_G for G wrt. the generating system S and the subgroup F. So the cost of a basic state is the length of a shortest process effecting , where we count only the simple operations in S, not the elements for the essentially solved operations in F. Note that of course the costs of two essentially equal elements are equal. For the essential puzzle group E, we want to find a cost function cost_E that preserves this cost. That is, we want cost_E( F ) = cost_G( ). So the question is, can we choose a generating system X_E of E and a subgroup Z_E of E such that the cost function for E wrt. to X_E and Z_E has the above property. If you think about it for a moment, you will see, that we actually don't have any choice if we require cost_E( F ) = cost_G( ). Namely Z_E is simply the subgroup of E of the elements with cost 0. But if cost_E( F ) is 1, then cost_G( ) must be 1, so must be in F, and then ( F) is F, i.e., the identity of E. Likewise X_E is simply the subset of E of the elements with cost 1. But if cost_E( F ) is 1, then cost_G( ) must be 1, so must have the form , so we see that X_E must be the set { ( F) | in F, in S }. Now it turns out that those two conditions are not only necessary, they are in fact sufficient. That is, if cost_E is the cost function for E wrt. the generating system X_E = { ( F) | in F, in S } and the subgroup Z_E = { ( F) }, then cost_E preserves the cost, i.e. cost_E( F ) = cost_G( ). So for example in the case of Rubik's cube the cost of an element of CG is the length of shortest process effecting , where we only count the face turns (or only the quarter face turns), not the rotations of the rigid cube. A model for the essential Rubik's cube is the supplement G generated by the face turns (without the rotations). Because for each process we can collect all the rotations of the rigid cube at the end of a process, we see that the set X_E is simply the set of the face turns. For another example take the edges only cube CG[E]. The cost of an element is again the length of the shortest process effecting , where we only count the face turns, not the rotations. A model for the essential edges only cube is E = (i.e., a subgroup of CG[E] that fixes one edge) (Confusion warning: running out of letters again, the first E stands for *e*ssential, the others for *e*dges). If we want the cost function for E to preserve the costs in CG[E], we must take the generating system X_E = { ( F) | in F, in S } = { L[E],D[E],F[E],B[E],r[E]'*R[E],u[E]'*U[E], L[E]', ... }. Otherwise some elements of E, will appear more expensive than they really are. Summary ------- Assume we have a puzzle modelled by a group G of basic elements with a generating system S of simple elements and their inverses. Assume that we have a subgroup F of essentially free elements, and that we call two elements essentially equal if the lie in the same left coset of F in G. Given a system of representatives for the cosets of F in G, we define the product of two cosets as the coset containing the product of the representatives of the two cosets. If this multiplication turns G/F into a group, we call this group a model for the essential puzzle. Note that such a model need not exist, i.e., it may happen that no system of representatives gives a group. Also such a model need not be unique, i.e., different systems of representatives may give nonisomorphic models. The cost of an element in G is the length of a shortest process effecting this element, where we count only the simple elements from S, not the essentially free elements from F. Then the cost of an element in G is equal to the cost of its left coset in G/F wrt. the generating system { ( F) | in F, in S }. Have a nice day. Martin. PS. I admit this more than a *bit* formal and long. Count it as my submission for the understatement-of-the-year award ;-) -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From mschoene@math.rwth-aachen.de Tue Jan 24 18:01:35 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA13203; Tue, 24 Jan 95 18:01:35 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rWuBw-000MPHC; Tue, 24 Jan 95 23:58 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rWuBw-00025hC; Tue, 24 Jan 95 23:58 WET Message-Id: Date: Tue, 24 Jan 95 23:58 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu In-Reply-To: "Jerry Bryan"'s message of Wed, 18 Jan 1995 11:53:21 EST <9501181654.AA27651@life.ai.mit.edu> Subject: Re: Re: Re: Models for the Cube Jerry Bryan wrote in his message of 1995/01/18 It is well known that G[E] must have an equal number of even and odd permutations. If we generate G[E] as , it is also the case that there are just as many positions an even distance from Start as an odd distance from Start because the parity of the distance from Start is the same as the parity of the permutation if we restrict ourselves to quarter turns. If you view the elements of G[E] as permutations on 24 facelets, then all elements are even. But if you forget for the moment the orientations of the edges, and view each element as only permuting the 12 edges, then there is an equal number of even and odd elements in G[E]. And then, since each quarter face turn cyclically permutes four edges, there must indeed be just as many states an even distance from Start as there are states an odd distance from Start. Jerry continued But in the computer search for God's Algorithm for edges only cubes, there were not equal numbers of positions an even distance from Start as an odd distance from Start. The computer search used the coset model G[E]/C[E], where this notation means the set of cosets of C, *not* the factor group. In and of itself, the mismatch between the number of positions at an even distance from Start and at an odd distance from Start should not pose a problem. It is not clear to me what it means to speak of the "parity" of a coset of C, and half of each coset will be even and the other half will be odd. Hence, it is not clear that a particular coset must *a priori* be an odd or even distance from Start. Allow me to translate this into the language I introduced in my other message. G[E] is the model for the basic puzzle. C[E] is the subgroup of essentially free elements. We consider two elements of G[E] to be essentially equal if they lie in the same left coset of C[E] in G[E]. The cost of an element of G[E] (or the distance from the Start), is the length of a shortest process effecting , where we only count the quarter face turns, not the rotations of the rigid cube. It is clear that two essentially equal elements have equal costs. Jerry continued But if we map each coset to an element of G[E], it is meaningful to speak of the parity of the element of G[E]. And if the elements of G[E] to which we map the cosets form a subgroup, then there must be an equal number of odd and even elements in the subgroup (unless they are all even?!). If the mapping respects costs in the sense of maintaining the same distance from Start, then I don't understand how we can avoid a conflict between the equal number of even and odd permutations in the subgroup of G[E] and the unequal number of even and odd distances from Start in the coset model G[E]/C[E]. Pick one edge, say the right upper edge. Then each coset of C[E] contains one representative that fixes this edge. The set of those representative is a subgroup U, generated by L[E],D[E],F[E],B[E]. Formally U is a supplement for C[E] in G[E]. It is a model for the essential edges only cube. And indeed it contains the same number of even and odd permutations. So far so good. But we must now be carefull how we measure the cost of elements in U. If we measure by taking the length of a shortest process effecting such an element in U using only the generators L[E],D[E],F[E],B[E] (and their inverses), then some elements will appear more expensive than they really are. For example r[E]'*R[E] should have cost 1, but there is no process of length 1 effecting this element using only the generators above. So we must take a larger generating system. As I described in my other message, the generating system to take is the set of all elements in U that should have cost 1. This gives us the generating system { L[E], D[E], F[E], B[E], r[E]'*R[E], u[E]'*U[E], L[E]', ... }. Still, so far so good. So where is the problem? Well the new generators r[E]'*R[E] and u[E]'*U[E] are *even* permutations. And since not all generators are odd permutations any more, the argument that the number of elements with even cost and the number of elements with odd cost must be equal, simply doesn't work anymore. Have a nice day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From VIKING1969@delphi.com Tue Jan 24 19:56:54 1995 Return-Path: Received: from bos1h.delphi.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA19301; Tue, 24 Jan 95 19:56:54 EST Received: from delphi.com by delphi.com (PMDF V4.3-9 #7804) id <01HM8J8E9RUO8YKNT5@delphi.com>; Tue, 24 Jan 1995 19:56:39 -0500 (EST) Date: Tue, 24 Jan 1995 19:56:39 -0500 (EST) From: VIKING1969@delphi.com Subject: To: cube-lovers@life.ai.mit.edu Message-Id: <01HM8J8EA1HU8YKNT5@delphi.com> X-Vms-To: INTERNET"cube-lovers@life.ai.mit.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT unsubsribecribe list viking1969 From rodrigo@lsi.usp.br Fri Jan 27 21:05:43 1995 Return-Path: Received: from ofelia (lsi.poli.usp.br) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA23203; Fri, 27 Jan 95 21:05:43 EST Reply-To: Received: by ofelia (4.1/SMI-4.1) id AA11945; Fri, 27 Jan 95 23:55:05 EDT Date: Fri, 27 Jan 1995 23:55:04 -0200 (EDT) From: Rodrigo de Almeida Siqueira X-Sender: rodrigo@ofelia To: cube-lovers@ai.mit.edu Subject: Robot using the Cube - WWW Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes. We have a robot that knows how to do it! The World Wide Web page with images of the 2 robots of DAIA (Departament of Artificial Intelligence and Automation) of LSI (Laboratory of Integrated Systems) at USP (University of Sao Paulo, Brazil) is here: http://www.lsi.usp.br/usp/rod/images/cube/rubik_cube.html Of course, it's Netscape enhanced. This page has also a link to a page I made with the X-Rubik's Cube software (xrubik.html in the same address), with inlined images of the software. Have fun. Rodrigo de Almeida Siqueira Webmaster at Universidade de Sao Paulo, Brazil. personal URL (full of things): http://www.lsi.usp.br/usp/rod/rod.html From @mail.uunet.ca:mark.longridge@canrem.com Sun Jan 29 23:48:39 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA14039; Sun, 29 Jan 95 23:48:39 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <86674-3>; Sun, 29 Jan 1995 23:49:42 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA09640; Sun, 29 Jan 95 23:45:33 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1CC7AE; Sun, 29 Jan 95 23:41:06 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Skewb thoughts From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1021.5834.0C1CC7AE@canrem.com> Date: Sun, 29 Jan 1995 23:40:00 -0500 Organization: CRS Online (Toronto, Ontario) Extract from Martin's very detailed skewb analysis: >Then the group CG = < C, G > is the set of all positions a puzzler >could observe. There are 24 solved position in CG (solved up to >rotations). > >The group CG has size 2 * 6!/2 * ((3^4*4!/2) * (3^4*4!/2) / 3^2) > |CG| = 75,582,720 Note that: |CG| /24 = 3,149,280 >The group G has size 6!/2 * ((3^4*4!/2) * (3^4*4!/2) / 3^2) > |G| = 37,791,360 Note that: |G| /12 = 3,149,280 The number of positions both David Singmaster and Tony Durham (the inventor) find for the skewb is 3,149,280. If we use only one tetrad of the skewb then GAP also finds this number: corners centers (each turn permutes 4) (each turn permutes 3) skewb := Group( ( 1,11,17) ( 2,12,20)( 4,10,18)(22, 6,14) (25,27,29), ( 2,10,22) ( 1, 9,23)( 3,11,21)(17, 5,15) (25,27,30), ( 4,14,20) ( 1,15,19)( 3,13,17)( 7,11,23) (25,28,29), ( 6,12,18) ( 5,11,19)( 7, 9,17)(21, 1,13) (26,27,29) );; Size (skewb); > 3149280 Mr. Singmaster had indicated in his last Cubic Circular that we may determine the skewb's orientation if only one of the tetrads are moved. By moving first one tetrad and then the other we can easily change the skewb's orientation in space. Martin finds that the diameter of the skewb is 11 moves, with perhaps 90 antipodes. The idea that the skewb has 2 positions at 0 moves is rather odd, but I think if we divide Martin's table by 2 we should get the answer for visually distinguishable states for a skewb fixed in orientation. ------------------------------------------------------------ I'm still trying to tame the dodecahedron. -> Mark <- From mreid@ptc.com Mon Jan 30 11:04:29 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA02836; Mon, 30 Jan 95 11:04:29 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA28955; Mon, 30 Jan 95 11:03:02 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA15148; Mon, 30 Jan 1995 11:16:56 -0500 Date: Mon, 30 Jan 1995 11:16:56 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9501301616.AA15148@ducie> To: cube-lovers@ai.mit.edu Subject: Re: superflip requires 20 face turns Content-Length: 5225 as promised, i reran the face turn search and collected data along the way. total run time was 143.7 cpu hours (just a shade under six days) on an HP 9000 series 715, 100MHz clock. so this machine is a bit faster than some of the others that helped out on the original run. (there was also some overlap between different machines.) these figures also show why the cases starting with R1 L1 and R1 L3 are so slow: many more sequences in stage 1 to check. mike statistics below: depth in number of times solutions stage 1 stage 2 is reached found superflip R1 F1: 9f 2 23f, 22f 10f 942 21f, 20f 11f 19180 12f 255716 19f 13f 2967572 14f 32053344 15f 330809868 18f superflip R1 F2: 10f 948 22f, 21f 11f 19032 20f, 19f 12f 251312 13f 2913516 14f 31351632 15f 321390912 18f superflip R1 F3: 9f 2 21f 10f 942 11f 19180 20f, 19f 12f 255716 13f 2967572 14f 32053344 15f 330809868 18f superflip R1 U1: 9f 2 21f 10f 826 11f 17140 20f, 19f 12f 231130 13f 2702062 14f 29334386 15f 303689360 superflip R1 U2: 10f 812 22f 11f 17080 21f 12f 232452 20f, 19f 13f 2735896 18f 14f 29776092 15f 307802732 superflip R1 U3: 9f 2 23f, 22f 10f 826 11f 17140 21f, 20f 12f 231130 19f 13f 2702062 14f 29334386 15f 303689360 superflip R1 L1 F1: 7f 96 20f, 19f 8f 1824 18f 9f 21768 10f 229616 11f 2267728 12f 21151120 17f 13f 189906448 14f 1660964664 superflip R1 L1 F2: 8f 384 22f, 21f, 20f 9f 8448 19f 10f 113440 18f 11f 1268896 12f 12941696 13f 124124064 14f 1141576128 superflip R1 L1 F3: 7f 96 20f, 19f 8f 1824 18f 9f 21768 10f 229616 11f 2267728 12f 21151120 17f 13f 189906448 14f 1660964664 superflip R1 L1 F3: 7f 96 20f, 19f 8f 1824 18f 9f 21768 10f 229616 11f 2267728 12f 21151120 17f 13f 189906448 14f 1660964664 superflip R1 L1 U1: 9f 832 22f, 21f, 20f 10f 16912 19f 11f 224248 18f 12f 2597672 13f 27754280 14f 279317240 superflip R1 L1 U2: 8f 384 22f, 21f, 20f 9f 8448 19f, 18f 10f 113440 17f 11f 1268896 12f 12941696 13f 124124064 14f 1141576128 superflip R1 L1 U3: 9f 832 21f, 20f 10f 16912 19f 11f 224248 18f 12f 2597672 13f 27754280 14f 279317240 superflip R1 L3 F1: 7f 96 21f, 20f, 19f 8f 1824 18f 9f 21768 10f 229616 11f 2267728 12f 21151120 17f 13f 189906448 14f 1660964664 superflip R1 L3 F2: 8f 384 22f, 21f, 20f 9f 8448 19f 10f 113440 11f 1268896 12f 12941696 13f 124124064 18f 14f 1141576128 superflip R1 L3 U1: 9f 832 23f, 22f, 21f, 19f 10f 16912 11f 224248 12f 2597672 18f 13f 27754280 14f 279317240 17f superflip R1 L3 U2: 8f 384 21f, 20f 9f 8448 19f 10f 113440 18f 11f 1268896 12f 12941696 13f 124124064 14f 1141576128 From mschoene@math.rwth-aachen.de Tue Jan 31 08:58:26 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA08559; Tue, 31 Jan 95 08:58:26 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rZG32-000MP6C; Tue, 31 Jan 95 11:43 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rZG32-00025cC; Tue, 31 Jan 95 11:43 WET Message-Id: Date: Tue, 31 Jan 95 11:43 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu In-Reply-To: Mark Longridge's message of Sun, 29 Jan 1995 23:40:00 -0500 <60.1021.5834.0C1CC7AE@canrem.com> Subject: Re: Skewb thoughts Mark Longridge wrote in his e-mail message of 1995/01/29 Extract from Martin's very detailed skewb analysis: >Then the group CG = < C, G > is the set of all positions a puzzler >could observe. There are 24 solved position in CG (solved up to >rotations). >The group CG has size 2 * 6!/2 * ((3^4*4!/2) * (3^4*4!/2) / 3^2) > |CG| = 75,582,720 Note that: |CG| /24 = 3,149,280 >The group G has size 6!/2 * ((3^4*4!/2) * (3^4*4!/2) / 3^2) > |G| = 37,791,360 Note that: |G| /12 = 3,149,280 The number of positions both David Singmaster and Tony Durham (the inventor) find for the skewb is 3,149,280. Right. The SKEWB has 75582720 basic states. Just as with the cube, we consider two basic states to be essential equal if the differ only by a rotation of the rigid cube. Since there are 24 rotations of the rigid cube, the SKEWB has 3149280 = 75582720/24 essential states. Mark continued If we use only one tetrad of the skewb then GAP also finds this number: ## corners centers ## (each turn permutes 4) (each turn permutes 3) skewb := Group( ( 1,11,17) ( 2,12,20)( 4,10,18)(22, 6,14) (25,27,29), ( 2,10,22) ( 1, 9,23)( 3,11,21)(17, 5,15) (25,27,30), ( 4,14,20) ( 1,15,19)( 3,13,17)( 7,11,23) (25,28,29), ( 6,12,18) ( 5,11,19)( 7, 9,17)(21, 1,13) (26,27,29) );; Size (skewb); > 3149280 In my message on the SKEWB I used the subgroup H generated by LUB, LUF, RUB, and RUF. As I noted, this subgroup has a nontrivial intersection with the subgroup C of rotations of the rigid cube. Thus it is *not* a model for the essential SKEWB. The subgroup that Mark uses, which is generated by RUF, RUB, LUF, and RDF is much better. It has trivial intersection with C and is a model for the essential SKEWB. Note however, that the corners corresponding to the four generators for this subgroups do *not* form a tetrad. They are the corner RUF and the three adjacent corners. In particular, those four generators do not fix the positions of the four corners; the generator RUF permutes the three corner cubies at RUB, LUF, and RDF. This subgroup has 7 other conjugated subgroups, corresponding to the 7 other possible choices of the first generator (the one that is adjacent to the other 3 generators). So allow me to use the subgroup H generated by RUF, LUB, RDB, and LDF. The corresponding four corners do form a tetrad. This H also has trivial intersection with C and also has size 3149280. Thus it also is a model for the essential SKEWB. Note that those four generators never change the positions of the four corner cubies. This subgroup is ``almost normal''; it has only 1 other conjugated subgroup, corresponding to the stabilizer of the other tetrad. Mark continued Mr. Singmaster had indicated in his last Cubic Circular that we may determine the skewb's orientation if only one of the tetrads are moved. I am not certain that I understand what this means. One possible interpretation is, that for each state g of the SKEWB we can easily find the rotation x of the rigid cube, such that (g x) is in the subgroup H. That means that for each state g we can easily find how to rotate the rigid cube, so that the rotated state can be solved using only the four generators above. But this is obvious. Since the four generators do not change the positions of the four corner cubies of the tetrad, the rotation x must be the one that puts those four corner cubies to their home positions. Mark continued By moving first one tetrad and then the other we can easily change the skewb's orientation in space. This comment I don't understand at all. Could you clarify it a bit? Mark continued Martin finds that the diameter of the skewb is 11 moves, with perhaps 90 antipodes. The idea that the skewb has 2 positions at 0 moves is rather odd, but I think if we divide Martin's table by 2 we should get the answer for visually distinguishable states for a skewb fixed in orientation. Right. The diameter of the SKEWB is 11 moves and there are 90 essential different antipodes. The essential SKEWB does *not* have 2 states at 0 moves, only the subgroup H which I used has 2 essentially solved states. This is not odder than the notion that the basic SKEWB has 24 essentially solved states. And yes, if you divide the numbers in my table by 2, you get the table for the essential SKEWB. I rerun the computation using the new subgroup H as a model for the essential SKEWB. Here is the output. 0 1 0 0 0 0 0 0 0 0 1 1 8 0 0 0 0 0 0 8 0 0 2 48 0 0 0 0 0 0 48 0 0 3 288 0 0 0 0 0 0 288 0 0 4 1728 0 0 0 0 0 120 1608 0 0 5 10248 0 0 0 36 377 1322 8513 0 0 6 59304 12 87 662 2217 7561 15698 33067 0 0 7 315198 4331 16897 37723 61161 76931 66997 51158 0 0 8 1225483 515249 311594 186221 115830 65096 25012 6481 0 0 9 1455856 1384909 61839 8280 708 95 25 0 0 0 10 81028 80938 90 0 0 0 0 0 0 0 11 90 90 0 0 0 0 0 0 0 0 Since the group is smaller it run faster and also used less memory. Using some additional tricks, I could cut down the time to 40 seconds and the memory needed to 2.5 megabytes. As you can see, the numbers in the first column are exactely half of the corresponding numbers in my previous message (as was expected). The numbers in the other columns are close to half of the corresponding numbers in my previous message but not exactely identical. I have to rethink what those numbers mean and how they relate to the corresponding numbers for the basic SKEWB. Have a nice day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From mschoene@math.rwth-aachen.de Wed Feb 1 07:05:22 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA22110; Wed, 1 Feb 95 07:05:22 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rZdll-000MP6C; Wed, 1 Feb 95 13:02 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rZdlk-00025cC; Wed, 1 Feb 95 13:02 WET Message-Id: Date: Wed, 1 Feb 95 13:02 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu In-Reply-To: "Martin Schoenert"'s message of Tue, 24 Jan 95 23:12 WET Subject: Re: Re: Re: Re: Models for the Cube In my previous message I introduced the basic puzzle and the essential puzzle and their models. There is one more thing I would like to say about models for the cube. The situation is the same as in my previous message. Assume we have a puzzle modelled by a group G of basic elements with a generating system S of simple elements and their inverses. Assume that we have a subgroup F of essentially free elements, and that we call two elements essentially equal if the lie in the same left coset of F in G. Given a system of representatives for the cosets of F in G, we define the product of two cosets as the coset containing the product of the representatives of the two cosets. If this multiplication turns G/F into a group, we call this group a model for the essential puzzle. Note that such a model need not exist, i.e., it may happen that no system of representatives gives a group. Also such a model need not be unique, i.e., different systems of representatives may give nonisomorphic models. The cost of an element in G is the length of a shortest process effecting this element, where we count only the simple elements from S, not the essentially free elements from F. Then the cost of an element in G is equal to the cost of its left coset in G/F wrt. the generating system { ( F) | in F, in S }. The Real Puzzle --------------- Assume that we call two elements and in G to be *really equal* if there are essentially free elements and in F, such that = . Then the sets of really equal elements are the double cosets (F F). Obviously two really equal elements have the same costs. The set of all double cosets is usually written F\G/F. Let us call the size of F\G/F the *real size* of the puzzle. Note that each double coset (F F) is a disjoint union of single cosets of F. On the other hand let H be the largest subgroup of F such that (H F) = ( F). Then the number of single cosets in the double cosets is the index of H in F. So we see that the size of each double coset is a multiple of |F| and a divisor of |F|^2. Furthermore note that the size of the double coset (F F) is |F|, i.e., (F F) is a single coset, if and only if normalizes F, i.e., ( F) = (F ). Now in general F\G/F is notoriously badly behaved. For example the size of F\G/F is in general not a divisor of the size of G. So there is no hope that we can turn F\G/F into a group that has anything to do with G. That means that we cannot model the real puzzle with a group. But that shouldn't stop us from investigating this real puzzle. One question we can ask is, what is the real size of the puzzle? Another question might be, what are the elements that lie in small double cosets. For an example, let us again take Rubik's cube. Here we have a very nice description of when two states are really equal. This is because the premultiplication with corresponds to a recoloring of the cube and the postmultiplication with corresponds to a rotation of the cube. So two states are really equal if we can recolor and rotate one state to get the other state. This idea has come up several times in this list, for example in Jerry Bryan's message about 1152 fold symmetry (see Jerry_Bryan__1152-fold_Symmetry_and_24-fold_Symmetry of 1993/12/08). Note that we must be a little bit more careful with the real cube than with the essential cube. With the essential cube it doesn't matter whether the subgroup of essentially free elements is the subgroup C of rotations of the rigid cube or the subgroup M of rotations and reflections of the rigid cube. That is the group G generated by the face turns is a model for the essential cube in both cases, i.e., G is a supplement of C in CG and is also a supplement of M in MG. But for the essential cube it does matter which subgroup we take. Dan Hoey computed the real size of M\MG/M as 901083404981813616 (see Dan_Hoey__The_real_size_of_cube_space of 1994/11/04). He used the fact that, since the supplement G is a normal subgroup of MG, the number of double cosets in M\MG/M is equal to the number of conjugacy classes in G under the operation of M. With the same idea we can compute the real size of C\CG/C as 1802166805653080256, which is slightly less than 2*901083404981813616. Dan Hoey and Jim Saxe searched for elements such that the double coset (M M) has size 48, 96, or 192 (see Dan_Hoey__Symmetry_and_Local_Maxima_(long_message) of 1980/12/14). More precisely, they classified the elements for which the subgroup H that fixes the single coset ( M) operates transitively on the set of quarter face turns, because those elements must be local maxima (except for the identity). They found 4 double cosets of size 48, 10 double cosets of size 96, and 12 double cosets of size 196, or 72 local maxima. Have a nice day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From BECK@vax88a.pica.army.mil Wed Feb 1 08:19:36 1995 Return-Path: Received: from VAX88A.PICA.ARMY.MIL by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA24361; Wed, 1 Feb 95 08:19:36 EST Date: Wed, 1 Feb 1995 8:19:57 -0500 (EST) From: BECK@vax40a.pica.army.mil To: cube-lovers@ai.mit.edu Message-Id: <950201081957.40400150@VAX40A.PICA.ARMY.MIL> Subject: magic jack a friend of mine sent me the following: > At a recent visit to Games People Play we saw a Magic Jack from Fun Tech. The design was similar to a Rubiks Cube. Have you seen? ANYBODY OUT THERE KNOW MORE of this puxxle ???? From GPATYK@aol.com Wed Feb 1 11:08:10 1995 Return-Path: Received: from mail04.mail.aol.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA04681; Wed, 1 Feb 95 11:08:10 EST Received: by mail04.mail.aol.com (1.37.109.11/16.2) id AA170534691; Wed, 1 Feb 1995 11:04:51 -0500 Date: Wed, 1 Feb 1995 11:04:51 -0500 From: GPATYK@aol.com Message-Id: <950201110450_10093643@aol.com> To: cube-lovers@life.ai.mit.edu Subject: cubelovers-request@ai.ai.mit.edu thank you >greg From @ibm.co.hennepin.mn.us:WF5435@CO.HENNEPIN.MN.US Thu Feb 2 13:38:26 1995 Return-Path: <@ibm.co.hennepin.mn.us:WF5435@CO.HENNEPIN.MN.US> Received: from IBM.CO.HENNEPIN.MN.US by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27718; Thu, 2 Feb 95 13:38:26 EST Message-Id: <9502021838.AA27718@life.ai.mit.edu> Received: from CO.HENNEPIN.MN.US by IBM.CO.HENNEPIN.MN.US (IBM MVS SMTP V3R1) with BSMTP id 0229; Wed, 01 Feb 95 13:00:31 CST Date: Wed, 1 Feb 95 13:00:07 CST To: cube-lovers@life.ai.mit.edu From: SUBSCRIBE cube-lovers-request Jill Lyons From @mail.uunet.ca:mark.longridge@canrem.com Fri Feb 3 03:32:33 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA18834; Fri, 3 Feb 95 03:32:33 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <88129-3>; Fri, 3 Feb 1995 03:32:45 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA20793; Fri, 3 Feb 95 03:28:33 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1CD83B; Fri, 3 Feb 95 02:50:28 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: More skewb thoughts From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1030.5834.0C1CD83B@canrem.com> Date: Fri, 3 Feb 1995 00:40:00 -0500 Organization: CRS Online (Toronto, Ontario) The following is a follow up to the discussion on the SKEWB containing quotes from messages of Martin and myself. >> The number of positions both David Singmaster and Tony Durham >> (the inventor) find for the skewb is 3,149,280. > Right. The SKEWB has 75582720 basic states. Just as with the cube, > we consider two basic states to be essential equal if the differ only > by a rotation of the rigid cube. Since there are 24 rotations of > the rigid cube, the SKEWB has 3149280 = 75582720/24 essential states. I just noticed that the number of states of the pyraminx (with vertex rotations included) also equals 75,582,720. (933,120 * 3^4) >>Mark continued >> >>If we use only one tetrad of the skewb then GAP also finds this >> number: >> >> ## corners centers >> ## (each turn permutes 4) (each turn permutes 3) >> skewb := Group( >> ( 1,11,17) ( 2,12,20)( 4,10,18)(22, 6,14) (25,27,29), >> ( 2,10,22) ( 1, 9,23)( 3,11,21)(17, 5,15) (25,27,30), >> ( 4,14,20) ( 1,15,19)( 3,13,17)( 7,11,23) (25,28,29), >> ( 6,12,18) ( 5,11,19)( 7, 9,17)(21, 1,13) (26,27,29) >> );; I'll amend 'each turn permutes 4' to 'rotates one, 3-cycles the others', although half the corners do move in some way. Also the operators are RUF, RUB, RDF and lastly LUF. The corner LDB remains fixed, so just like the 2x2x2 cube we are fixing a corner. >Note however, that the corners corresponding to the four generators for >this subgroups do *not* form a tetrad. They are the corner RUF and the >three adjacent corners. My computer Webster says that a tetrad is 'A group of four'. Perhaps there is another meaning in geometry or group theory? Certainly I agree with the 2nd statement. >Snip< I concur with the Martin's next paragraph (excuse the editing) >So allow me to use the subgroup H generated by RUF, LUB, RDB, and LDF. >The corresponding four corners do form a tetrad. Martin, could you clarify the use of tetrad here? :-) >More Snips< >> Mr. Singmaster had indicated in his last Cubic Circular that we may >> determine the skewb's orientation if only one of the tetrads are >> moved. > I am not certain that I understand what this means. >Snip< I'm going to re-read the article and think about this some more. >> By moving first one tetrad and then the other we can easily change >> the skewb's orientation in space. > This comment I don't understand at all. Could you clarify it a bit? I shall amend by comment >> above to: By moving first one half of the puzzle and then the other we can easily change the skewb's orientation in space. As stated in Douglas Hofstadter's column in the July 1982 issue of Scientific American, the skewb is a deep-cut puzzle, that is the part of the puzzle that is being operated on is no smaller than the stationary portion. -> Mark <- From BRYAN@wvnvm.wvnet.edu Sat Feb 4 12:08:24 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA17871; Sat, 4 Feb 95 12:08:24 EST Message-Id: <9502041708.AA17871@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 4730; Sat, 04 Feb 95 09:25:25 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 9067; Sat, 4 Feb 1995 09:25:25 -0500 X-Acknowledge-To: Date: Sat, 4 Feb 1995 09:25:24 EST From: "Jerry Bryan" To: "Cube Lovers List" Subject: Level 11, Whole Cube, Q-turns Distance X Branching {m'Xm} Branching Ratio Local from Factor Factor of Max Start Cubes to Classes 0 1 1 0 1 12 12.000 1 1.000 12.000 0 2 114 9.500 5 5.000 22.800 0 3 1,068 9.368 25 5.000 42.720 0 4 10,011 9.374 219 8.760 45.712 0 5 93,840 9.374 1,978 9.032 47.442 0 6 878,880 9.366 18,395 9.300 47.778 0 7 8,221,632 9.355 171,529 9.325 47.931 0 8 76,843,595 9.347 1,601,725 9.338 47.976 0 9 717,789,576 9.341 14,956,266 9.338 47.993 0 10 6,701,836,858 9.337 139,629,194 9.336 47.997 11 62,549,615,248 9.333 1,303,138,445 9.333 47.9992 This chart includes a column for local maxima, which my charts usually do not. With all the data kept in files instead of memory, it is not a very natural calculation to determine which positions are local maxima. With the data in memory, for any position X you would calculate the 12 neighbors Xq, and immediately determine which of the 12 neighbors were one move closer to Start. It is easy to identify local maxima in this situation. With the data written to files, the neighbors Xq are sorted before determining which are closer to Start, and there is no (easy) way to relate a given Xq back to its original X. However, let me describe the sorting/merging process in a little more detail. There is a file containing all cubes X such that |X|=n. The neighbors Xq are written to a file. The file is sorted, with duplicates deleted. (Actually, the problem is so large that there are *many* files containing the neighbors Xq. Each file is sorted, and then the results are merged). Finally, the resulting file is matched against another file containing all cubes Y such that |Y|=(n-1). Any matches are deleted, and whatever is left over becomes the file containing all cubes Z such that |Z|=(n+1). The difference between the number of matches deleted and the number of cubes in the n-1 file is the number of local maxima of length n-1. (Remember that all the X's and Y's and Z's and Xq's are representative elements of M-conjugacy classes.) The last time through this process, I generated neighbors of level 10 to create level 11, sorted and deleted duplicates, and matched against level 9 deleting matches. Hence, the last level for which I have local maxima information is level 9. There are not any local maxima through level 9. I am not really expecting any until Pons Asinorum at level 12. However, it would be nice to verify that Pons Asinorum is the shortest local maximum. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mschoene@math.rwth-aachen.de Sun Feb 5 19:07:52 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA22273; Sun, 5 Feb 95 19:07:52 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rbGx8-000MPPC; Mon, 6 Feb 95 01:05 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rbGx8-00025cC; Mon, 6 Feb 95 01:05 WET Message-Id: Date: Mon, 6 Feb 95 01:05 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu In-Reply-To: Mark Longridge's message of Fri, 3 Feb 1995 00:40:00 -0500 <60.1030.5834.0C1CD83B@canrem.com> Subject: Re: More skewb thoughts Mark Longridge wrote in his e-mail message of 1995/01/29 If we use only one tetrad of the skewb then GAP also finds this number: ... shows how GAP computes the size of this subgroup as 3149280 ... I replied in my e-mail message of 1995/01/31 Note however, that the corners corresponding to the four generators for this subgroups do *not* form a tetrad. Mark Longridge replied in his e-mail message of 1995/02/03 My computer Webster says that a tetrad is 'A group of four'. Perhaps there is another meaning in geometry or group theory? Sorry for the confusion. There is no special meaning of the word ``tetrad'' that I am aware of, neither in geometry nor in group theory. I interpreted Mark's ``one tetrad of the skewb'' as ``four corners of the skewb that are the corners of a regular tetrahedron'', probably because of the common prefix ``tetra''. Note that it is problematic to interpret Mark's ``one tetrad of the skewb'' as ``one group of four corners of the skewb'', since not for all groups of four corners of the skewb the subgroup generated by the corresponding generators has size 3149280, for example the subgroup generated by the generators corresponding to the four corners of the up face, which I used in my first e-mail message, has size 6298560. All in all there are 70 different ways to select a 4-tuple of corners of the cube. Up to rotation there are 6 (essentially) different types. +------* +------* *------* +------* +------* +------* /| /| /| /| /| /| /| /| /| /| /| /| *------+ | *------* | *------* | *------* | *------* | +------* | | | | | | | | | | | | | | | | | | | | | | | | | | *----|-+ | +----|-+ | +----|-+ | *----|-+ | +----|-+ | *----|-+ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ |/ +------* +------* +------+ +------+ *------+ *------+ The first type is what I proposed in my last e-mail message. The 4 corners are the corners of a regular tetrahedron. There are 2 such 4-tuples (corresponding to the 2 tetrahedrons). The subgroup generated by the corresponding generators has size 3149280, and is a model for the essential SKEWB (i.e. the SKEWB up to rotations). It leaves the 4 corners RUB, LUF, RDF, and LDB at their home positions, so it is easy to determine the orientation of an arbitrary state (in the sense that it is easy to determine how to rotate this state so that the rotated state is in the subgroup generated by RUB, LUF, RDF, and LDB). The second type is what Mark proposed in his last e-mail message. There are 8 such 4-tuples (corresponding to the 8 possible choices for the ``central'' corner RUF). The subgroup generated by the corresponding generators also has size 3149280, and is a model for the essential SKEWB. It fixes the corner LDB, so it is again easy to determine the orientation of an arbitrary state. The third type is what I proposed in my first e-mail message. There are 6 such 4-tuples (corresponding to the 6 faces). The subgroup generated by the corresponding generators has size 6298560, so it is too large by a factor of 2 to be a model for the essential SKEWB. It fixes the face center of the down face. In this case it is not easy to determine the orientation of an arbitrary state (in the sense above it is in fact impossible, because for every state there are *two* rotations such that the rotated cube is in the subgroup generated by RUB, LUB, RUF, and LUF). There are 24 4-tuples of the fourth type. The subgroup generated by the corresponding generators has size 9447840, so it is too large by a factor of 3 to be a model for the essential SKEWB. It fixes nothing. There are 24 4-tuples of the fifth type, and 6 4-tuples of the sixth type. The subgroups generated by the corresponding generators have size 37791360, so it is in fact the group G generated by all 8 generators. So if we want a model for the essential SKEWB then we have to take one of the first two types. My preference is for the first type, which I think is more special than the second. Namely there are only 2 such 4-tuples, whereas there are 8 4-tuples of the second type. Correspondingly there are only 2 such subgroups (which are both normal in the group G generated by 8 generators, though they are conjugated in the group CG generated by the 8 generators and the rotations of the rigid cube). Mark Longridge wrote in his e-mail message of 1995/01/29 By moving first one tetrad and then the other we can easily change the skewb's orientation in space. I replied in my e-mail message of 1995/01/31 This comment I don't understand at all. Could you clarify it a bit? Mark Longridge replied in his e-mail message of 1995/02/03 I shall amend by comment >> above to: By moving first one half of the puzzle and then the other we can easily change the skewb's orientation in space. I interpret that as follows. By first using an element g1 from the subgroup H1 generated by RUB, RUF, LUF, and RDF, and then an element g2 from the subgroup H2 generated by RDB, LDB, LDF, and LUB, we can acchieve *any* rotation c of the rigid cube. Now it is true that by first using an element g1 from the subgroup H1 generated by RUB, RUF, LUF, and RDF, and then an element g2 from the subgroup H2 generated by RDB, LDB, LDF, and LUB, we can acchieve any element of the group G generated by all 8 generators (this follows from the fact that |G| = |H1| |H2| / |H1 H2|). But G contains only one half of the rotations of the rigid cube. So of the 24 rotations of the rigid cube we can only achieve 12 (the even ones if we view the rotations as permutations of the 4 diagonals of the cube). This becomes obvious if you note that the 8 generators never exchange the two sets of four corners that form tetrahedrons. Mark also wrote in his e-mail message of 1995/02/03 I just noticed that the number of states of the pyraminx (with vertex rotations included) also equals 75,582,720. (933,120 * 3^4) Is this just by chance, or is there some connection between those two puzzles? Could you describe the pyraminx? Have a nice day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From @mail.uunet.ca:mark.longridge@canrem.com Fri Feb 10 11:54:22 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA08853; Fri, 10 Feb 95 11:54:22 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <109773-2>; Fri, 10 Feb 1995 11:55:11 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA26149; Fri, 10 Feb 95 00:10:57 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1CF175; Fri, 10 Feb 95 00:03:07 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: The Pyraminx Lost From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1035.5834.0C1CF175@canrem.com> Date: Thu, 9 Feb 1995 23:55:00 -0500 Organization: CRS Online (Toronto, Ontario) Subgroup Sizes of the Pyraminx Octahedron ------------------------------------------ 8 * 9 = 72 facelets (triangles) The standard Pyraminx Octahedron has 8 faces, 6 vertices, and 12 edges. It's vertices rotate. One may imagine a "Master" Pyraminx Octahedron with edge AND face rotations as well. Christoph Bandelow has a version of the Pyraminx Octahedron (I call it "Octa" for short) which has no tips. Size of Groups without rotating vertex tips: Name Subgroup # of Elements ---- -------- ------------- OCT1 4 OCT2 16 OCT3 116,121,600 OCT4 613,312,204,800 OCT5 502,269,581,721,600 OCT6 2,009,078,326,886,400 Size of Groups with rotating vertex tips: Name Subgroup # of Elements ---- -------- ------------- OCT1 16 OCT2 256 OCT3 7,431,782,400 OCT4 157,007,924,428,800 OCT5 514,324,051,682,918,400 OCT6 8,229,184,826,926,694,400 Approximately 8.2 * 10^18 ..so still less than the 3x3x3 cube The number of elements increases by a factor of 4^N for each successive group if we include the trivial vertex rotations. A Skewb Summary --------------- Without repeating Martin's results on the skewb, (which I concur with) here is a quick summary on Skewb facts: It is impossible for any face piece to turn in place 90 degrees. It is impossible to flip a single face piece 180 degrees. It is impossible to transpose 2 face pieces. The Skewb has no non-trivial centre. The SuperSkewb has non-trivial centre with all 6 face pieces rotated 180 degrees. The Mystery of the Five Pyraminxi --------------------------------- Or perhaps that should be Pyraminxes... but I can not resist comparing the Five Pyraminxes to the Five Wizards of J.R.R Tolkien, due to their mysterious nature. We are probably all familar with the Popular Pyraminx created by Uwe Meffert. What really confounds me is that Dr. Ronald Turner- Smith kepts referring to the 5 pyraminxes in ad literature and his book "The Amazing Pyraminx". The Master Pyraminx I understand, it has all the basic properties of the standard popular pyraminx plus all 6 of it's edges can rotate 180 degrees (which flips one edge, transposes 2 tips, and swaps 2 pairs of interior edge pieces) giving a total number of permutations of 446,965,972,992,000. Then there is the mysterious "Senior Pyraminx" (this is like Tolkien's Blue Wizards no one knows about). I can only speculate on the properties of the Senior Pyraminx having never read a description, and never seen the physical puzzle itself. The only fact on the Senior Pyraminx I am sure about is that it has less permutations than the Master Pyraminx. My theory is that the Senior Pyraminx has all the properties of the standard pyraminx plus it can rotate SOME of it's edges but not all 6 like the Master Pyraminx (perhaps one or two?). Perhaps Mr. Singmaster, who has seen magic solid variants from all over the world, can shed some light on the matter! -> Mark <- Email: mark.longridge@canrem.com From villa@esaii.upc.es Fri Feb 10 15:26:58 1995 Return-Path: Received: from diable.upc.es by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA22924; Fri, 10 Feb 95 15:26:58 EST Received: by diable.upc.es (4.1/SMI-4.1) id AA29541; Fri, 10 Feb 95 08:04:16 +0100 X400-Received: by /PRMD=Iris/ADMD=Mensatex/C=Es/; Relayed; Fri, 10 Feb 1995 8:04:13 UTC+0100 X400-Received: by /PRMD=es/ADMD=/C=/; Relayed; Fri, 10 Feb 1995 8:00:32 UTC+0200 Date: Fri, 10 Feb 1995 8:00:32 UTC+0200 X400-Originator: villa@esaii.upc.es X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=es/ADMD=/C=/;950210080032] Content-Identifier: 75 From: Ricard Villa To: cube-lovers@life.ai.mit.edu Message-Id: <75*/S=villa/OU=esaii/O=upc/PRMD=iris/ADMD=mensatex/C=es/@MHS> Mime-Version: 1.0 (Generated by Ean X.400 to MIME gateway) help From ccw@eql12.caltech.edu Fri Feb 10 19:14:16 1995 Return-Path: Received: from EQL12.Caltech.Edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA05888; Fri, 10 Feb 95 19:14:16 EST Date: Fri, 10 Feb 95 16:14:11 PST From: ccw@eql12.caltech.edu Message-Id: <950210161411.25007867@EQL12.Caltech.Edu> Subject: I have a non-standard Pyraminx. (its magic number is 5) To: cube-lovers@ai.mit.edu X-St-Vmsmail-To: ST%"cube-lovers@ai.mit.edu" It is a shallow cut Dodecahedron. Could this be one of the "Five Pyraminxes"? I don't remember what it's official name is, though I thought it was the Master Pyraminx. (I will have to check my collection at home) I only ever sow these once, in J.C Penny's, thankfully I bought one. I always viewed this as a combining of 2 puzzles, Alexander's Star and a round one, whose name escapes me at the moment. My copy of this puzzle has 2 yellow and 2 red faces. I think they ran out of colors. This means that if I am not carefull I can appear to have 2 edges switched. This is more apparant then real because the stickers for each face have ridges which can be used to make the proper choice. There are 12 faces, which can be independantly turned by 72 degrees. Faces do not move with respect to each other. There are 20 corners which can only be in Even Permutations. Corners are like the cube, trios can be spun in the same direction, pairs can be spun in opposite directions. There are 30 edges which can only be in Even Permutations. Edges can flipped in pairs, just like the normal cube. group size should be 20 30 30! 20! 3 2 --- * --- * --- * --- 2 2 3 2 Edge Corn Spin Flip for the supergroup, increase by a factor of 12 5 From mschoene@math.rwth-aachen.de Sun Feb 12 19:02:40 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA07507; Sun, 12 Feb 95 19:02:40 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rdoCr-000MPEC; Mon, 13 Feb 95 00:59 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rdoCq-00025cC; Mon, 13 Feb 95 00:59 WET Message-Id: Date: Mon, 13 Feb 95 00:59 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu In-Reply-To: "Martin Schoenert"'s message of Tue, 31 Jan 95 11:43 WET Subject: Re: Re: Skewb thoughts I wrote in my e-mail message about the SKEWB of 1995/01/15 Here is the table for H. The first column contains the lenght. The second column contains the number of positions of that length in H. The third column contains the number of positions of that length that are local maxima, i.e., the number of positions such that for no generator the position * is longer. The fourth column contains the number of positions such that for one generator the position * is longer. And so on. So the eleventh column contains the number of positions such that for all eight generators * is longer (this happens of course only for the 2 solutions). length #pos #loc max 0 2 0 0 0 0 0 0 0 0 2 1 16 0 0 0 0 0 0 16 0 0 2 96 0 0 0 0 0 0 96 0 0 3 576 0 0 0 0 0 0 576 0 0 4 3456 0 0 0 0 0 240 3216 0 0 5 20496 0 0 0 48 729 2766 16953 0 0 6 118608 48 161 1231 4228 14779 32993 65168 0 0 7 630396 8266 33358 76349 121363 153892 137755 99413 0 0 8 2450966 1025322 621763 381098 234661 128570 47822 11730 0 0 9 2911712 2768641 126056 15344 1422 199 50 0 0 0 10 162056 161876 180 0 0 0 0 0 0 0 11 180 180 0 0 0 0 0 0 0 0 ... note that this is the H = < RUF, RUB, LUF, LUB > ... And in my e-mail message of 1995/01/31 I rerun the computation using the new subgroup H as a model for the essential SKEWB. Here is the output. 0 1 0 0 0 0 0 0 0 0 1 1 8 0 0 0 0 0 0 8 0 0 2 48 0 0 0 0 0 0 48 0 0 3 288 0 0 0 0 0 0 288 0 0 4 1728 0 0 0 0 0 120 1608 0 0 5 10248 0 0 0 36 377 1322 8513 0 0 6 59304 12 87 662 2217 7561 15698 33067 0 0 7 315198 4331 16897 37723 61161 76931 66997 51158 0 0 8 1225483 515249 311594 186221 115830 65096 25012 6481 0 0 9 1455856 1384909 61839 8280 708 95 25 0 0 0 10 81028 80938 90 0 0 0 0 0 0 0 11 90 90 0 0 0 0 0 0 0 0 As you can see, the numbers in the first column are exactely half of the corresponding numbers in my previous message (as was expected). The numbers in the other columns are close to half of the corresponding numbers in my previous message but not exactely identical. I have to rethink what those numbers mean and how they relate to the corresponding numbers for the basic SKEWB. ... note that this is now H = < RUF, LUB, RDB, LDF > ... The reason that the numbers in the other columns of the second table are not exactely half of the corresponding numbers in the first table is rather simple. They are *both wrong*. The correct numbers for H = < RUF, LUB, RDB, LDF > are as follows 0 1 0 0 0 0 0 0 0 0 1 1 8 0 0 0 0 0 0 8 0 0 2 48 0 0 0 0 0 0 48 0 0 3 288 0 0 0 0 0 0 288 0 0 4 1728 0 0 0 0 0 0 1728 0 0 5 10248 0 0 0 0 120 240 9888 0 0 6 59304 0 0 84 96 1740 6024 51360 0 0 7 315198 198 144 3600 9768 42900 94344 164244 0 0 8 1225483 15783 73016 199808 316776 343992 208584 67524 0 0 9 1455856 1001960 365792 74976 11760 1224 144 0 0 0 10 81028 80308 720 0 0 0 0 0 0 0 11 90 90 0 0 0 0 0 0 0 0 and the correct numbers for H = < RUF, LUB, RUB, LUF > are exactely twice as large. I figured out what those numbers mean. It is all rather simple. Everybody who thought about them probably knows everything that follows. I use the terms from my last few messages about models for the cube. The basic states of cost 1 are exactely the elements in (F S F), where F is the subgroup of essentially free elements, and S is the set of simple elements (the set of generators) of G. Not all those elements need to be different. Assume that there are basic states of cost 1. Each basic state has neighbors, namely the elements (F S F). The set of neighbors of each state is obviously a union of right cosets of F. Furthermore if and are essentially equal, then there sets of neighbors are equal. So we can map the whole concept to the essential model G/F. Recall that in the essential model G/F the set of elements of cost 1 was exactely the set X = { ( F) | in F S }. Assume that there are essential states of coset 1. Then each essential state ( F) has essential neighbors, namely the essential elements ( F) X. We can now count how many of the basic neighbors of a basic state have smaller cost than . If all basic neighbors have smaller cost than , then we call a basic local maximum. Likewise we can count how many of the essential neighbors of the essential state ( F) have smaller cost than ( F). If all essential neighbors have smaller cost than ( F), then we call ( F) an essential local maximum. It is easy to see that a basic element is a basic local maximum if and only if ( F) is an essential maximum. In fact in most cases the number of basic states that have smaller cost than is simply ( / ) times the number of essential states that have smaller cost than ( F). One sufficient condition for this to happen is, that S is invariant under conjugation by S and that all classes have the same length. This condition is met for the SKEWB, so the numbers in the first table *had* to be twice the numbers in the second table. Sorry about any confusion I caused. Have a nice day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From mschoene@math.rwth-aachen.de Sun Feb 12 19:07:52 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA07555; Sun, 12 Feb 95 19:07:52 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rdoHv-000MPEC; Mon, 13 Feb 95 01:05 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rdoHu-00025cC; Mon, 13 Feb 95 01:05 WET Message-Id: Date: Mon, 13 Feb 95 01:05 WET From: "Martin Schoenert" To: cube-lovers@life.ai.mit.edu In-Reply-To: Mark Longridge's message of Thu, 9 Feb 1995 23:55:00 -0500 <60.1035.5834.0C1CF175@canrem.com> Subject: Re: The Pyraminx Lost I have never seen the Pyraminx. I wonder if somebody could tell me whether the picture I put together from the various comments made about the Pyraminx is correct? I am fairly certain that the Pyraminx is a regular tetrahedron. In the solved state each of the four faces shows only one of the four colours. I think the Pyraminx is cut along 8 planes, two planes perpendicular to each of the four heights (i.e., the four lines that connect a corner with the center of the opposite face). I think for the Pyraminx those planes intersect the height at about 2/5 and 3/5 of the length of the height. Those planes cut the Pyraminx into 15 pieces (1 central piece, 4 corners, 4 inner pieces, and 6 edes), which are all visible. Each face is cut into 10 facelets by them as follows. + / \ / \ / \ / \ / \ +-----------+ / \ / \ / \ / \ +-----+-----+-----+ / \ \ / / \ / \ \ / / \ / \ + / \ / \ / \ / \ / \ / \ / \ +-----------+-----+-----------+ The Pyraminx Star was descibred as a Pyraminx without the centers. So I guess each face of the Pyraminx Star looks as follows. + / \ / \ / \ / \ +---------+ / \ / \ / \ / \ / \ / \ / \ / \ +---------*---------+ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ +---------+---------+---------+ The Pyraminx Snub was described as a Pyraminx without the tips. So I guess each face of the Pyraminx Snub looks as follows. +-----------+ / \ / \ / \ / \ +-----+-----+-----+ \ \ / / \ \ / / \ + / \ / \ / \ / \ / +-----+ I have no idea what Pyraminx Senior and the Pyraminx Master look like. Have a nice day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From ad@dcs.st-andrews.ac.uk Mon Feb 13 04:21:08 1995 Return-Path: Received: from andie.st-andrews.ac.uk (andie.st-and.ac.uk) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA26342; Mon, 13 Feb 95 04:21:08 EST Received: from tamdhu.dcs.st-and.ac.uk by andie.st-andrews.ac.uk with SMTP (PP) id <06511-0@andie.st-andrews.ac.uk>; Mon, 13 Feb 1995 09:19:32 +0000 Received: from [138.251.192.26] (bruichladdich.dcs.st-and.ac.uk) by dcs.st-and.ac.uk (4.1/SMI-4.1) id AA10670; Mon, 13 Feb 95 09:17:27 GMT Date: Mon, 13 Feb 95 09:17:26 GMT Message-Id: <9502130917.AA10670@ dcs.st-and.ac.uk> X-Sender: ad@talisker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cube-lovers@ai.mit.edu, ccw@eql12.caltech.edu From: ad@dcs.st-andrews.ac.uk Subject: Re: I have a non-standard Pyraminx. (its magic number is 5) >My copy of this puzzle has 2 yellow and 2 red faces. I think they ran >out of colors. Reminds me of the joke: "Have you heard about the Irish version of Rubik's Cube?" "No. Tell me." "All the fAces were green." -- Tony Davie Computer Science __ Tel: +44 334 463257 St.Andrews University __/\_\ Fax: +44 334 463278 North Haugh __/\_\/_/ ad@dcs.st-and.ac.uk St.Andrews /\_\/_/\_\ Scotland \/_/\_\/_/ KY16 9SS \/_/\_\ \/_/ A lottery is a tax on the mathematically challenged From mschoene@math.rwth-aachen.de Mon Feb 13 05:57:30 1995 Return-Path: Received: from samson.math.rwth-aachen.de by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27480; Mon, 13 Feb 95 05:57:30 EST Received: from hobbes.math.rwth-aachen.de by samson.math.rwth-aachen.de with smtp (Smail3.1.28.1 #11) id m0rdyQX-000MPAC; Mon, 13 Feb 95 11:54 MET Received: by hobbes.math.rwth-aachen.de (Smail3.1.28.1 #19) id m0rdyQW-00025cC; Mon, 13 Feb 95 11:54 WET Message-Id: Date: Mon, 13 Feb 95 11:54 WET From: "Martin Schoenert" To: Cube-Lovers@ai.mit.edu In-Reply-To: "Jerry Bryan"'s message of Sat, 21 Jan 1995 12:44:42 EST <9501212203.AA05451@life.ai.mit.edu> Subject: Re: Re: superflip in quarter turn metric Jerry Bryan wrote in his e-mail message of 1995/01/21 I am taking the liberty of CC'ing Cube-Lovers as well. A search tree giving distances from Start calculates d(I,IY) for all positions IY in the domain of inquiry. With an X-rooted tree, distances are of the form d(X,XZ) for all positions XZ in the domain of inquiry. In general, it is not the case that d(I,IY)=d(X,XY). Hence, we cannot simply take Z=Y, and elements of the form XY do not produce the X-rooted tree. Therefore, to perform two half-depth searches to connect I and X, you really do have to construct a standard Start-rooted tree as well as an X-rooted tree. You are looking for a position IY=XZ such that |IY|=|XZ|=|X|/2. First we have to make certain that we agree how to multiply permutations. If I write , then I mean *first* do and *then* do . So I compute the image of a point

under the permutation ( ) by first computing the image of

under and then computing the image of that point under . For this order of multiplication it is usual to write

^ for the image of a point

under a permutation (instead of writing (

), which would be better for the other order). For this order of multiplication we must define conjugation of by as ^ := ^-1 (instead of ^ := ^-1). In this notation, it is certainly true that d(,) = d(,). This is because each process that transforms to the state , will also transform to , and likewise each process that transforms to will also transform to . In a certain sense we don't need this though. What you are looking for is a process

that effects the state , i.e.,

= . If such a process of length 22 exists, then there exist two processes and of length 11, such that = . We can rewrite this as = ^-1. Let T be the set of elements reachable from by a process of length 11. Note T^-1 = T. So we see that if there is a process of length 22 effecting , then the intersection ( T) ( T) must be nonempty. As mentioned above, you can interpret the set ( T) as the set of elements at distance 11 from , but you don't have to. Now for the superflip you even have d(,) = d(,), since = because the central commutes with every . Put differently this means that ( T) = (T ), i.e., instead of multiplying each element of T from the left by , you can instead multiply each element from the right. Have a nice day. Martin. -- .- .-. - .. -. .-.. --- ...- . ... .- -. -. .. -.- .- Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551 Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, 52056 Aachen, Germany From ncramer@bbn.com Mon Feb 13 06:57:48 1995 Return-Path: Received: from LABS-N.BBN.COM by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA28197; Mon, 13 Feb 95 06:57:48 EST Message-Id: <9502131157.AA28197@life.ai.mit.edu> Date: Mon, 13 Feb 95 6:54:06 EST From: Nichael Cramer To: ad@dcs.st-andrews.ac.uk Cc: cube-lovers@ai.mit.edu Subject: 6:45 am Monday Morning Humor [was: I have a non-standard Pyraminx...] >Date: Mon, 13 Feb 95 09:17:26 GMT >From: ad@dcs.st-andrews.ac.uk >Subject: Re: I have a non-standard Pyraminx. (its magic number is 5) > >>My copy of this puzzle has 2 yellow and 2 red faces. I think they ran >>out of colors. > >Reminds me of the joke: > >"Have you heard about the Irish version of Rubik's Cube?" >"No. Tell me." >"All the fAces were green." Well, I have, sitting on the shelf beside me here in my office as I type, a cube with six blue faces. What nationality is this I suppose? (Or is this because it was -4 [F] when I left home in Vermont this morning?) >Tony Davie Computer Science __ >Tel: +44 334 463257 St.Andrews University __/\_\ >Fax: +44 334 463278 North Haugh __/\_\/_/ >ad@dcs.st-and.ac.uk St.Andrews /\_\/_/\_\ > Scotland \/_/\_\/_/ > KY16 9SS \/_/\_\ > \/_/ A scots cube consists wholly, I presume, of alternating red and green cubies? N From mouse@collatz.mcrcim.mcgill.edu Mon Feb 13 18:30:35 1995 Return-Path: Received: from Collatz.McRCIM.McGill.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA10510; Mon, 13 Feb 95 18:30:35 EST Received: (root@localhost) by 11948 on Collatz.McRCIM.McGill.EDU (8.6.8.1 Mouse 1.0) id SAA11948 for cube-lovers@ai.mit.edu; Mon, 13 Feb 1995 18:30:32 -0500 Date: Mon, 13 Feb 1995 18:30:32 -0500 From: der Mouse Message-Id: <199502132330.SAA11948@Collatz.McRCIM.McGill.EDU> To: cube-lovers@ai.mit.edu Subject: Re: Re: superflip in quarter turn metric In response to a note of mine, >> A search treegiving distances from Start calculates d(I,IY) for all >> positions IY in the domain of inquiry. With an X-rooted tree, >> distances are of the form d(X,XZ) for all positions XZ in the domain >> of inquiry. In general, it is not the case that d(I,IY)=d(X,XY). whereupon what's-his-name :-) responds > In this notation, it is certainly true that > d(,) = d(,). This is because each process that > transforms to the state , will also transform to , > and likewise each process that transforms to will also > transform to . This is what I was trying to say in the message that started this: that one is building a tree of all move sequences no longer than N, which is to say a certain subset of permutations of the cube. But these permutations can be applied to arbitrary positions just as well as as they can be to Start. Any Cubist knows this; it's the basis for many of the common solving macros: that a process that (say) swaps RF and RB, and TF and TB, can be used to swap whatever cubies happen to be in those cubicles, even if they aren't the RF/RB/TF/TB cubies. der Mouse mouse@collatz.mcrcim.mcgill.edu From BRYAN@wvnvm.wvnet.edu Tue Feb 14 13:11:30 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA10450; Tue, 14 Feb 95 13:11:30 EST Message-Id: <9502141811.AA10450@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 7478; Tue, 14 Feb 95 13:10:42 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 9940; Tue, 14 Feb 1995 13:10:42 -0500 X-Acknowledge-To: Date: Tue, 14 Feb 1995 13:10:41 EST From: "Jerry Bryan" To: "der Mouse" , "Cube Lovers List" Subject: Re: Re: superflip in quarter turn metric In-Reply-To: Message of 02/13/95 at 18:30:32 from , mouse@collatz.mcrcim.mcgill.edu Ok, let's try, try again. I was incorrect in my response to der Mouse, and Martin Schoenert's correction is appreciated. The original issue was as follows: suppose you have created a data base for N levels of God's algorithm, beginning with Start at the root of a tree. With quarter-turns as generators, there is 1 position at level zero, 12 positions at level one, 114 positions at level two, etc. Now, suppose you want to create a data base for N levels of God's algorithm, starting with X at the root of the tree. Can you simply compose your first tree with X on an element by element basis in order to obtain the X-rooted data base? (You do have to be careful about pre-multiplying vs. post-multiplying as Martin indicated!) I stated essentially that the superflip was fairly unique in that you could compose the superflip with the Start-rooted data base in order to obtain the superflip-rooted data base, but that for X-rooted data bases in general you would have to perform a complete search starting with X. der Mouse (correctly) noted that the same procedure would work for any position X as for the superflip. I (incorrectly) took exception with der Mouse, citing my fallacious distance argument. However, the way my data bases work, I still think that the superflip is fairly unique in its ability to be composed with a Start-rooted data base. der Mouse was on the right track in his first post when he questioned whether the issue was the fact that the data bases only store representative elements of M-conjugacy classes. I responded that the storage of representative elements was not the issue, but in fact it is. For example, when storing only representative elements of M-conjugacy classes, consider an F-rooted data base. Strictly speaking, we would have to speak of a Repr{m'Fm}-rooted data base, because F might not be the representative element of {m'Fm} -- it could be any of the twelve elements of Q. When storing only representative elements for a Start-rooted data base, there is 1 element at level zero, 1 element at level one, and 5 elements at level two. For a Repr{m'Fm}-rooted data base, there is 1 element at level zero, and six (!) elements at level one -- namely those same elements that are at level zero and level two of the Start-rooted data base. Hence, we cannot take the Start-rooted data base and pre-multiply each element by Repr{m'Fm} to obtain a Repr{m'Fm}-rooted data base. And in general, we cannot take the Start-rooted data base and pre-multiply each element by an arbitrary Repr{m'Xm} to obtain a Repr{m'Xm}-rooted data base. But for the superflip E, we *can* take the Start-rooted data base and pre-multiply each element by Repr{m'Em} to obtain a Repr{m'Em}-rooted data base. In fact, note that |{m'Em}|=1, so we must have Repr{m'Em}=E. However, note that for each Y in the Start-rooted data base, it is not sufficient to calculate (EY). Rather, we must calculate Repr{m'(EY)m}. That is, we know by definition that we have Y=Repr{m'Ym}, but we do not necessarily have (EY)=Repr{m'(EY)m}. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mbparker@share.netcom.com Wed Feb 15 20:44:52 1995 Return-Path: Received: from netcomsv.netcom.com (uumail3.netcom.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA29125; Wed, 15 Feb 95 20:44:52 EST Received: from share.mbparker.slip.netcom.com by netcomsv.netcom.com with SMTP (8.6.9/SMI-4.1) id RAA21900; Wed, 15 Feb 1995 17:37:43 -0800 Received: by share.mbparker.slip.netcom.com (NX5.67d/NX3.0M) id AA07457; Wed, 15 Feb 95 17:43:19 -0800 Date: Wed, 15 Feb 95 17:43:19 -0800 From: Michael Benjamin Parker Message-Id: <9502160143.AA07457@share.mbparker.slip.netcom.com> To: Cube-Lovers@ai.mit.edu Subject: PUZZLE PARTY! in Orange County, CA; 1995 Feb. 18th (Sat) 7:00pm- Reply-To: mbparker@mit.edu Dear Cube-Lovers, One of your members Jerry Slocum mentioned you might be interested in this event. If you're in the area this weekend, you're welcome to come to the puzzle party of the MIT Club of S. California... PUZZLE PARTY! Like to play games? Need some new challenges? What some intellectual stimulation different from your day-to-day routine? Then gather together your favorite brain teasers, mental games, IQ tests, & mechanical puzzles, and come to the PUZZLE PARTY! -- a ``puzzle-potluck'' to bring and share your favorite puzzles. We will re-energize our brains as we attempt to decipher the puzzles of our fellow Southern Cal. friends. Show off your puzzle collection --or your puzzle-solving wizardry. Discover new puzzles and new friends. Fill your mind with amusing problems and good conversation as we sit by the fireside. Plenty of snacks and refreshments provided. WHEN: Saturday, February 18th, 7pm until... WHERE: 506 N. Maplewood, Orange, CA 92666 (Near 55 and 22 freeways), phone 800-MBPARKER xLIVE. From 55 fwy, exit west on Chapman Ave., 1st light turn right (north) on Tustin, 2nd light turn left (west) on Walnut, 3rd right is Maplewood: I'm the big yellow house at the corner of Walnut and Maplewood. Use the Maplewood-side entrance. COST: For persons bringing puzzle(s), $4 for each MITCSC member and $6 for each non-member. For ``puzzle-less'' persons, $8 for each member and $10 for each non-member. RSVP: You may pay at the door, but please let me know you are coming if possible. Please email, fax, or phone in the following info: your name, address, phone, fax, email, and what you're bringing: ___ puzzle-bearing members at $ 4 each: $___ ___ puzzle-bearing non-members at $ 6 each: $___ ___ puzzle-less members at $ 8 each: $___ ___ puzzle-less non-members at $10 each: $___ ___ <- total persons total cost -> $___ total number of puzzles being brought ___ See you there! Michael B. Parker, MIT '89 PERMANENT CONTACT INFO (always forwards to my current address): 721 E. Walnut Ave., Orange, CA 92667-6833 USA; mbparker@mit.edu (NeXTmail ok) 800-MBPARKER (800-627-2753) ext: LIVE (5483), MESG (6374), and FAXX (3299) CURRENT ADDRESS (modified 2/6/95): Orange, CA; live 714-639-6436, fax 714-639-5381, vmail pager 714-413-2090. From BRYAN@wvnvm.wvnet.edu Thu Feb 16 03:12:38 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA23166; Thu, 16 Feb 95 03:12:38 EST Message-Id: <9502160812.AA23166@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 8706; Wed, 15 Feb 95 21:47:09 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 6982; Wed, 15 Feb 1995 21:47:09 -0500 X-Acknowledge-To: Date: Wed, 15 Feb 1995 21:47:07 EST From: "Jerry Bryan" To: "Cube Lovers List" Subject: Start-rooted vs. X-rooted Search Example It's a fool's errand, I suppose, but in light of our recent discussions, I created an X-rooted data base up through level 5, where X is the representative element of {m'Fm}. Here are the results compared to a standard Start-rooted data base. It is most important to realize that both data bases contain only representative elements, and that the results with total cubes are derived from the representative elements by calculating the sizes of the conjugacy classes. Start- Repr{m'Fm}- Rooted Rooted Representative Representative Level Cubes Elements Cubes Elements 0 1 1 12 1 1 12 1 115 6 2 114 5 1,068 25 3 1,068 25 10,011 219 4 10,011 219 93,840 1,978 5 93,840 1,978 878,880 18,395 Performing the search in this fashion, it seems to me that there are only four positions for which the search would look the same as for Start -- Start itself, the Superflip, the Pons Asinorum, and the composition of the Superflip with Pons Asinorum. Martin Shoenert and Mark Longridge have convinced me that the Pons Asinorum and the composition of the Superflip with Pons Asinorum are not in the center of the cube group. But I still believe that the search space for all four position looks essentially the same because these are the only four positions for which the associated symmetry group is M. That is, it is only these four positions for which X=m'Xm for all m in M. It was in this sense -- that the search space structure using representative elements is the same for Start and for superflip -- that I meant that two half-depth searches using representative elements were easy for the superflip, but would be harder for other positions. Here is a question for Dik Winter and Mike Reid (and my apologies if I have asked this before): have you tried your Kociemba's algorithm programs for the composition of Pons Asinorum with superflip? I would find the results to be *very* interesting. Finally, as one last fool's errand, I performed the search for the first five levels again, this time using cubes instead of representative elements. With this last search, the results are the same whether the root of the search is Start or something else, which is the point both der Mouse and Martin Schoenert were making. In this chart, "level" has to be interpreted as "distance from root", not "distance from Start". Start- Repr{m'Fm}- Rooted Rooted Level Cubes Cubes 0 1 1 1 12 12 2 114 114 3 1,068 1,068 4 10,011 10,011 5 93,840 98,840 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mreid@ptc.com Thu Feb 16 09:48:16 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA04895; Thu, 16 Feb 95 09:48:16 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA20708; Thu, 16 Feb 95 09:46:37 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA08579; Thu, 16 Feb 1995 10:01:11 -0500 Date: Thu, 16 Feb 1995 10:01:11 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9502161501.AA08579@ducie> To: cube-lovers@ai.mit.edu, bryan@wvnvm.wvnet.edu Subject: superflip composed with pons asinorum Content-Length: 807 jerry asks > have you tried your Kociemba's > algorithm programs for the composition of Pons Asinorum with > superflip? after superflip, this is probably the second most likely candidate for an antipode. there are only 4 positions which are fixed by all 48 symmetries of the cube. they are: start, superflip, pons asinorum, and the composition of superflip and pons asinorum. obviously start is of no interest and neither is pons asinorum. my quarter turn version found this in less than one minute: B3 L1 D1 L1 F3 U3 D3 L1 B3 D3 F3 R1 L3 F3 U1 D1 L2 U1 D1 B2 22q, 20f so this position is at least as close to start as superflip. i've tested (but not yet extensively) all the local maxima given by hoey and saxe. i'll give a report on these some time soon. mike From @mail.uunet.ca:mark.longridge@canrem.com Thu Feb 16 14:47:44 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA24034; Thu, 16 Feb 95 14:47:44 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <173030-1>; Thu, 16 Feb 1995 14:48:51 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA13094; Thu, 16 Feb 95 14:44:29 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1D048E; Thu, 16 Feb 95 00:47:29 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Assorted Pyraminxi From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1049.5834.0C1D048E@canrem.com> Date: Thu, 16 Feb 1995 00:11:00 -0500 Organization: CRS Online (Toronto, Ontario) MS> I am fairly certain that the Pyraminx is a regular tetrahedron. In the solved state each of the four faces shows only one of the four colours. ML> This is correct for all of the *tetrahedral* pyraminxes with only one small exception: the Star Pyraminx has all middle pieces the same colour. Meffert used the word "pyraminx" as a prefix to just about all the puzzles he either conceived or planned to market. MS> The Pyraminx Star was described as a Pyraminx without the centers. So I guess each face of the Pyraminx Star looks as follows. + / \ / \ / V \ / \ +---------+ / \ / \ / \ M / \ / E \ / E \ / \ / \ +---------*---------+ / \ / \ / \ / \ M / \ M / \ / V \ / E \ / V \ / \ / \ / \ +---------+---------+---------+ ML> Actually the above diagram is a good representation of a head-on view of the popular or standard pyraminx (I've taken the liberty of embellishing it a little). There are 4 Vertices (3 colours), 6 Edges (2 colours) and 12 Middle pieces (single colur) so there are 12 + 12 + 12 = 36 facelets. The tips (or small vertices) can rotate independently, and the larger turn includes the rotaion of the adjacent 2 edge pieces and single middle piece. The small tips each have 3 positions, it's adjacent middle piece also has 3 positions, and the 6 edges obey the same basic laws as the cube, so there are: 3^4 * 3^4 * (6!/2) * (2^6 /2) = 75,582,720 combinations or approximately 75.5 million (993,120 for the snub version) The math for the pyraminx octahedron is very similar, though it has 4 positions for the 6 vertices and middle pieces and 12 edges: 4^6 * 4^6 * (12!/2) * (2^12/2) = 8,229,184,826,926,694,400 or approximately 8.2 quintillion. So the snub pyraminx (or if you prefer "The Pyraminx Snub") would look like: +---------+ / \ / \ / \ / \ / \ / \ / \ / \ +---------*---------+ \ / \ / \ / \ / \ / \ / \ / \ / +---------+ One could imagine snub octahedrons as well. MS> I have no idea what Pyraminx Senior and the Pyraminx Master look like. ML> They are visually indistinguishable from the standard pyraminx, however information on the Senior Pyraminx is exceedingly sketchy. I've never seen a photograph of a Master Pyraminx in the middle of an edge turn so I rather doubt a working prototype was ever made, but you never know... I'll take a stab at one more calculation... The pyraminx hexagon has 12 corners and 18 edges and 8 centres. Each side has 13 facelets so there are 13 * 8 = 104 total facelets. 12!/2 * 3^11 * 16! * 2^15 = 29,087,761,395,446,975,811,708,518,400,000 or approximately 29 nonillion (29^30). -> Mark <- From Cube-Lovers-Request@AI.MIT.EDU Thu Feb 16 15:27:33 1995 Received: from life.ai.mit.edu by ptc.com (5.0/SMI-SVR4-NN) id AA22606; Thu, 16 Feb 95 15:27:33 EST Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for mreid@ptc.com id AA24045; Thu, 16 Feb 95 14:47:58 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <173018-2>; Thu, 16 Feb 1995 14:49:03 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA13116; Thu, 16 Feb 95 14:44:44 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1D0491; Thu, 16 Feb 95 00:59:06 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Corrections From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1050.5834.0C1D0491@canrem.com> Date: Thu, 16 Feb 1995 00:49:00 -0500 Organization: CRS Online (Toronto, Ontario) Content-Length: 447 Status: R >The tips (or small vertices) can rotate independently, and the larger >turn includes the rotation of the adjacent 2 edge pieces and single >middle piece. This should read: The tips (or small vertices) can rotate independently, and the larger turn includes the rotation of the adjacent 3 edge pieces and 3 middle pieces. ...or approximately 29 nonillion (29^30). This should read: ...or approximately 29 nonillion (29*10^30). -> Mark <- [ This message was missing from the mailer archive for some reason. I have added it manually. - Cube-Lovers Moderator ] From BRYAN@wvnvm.wvnet.edu Sun Feb 19 23:21:13 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27346; Sun, 19 Feb 95 23:21:13 EST Message-Id: <9502200421.AA27346@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 2606; Sun, 19 Feb 95 23:20:23 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 5418; Sun, 19 Feb 1995 23:20:23 -0500 X-Acknowledge-To: Date: Sun, 19 Feb 1995 23:20:22 EST From: "Jerry Bryan" To: "Cube Lovers List" Subject: Qturn Lengths of M-Symmetric Positions 1. The length of Start is of course 0 qturns. 2. The length of Pons Asinorum is of course 12 qturns. This result has been known since 1980. However, in the process of testing out half-depth searches, I tested Pons Asinorum and encountered a minor surprise. There are five "halfway" positions which are unique up to M-conjugacy. I only expected three. They are: a. (RRLL)(FF) expected -- continue BB etc. b. (RRLL)(FB) expected -- continue FB etc. c. (RRLL)(FB') expected -- continue FB' etc. d. (FB')(RRLL) a surprise to me e. (RL')(FB')(RL') a surprise to me 3. The length of Pons Asinorum composed with Superflip is 20 qturns. Half-depth searches through level 9 found nothing. A half-depth search at level 10 found ten "halfway" positions which are unique up to M-conjugacy. I have my usual trouble of spinning tapes containing representative elements in order to find the processes, but I should have them in a couple of days or so. I expect we will find that many (or all) of them are really closely related, differing only by commuting in fairly trivial ways, just as do the five half-way positions for Pons Asinorum. 4. The length of Superflip is 24 qturns. Half-depth searches through level 11 found nothing, so the length is greater than 22. Mike Reid has found a Superflip process of length 24. Hence, the length is 24. It would be more satisfying if I could perform a half-depth search to level 12, but the problem is just too big. Hence, I have no idea how many "halfway" positions there are which are unique up to M-conjugacy. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mouse@collatz.mcrcim.mcgill.edu Mon Feb 20 15:37:03 1995 Return-Path: Received: from Collatz.McRCIM.McGill.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA01812; Mon, 20 Feb 95 15:37:03 EST Received: (root@localhost) by 23249 on Collatz.McRCIM.McGill.EDU (8.6.8.1 Mouse 1.0) id PAA23249 for cube-lovers@ai.mit.edu; Mon, 20 Feb 1995 15:36:54 -0500 Date: Mon, 20 Feb 1995 15:36:54 -0500 From: der Mouse Message-Id: <199502202036.PAA23249@Collatz.McRCIM.McGill.EDU> To: cube-lovers@ai.mit.edu Subject: Re: Qturn Lengths of M-Symmetric Positions > 2. The length of Pons Asinorum is of course 12 qturns. [...] > d. (FB')(RRLL) a surprise to me Surprising, but explicable. Write PA as (RRLL)(UUDD)(FFBB). Since PA commutes with everything, [PA](FB') = (FB')[PA]. (I am writing X Y to mean sequence X followed by sequence Y.) Note also that [PA](F'B) = (RRLL)(UUDD)(FB'). But then [PA] = [PA](FB')(F'B) = (FB')[PA](F'B) = (FB')(RRLL)(UUDD)(FB') gives us a length-12 process for PA whose first half is what you found. > e. (RL')(FB')(RL') a surprise to me Me too. By elimination, its second half must be M-equivalent to the first half, since we can look at these five half-processes as equally being M-representatives of the reversals of the PA second halves, and the other four first halves' second halves account for the other four. (Got that? :-) In fact, each first half is M-equivalent to the reversal of the corresponding second half, which is pleasing. After juggling letters for a while, I've been unable to "justify" this process the way I did the one above, which leads me to suspect it may be a fundamentally new process for PA. Amazing, the things you can find when you're not looking for them. :-) > 3. The length of Pons Asinorum composed with Superflip is 20 qturns. > [...] I expect we will find that many (or all) of [the midway > positions for this] are really closely related, differing only by > commuting in fairly trivial ways, just as do the five half-way > positions for Pons Asinorum. Does this mean you see the fifth process for PA as a trivial commutation of the known PA process? How? der Mouse mouse@collatz.mcrcim.mcgill.edu From mreid@ptc.com Mon Feb 20 16:38:19 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA05190; Mon, 20 Feb 95 16:38:19 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA04548; Mon, 20 Feb 95 16:36:20 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA17023; Mon, 20 Feb 1995 16:51:10 -0500 Date: Mon, 20 Feb 1995 16:51:10 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9502202151.AA17023@ducie> To: cube-lovers@ai.mit.edu, mouse@collatz.mcrcim.mcgill.edu Subject: Re: Qturn Lengths of M-Symmetric Positions Content-Length: 1407 der mouse writes > > 2. The length of Pons Asinorum is of course 12 qturns. [...] > > d. (FB')(RRLL) a surprise to me > > Surprising, but explicable. Write PA as (RRLL)(UUDD)(FFBB). Since PA > commutes with everything, [PA](FB') = (FB')[PA]. we've had this discussion before. pons asinorum does not "commute with everything". however, it does commute with "slices" and with cube symmetries. (which is all you're really using here.) > > e. (RL')(FB')(RL') a surprise to me > > Me too. [ ... ] the only reason i'm not surprised here is that i've read the archives. dan hoey gave this maneuver on jan 7 1981. also, it was recently mentioned by chris worrell (on dec 16 1994). > > 3. The length of Pons Asinorum composed with Superflip is 20 qturns. > > [...] I expect we will find that many (or all) of [the midway > > positions for this] are really closely related, differing only by > > commuting in fairly trivial ways, just as do the five half-way > > positions for Pons Asinorum. > > Does this mean you see the fifth process for PA as a trivial > commutation of the known PA process? How? er, i think he means that "many" (i.e. 4) of the 5 maneuvers are closely related. however, i disagree with jerry's conjecture that the maneuvers for pons asinorum composed with superflip will be closely related. i guess we'll know for sure fairly soon. mike From BRYAN@wvnvm.wvnet.edu Tue Feb 21 03:33:17 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA02275; Tue, 21 Feb 95 03:33:17 EST Message-Id: <9502210833.AA02275@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 9130; Mon, 20 Feb 95 20:11:51 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 3003; Mon, 20 Feb 1995 20:11:51 -0500 X-Acknowledge-To: Date: Mon, 20 Feb 1995 20:11:50 EST From: "Jerry Bryan" To: "Cube Lovers List" Subject: Pons Asinorum Superflipped Halfway Positions 1. L' R D' R L' F R' B' U' F' 2. L' R D' R L' F U' F' R' B' 3. U' D L' D U' F D' B' R' B' 4. F' B U F' B D' F' L' D' B' 5. U' D F U' D R' B R U R 6. U' D L' D U' F R B D B 7. F' B L F' B D' F' D' R' D' 8. F' B L F' B D' R' U' F' D' 9. U' D B' U' D L D L F R 10. B B F U' D R F D B U This presentation of the data is a little dissatisfying. These ten processes yield representative element *positions*. With a certain amount of analysis, you could take M-conjugates of the *processes*, plus maybe a little astute rearranging of commuting moves, and make the processes look a little more similar, I think. I actually did so for the five Pons Asinorum halfway positions, but those were easy to futz around with compared to the ones above. Notice, for example, that the first three moves of each of the first nine processes are M-conjugates. That is about as far as I can go in my head. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mreid@ptc.com Tue Feb 21 11:23:45 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA18802; Tue, 21 Feb 95 11:23:45 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA07764; Tue, 21 Feb 95 11:22:05 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA17284; Tue, 21 Feb 1995 11:36:58 -0500 Date: Tue, 21 Feb 1995 11:36:58 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9502211636.AA17284@ducie> To: bryan@wvnvm.wvnet.edu, cube-lovers@ai.mit.edu Subject: Pons Asinorum Superflipped Halfway Positions Content-Length: 543 it looks like jerry gave those sequences backwards. these sequences pair up (as der mouse points out for pons asinorum) and we get five essentially different maneuvers: F3 U3 B3 R3 F1 R1 L3 D3 R1 L3 U1 D3 L3 U1 D3 F1 R1 B1 U1 F1 (1, 8) B3 R3 F3 U3 F1 R1 L3 D3 R1 L3 U1 D3 L3 U1 D3 F1 U1 F1 R1 B1 (2, 9) B3 R3 B3 D3 F1 U3 D1 L3 U3 D1 R1 L3 U3 R1 L3 F1 D1 B1 R1 B1 (3, 6) B3 D3 L3 F3 D3 F3 B1 U1 F3 B1 R2 L1 U1 D3 F1 L1 U1 R1 D1 (4, 10) R1 U1 R1 B1 R3 U3 D1 F1 U3 D1 F1 B3 D1 F1 B3 R3 B3 R3 U3 R3 (5, 7) mike From BRYAN@wvnvm.wvnet.edu Tue Feb 21 14:31:14 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA01060; Tue, 21 Feb 95 14:31:14 EST Message-Id: <9502211931.AA01060@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 4023; Tue, 21 Feb 95 13:20:15 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 3261; Tue, 21 Feb 1995 13:20:16 -0500 X-Acknowledge-To: Date: Mon, 20 Feb 1995 20:11:50 EST From: "Jerry Bryan" To: "Cube Lovers List" Subject: Pons Asinorum Superflipped Halfway Positions (corrected) As Mike Reid pointed out, the sequences were backwards. The error was a human error on my part interpreting the output of the backtracking program which converted positions to processes. The error occurred when I moved the output of the program to E-mail. Each individual qturn operator needs to be inverted as in the following corrected table. 1. L R' D R' L F' R B U F 2. L R' D R' L F' U F R B 3. U D' L D' U F' D B R B 4. F B' U' F B' D F L D B 5. U D' F' U D' R B' R' U' R' 6. U D' L D' U F' R' B' D' B' 7. F B' L' F B' D F D R D 8. F B' L' F B' D R U F D 9. U D' B U D' L' D' L' F' R' 10. B' B' F' U D' R' F' D' B' U' = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From BRYAN@wvnvm.wvnet.edu Wed Feb 22 13:06:05 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA19585; Wed, 22 Feb 95 13:06:05 EST Message-Id: <9502221806.AA19585@life.ai.mit.edu> Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 2290; Wed, 22 Feb 95 11:09:14 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 6020; Wed, 22 Feb 1995 11:09:14 -0500 X-Acknowledge-To: Date: Wed, 22 Feb 1995 11:08:56 EST From: "Jerry Bryan" To: "Cube Lovers List" Subject: Run Times, Storage Requirements, etc. I have been asked to post some run times, storage requirements, etc. related to my recent work. The current model for the whole cube (which I treat as Q[C,E] -- corners and edges, without storing Face centers explicitly) requires 14 bytes per position. I know you can identify a position with the permutation operation which yields that position when applied to Start, but I certainly think of the data base as consisting of positions rather than as of operations. 8 corner facelets and 12 edge facelets are stored in 5 bits each, for a total of 100 bits, or 12.5 bytes. I waste 4 bits, so 13 bytes are required. I could get by with 7 corner facelets and 11 edge facelets (saving 10 bits), but it would increase the processing time. Most of the time (but not for every single project!) I only store representative elements of M-conjugate classes. My representative element function fixes one facelet, so I could save 5 bits there (and have done so on some previous versions of the model). However, I wanted to be able to represent all cubes in the same format as representative elements (remember that representative elements of M-conjugate classes are cubes, too!), so I go ahead and store the fixed facelet. The 14th byte is the length of the cube. I am presently storing cubes of each length in a separate file. For short lengths, it is easy to keep the files on disk instead of tape because they are so small. This greatly assists the backtracking process to convert positions to processes. The files for qturn lengths 0 through 8 are on disk. Length 9 is on one tape, length 10 is on nine tapes, and length 11 is on eighty-two tapes. Each tape holds about 16 million positions. All tapes are not exactly the same length, so some tapes hold a bit more than 16 million and some a bit less. These are mainframe cartridge tapes. Their capacity is not all that great (225MB) compared to some tapes used for backup on desktop systems, but their data transfer rate is as fast or faster than disk -- 4.5 Mbyte per second (36 Mbit per second), vastly faster than most desktop backup systems I know anything about. Because the cube positions are segregated into files based on length, it is not strictly necessary to store the length at all. Also, the length could be stored in the four "wasted" bits of byte 13. Or, the length could be stored as (length mod 3) to reduce the storage requirements to 2 bits. For this model, I have rejected all such accommodations. For example, the little project I did to compare lengths in to lengths in was greatly assisted by having the full length stored explicitly. Also, it is much easier to deal with the sort program I am using when the sort control field (which is the cube position) is lined up on byte boundaries. So I think the various "wasted" space in the model is a good compromise with some practical processing requirements. When doing normal qturn searches, generating the neighbors of each position yields an output file which is initially (before sorting and eliminating duplicate positions) 12 times larger than the original file. With the Pons Asinorum-Superflip project, each X in the data base is pre-multiplied by PA, Superflip, or their composition rather than post-multiplied by qturns, and the output file is exactly the same size as the input file. The output file has to be sorted anyway, but you know a priori that there will be no duplicate positions. For the Pons Asinorum-Superflip project, it took about 90 minutes to process and sort each input tape. For Superflip, I had to go all the way to length 11, so it took about 125 hours to convert 82 input tapes into 82 separate files on 82 separate output tapes. (Actually, because all tapes aren't the same length, about half the time the output file extended a few feet of tape onto a second tape.) Then, the 82 separate output files had to be merged into one large output file spanning 82 tapes. We have 24 tape drives, but we only allow 4 to be used by one job. Hence, each merge can only combine 3 files into 1. (A file can be multiple tapes, read one after the other.) One bunch of merges reduced the 82 files to 28, a second bunch of merges reduced the 28 files to 10, etc. until only 1 file was left. Each bunch of merges had about 82 input tapes total, and about 82 output tapes total, and each bunch of merges took about 10 hours. However, I had to spread the runs over a couple of weeks to keep our operators from shooting me. Finally, the 82 tapes for positions 11 moves from Superflip were matched against the 82 tapes for positions 11 moves from Start, again taking about 10 hours. (I also checked the shorter lengths along the way, but it didn't take anywhere near as long for the shorter lengths). I never found any "halfway" positions for Superflip (would have required going to length 12). Finding the "halfway" positions for PA+Superflip required matching the nine tapes holding positions 10 moves from Start against the nine tapes holding positions 10 moves from PA+Superflip. Having found them, I then did mini-searches. First, the "halfway" positions were the root. After 3 levels, the results were matched against the data base for level 7 (which is a disk file, not tape!). The matches at that level became the root for a new mini-search that leaped from level 7 to level 4, etc. The backtracking search was greatly assisted by the "leaping" procedure (first suggested to me by Dan Hoey). The backtracking search was also assisted by keeping each length segregated, so that the files for lengths close to Start could be small files, and could be on disk. The backtracking search is still very much complicated by the fact that only representative elements are stored, so the backtracking process rotates and reflects out from under you as you generate it. I have a solution for the problem. It amounts to carrying along both a cube and the cube's representative element during the backtracking search, and applying qturns to the cube rather than to the representative element. (The representative element is still the one that has to be matched against the data base.) In a normal "forward" search where the data base is being generated, the qturns are applied to the representative elements and new representative elements are calculated immediately. The original "unrepresentative" cubes are not used in the forward search at all as I now do in the backward search. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mreid@ptc.com Wed Feb 22 18:14:54 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA12024; Wed, 22 Feb 95 18:14:54 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA17114; Wed, 22 Feb 95 18:13:15 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA22074; Wed, 22 Feb 1995 18:28:13 -0500 Date: Wed, 22 Feb 1995 18:28:13 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9502222328.AA22074@ducie> To: bryan@wvnvm.wvnet.edu, cube-lovers@ai.mit.edu Subject: Re: Run Times, Storage Requirements, etc. Content-Length: 1698 jerry writes about his search for superflip in 22q: > [ ... ] However, I had to spread the > runs over a couple of weeks to keep our operators from shooting me. isn't it amazing how they never seem to fully understand the importance of this stuff! :-) > Finally, the 82 tapes for positions 11 moves from Superflip were > matched against the 82 tapes for positions 11 moves from Start, again > taking about 10 hours. (I also checked the shorter lengths along the > way, but it didn't take anywhere near as long for the shorter lengths). i think this can be done much more efficiently. well, at least if you set things up properly in the first place. suppose that you use an order (for sorting positions) in which the corner configuration is more significant than the edge configuration. then, for each position X on your huge list, you need to check if repr(X superflip) is on the list. since superflip only affects edges, the corner configuration of X superflip is the same as that of X. thus the same holds for repr(X superflip) and repr(X) = X. therefore, you only need to look for repr(X superflip) nearby in the sorted list. now, for each corner configuration, load all the positions on your list with that corner configuration into memory (it shouldn't be too many), superflip them, compute representative elements, and look for "halfway" positions. this way, there's no need to sort or store all the positions 11q from superflip (although it wouldn't be hard using this). of course this also works for pons asinorum and its composition with superflip. but it does require that things were set up properly in the beginning. mike From jxs3704@hertz.njit.edu Thu Feb 23 10:47:47 1995 Return-Path: Received: from hertz.njit.edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27189; Thu, 23 Feb 95 10:47:47 EST Received: (from jxs3704@localhost) by hertz.njit.edu (8.6.10/8.6.9) id KAA13328; Thu, 23 Feb 1995 10:47:45 -0500 Date: Thu, 23 Feb 1995 10:47:45 -0500 (EST) From: Codey To: cube-lovers@life.ai.mit.edu Subject: software for Rubik's cube Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone know if there is any software to assist in solving the original Rubik's cube? I just dug my cube up a couple weeks ago and am still having problems solving it. Thanks. -Codey From miz007@admin.connect.more.net Thu Feb 23 23:50:22 1995 Return-Path: Received: from admin (admin.connect.more.net) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA12046; Thu, 23 Feb 95 23:50:22 EST Received: from [204.185.50.27] by admin (5.0/SMI-SVR4) id AA03921; Thu, 23 Feb 1995 22:46:32 -0600 Message-Id: <9502240446.AA03921@admin> X-Sender: miz007@admin.connect.more.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Feb 1995 22:50:44 -0700 To: cube-lovers@life.ai.mit.edu From: miz007@admin.connect.more.net (Tyler Duncan) Subject: solving the cube? Content-Length: 339 I just can't figure out how to solve the rubiks cube. Is there a simple way to solve it? I know my cousin had a pattern to follow and it would work every time, but I haven't seen him in years and can't remember the pattern. Please reply if you know the answer. Tyler Duncan Miz007@admin.connect.more.net Miz007@mail.connect.more.net From BECK@vax88a.pica.army.mil Fri Feb 24 10:22:36 1995 Return-Path: Received: from VAX88A.PICA.ARMY.MIL by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA12292; Fri, 24 Feb 95 10:22:36 EST Date: Fri, 24 Feb 1995 10:22:53 -0500 (EST) From: BECK@vax88a.pica.army.mil To: Cube-Lovers@ai.mit.edu Message-Id: <950224102253.2060111e@VAX88A.PICA.ARMY.MIL> Subject: new puzzle ??? I was given a puzzle, new to me, whose name I do not know. It is magic polyhedra in the shape of a cube. The surface looks like Yoshi's puzzle when folded, ie, 12 edge wedges going to the center of the faces. It turns on the corners of the cube, in groups of 3 wedges at a time. Feels a lot like a skewb but it is not. The mechanism is analogous to Alexander's Star, ie, on each of the faces of the core solid there are pyramids fixed to the faces on rods that are free to turn. This puzzle has an octahedron (equilateral) as the core solid and and equilateral pyramids. {a paper construction is very easy to do - make an octahedron and 8 pyramids - use a rubber band through the apex of the pyramid and through the faces of opposing octahedron faces to attach the pyramids while allowing them to turn. the wedges fit between the pyramids. I do not know how to hold them down but if you join three and sit them over a pyramid you can get the idea of the puzzle - i think} 1 - does anybody know what this puzzle is called ?? 2 - besides this one and Alexander's Star are there other puzzles that use this type of mechanism ?? 3 - If anybody uses this mechanism with a triangular faced hexahedron or icosahedron as the core solid please let me know or any other solid for that matter. THE FUTURE IS PUZZLING, BUT CUBING IS FOREVER !!! pete From ronnie@cisco.com Fri Feb 24 11:23:40 1995 Return-Path: Received: from lager.cisco.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA15977; Fri, 24 Feb 95 11:23:40 EST Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id IAA18802; Fri, 24 Feb 1995 08:23:37 -0800 Message-Id: <199502241623.IAA18802@lager.cisco.com> X-Authentication-Warning: lager.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: BECK@vax88a.pica.army.mil Cc: Cube-Lovers@ai.mit.edu Subject: Re: new puzzle ??? In-Reply-To: Your message of "Fri, 24 Feb 1995 10:22:53 EST." <950224102253.2060111e@VAX88A.PICA.ARMY.MIL> Date: Fri, 24 Feb 1995 08:23:36 -0800 From: "Ronnie B. Kon" > 1 - does anybody know what this puzzle is called ?? > 2 - besides this one and Alexander's Star are there other puzzles that > use this type of mechanism ?? > 3 - If anybody uses this mechanism with a triangular faced hexahedron > or icosahedron as the core solid please let me know or any other solid > for that matter. You left out the most important question: 4 - does anybody know where other people can buy one? Ronnie ---------------------------------------------------------------------------- Ronnie B. Kon | "You couldn't deny that, even if you used both hands" ronnie@cisco.com | (408) 526-4592 | -- The Red Queen ---------------------------------------------------------------------------- From rebdr@mailserv.mta.ca Sun Feb 26 20:36:47 1995 Return-Path: Received: from unb.ca (hermes.csd.unb.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA02123; Sun, 26 Feb 95 20:36:47 EST Received: from mailserv.mta.ca by unb.ca (8.6.10/950124-08:07) id VAA24637; Sun, 26 Feb 1995 21:36:46 -0400 Received: from [138.73.10.3] by mailserv.mta.ca; (5.65/1.1.8.2/09Sep94-0117PM) id AA19550; Sun, 26 Feb 1995 21:38:51 -0400 Date: Sun, 26 Feb 1995 21:38:51 -0400 Message-Id: <9502270138.AA19550@mailserv.mta.ca> X-Sender: rebdr@mailserv.mta.ca Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cube-lovers@life.ai.mit.edu From: rebdr@mailserv.mta.ca (Chico) Subject: Rubik's cube X-Mailer: I am a cube lover. I can solve both the rubik's cube and the rubik's revenge. My personal best at the regular cube is 45 seconds, but it usually takes me about 1min20sec. The few cubes I have are getting really beat up, and I would really like to know if there is still some way to get some new ones. I would appreciate any help. cubeless From ncramer@bbn.com Tue Feb 28 16:08:33 1995 Return-Path: Received: from LABS-N.BBN.COM by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA04677; Tue, 28 Feb 95 16:08:33 EST Message-Id: <9502282108.AA04677@life.ai.mit.edu> Date: Tue, 28 Feb 95 16:00:25 EST From: Nichael Cramer To: Cube-Lovers@ai.mit.edu Subject: Custom Cubes A couple of days back there was brief discussion of some custom-made cubes (e.g. all six sides the same color, etc). Just a couple of additional notes on this point: Some six or eight years ago MIT museum had a major exhibit of puzzles (I particularly remember the full-sized tangram tables). In the last room was a largish display case --the kind of thing your Grandmother displayed her China in-- filled with an assortment of custom cubes. For example, one that I remember was one done for Charles and Diane's wedding; pictures of HRHes on the various faces. (I've not been back to the Museum since, so I'm afraid I don't know the current status of these, or if they are still on display.) Likewise a few years back I had occassion to visit the rare books collection at Widener library. In the entrance-way there were several displays (Cotton Mather's Library, a complete set of Jane Austen first editions, that sort of thing). One shelf had a handful of cubes as "objets d'art": e.g. a pair of white cube (they looked like ivory, but surely not) with words written on the various faces. Don't recall the artist. Cheers Nichael From pontius@bartol.udel.edu Thu Mar 2 11:52:52 1995 Return-Path: Received: from BARTOL.BARTOL.UDEL.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA05044; Thu, 2 Mar 95 11:52:52 EST Received: from [128.175.14.94] by 128.175.14.94 with SMTP; Thu, 2 Mar 1995 7:48:13 -0500 (EST) X-Sender: pontius@128.175.14.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Mar 1995 07:46:40 -0500 To: cube-lovers@life.ai.mit.edu From: pontius@bartol.udel.edu (Duane H. Pontius) Subject: Info? Greetings, I was pointed to this group and would like some info. Please reply to pontius@bartol.udel.edu. Thanks, dp From @mail.uunet.ca:mark.longridge@canrem.com Fri Mar 3 02:53:46 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA01871; Fri, 3 Mar 95 02:53:46 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <173373-1>; Fri, 3 Mar 1995 02:54:50 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA20651; Fri, 3 Mar 95 02:50:22 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1D32BD; Fri, 3 Mar 95 02:44:35 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Centralizers & GAP From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1070.5834.0C1D32BD@canrem.com> Date: Fri, 3 Mar 1995 02:38:00 -0500 Organization: CRS Online (Toronto, Ontario) Martin wrote: That is, of the total 980995276800 elements in GE only 980995276800/332640 = 2949120 elements centralize P. And I used the definition of P from your e-mail of 1995/01/03, i.e., P = (F2 B2) (U2 D2) (L2 R2) = (F2 B2) (L2 R2) (U2 D2) = ... (one gets the same element independent of the order of the three pairs). Ok.... let's see if I understand this "centralizer" business (2 ^ 12 / 2 ) * 12! = 980,995,276,800 elements in GE G is the Group of the cube GE is the Group of the Edges Only cube P is the element we call the Pons Asinorum (or 6 X order 2) Only 2,949,120 elements of GE centralize P, also only... 2,949,120 elements of G centralize P That is, out of all the elements of GE (or G) only 2,949,120 of them commute with the pons asinorum. Let's represent the Group of elements of GE that commute with P as X. Elements of X are represented by x. Then in all x of X, xP = Px. But what is really troubling me is: * How do you represent a particular cube position (e.g. pons) with GAP? * If I could do that, then I could verify how many elements of the cube group commute with a given cube position: Size (Centralizer (cube, pons)); Should give 2949120 (2,949,120) ... right Martin? and Size (Centralizer (sq, cube.centre)); 663552 -> Mark <- From SHV6937@ocvaxa.cc.oberlin.edu Mon Mar 6 08:41:02 1995 Return-Path: Received: from OCVAXA.CC.OBERLIN.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA15534; Mon, 6 Mar 95 08:41:02 EST Received: from OCVAXA.CC.OBERLIN.EDU by OCVAXA.CC.OBERLIN.EDU (PMDF V4.3-7 #7710) id <01HNT5KU4DCW00768T@OCVAXA.CC.OBERLIN.EDU>; Mon, 6 Mar 1995 08:40:53 EST Date: Mon, 06 Mar 1995 08:40:53 -0500 (EST) From: Huy Vo Subject: Subscription To: CUBE-LOVERS@life.ai.mit.edu Message-Id: <01HNT5KU4WN600768T@OCVAXA.CC.OBERLIN.EDU> X-Vms-To: IN%"CUBE-LOVERS@AI.AI.MIT.EDU" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sub Cube-Lovers Huy Vo From @mail.uunet.ca:mark.longridge@canrem.com Tue Mar 7 00:02:49 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA14963; Tue, 7 Mar 95 00:02:49 EST Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <174044-8>; Tue, 7 Mar 1995 00:01:32 -0500 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA10058; Mon, 6 Mar 95 23:56:25 EST Received: by canrem.com (PCB-UUCP 1.1f) id 1D3F42; Mon, 6 Mar 95 23:46:14 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: New GAP insights From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1076.5834.0C1D3F42@canrem.com> Date: Mon, 6 Mar 1995 23:44:00 -0500 Organization: CRS Online (Toronto, Ontario) Okay, I understand the GAP conventions better now. If we adhere to the following model for the cube: +--------------+ | 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 | +--------------+ Then the Pons Asinorum would be: pons := ( 2,42)( 4,45)( 5,44)( 7,47)(10,31)(12,28)(13,29)(15,26) (18,39)(20,36)(21,37)(23,34);; And the slice group would be: slice := Group( ( 1, 3, 8, 6)( 2, 5, 7, 4)( 9,33,25,17)(10,34,26,18)(11,35,27,19) (41,46,48,43)(42,44,47,45)(14,38,30,22)(15,39,31,23)(16,40,32,24), ( 9,11,16,14)(10,13,15,12)( 1,17,41,40)( 4,20,44,37)( 6,22,46,35) (25,30,32,27)(26,28,31,29)( 3,19,43,38)( 5,21,45,36)( 8,24,48,33), (17,19,24,22)(18,21,23,20)( 6,25,43,16)( 7,28,42,13)( 8,30,41,11) (33,38,40,35)(34,36,39,37)( 3,32,46, 9)( 2,29,47,12)( 1,27,48,14) );; And the anti-slice group would be: antisl := Group( ( 1, 3, 8, 6)( 2, 5, 7, 4)( 9,33,25,17)(10,34,26,18)(11,35,27,19) (41,43,48,46)(42,45,47,44)(14,22,30,38)(15,23,31,39)(16,24,32,40), ( 9,11,16,14)(10,13,15,12)( 1,17,41,40)( 4,20,44,37)( 6,22,46,35) (25,27,32,30)(26,29,31,28)( 3,38,43,19)( 5,36,45,21)( 8,33,48,24), (17,19,24,22)(18,21,23,20)( 6,25,43,16)( 7,28,42,13)( 8,30,41,11) (33,35,40,38)(34,37,39,36)( 3, 9,46,32)( 2,12,47,29)( 1,14,48,27) );; Size (antisl) = 6,144 Size (slice) = 768 These numbers concur with Mr. Singmaster's earlier "Notes". The following command shows that pons is at the centre of slice group: Size (Centralizer (slice, pons)) = 768 Once again, I will refer to Martin's earlier statement about centralizers: > That is, of the total 980995276800 elements in GE > only 980995276800/332640 = 2949120 elements centralize P. > And I used the definition of P from your e-mail of 1995/01/03, > i.e., P = (F2 B2) (U2 D2) (L2 R2) = (F2 B2) (L2 R2) (U2 D2) = ... > (one gets the same element independent of the order of the > three pairs). So now that I have the groups and pons element correct: Size (Centralizer (edge, pons)) = 2,949,120 I wrote some statements before.... > Only 2,949,120 elements of GE centralize P, > also only... > 2,949,120 elements of G centralize P I am only partly correct as.... Size (Centralizer (cube, pons)) = 130,026,464,870,400 As Martin said before: > Only one out of 332640 elements of GE (and of G) centralizes P. Size (cube) / 332640 = 130,026,464,870,400 or 130 trillion and change. ...the full cube group has many more elements which commute with pons than the mere edge group! GAP is a very function-laden beastie: Size (Intersection (antisl, slice)) = 8 This function gives the number of elements included in both the anti-slice and slice groups. Naturally there is a corresponding Union function. Since I have studied the squares group and the group, the number of elements in the intersection of the two are of particular interest: Size (Intersection (ur, sq)) = 72 And now we have a new way to check an old result :-) Order (cube, uturn * rturn) = 105 Of course, now that I have answered my old questions, I must formulate new ones.... A) What is the next most commutative element (the pancentre?) after the 12-flip? B) What is the least commutative element (the anticentre?) of the cube group? -> Mark <- From mreid@ptc.com Tue Mar 7 10:11:22 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA04717; Tue, 7 Mar 95 10:11:22 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA07245; Tue, 7 Mar 95 10:09:26 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA25628; Tue, 7 Mar 1995 10:25:12 -0500 Date: Tue, 7 Mar 1995 10:25:12 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9503071525.AA25628@ducie> To: cube-lovers@ai.mit.edu, mark.longridge@canrem.com Subject: New GAP insights Content-Length: 1426 mark writes [ ... ] > The following command shows that pons is at the centre of slice group: > Size (Centralizer (slice, pons)) = 768 this is not hard to see. the center of the slice group has order 32. if we hold the corners fixed, then these central elements are exactly those for which the six face-centers are correct. [ ... ] > Of course, now that I have answered my old questions, I must > formulate new ones.... > > A) What is the next most commutative element (the pancentre?) > after the 12-flip? > B) What is the least commutative element (the anticentre?) of > the cube group? i'm sure that GAP can do these. you're interested in knowing about the orders of centralizers of various elements. for an element g in a group G , we have |G| / |Z(g)| = number of conjugates of g . this is because the cosets G / Z(g) are in one-to-one correspondence with the conjugates of g. of course, this doesn't help much unless we know about conjugacy classes in G. in the case of the cube group, however, conjugacy classes are easy to understand. they are (almost) completely described by cycle structure. (some cycle structures have two conjugacy classes.) there are many different possible cycle structures, but for each it should be easy to count the number of elements with that cycle structure (and also to tell whether they comprise a single conjugacy class or split into two). mike From @mitvma.mit.edu:JI9316@CMSUVMB.BITNET Tue Mar 7 12:40:21 1995 Return-Path: <@mitvma.mit.edu:JI9316@CMSUVMB.BITNET> Received: from mitvma.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA13943; Tue, 7 Mar 95 12:40:21 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 4272; Tue, 07 Mar 95 12:40:03 EST Received: from CMSUVMB.CMSU.EDU (NJE origin MAILER@CMSUVMB) by MITVMA.MIT.EDU (LMail V1.2a/1.8a) with BSMTP id 4328; Tue, 7 Mar 1995 12:40:03 -0500 Received: from CMSUVMB (JI9316) by CMSUVMB.CMSU.EDU (Mailer R2.10 ptf000) with BSMTP id 8088; Tue, 07 Mar 95 11:37:54 CST Date: Tue, 07 Mar 95 11:37:12 CST From: "Justin I." Organization: POOR STUDENTS OF AMERICA Subject: UNSUBSCRIBE To: CUBE-LOVERS@ai.mit.edu Message-Id: <950307.113747.CST.JI9316@CMSUVMB> Please take me off the Cube-Lovers list. THANK YOU. JUSTIN INZAURO FULL TIME STUDENT JI9316@CMSUVMB.CMSU.EDU (816)543-4196 -IN MEMORY OF BETSY, MY FIRST LOVE- -I WILL NEVER FORGET WHAT HAPPENED- -DON'T BE MAD THAT I WAS UNABLE TO STAY- From mreid@ptc.com Tue Mar 7 14:35:00 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA21039; Tue, 7 Mar 95 14:35:00 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA09328; Tue, 7 Mar 95 14:33:16 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA26403; Tue, 7 Mar 1995 14:49:04 -0500 Date: Tue, 7 Mar 1995 14:49:04 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9503071949.AA26403@ducie> To: cube-lovers@ai.mit.edu, mark.longridge@canrem.com Subject: New GAP insights Content-Length: 1222 for what it's worth, i'll make some conjectures about mark's questions. > A) What is the next most commutative element (the pancentre?) > after the 12-flip? (presumably, start excluded as well) i'll guess that these four conjugacy classes are tied for next. corner cycle structure: (1+)(1+)(1+)(1+)(1+)(1+)(1+)(1-) edge cycle structure: (1)(1)(1)(1)(1)(1)(1)(1)(1)(1)(1)(1) corner cycle structure: (1+)(1+)(1+)(1+)(1+)(1+)(1+)(1-) edge cycle structure: (1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+) corner cycle structure: (1+)(1-)(1-)(1-)(1-)(1-)(1-)(1-) edge cycle structure: (1)(1)(1)(1)(1)(1)(1)(1)(1)(1)(1)(1) corner cycle structure: (1+)(1-)(1-)(1-)(1-)(1-)(1-)(1-) edge cycle structure: (1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+)(1+) > B) What is the least commutative element (the anticentre?) of > the cube group? i'll guess corners: (1)(7) edges: (1)(11) corners: (1+)(7-) edges: (1)(11) corners: (1-)(7+) edges: (1)(11) corners: (1)(7) edges: (1+)(11+) corners: (1+)(7-) edges: (1+)(11+) corners: (1-)(7+) edges: (1+)(11+) each of these splits into two conjugacy classes. i think this is the example bandelow gives in his book. mike From mreid@ptc.com Wed Mar 8 10:33:00 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA01704; Wed, 8 Mar 95 10:33:00 EST Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA16380; Wed, 8 Mar 95 10:31:19 EST Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA27471; Wed, 8 Mar 1995 10:47:10 -0500 Date: Wed, 8 Mar 1995 10:47:10 -0500 From: mreid@ptc.com (michael reid) Message-Id: <9503081547.AA27471@ducie> To: cube-lovers@ai.mit.edu Subject: New GAP insights Content-Length: 559 i wrote > > B) What is the least commutative element (the anticentre?) of > > the cube group? > > i'll guess > > corners: (1)(7) edges: (1)(11) > corners: (1+)(7-) edges: (1)(11) > corners: (1-)(7+) edges: (1)(11) > corners: (1)(7) edges: (1+)(11+) > corners: (1+)(7-) edges: (1+)(11+) > corners: (1-)(7+) edges: (1+)(11+) after thinking about it, i realized that corners: (8) edges: (12) commutes with even fewer elements. again, elements with this cycle structure split into two conjugacy classes. mike From GPATYK@aol.com Sat Mar 11 11:23:04 1995 Return-Path: Received: from mail02.mail.aol.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA06352; Sat, 11 Mar 95 11:23:04 EST Received: by mail02.mail.aol.com (1.37.109.11/16.2) id AA063306395; Sat, 11 Mar 1995 10:39:55 -0500 Date: Sat, 11 Mar 1995 10:39:55 -0500 From: GPATYK@aol.com Message-Id: <950311103954_46192197@aol.com> To: cube-lovers@ai.mit.edu Subject: list Please take me off list. thank you >>>gregp From alan@curry.epilogue.com Sun Mar 12 01:34:35 1995 Return-Path: Received: from curry.epilogue.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA07735; Sun, 12 Mar 95 01:34:35 EST Received: (from alan@localhost) by curry.epilogue.com (8.6.8/8.6.6) id BAA06387; Sun, 12 Mar 1995 01:36:17 -0500 Date: Sun, 12 Mar 1995 01:36:17 -0500 Message-Id: <12Mar1995.011352.Alan@LCS.MIT.EDU> From: Alan Bawden Sender: Cube-Lovers-Request@ai.mit.edu To: GPATYK@aol.com Cc: cube-lovers@ai.mit.edu In-Reply-To: GPATYK@aol.com's message of Sat, 11 Mar 1995 10:39:55 -0500 <950311103954_46192197@aol.com> Subject: list Date: Sat, 11 Mar 1995 10:39:55 -0500 From: GPATYK@aol.com Message-Id: <950311103954_46192197@aol.com> To: cube-lovers@ai.mit.edu Subject: list Please take me off list. thank you >>>gregp Looking back through my records, I find that when you asked to be added to Cube-Lovers back in February, you sent your subscription request to the entire mailing list. At the time I explained to you that subscription requests should be sent to Cube-Lovers-REQUEST -- and that this is in fact an Internet-wide convention. In fact, the greeting message I sent you contained the following text: REMEMBER: Our addresses are Cube-Lovers@AI.MIT.EDU for submissions and Cube-Lovers-Request@AI.MIT.EDU for administrivia. Save this message somewhere so you don't forget about Cube-Lovers-Request. If you ever want to be -removed- from Cube-Lovers, your request should be sent to Cube-Lovers-Request. If you forget, and send mail concerning your subscription to the entire list again, you should expect to be severely chastised -- that mistake is considered particularly annoying by Internet old-timers. So here you are, only a month later, screwing up in public -- a particularly pathetic example of inability to follow simple directions. To the rest of you on Cube-Lovers: The paragraph quoted above is now sent to -all- new subscribers (and now all you old-timers have seen it as well), so don't make the mistake that Greg did -- send your administrative requests to -me- (Cube-Lovers-Request@AI.MIT.EDU). If you don't, I have now given you fair warning that I will feel perfectly free to hold you up for public ridicule! - Alan (Cube-Lovers-Request@AI.MIT.EDU) From hirsh@cs.rutgers.edu Mon Mar 13 12:31:57 1995 Return-Path: Received: from pei.rutgers.edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA18376; Mon, 13 Mar 95 12:31:57 EST Received: (from hirsh@localhost) by pei.rutgers.edu (8.6.10+bestmx+oldruq+newsunq+grosshack/8.6.10) id MAA26618; Mon, 13 Mar 1995 12:31:50 -0500 Sender: Haym Hirsh Date: Mon, 13 Mar 95 12:31:49 EST From: Haym Hirsh Reply-To: Haym Hirsh To: cube-lovers@ai.mit.edu Subject: Announcement - Workshop on Groups and Computation, June 7-9, 1995 Cc: Haym Hirsh Message-Id: Thought this might be of interest to some on this list. Please do not contact me, I am not involved with the workshop. Haym =========================================================================== Date: Mon, 13 Mar 1995 11:34:32 -0500 From: bquigley@dimacs.rutgers.edu WORKSHOP ON GROUPS AND COMPUTATION Rutgers University, June 7-9, 1995 Computational group theory is an interdisciplinary field involving the use of groups to solve problems in computer science and mathematics. The workshop will explore the interplay of research which has taken place in a number of broad areas: Symbolic algebra which has led to the development of algorithms for group--theoretic computation and large integrated software packages (such as Cayley, Magma and Gap). Theoretical computer science which has studied the complexity of computation with groups. Group theory which has provided new tools for understanding the structure of groups, both finite and infinite. Applications of group computation within mathematics or computer science, which have dealt with such diverse subjects as simple groups, combinatorial search, routing on interconnection networks of processors, the analysis of data, and problems in geometry and topology. The primary workshop theme is to understand the algorithmic and mathematical obstructions to efficient computations with groups. This will require an assessment of algorithms that have had effective implementations and recently developed algorithms that have improved worst--case asymptotic times. Many algorithms of these two types depend heavily on structural properties of groups (such as properties of simple groups in the finite case), both for motivation and correctness proofs, while other algorithms have depended more on novel data structures than on group theory. The scientific program will consist of a limited number of invited lectures and short research announcements, as well as informal discussions and software demonstrations. Although it is likely that individual talks will have a theoretical or practical focus, it has become increasingly recognized since the first DIMACS Workshop on Groups and Computation that there are no clear dividing lines between theory and practice. Experience has shown that a thorough discussion of implementation issues produces a deeper understanding of the mathematical underpinnings for group computations, leading both to new algorithms and to improvements of existing ones. Some background for these discussions will be obtained through software produced by several participants. Organizers are Larry Finkelstein (Northeastern Univ.; {\tt laf@ccs.neu.edu}), William M. Kantor (Univ. of Oregon; {\tt kantor@bright.uoregon.edu}) and Charles C. Sims (Rutgers Univ.; {\tt sims@math.rutgers.edu}). Contact the organizers or DIMACS for information about attending. From ChadL39788@aol.com Tue Mar 21 16:04:21 1995 Return-Path: Received: from mail04.mail.aol.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA15262; Tue, 21 Mar 95 16:04:21 EST Received: by mail04.mail.aol.com (1.37.109.11/16.2) id AA130564273; Tue, 21 Mar 1995 14:31:13 -0500 Date: Tue, 21 Mar 1995 14:31:13 -0500 From: ChadL39788@aol.com Message-Id: <950321143111_56421409@aol.com> To: cube-lovers@life.ai.mit.edu Subject: Rubic's Revenge Are there any computer programs available to help me solve the Rubic's Revenge I bought in Japan? I know the basics for the first three rows, but not the final side. From BRYAN@wvnvm.wvnet.edu Thu Mar 23 01:17:30 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA26885; Thu, 23 Mar 95 01:17:30 EST Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 5739; Thu, 23 Mar 95 00:30:04 EST Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 1930; Thu, 23 Mar 1995 00:30:04 -0500 Message-Id: Date: Thu, 23 Mar 1995 00:29:47 -0500 (EST) From: "Jerry Bryan" To: "Cube Lovers List" Subject: Some Thoughts on Representative Elements I would like to make some comments on representative elements, but first there are some preliminaries. In some of his recent notes, Martin Schoenert has carefully distinguished between processes, operations, and states. For the purposes of this note, I wish to distinguish between processes and operations on the one hand, and states on the other hand. For this one note alone, I will always use upper case letters for processes and operations, and lower case letters for states. In functional notation, we often (e.g., calculus) see such things as y=F(x). "Function" is synonymous with "operation", and I will use the two terms somewhat interchangeably. In calculus, function composition is often written something like y=FoG(x)=F(G(x)), where the "o" is the best simulation I can do in E-mail of the typical function composition symbol. As has been discussed several times in this forum, the FoG type of notation is interpreted right-to-left, but in group theory we more typically write GF for function composition, and it is interpreted left-to-right. With the left-to-right notation, the function argument (if it is written) can be written on the right as y=GF(x) or on the left as y=(x)GF. I gather that most of Cube-Lovers do not like the latter convention, but I am going to use it anyway. Indeed, as long as we are utterly rigorous in our upper-case/lower-case convention, we can dispense with the parentheses and write y=xGF (or simply y=xF if the function F is a single function). Parentheses can then be used for grouping without any ambiguity that they might be denoting arguments. We let G be the cube group and g be the set of cube states. We can observe that each X in G is a function on g. Furthermore, each X in G is a one-to-one function from g onto g. Hence, each inverse X' exists. These facts are so obvious that they are virtually never stated. But we are about to talk about representative elements, and things are much less well behaved when we talk about representatives. One more preliminary: the idea that a state can be identified with the operation which effects the state when applied to Start can be expressed as x=iX. Hence, there is a one-to-one correspondence between g and G, and we have |g|=|G|. Again, things get much more unruly when we start talking about representatives. Also, we can define the composition of the states x and y as xy=(iX)(iY)=i(XY)=iXY, and this equation defines an obvious isomorphism between g and G. We will use * as the symbol for a selection function on the M-conjugacy classes of g. We will write * as a postfix operator so that it reads left-to-right with the rest of our operators. We have x*=Repr{N'xN} for all N in M, the set of 48 rotations and reflections. Note that * is not uniquely determined. There are approximately |M| ^ (|G| / |M|) possible choices for *, which is a truly large number when compared with |G|. It is conceivable that we might be able to prove some result for one particular choice of * that would not be true for every choice of *. In general, however, we will assume that * is fixed but arbitrary. * is a function from g into (but not onto) g. We let g* be the set of representative states, and * is a function from g onto g*. The function * does not have an inverse, but if we consider * to be a relation, then the inverse relation *' simply maps each representative x* in g* back to the entire M-conjugacy class of x*. Consider the restriction of * to the set g*. At this point, * is not very useful, because it is simply the identity. Define the set Q* as Q* = {F*, R*, L*, B*, U*, D*, F'*, R'*, L'*, B'*, U'*, D'*} This set is near and dear to my heart, because it is how I obtain nearly all my results. We will say more about inverses very soon, but it should be observed immediately that it is not the case that (F*)'=F'*, nor that (R*)'=R'*, etc. Each of the twelve elements in Q* are functions from g into g*. Much more interesting is the restriction of each element of Q* to g*, so that they are functions from g* into g*. We are treating each Q* as composed and not to be decomposed. You could think of elements of g that are not also elements of g* appearing briefly and virtually between the Q and the *, but each Q* is to be treated as from g* into g* without being decomposed. Can we do something like define the group G*=? The answer is no. I assume it will be totally obvious to many of you why not, but I have to think about it for a bit. Martin commented that the set of representatives could not be a group because the number of representatives does not divide the size of G. But it seems to me that Martin's argument only says that the representatives are not a subgroup of G. It seems to me that it does not say that there could not be a group constructed from the representatives. But nonetheless, I think it is quite easy to show that there is no way to make G* into a group. Before I go on, I suspect that many of you will object to me using the generator notation G*=, even with the caveat that G* is not a group. I probably agree, but I am not sure how else to convey the same idea quite so compactly. I simply want to define G* as the set of all compositions of elements of Q*. The compositions are all well defined, although they behave terribly. And G* must be finite, because g* is finite and there are only finitely many functions that can be defined on a finite set. I find the following argument that G* is not a group (and cannot be made into a group) compelling, although there might well be simpler arguments. Do any of the functions Q* have inverses? In order to do so, they would have to be one-to-one from g* onto g*. But i=i*, so i is in g*, and there is only one of the twelve elements of Q* which maps onto i. Hence, at least eleven of the twelve elements of Q* are not onto g*, and therefore do not have inverses. It is trivial do choose * in such a way that all twelve elements of Q* are not onto g*. However, I have not been able to decide if there is way to choose * such that one of the elements of Q* is onto g*. No doubt, somebody out there will have a trivial proof one way or the other. In any case, the general lack of inverses in Q* shows that G* cannot be made into a group. Even though G* is not a group, it is nonetheless an interesting structure. We can think of a "Cayley graph-like" structure where we connect nodes in g* with arcs from Q*. I am not sure if such a structure is properly called a Cayley graph, so just to be safe I will call it a Cayley* graph. As we have already seen, the identity state i*=i has only one neighbor in our Cayley* graph. Are there any other such states? Dan Hoey and Jim Saxe's _Symmetry and Local Maxima_ suggests that there might be 72 such states, namely those states which they call Q-transitive. A Q-transitive state has the characteristic that all its neighbors are M-conjugate. However, some of the Q-transitive states are themselves M-conjugate, so the 72 states collapse somewhat in our Cayley* graph. There are 4 states which are M-symmetric, and these states are distinct in our Cayley* graph. There are 20 states which are H-symmetric but not M-symmetric, but these states collapse into 10 states in our Cayley* graph. There are 48 states which are T-symmetric but not M-symmetric, but these states collapse into 12 states in our Cayley* graph. Hence, there are 26=4+10+12 nodes in our Cayley* graph which have only one neighbor. These figures are given right at the end of _Symmetry and Local Maxima_. They are also given by Martin Schoenert in _Re: Re: Re: Re: Models of the Cube_ on 1 February 1995. It has been thoroughly discussed that |X| = |X*| for all X in G. But of more import for the way I build my data bases is the question of whether for every x in g, will x* appear in my data base, given that I generate the data base as i. In other words, can any x* of length n be decomposed into i(Q_1*)(Q_2*)...(Q_n*)? I find this to be one of those things that is obvious yet is hard to explain. Hence, I will borrow the following explanation that was given to me by Dan Hoey. (Dan's version is much more elegant than mine. Any crud in the following is mine, not Dan's.) First of all, every x* in g* either is the identity or else has a neighbor in g which is closer to Start. If it is the identity, it is in (and indeed is the root of) the data base. Otherwise, we call the neighbor y and calculate y*. Again, y* is either the identity or else has a neighbor which is closer to Start. In this manner, we can backtrack our way to Start from any x*. However, there is not (yet) a guarantee that a forward search will find traverse the same path forwards and find x*, and hence not (yet) a proof that any of the path to x* except i itself is in the data base. We note that if y is a neighbor of x in g, then it is immediate that x is a neighbor of y as well. We need the same thing in g* in order to get a forward search that corresponds to the backwards search. That is, we need to show that if y* is a neighbor of x* in g*, then x* is a neighbor of y*. We now show that if y* is a neighbor of x* in g*, then x* is a neighbor of y* in g*. Observe that if v* = w* (i.e., if v and w are M-conjugates), then the neighbors of v and w are respective M-conjugates as well. Assume x* is not the identity and let y be a neighbor which is closer to Start. Then y* has a neighbor z with z*=x*. Hence, if y* is in the data base, then x* is in the data base, and we have neighbors in both directions. I think of the preceding result as follows. Even though the functions in G* are not individually ("locally") onto, the functions in G* are collectively ("globally") onto. Hence, there is an arc _from_ every node in the Cayley* graph, and there is an arc _to_ every node in the Cayley* graph, and you can get from anywhere to anywhere in the graph. The Cayley* graph is not a homomorphism of the Cayley graph (G* is not a subgroup of G, and is not even a group), but I think of G* as sort of passing the duck test for a homomorphism. That is, it looks like a homomorphism and smells like homomorphism, even though it isn't. (Personal opinion is that the duck test often fails in this manner). But G* is a collapsing of G which does encode an enormous amount of information about G. Roughly speaking, there are two definitions of permutation. The more informal definition is simply than a permutation is an arrangement (or re-arrangement) of objects --- e.g., the number of permutations of n objects taken r at a time. The more formal definition is that a permutation is a function on a set which is one-to-one and onto. Note that function on a finite set is one-to-one if and only if it is onto, so in dealing with the cube we can be a little sloppy at times and speak only of onto or only of one-to-one. All the elements in G are permutations and G is finite. It is therefore trivial to show that for every X in G, there is some integer n such that X^n=I. This means, among other things, that there exists some integer n such that i(X^n)=i (from Start, repeat a process enough times and you will return to Start) and y(X^n)=y (from any position, repeat a process enough times and you will return to the same position). The least such n for each X is the order of X, and considerable discussion has occurred in this forum concerning the order of various elements of G. Once again, things become a bit more unruly when we talk about G* instead of G. The elements of G* are not permutations because they are not onto. So consider what happens when we calculate something like (X*)^n. As a specific example, consider i(R*)^n. If iR*=r', then i(R*)^n simply oscillates back and forth between i and r'. But if * is chosen so that iR* does not equal r', then all bets are off. i(R*)^n will enter a loop eventually, but it will never return to i. To understand its exact behavior, we would have to be specific rather than arbitrary about the definition of *. Similarly, x*(R*)^n might well never return to x*, but it would loop eventually. These "eventual loops" rather remind me of strange attractors. My data bases are of the form i, for example iR*L'*U'*R'*, etc. As I have discussed before, backtracking through such a structure is a bit tricky. Suppose, for example that you have x* in hand and wish to backtrack to i. The way to do it that works best for me is as follows: begin with x*; find x*(Q_1)* that is closer to Start; find x*(Q_1)(Q_2)* that is closer to start (most definitely NOT x*(Q_1)*(Q_2)*); find x*(Q_1)(Q_2)(Q_3)* that is closer to Start (most definitely NOT x*(Q_1)*(Q_2)*(Q_3)*; etc. It is doable in the fashion I said NOT to do, but it is extremely tricky. You will have the sensation (as I have described before) that your solution is rotating and reflecting out from under you. The first way is much easier to keep up with. Finally, how big is G*? Remember that g and G are the same size. Write the restriction of G* to i as iG*. There is clearly a one-to-one mapping between g* and iG*, and indeed we can identify g* with iG* in the same manner in which we identify g with G. But in iG*, all the elements of Q* are equivalent. When we allow the domain of G* to be the entirety of g*, then the elements of Q* are not equivalent. Hence, there are at least eleven more elements in G* than in g*. I don't know how to calculate the size of G*. But when Dan Hoey calculated the real size of the cube space, he calculated the size of g*, not the size of G*. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From itg@athena.compulink.forthnet.gr Fri Apr 7 03:38:26 1995 Return-Path: Received: from info.forthnet.gr by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA10118; Fri, 7 Apr 95 03:38:26 EDT Received: from athena.compulink.forthnet.gr by info.forthnet.gr via FORTHnet with SMTP; id AA29859 (5.65c/FORTHNET-1.1); Fri, 7 Apr 1995 10:36:21 +0300 (EET DST) Organization: From: Theodoros Emmanouil X-Mailer: SCO System V Mail (version 3.2) To: cube-lovers@life.ai.mit.edu Subject: subscribe Date: Fri, 7 Apr 95 10:34:19 EET Message-Id: <9504071034.aa28143@athena.compulink.forthnet.gr> subscribe cube-lovers Thedore Emmanuel From patrick@athos.med.auth.gr Fri Apr 7 11:27:21 1995 Return-Path: Received: from athos.med.auth.gr by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA25540; Fri, 7 Apr 95 11:27:21 EDT Date: Fri, 7 Apr 1995 17:40:46 -0200 (GMT-0200) From: Patrick X-Sender: patrick@athos To: cube-lovers@life.ai.mit.edu Subject: subscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe listname patrick pfavayi From ivan@antares.aero.org Mon Apr 10 19:30:23 1995 Return-Path: Received: from aero.org by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA29530; Mon, 10 Apr 95 19:30:23 EDT Received: from antares.aero.org ([130.221.192.46]) by aero.org with SMTP id <111111-3>; Mon, 10 Apr 1995 13:17:11 -0700 Received: from armadillo.aero.org by antares.aero.org (4.1/AMS-1.0) id AA23506 for cube-lovers@life.ai.mit.edu; Mon, 10 Apr 95 13:16:45 PDT To: cube-lovers@life.ai.mit.edu Subject: Singmaster's works Date: Mon, 10 Apr 1995 13:16:44 -0700 Message-Id: <10272.797545004@armadillo.aero.org> From: Ivan Filippenko Hello, Can anybody suggest how I might be able to get copies of David Singmaster's "Notes on Rubik's Magic Cube" and A. H. Frey and Singmaster's "Handbook of Cubik Math" ? How about Christoph Bandelow's "Inside Rubik's Cube and Beyond" ? I'm also looking for Chris Rowley's "The group of the Hungarian Magic Cube" (in Algebraic Structures and Applications, Proceedings of the First Western Australian Conference on Algebra, 1982). Many thanks, -- Ivan ivan@aero.org From @mail.uunet.ca:mark.longridge@canrem.com Fri Apr 14 03:04:40 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA22192; Fri, 14 Apr 95 03:04:40 EDT Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <186424-8>; Fri, 14 Apr 1995 03:03:03 -0400 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA08822; Fri, 14 Apr 95 02:57:27 EDT Received: by canrem.com (PCB-UUCP 1.1f) id 1DBB1F; Fri, 14 Apr 95 02:50:36 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Slice & Anti-Slice From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1089.5834.0C1DBB1F@canrem.com> Date: Fri, 14 Apr 1995 03:45:00 -0400 Organization: CRS Online (Toronto, Ontario) Some notes on the numeration of the slice and anti-slice groups.... Analysis of the 3x3x3 Slice & Anti-Slice Groups ----------------------------------------------- arrangements arrangements Moves Deep (2q or slice moves) (4q or double slice moves) 0 1 1 1 6 9 2 27 51 3 120 247 4 287 428 5 258 32 6 69 --- --- 768 768 arrangements arrangements Moves Deep (2q or anti-slice moves) (4q or double anti-slice moves) 0 1 1 1 6 9 2 27 51 3 120 265 4 423 864 5 1,098 1,785 6 1,770 2,017 7 1,650 1,008 8 851 144 9 198 ----- 6,144 From BRYAN@wvnvm.wvnet.edu Fri Apr 14 17:08:12 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27690; Fri, 14 Apr 95 17:08:12 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 3964; Fri, 14 Apr 95 17:06:54 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 0638; Fri, 14 Apr 1995 17:06:54 -0400 Message-Id: Date: Fri, 14 Apr 1995 17:06:48 -0400 (EDT) From: "Jerry Bryan" To: "Cube Lovers List" Subject: Repetitive Application of Elements of Q* Recall that Q* has been defined as the set of representatives Q* = {F*, R*, L*, B*, U*, D*, F'*, R'*, L'*, B'*, U'*, D'*} where * has been defined as a function selecting a representative element of an M-conjugacy class. I have done a little experimentation with cycles of the form X* ^ n. As long as the X* are directly in Q*, the sequences are quite short, and the final cycle is of length 2 in all cases. I found the latter surprising initially, but with the wisdom of hindsight, it was inevitable. Here is a table of lengths. Operation Length of Sequence F* 11 U* 10 L* 7 R* 3 D* 9 B* 2 F'* 7 U'* 10 L'* 4 R'* 6 D'* 7 B'* 2 A couple of points of clarification: 1. As an example, for F*, we take i(F*)^n (that is, apply F* to Start repeatedly). The sequence has 11 elements before it repeats, then the 10-th and 11-th element repeat over and over again. In all twelve cases, it is the last two elements of the sequence which repeat. 2. In order to replicate my results, you would have to define a representative element function exactly like mine. Every choice of representative element function can be expected to yield different results. To take a little more interesting case, I tried i(F*D'*) ^ n. In this case, there were 63 unique elements in the sequence, and then the 8-th through the 63-rd elements repeated. Hence, the final cycle had 56 elements rather than the 2 elements of the simpler cases. I suppose I could try quite a few other cases, but I have no idea how to predict how long the sequences or the terminal cycles might be. All I know to expect for sure is for things to be quite ill-behaved. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mreid@ptc.com Fri Apr 14 17:30:05 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA29204; Fri, 14 Apr 95 17:30:05 EDT Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA11438; Fri, 14 Apr 95 17:22:59 EDT Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA04391; Fri, 14 Apr 1995 16:03:31 -0400 Date: Fri, 14 Apr 1995 16:03:31 -0400 From: mreid@ptc.com (michael reid) Message-Id: <9504142003.AA04391@ducie> To: cube-lovers@ai.mit.edu, mark.longridge@canrem.com, CRSO.Cube@canrem.com Subject: more on the slice group Content-Length: 2394 mark's post got me thinking ... i made a quick hack for the slice group (which is easy to represent by fixing the corners). my figures concur with his. i wanted to see the number of local maxima. 90 degree number of number of slice turns positions local maxima 0 1 0 1 6 0 2 27 0 3 120 0 4 287 0 5 258 24 6 69 69 as i'd hoped, there are local maxima at distance 5. one such is: (FB') (RL') (U'D) (R2L2) = (R2L2) (F'B) (RL') (UD') = (R'L) (FB') (RL') (F'B) (U'D) = (U'D) (F'B) (RL') (U'D) (F'B) = (R'L) (UD') (F'B) (RL') (FB') (actually i think all are equivalent to this one under symmetries of the cube.) this is especially interesting because it is a local maximum in the full cube group (quarter turn metric) at distance 10q. according to jerry bryan's results, there are no local maxima within 9q of start, so this gives the closest local maximum. (there may well be others.) i also calculated for the other slice metric. in this metric, neighbors can have the same distance from start, so a "strong" local maximum is a position all of whose neighbors are strictly closer to start. a "weak" local maximum is a position none of whose neighbors are further from start. 90 or 180 degree number of number of strong number of weak slice turns positions local maxima local maxima 0 1 0 0 1 9 0 0 2 51 0 0 3 247 0 7 4 428 0 212 5 32 8 32 the strict local maxima are all equivalent under symmetries of the cube. they are the composition of pons asinorum with any of the eight positions called "six dots". in the same way, local maxima (within the antislice group) in the 90 degree antislice metric are local maxima in the full cube group (quarter turn metric). perhaps mark will tell us more about this. mike From BRYAN@wvnvm.wvnet.edu Fri Apr 14 23:33:20 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA02160; Fri, 14 Apr 95 23:33:20 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 4917; Fri, 14 Apr 95 21:12:54 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 4876; Fri, 14 Apr 1995 21:12:54 -0400 Message-Id: Date: Fri, 14 Apr 1995 21:12:53 -0400 (EDT) From: "Jerry Bryan" To: "Cube Lovers List" Subject: Re: Repetitive Application of Elements of Q* In-Reply-To: Message of 04/14/95 at 17:06:48 from BRYAN@wvnvm.wvnet.edu The astute reader will have noticed that there *has* to be an error in the table as it was originally posted. It is impossible for there to be two distinct sequences of length 2, because there is only one position unique up to M-conjugancy which is only one qturn from Start. All of the lengths in the original table except for one were short by one. I had two programs -- one to generate the sequences to a file, and a second to analyze the sequences. The first program did not write Start to the file, resulting in all the sequences except one being one short. Here follows the correction. (Incorrect) (Correct) > Operation Length Length > of of > Sequence Sequence > F* 11 12 > U* 10 11 > L* 7 8 > R* 3 4 > D* 9 10 > B* 2 2 !! > F'* 7 8 > U'* 10 11 > L'* 4 5 > R'* 6 7 > D'* 7 8 > B'* 2 3 >To take a little more interesting case, I tried i(F*D'*) ^ n. In this >case, there were 63 unique elements in the sequence, and then the >8-th through the 63-rd elements repeated. Hence, the final cycle had >56 elements rather than the 2 elements of the simpler cases. Similarly, here there were 64 unique elements in the sequence, with the 9-th through the 64-th elements repeated. The final cycle still (correctly) had 56 elements. The length of the final cycle has to be even, of course, since qturns are odd. > = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = >Robert G. Bryan (Jerry Bryan) (304) 293-5192 >Associate Director, WVNET (304) 293-5540 fax >837 Chestnut Ridge Road BRYAN@WVNVM >Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From @mail.uunet.ca:mark.longridge@canrem.com Sun Apr 16 21:14:23 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA28498; Sun, 16 Apr 95 21:14:23 EDT Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <187140-4>; Sun, 16 Apr 1995 21:15:31 -0400 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA04434; Sun, 16 Apr 95 21:10:34 EDT Received: by canrem.com (PCB-UUCP 1.1f) id 1DC195; Sun, 16 Apr 95 21:02:48 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Antislice revisited From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1095.5834.0C1DC195@canrem.com> Date: Sun, 16 Apr 1995 21:57:00 -0400 Organization: CRS Online (Toronto, Ontario) Mike Reid writes: > 90 or 180 degree number of number of strong number of weak > slice turns positions local maxima local maxma > > 0 1 0 0 > 1 9 0 0 > 2 51 0 0 > 3 247 0 7 > 4 428 0 212 > 5 32 8 32 > > the strict local maxima are all equivalent under symmetries of > the cube. they are the composition of pons asinorum with any > of the eight positions called "six dots". Very Interesting. Here's a 12q process for pons asinorum + 6 dots: (F2 B2) (T1 D3) (F1 B3) (L3 R1) (T1 D3) I have some thoughts on the relationship between the groups of the slice, antislice and squares, although some of it is old news, discovered by Mr. Singmaster back in 1980. The fact that, at most, 9 anti-slice moves always suffice to restore any position in this group I think is new. If we define Combo = < antislice , slice > I.e. Combo is the group generated by antislice and slice moves. Then.... Size (Combo) = 15,925,248 The Combo group fully includes the square's group and each group has some elements in common: Size (Intersection (antisl, slice, sq)) = 8 Also Size(Combo) / Size Sq) = 24 The Combo group has trivial centre. I should also note that.... Size (Intersection (sq, antisl)) = 256. Mike continues: > in the same way, local maxima (within the antislice group) in the > 90 degree antislice metric are local maxima in the full cube group > (quarter turn metric). perhaps mark will tell us more about this. Well, I didn't calculate local maxima for the anti-slice group, but I will look at it. I did create a file of all the processes for each anti-slice position, and most of the anti-slice group antipodes are quite ugly looking! One of the "not quite so ugly" antipodes: ( F1 B1 L1 R1)^3 + T1 D1 F1 B1 T1 D1 = 18 q The Centre elements of the Antislice group ------------------------------------------ There are 4 elements which commute with all elements of the group, the identity and the three 4 cross order 2 patterns. (F1 B1) (T1 D1) (L2 R2) (T1 D1) (F1 B1) (T2 D2) = 16 q TTT TTT TTT RLR BFB LRL FBF LLL FFF RRR BBB RLR BFB LRR FBF DDD DDD DDD Cheers! -> Mark <- From @mail.uunet.ca:mark.longridge@canrem.com Sun Apr 16 21:39:05 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA29757; Sun, 16 Apr 95 21:39:05 EDT Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <187145-1>; Sun, 16 Apr 1995 21:40:20 -0400 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA05565; Sun, 16 Apr 95 21:35:23 EDT Received: by canrem.com (PCB-UUCP 1.1f) id 1DC1A2; Sun, 16 Apr 95 21:29:19 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: DOTC From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1096.5834.0C1DC1A2@canrem.com> Date: Sun, 16 Apr 1995 22:04:00 -0400 Organization: CRS Online (Toronto, Ontario) I am a poor correspondent... No real excuse... I will send #4 out on Tuesday. Maybe I'll thrash future issues out in e-mail form. By the way, I thought your message on symmetric maneuvers was quite insightful. Did you ever find a symmetric move for "Cube in a Cube"? Cheers! -> Mark <- From patrick@athos.med.auth.gr Mon Apr 17 04:22:26 1995 Return-Path: Received: from athos.med.auth.gr by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA11715; Mon, 17 Apr 95 04:22:26 EDT Date: Mon, 17 Apr 1995 10:40:17 -0200 (GMT-0200) From: Patrick X-Sender: patrick@athos To: cube-lovers@life.ai.mit.edu Subject: subscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sirs ,I am sorry to bother you with junck mail, but I wish to join Cube-Lovers. And I have written to you two or three times at the address cube-lovers-REQUEST@life.ai.mit.edu and each time after a delay of a No. of days I got the response that my mail hadn't been delivered since you cuoldn't be found. Now I know you may not appreciate a new user littering your mail boxes with junk mail but I don't know any other way to join in--please excuse me. Yours sincerely Patrick From alan@curry.epilogue.com Mon Apr 17 23:54:43 1995 Return-Path: Received: from curry.epilogue.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA04644; Mon, 17 Apr 95 23:54:43 EDT Received: (from alan@localhost) by curry.epilogue.com (8.6.8/8.6.6) id XAA01827; Mon, 17 Apr 1995 23:50:25 -0400 Date: Mon, 17 Apr 1995 23:50:25 -0400 Message-Id: <17Apr1995.232904.Alan@LCS.MIT.EDU> From: Alan Bawden Sender: Cube-Lovers-Request@ai.mit.edu To: patrick@athos.med.auth.gr Cc: Cube-Lovers@ai.mit.edu In-Reply-To: Patrick's message of Mon, 17 Apr 1995 10:40:17 -0200 (GMT-0200) Subject: subscribe Date: Mon, 17 Apr 1995 10:40:17 -0200 (GMT-0200) From: Patrick Sirs ,I am sorry to bother you with junck mail, but I wish to join Cube-Lovers. And I have written to you two or three times at the address cube-lovers-REQUEST@life.ai.mit.edu and each time after a delay of a No. of days I got the response that my mail hadn't been delivered since you cuoldn't be found. Now I know you may not appreciate a new user littering your mail boxes with junk mail but I don't know any other way to join in--please excuse me. Yours sincerely Patrick I added your subscription a week ago. You even -responded- to one message I sent you, so I know that you -can- send mail to Cube-Lovers-Request. DO NOT SEND ANY FURTHER MESSAGES TO CUBE-LOVERS AS A WHOLE OR YOUR SUBSCRIPTION WILL BE TERMINATED. If you are experiencing trouble receiving Cube-Lovers mail, your only recourse is to complain to -me-, Cube-Lovers-Request -- I will try my best to help you. If, for some reason, you are unable to send mail to the -Request address, then you are simply screwed -- it will -never- do you any good to send mail to the entire mailing list about list administration. Everybody please note that the correct administrative address is: Cube-Lovers-Request@AI.MIT.EDU Some mail programs will re-write mail headers to make it look as though the address is "cube-lovers-request@life.ai.mit.edu", but it isn't. - Alan From BRYAN@wvnvm.wvnet.edu Thu Apr 20 12:00:31 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA07555; Thu, 20 Apr 95 12:00:31 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 8132; Thu, 20 Apr 95 11:36:06 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 5049; Thu, 20 Apr 1995 11:36:05 -0400 Message-Id: Date: Thu, 20 Apr 1995 11:35:56 -0400 (EDT) From: "Jerry Bryan" To: "Cube Lovers List" Subject: Re: Run Times, Storage Requirements, etc. In-Reply-To: Message of 02/22/95 at 18:28:13 from mreid@ptc.com On 02/22/95 at 18:28:13 mreid@ptc.com said: >i think this can be done much more efficiently. well, at least if you >set things up properly in the first place. >suppose that you use an order (for sorting positions) in which the corner >configuration is more significant than the edge configuration. Unfortunately, I made the edge more significant for sorting than the corner. I plan to change that in the near future. Strictly speaking, it would not be *too* bad to simply sort the same data in a different order. But the problem is worse than that. I also made the edge more significant for choosing a representative element than the corner. So I need a new representative element function to make the corner more significant for choosing the representative element. Such a change to the program would be trivial, but I would have to regenerate the data before it was re-sorted. Otherwise, the "same" corner configuration would not be the same; equivalent corner configurations would be M-conjugate rather than equal. >then, for each position X on your huge list, you need to check if >repr(X superflip) is on the list. since superflip only affects edges, >the corner configuration of X superflip is the same as that of X. >thus the same holds for repr(X superflip) and repr(X) = X. therefore, >you only need to look for repr(X superflip) nearby in the sorted list. Mike's note raises several interesting points. Suppose we write a cube Z as the disjoint union XY of corners X and edges Y. (We could say something like Z[C,E] = Z[C]*Z[E], but let's keep the notation a little simpler). A list of cubes in my data base would then look something like: X1 Y3 X1 Y7 X1 Y8 X2 Y1 X2 Y2 X2 Y5 etc. If we were sufficiently clever, we might be able to save some space by rewriting the list as something like: X1 Y3 Y7 Y8 X2 Y1 Y2 Y5 etc. In other words, store each corner position only one time. This is very similar to some of the indexing schemes that have been described to store large numbers of cubes very compactly. I have used some of these indexing schemes for corners only or edges only, but I have always rejected them for whole cubes (corners plus edges) because the representation is so sparse close to Start. (and you really can't get very far away from Start with whole cubes!) But the picture above just might work. I'm going to think about it. Next, notice that Mike's proposal for dealing with Pons Asinorum and Superflip results in a cube and its neighbor being stored very close together in the data base. In this case, a "neighbor" is a position Z composed with Pons Asinorum or Superflip or both. More typically, a neighbor is a position Z composed with an element from Q or from Q+H. What would be really nice (and which may not be possible) is some representation for the cube such that a cube Z and its neighbors Zq or Zh are stored very close together. Such a representation would be very helpful in particular for searches accomplished with massively parallel machines or with farms of workstations. But I certainly have never been able to find such a representation. I have yet to fully understand the Sims table (or FHL table) that many of you seem to use, so I don't know if it will do the trick or not. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mreid@ptc.com Thu Apr 20 15:46:58 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA21486; Thu, 20 Apr 95 15:46:58 EDT Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA11510; Thu, 20 Apr 95 15:45:01 EDT Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA19008; Thu, 20 Apr 1995 16:03:31 -0400 Date: Thu, 20 Apr 1995 16:03:31 -0400 From: mreid@ptc.com (michael reid) Message-Id: <9504202003.AA19008@ducie> To: cube-lovers@ai.mit.edu Subject: correction and an interesting example Content-Length: 1221 [ i sent a similar message several days ago, but it appears to have gotten lost. my apologies if anyone already got this. ] i wrote > in the same way, local maxima (within the antislice group) in the > 90 degree antislice metric are local maxima in the full cube group > (quarter turn metric). this isn't necessarily true. one must check that the minimal maneuvers (within the antislice group) for such positions are also minimal in the full group. the position i mentioned > (FB') (RL') (U'D) (R2L2) = [ ... ] is quickly checked to require 10 quarter turns, so indeed it is locally maximal. here's an example i found of a locally maximal position whose inverse is not locally maximal: A = B U2 F2 R U' R' B' R' U F2 U2 (15q) this position has six symmetries, generated by the cube rotation C_UFR and central reflection. using these symmetries we can give minimal maneuvers which end with a half turn of any face, and thus with any of the twelve quarter turns. the same is not true of its inverse, and we can easily check that there is no minimal maneuver for A which begins with the quarter turn B'. equivalently, the position A^-1 B' requires 16 quarter turns. mike From mreid@ptc.com Fri Apr 21 11:20:45 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA09079; Fri, 21 Apr 95 11:20:45 EDT Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA16270; Fri, 21 Apr 95 11:18:44 EDT Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA20597; Fri, 21 Apr 1995 11:37:18 -0400 Date: Fri, 21 Apr 1995 11:37:18 -0400 From: mreid@ptc.com (michael reid) Message-Id: <9504211537.AA20597@ducie> To: cube-lovers@ai.mit.edu, bryan@wvnvm.wvnet.edu Subject: Re: Run Times, Storage Requirements, etc. Content-Length: 858 jerry writes > So I need a new representative element function > to make the corner more significant for choosing the representative > element. Such a change to the program would be trivial, but I would > have to regenerate the data before it was re-sorted. i don't think you need to regenerate; you just need to put your old list through your new representative choosing function and sort the output. of course, regenerating would give a reasonable consistency check. > What would be really nice (and which may not be possible) is some > representation for the cube such that a cube Z and its neighbors > Zq or Zh are stored very close together. remember that the diameter of the group is small. (my guess is 21 face turns, 24 quarter turns.) so this isn't possible without resorting to a liberal definition of "very close". mike From @mail.uunet.ca:mark.longridge@canrem.com Mon Apr 24 04:12:38 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA28938; Mon, 24 Apr 95 04:12:38 EDT Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <212875-8>; Mon, 24 Apr 1995 04:13:36 -0400 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA11604; Sun, 23 Apr 95 22:40:35 EDT Received: by canrem.com (PCB-UUCP 1.1f) id 1DD97C; Sun, 23 Apr 95 22:33:19 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: Orders of Symmetry From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1104.5834.0C1DD97C@canrem.com> Date: Sun, 23 Apr 1995 23:29:00 -0400 Organization: CRS Online (Toronto, Ontario) >Date: Wed, 8 Dec 93 16:28:29 EST >From: hoey@AIC.NRL.Navy.Mil (Dan Hoey) >Message-Id: <9312082128.AA23718@Sun0.AIC.NRL.Navy.Mil> >To: mark.longridge@canrem.com (Mark Longridge), CRSO.Cube@canrem.com >Subject: Re: More corrections > >> * Hmmm, what are all the possible orders of symmetry? * > > M has subgroups of order 48, 24, 16, 12, 8, 6, 4, 3, 2, 1. Some of > these subgroups (e.g., A, C) are not symmetry groups of any position, > so I can't be sure there are positions of all these symmetry orders. Quite a while ago I asked Dan the question above, and I've thought a lot about the answer. So I decided to look at certain cube positions and I wrote a module to perform C and C + Sm where C = 24 rotations of the cube Sm = Central Reflection on any pattern I had in my database, and count how many different patterns resulted from the 48 operations. The following are some patterns which I found: Number of different Pattern patterns ------- --------- 48 R1 U1 24 L2 U2 16 Mark's Pattern 1 (18 q+h, 22 q) R2 U3 R1 D1 F1 B1 R3 L3 U1 D1 F3 U1 F3 U2 D3 B2 R2 U1 (Also 7 clockwise + 1 anticlockwise corner twist) 12 2 dot, 2 T, 2 ARM (sq group antipode, see p108) 8 6 Dot (a slice pattern) 6 2 DOT, 4 ARM (sq group antipode, see p99) 4 ???? 3 4 Dot pattern (slice pattern) 2 6 H pattern type 2, T2 B2 L2 T2 D2 L2 F2 T2 1 Pons Asinorum (6 X order 2) or all edges flipped It took a while to find a pattern which could be transformed 16 different ways. Still trying to find a pattern which will result in 4 distinct ways, but I am not optimistic. A random walk through the cube resulted in a pattern which would transform 48 ways in every case I tried. >> A) What is the next most commutative element (the pancentre?) >> after the 12-flip? > > (presumably, start excluded as well) > > i'll guess that these four conjugacy classes are tied for next. > > corner cycle structure: (1+)(1+)(1+)(1+)(1+)(1+)(1+)(1-) > edge cycle structure: (1)(1)(1)(1)(1)(1)(1)(1)(1)(1)(1)(1) Here's a small followup to the pancentre question. The reason why the 7 clockwise + 1 anticlockwise corner twist is the next most commutative element after the 12-flip & start is because it has the most number of cube elements (in this case corners) the same as possible without all the elements being the same, as with the 12-flip. It must be 7 clockwise + 1 anticlockwise corner twist because the next most commutative element effecting edges only would be the 10-flip and that would have 2 elements not the same as the rest instead of just 1. -> Mark <- From ismaia01@bh.bbc.co.uk Mon Apr 24 23:28:08 1995 Return-Path: Received: from ns.bbc.co.uk by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27779; Mon, 24 Apr 95 23:28:08 EDT Received: from mail.radio.bbc.co.uk (diskworld.radio.bbc.co.uk) by ns.bbc.co.uk with SMTP id AA07801 (5.65c/IDA-1.4.4 for ); Tue, 25 Apr 1995 04:28:06 +0100 Received: from nr-comms.radio.bbc.co.uk by mail.radio.bbc.co.uk with SMTP id AA15998 (5.67b/IDA-1.4.4 for ); Tue, 25 Apr 1995 04:28:01 +0100 X-Nvlenv-01Date-Transferred: 25-Apr-1995 4:22:54 -0400; at link1.bbc X-Nvlenv-01Date-Posted: 25-Apr-1995 04:28:35 -0400; at bh2.bbc To: cube-lovers@life.ai.mit.edu Message-Id: <5D6D7C370103370C@-SMF-> Subject: From: ismaia01@bh.bbc.co.uk(Abdi Ismail) Date: 25 Apr 95 04:28:50 EDT References: <5D6D7C370203370C@-SMF-> subscribe cube-lovers-request@ai.ai.mit.edu From @mail.uunet.ca:mark.longridge@canrem.com Tue Apr 25 23:05:02 1995 Return-Path: <@mail.uunet.ca:mark.longridge@canrem.com> Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA29970; Tue, 25 Apr 95 23:05:02 EDT Received: from portnoy.canrem.com ([198.133.42.17]) by mail.uunet.ca with SMTP id <194293-8>; Tue, 25 Apr 1995 23:06:32 -0400 Received: from canrem.com by portnoy.canrem.com (4.1/SMI-4.1) id AA03179; Tue, 25 Apr 95 23:01:31 EDT Received: by canrem.com (PCB-UUCP 1.1f) id 1DE11D; Tue, 25 Apr 95 22:50:25 -0500 To: cube-lovers@life.ai.mit.edu Reply-To: CRSO.Cube@canrem.com Sender: CRSO.Cube@canrem.com Subject: More Cube Orders From: mark.longridge@canrem.com (Mark Longridge) Message-Id: <60.1107.5834.0C1DE11D@canrem.com> Date: Tue, 25 Apr 1995 23:27:00 -0400 Organization: CRS Online (Toronto, Ontario) I said: > Still trying to find a pattern which will > result in 4 distinct ways, but I am not optimistic. Jerry adds: > As one more followup, for each symmetry group order in the above list, > there exists at least one cube. > That is, 96 of the 98 subgroups are symmetry groups for at > least one cube. The two "missing" subgroups -- A and C -- are of > order 24. But there is a third subgroup -- H -- of order 24 > (H is the set of 12 even rotations and 12 odd reflections), and there > are cube positions whose symmetry subgroup is H. Hence, there are > cube positions for every symmetry subgroup order. Well, I figure Jerry is correct and so I kept looking for the magic pattern which transforms 4 ways... Number of different Pattern patterns ------- --------- ... 4 6 flip (UF, UR, FR, DB, DL, BL) ... So there are 4 types of this 6 flip. Jerry has said before: > I believe that Dan and I have solved (sort of independently, and sort > of working together) the problem you pose (and I give Dan the bulk > of the credit). That is, how many cubs are there in each symmetry > group and each symmetry class? That sounds harder. Looks like I am specifying only the index of the symmetry subgroup... perhaps it makes sense to find out exactly which subgroup of M is the symmetry group of my positions. It all sounds vaguely familar.... but it will try again tomorrow. -> Mark <- From mbparker@share.ai.mit.edu Thu Apr 27 18:17:58 1995 Return-Path: Received: from share (mbparker.earthlink.net) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA26953; Thu, 27 Apr 95 18:17:58 EDT Received: by share (NX5.67e/NX3.0M) id AA09162; Thu, 27 Apr 95 14:49:35 -0700 Date: Thu, 27 Apr 95 14:49:35 -0700 From: Michael Benjamin Parker Message-Id: <9504272149.AA09162@share> To: Cube-Lovers@ai.mit.edu, Jennifer Dubin , Stan Isaacs , ccw@alumni.caltech.edu, Jonathan Haas , "Byon Garrabrant" , markc@deltanet.com, 73613.536@compuserve.com, 70410.1050@compuserve.com, ccw@alumni.caltech.edu, mklein@alumni.caltech.edu, mikeh@gordian.com, damon@gordian.com, whuang@cco.caltech.edu Subject: PUZZLE PARTY! in Orange County, CA; 1995 Apr. 29 (Sat) 7:00pm- Reply-To: mbparker@mit.edu Newsgroups: rec.puzzles,geometry.puzzles,rec.games.abstract,oc.general,la.general Dear puzzle lovers, Presenting MIT Club of Southern California's... PUZZLE PARTY 2! At our first puzzle party in February, Parker's place was packed with puzzlers of all sorts! Puzzling continued for hours, with the last hard-core, half-crazed puzzlers quitting at 5AM. The party featured the the puzzles and participation of the Master Puzzler himself, Mr. Jerry Slocum, a UCLA alumnus who has authored three puzzle books and owns an unmatched 20,000-piece private collection of puzzles. [Incidentally, on May 9th and June 22nd, Jerry and his Puzzle Museum will be featured in Start to Finish on the Discovery Channel.] If you didn't have a chance to participate, you'll have another opportunity at PUZZLE PARTY TWO. So, dig out your favorite brain teasers, mental games, IQ tests, and mechanical puzzles. If you have a puzzle-freak friend, bring him/her! Like the first party, this will be a leisurely puzzling event with amusing problems as well as food, drink, and conversation by the fireside. So grab your brain and some puzzles... and see you there! WHEN: Saturday, April 29th, 7pm until... WHERE: In Orange, CA; RSVP as below for directions. COST: For persons bringing puzzle(s), $4 for each MITCSC member and $6 for each non-member. For ``puzzle-less'' persons, $8 for each member and $10 for each non-member. RSVP: You may pay at the door, but first contact me so I'll know you are coming and can give you directions. Please email, fax, or phone in the following info: Your name, address, phone, fax, email, and what you're bringing: ___ puzzle-bearing members at $ 4 each: $___ ___ puzzle-bearing non-members at $ 6 each: $___ ___ puzzle-less members at $ 8 each: $___ ___ puzzle-less non-members at $10 each: $___ ___ <- total persons total cost -> $___ total number of puzzles being brought ___ Michael B. Parker, MIT '89 email mbparker@mit.edu or mbparker@cytex.com 1-800-MBPARKER(627-2753) xLIVE(5483) MESG(6374) PAGE(7243) FAXX(3299) live 714-639-6436, mesg pager 714-413-2090, fax 714-639-5381 From 100343.236@compuserve.com Sat Apr 29 15:31:10 1995 Return-Path: <100343.236@compuserve.com> Received: from dub-img-3.compuserve.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA13118; Sat, 29 Apr 95 15:31:10 EDT Received: by dub-img-3.compuserve.com (8.6.10/5.941228sam) id PAA19423; Sat, 29 Apr 1995 15:31:10 -0400 Date: 29 Apr 95 15:26:03 EDT From: Dominic Parkinson <100343.236@compuserve.com> To: "AI.AI.MIT.EDU" Subject: subscribe RUBIKS CUBE Dominic Parkinson Message-Id: <950429192603_100343.236_EHQ79-2@CompuServe.COM> subscribe RUBIKS CUBE Dominic Parkinson From miz007@admin.connect.more.net Wed May 3 09:11:13 1995 Return-Path: Received: from admin (admin.connect.more.net) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA19954; Wed, 3 May 95 09:11:13 EDT Received: from [204.185.50.22] by admin (5.0/SMI-SVR4) id AA13713; Wed, 3 May 1995 06:04:10 -0500 Message-Id: <9505031104.AA13713@admin> X-Sender: miz007@admin.connect.more.net (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 May 1995 06:06:02 -0700 To: "AI.AI.MIT.EDU" From: miz007@admin.connect.more.net (Tyler Duncan) Content-Length: 0 unsubscribe RUBIKS CUBE Tyler Duncan From lag@erc.msstate.edu Wed May 3 12:11:59 1995 Return-Path: Received: from Phoenix.ERC.MsState.Edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA02075; Wed, 3 May 95 12:11:59 EDT Received: from water.ERC.MsState.Edu (lag@Water.ERC.MsState.Edu [192.208.140.162]); by Phoenix.ERC.MsState.Edu using ESMTP (8.6.8.1/7.0m-FWP-MsState); id LAA24178; Wed, 3 May 1995 11:11:27 -0500 From: "Ludwig A. Goon" Received: by water.ERC.MsState.Edu (8.6.8.1/6.0c-FWP); id LAA07405; Wed, 3 May 1995 11:11:53 -0500 Date: Wed, 3 May 1995 11:11:53 -0500 Message-Id: <199505031611.LAA07405@water.ERC.MsState.Edu> To: CUBE-LOVERS@life.ai.mit.edu unsubscribe RUBIKS CUBE Ludwig Goon lag@erc.msstate.edu From lag@erc.msstate.edu Wed May 3 16:06:43 1995 Return-Path: Received: from Phoenix.ERC.MsState.Edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA17510; Wed, 3 May 95 16:06:43 EDT Received: from athena.ERC.MsState.Edu (lag@Athena.ERC.MsState.Edu [192.208.145.68]); by Phoenix.ERC.MsState.Edu using ESMTP (8.6.8.1/7.0m-FWP-MsState); id PAA29389; Wed, 3 May 1995 15:06:20 -0500 From: "Ludwig A. Goon" Received: by athena.ERC.MsState.Edu (8.6.8.1/6.0c-FWP); id PAA09711; Wed, 3 May 1995 15:06:15 -0500 Message-Id: <199505032006.PAA09711@athena.ERC.MsState.Edu> Subject: unsubscribe To: CUBE-LOVERS@life.ai.mit.edu Date: Wed, 3 May 1995 15:06:15 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 13 unsubscribe From mouse@collatz.mcrcim.mcgill.edu Thu May 4 17:08:31 1995 Return-Path: Received: from Collatz.McRCIM.McGill.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA25728; Thu, 4 May 95 17:08:31 EDT Received: (root@localhost) by 2560 on Collatz.McRCIM.McGill.EDU (8.6.10 Mouse 1.0) id RAA02560 for cube-lovers@ai.mit.edu; Thu, 4 May 1995 17:08:15 -0400 Date: Thu, 4 May 1995 17:08:15 -0400 From: der Mouse Message-Id: <199505042108.RAA02560@Collatz.McRCIM.McGill.EDU> To: cube-lovers@ai.mit.edu Subject: Re: SBP "Magic sQ" Back on > Date: Fri, 8 Jul 1994 15:24:30 -0400 I quoted and wrote: >> Sliding Block Puzzle "Magic sQ" >> Fig.1 is incomplete. +---+---+---+ >> Can you complete a magic square | 2 | 9 | 4 | >> with minimum sliding steps? +---+---+---+ >> | 7 | 5 | 3 | >> You, very easy or not? +---+---+---+---+ >> | 1 | 6 | 8 | | Fig.1 >> +---+---+---+---+ > [...]. It's then just a straightforward tree search to find a > solution. A simple brute-force "meet in the middle" breadth-first > search finds a solution easily. If we mark the squares as 0 1 2 3 4 5 6 7 8 9 then I gave a solution which makes the blank space follow the path 8 7 6 3 4 5 8 7 4 1 2 5 8 7 6 3 4 1 0 3 4 7 6 3 0 1 4 7 8 9. I remarked: > This solution exhibits curious near-symmetries in portions of the > path taken by the blank space. [...] Perhaps I should modify the > program so it reports _all_ solutions of this length; I finally got around to generating all minimal-length solutions. It turns out, curiously enough, that each solution is uniquely determined by the pattern of its middle position. There are ten solutions, listed here in terms of the path taken by the blank space, with the middle position written out: 2 3 * 8 7 4 3 0 1 2 5 4 1 0 3 4 1 4 9 7 5 8 7 6 3 4 1 2 5 8 7 4 5 8 1 5 6 2 5 * 8 5 4 3 0 1 2 5 4 1 0 3 4 1 4 9 7 5 8 7 6 3 4 5 8 7 4 1 2 5 8 1 6 3 7 2 9 8 7 4 5 2 1 0 3 4 5 8 7 6 3 4 * 6 1 2 5 8 7 6 3 4 1 0 3 4 5 8 3 1 5 7 4 3 8 7 4 1 0 3 4 1 2 5 8 7 6 3 2 * 6 1 2 5 8 7 4 1 0 3 6 7 4 5 8 9 1 5 2 5 7 8 5 2 1 4 3 0 1 4 5 2 1 0 3 4 * 9 5 8 7 6 3 4 5 8 7 4 1 2 5 8 1 6 3 2 4 6 8 7 6 3 4 5 8 7 4 1 2 5 8 7 5 * 1 1 0 3 6 7 4 3 0 1 4 3 6 7 8 7 9 3 2 4 6 8 7 4 5 8 7 6 3 4 1 2 5 8 7 3 9 5 3 4 1 0 3 4 7 6 3 0 1 4 5 8 * 7 1 2 4 6 8 7 6 3 4 5 8 7 4 1 2 5 8 7 5 9 1 3 4 1 0 3 4 7 6 3 0 1 4 7 8 * 7 3 2 3 6 8 7 4 1 2 5 8 7 6 3 4 1 2 5 9 4 5 7 4 1 0 3 6 7 4 3 0 1 4 5 8 7 1 * 2 9 7 8 7 4 3 0 1 4 5 2 1 0 3 4 5 3 4 6 7 6 3 4 1 2 5 8 7 6 3 4 5 8 1 5 * Of course, whether this actually matters to anyone is another story :-) der Mouse mouse@collatz.mcrcim.mcgill.edu From Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk Mon May 8 03:09:54 1995 Return-Path: Received: from LNG.HHA.DK by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA20671; Mon, 8 May 95 03:09:54 EDT Message-Id: <9505080709.AA20671@life.ai.mit.edu> Received: by LNG.HHA.DK with VINES ; Mon, 8 May 95 09:12:02 DST Date: Mon, 8 May 95 09:11:57 DST From: Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk Subject: unsubscribe To: CUBE-LOVERS@life.ai.mit.edu Cc: unsubscribe From alan@curry.epilogue.com Mon May 8 04:01:19 1995 Return-Path: Received: from curry.epilogue.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA21090; Mon, 8 May 95 04:01:19 EDT Received: (from alan@localhost) by curry.epilogue.com (8.6.8/8.6.6) id EAA11728; Mon, 8 May 1995 04:00:53 -0400 Date: Mon, 8 May 1995 04:00:53 -0400 Message-Id: <8May1995.031910.Alan@LCS.MIT.EDU> From: Alan Bawden Sender: Cube-Lovers-Request@ai.mit.edu To: Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk Cc: CUBE-LOVERS@life.ai.mit.edu In-Reply-To: Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk's message of Mon, 8 May 95 09:11:57 DST <9505080709.AA20671@life.ai.mit.edu> Subject: unsubscribe Date: Mon, 8 May 95 09:11:57 DST From: Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk Subject: unsubscribe To: CUBE-LOVERS@life.ai.mit.edu Cc: unsubscribe For crying out loud, do -not- send administrative requests to the -entire- mailing list. You're the third idiot to make this mistake recently, so I guess I really do have to bother everybody myself with a reminder. THINK! THINK! THINK! If you wanted to stop your subscription to a magazine, would you send postal mail to -all- of the other subscribers? Send all administrative requests to: Cube-Lovers-Request@AI.MIT.EDU Everybody got that? From BRYAN@wvnvm.wvnet.edu Tue May 9 09:12:52 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA12086; Tue, 9 May 95 09:12:52 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 3544; Tue, 09 May 95 08:48:24 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 1219; Tue, 9 May 1995 08:48:24 -0400 Message-Id: Date: Tue, 9 May 1995 08:48:23 -0400 (EDT) From: "Jerry Bryan" To: "Cube Lovers List" Subject: Re: more on the slice group In-Reply-To: Message of 04/14/95 at 16:03:31 from mreid@ptc.com On 04/14/95 at 16:03:31 mreid@ptc.com said: >mark's post got me thinking ... i made a quick hack for the slice >group (which is easy to represent by fixing the corners). my >figures concur with his. i wanted to see the number of local maxima. > 90 degree number of number of > slice turns positions local maxima > 0 1 0 > 1 6 0 > 2 27 0 > 3 120 0 > 4 287 0 > 5 258 24 > 6 69 69 >as i'd hoped, there are local maxima at distance 5. one such is: > (FB') (RL') (U'D) (R2L2) = > (R2L2) (F'B) (RL') (UD') = > (R'L) (FB') (RL') (F'B) (U'D) = > (U'D) (F'B) (RL') (U'D) (F'B) = > (R'L) (UD') (F'B) (RL') (FB') >(actually i think all are equivalent to this one under symmetries >of the cube.) >this is especially interesting because it is a local maximum in the >full cube group (quarter turn metric) at distance 10q. according >to jerry bryan's results, there are no local maxima within 9q >of start, so this gives the closest local maximum. (there may well >be others.) Results for the slice group under M-conjugacy: Level Number of Number of Positions Local Maxima 0 1 0 1 1 0 2 2 0 3 6 0 4 16 0 5 15 1 6 9 9 Mike's conjecture that all 24 positions which are a local maxima at level 5 are equivalent under M-conjugation is correct. I don't yet understand why Mike's position is a local maximum in the full cube group. But assuming it is, it is not only the shortest local maximum, it is the first local maximum which is not Q-transitive (i.e, we have |{m'Xm}|=24, hence we have |Symm(X)|=2, and the size of the symmetry groups for Q-transitive positions must be divisible by 12.). = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From hoey@aic.nrl.navy.mil Tue May 9 12:11:08 1995 Return-Path: Received: from Sun0.AIC.NRL.Navy.Mil by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA22920; Tue, 9 May 95 12:11:08 EDT Received: by Sun0.AIC.NRL.Navy.Mil (4.1/SMI-4.0) id AA26374; Tue, 9 May 95 12:11:02 EDT Date: Tue, 9 May 95 12:11:02 EDT From: hoey@aic.nrl.navy.mil (Dan Hoey) Message-Id: <9505091611.AA26374@Sun0.AIC.NRL.Navy.Mil> To: "Jerry Bryan" Cc: "Cube Lovers List" Subject: Re: more on the slice group Jerry Bryan writes: > I don't yet understand why Mike's position is a local maximum in the > full cube group. But assuming it is, it is not only the shortest > local maximum, it is the first local maximum which is not > Q-transitive (i.e, we have |{m'Xm}|=24, hence we have |Symm(X)|=2, > and the size of the symmetry groups for Q-transitive positions > must be divisible by 12.). No, the 4-spot pattern is also a local maximum at 12 qtw, although its symmetry group is of order 16. Jim Saxe and I reported this on 22 March 1981, in "No short relations and a new local maximum". Dan Hoey@AIC.NRL.Navy.Mil From BRYAN@wvnvm.wvnet.edu Tue May 9 18:17:13 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA15460; Tue, 9 May 95 18:17:13 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 7466; Tue, 09 May 95 15:32:53 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 7823; Tue, 9 May 1995 15:31:34 -0400 Message-Id: Date: Tue, 9 May 1995 15:31:32 -0400 (EDT) From: "Jerry Bryan" To: "Cube Lovers List" Subject: Re: more on the slice group In-Reply-To: Message of 04/14/95 at 16:03:31 from mreid@ptc.com On 04/14/95 at 16:03:31 mreid@ptc.com said: >i also calculated for the other slice metric. in this metric, >neighbors can have the same distance from start, so a "strong" >local maximum is a position all of whose neighbors are strictly >closer to start. a "weak" local maximum is a position none of >whose neighbors are further from start. I might prefer an alternative set of definitions: 1) a local maximum is a position none of whose neighbors are further from Start, 2) a strong local maximum is a position all of whose neighbors are strictly closer to Start, and 3) a weak local maximum is a local maximum which is not a strong local maximum. But in the table which follows, I adopt Mike's definition. > 90 or 180 degree number of number of strong number of weak > slice turns positions local maxima local maxima > 0 1 0 0 > 1 9 0 0 > 2 51 0 0 > 3 247 0 7 > 4 428 0 212 > 5 32 8 32 >the strict local maxima are all equivalent under symmetries of >the cube. they are the composition of pons asinorum with any >of the eight positions called "six dots". Under M-conjugacy, we have 90 or 180 degree number of number of strong number of weak slice turns positions local maxima local maxima 0 1 0 0 1 2 0 0 2 4 0 0 3 15 0 2 4 25 0 16 5 3 1 3 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From BRYAN@wvnvm.wvnet.edu Tue May 9 19:19:39 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA18463; Tue, 9 May 95 19:19:39 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 9269; Tue, 09 May 95 19:18:19 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 5433; Tue, 9 May 1995 19:18:19 -0400 Message-Id: Date: Tue, 9 May 1995 19:18:18 -0400 (EDT) From: "Jerry Bryan" To: Subject: Re: Orders of Symmetry In-Reply-To: Message of 04/23/95 at 23:29:00 from mark.longridge@canrem.com On 04/23/95 at 23:29:00 mark.longridge@canrem.com said: > It took a while to find a pattern which could be transformed 16 >different ways. Still trying to find a pattern which will >result in 4 distinct ways, but I am not optimistic. A random walk >through the cube resulted in a pattern which would transform >48 ways in every case I tried. For well over 99% of the positions we have |{m'Xm}|=48, so it will be a long time before a random walk finds anything. If my quick and dirty calculations are correct, |{m'Xm}|=48 for in excess of 99.9999986% of the M-conjugate classes. For positions themselves, the percentage would be higher still. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From BRYAN@wvnvm.wvnet.edu Thu May 11 03:58:11 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA04002; Thu, 11 May 95 03:58:11 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 9222; Wed, 10 May 95 22:38:33 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 9300; Wed, 10 May 1995 22:38:33 -0400 Message-Id: Date: Wed, 10 May 1995 22:38:32 -0400 (EDT) From: "Jerry Bryan" To: "Cube Lovers List" Subject: Re: more on the slice group In-Reply-To: Message of 05/09/95 at 12:11:02 from hoey@AIC.NRL.Navy.Mil On 05/09/95 at 12:11:02 hoey@AIC.NRL.Navy.Mil said: >No, the 4-spot pattern is also a local maximum at 12 qtw, although its >symmetry group is of order 16. Jim Saxe and I reported this on 22 >March 1981, in "No short relations and a new local maximum". Argh! After Dan and Mike pointed this out, I did remember having seen it in the archives. Worse still, Dan pointed it out again on 3 August 1992. But since it has come up, let's take a brief look at the 22 March 1981 note. > With five-qtw searches, it became possible to check another >conjecture, using an approach that Jim suggested. The four-spot >pattern > > U U U > U U U > U U U > > R R R B B B L L L F F F > R L R B F B L R L F B F > R R R B B B L L L F F F > > D D D > D D D > D D D > >is solvable in twelve qtw, either by (FFBB)(UD')(LLRR)(UD') or by its >inverse, (DU')(LLRR)(DU')(FFBB). It is immediate that a twelve qtw >path from this pattern to START can begin with a twist of any face in >either direction. The program was used to verify that there are no ten >qtw paths. (It generated the set of positions attainable at most five >qtw from START and the set of positions obtainable from the four-spot >in at most five qtw, and verified that the intersection of the two sets >is empty.) Thus the four-spot is exactly twelve qtw from START and all >its neighbors are exactly eleven qtw from START, proving that the >four-spot is a local maximum. > Call the 4-spot s. Then, the twelve neighbors form two M-conjugacy classes: N1={sL,sL',sF,sF',sR,sR',sB,sB'} and N2={sU,sU',sD,sD'}. Also, we have s'=s. Dan and Jim's solution starts in N1 and ends with a quarter-turn from N2, and since s'=s, we can say "or vice versa". Hence, we can start a solution with any of the twelve quarter turns, and therefore s is a local maximum. There are other positions with the same symmetry characteristics as the 4-spot. That is, there are other positions for which the symmetry group contains sixteen elements. There are only three subgroups of M containing sixteen elements, and the three subgroups are M conjugate. The three M-conjugates of the 4-spot position correspond to the three conjugate subgroups of M containing sixteen elements. But what of other positions with the same symmetry group? For example, if the edges of the 4-spot are all flipped, is the position a local maximum? I don't know, but it is interesting to see how far we can get without knowing a process. Call the 4-spot with all edges flipped t. Then, we certainly have t'=t. Is this true of all positions whose symmetry group contains sixteen elements? Also, we certainly have the twelve neighbors forming M-conjugacy classes similar to those for s, N1 with eight elements and N2 with four. Is this true of all positions whose symmetry group contains sixteen elements? Finally, a solution either starts in N1 or starts in N2. If starting in N1 implies ending with a quarter-turn from N2 or vice versa, then t is a local maximum. Can we prove such a thing without actually finding a solution? = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From mreid@ptc.com Thu May 11 17:40:36 1995 Return-Path: Received: from ptc.com (poster.ptc.com) by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27427; Thu, 11 May 95 17:40:36 EDT Received: from ducie by ptc.com (5.0/SMI-SVR4-NN) id AA03762; Thu, 11 May 95 17:38:35 EDT Received: by ducie (1.38.193.4/sendmail.28-May-87) id AA02793; Thu, 11 May 1995 17:57:14 -0400 Date: Thu, 11 May 1995 17:57:14 -0400 From: mreid@ptc.com (michael reid) Message-Id: <9505112157.AA02793@ducie> To: cube-lovers@ai.mit.edu Subject: Re: more on the slice group Content-Length: 1749 jerry writes > There are other positions with the same symmetry characteristics as > the 4-spot. That is, there are other positions for which the > symmetry group contains sixteen elements. There are only three subgroups > of M containing sixteen elements, and the three subgroups are M conjugate. these subgroups are the 2-sylow subgroups of M. one of sylow's theorems states that any two p-sylow subgroups are conjugate. one of these subgroups is the group of symmetries that preserve the U-D axis. call this subgroup "P". (this is also the group of symmetries of the intermediate subgroup of kociemba's algorithm.) jerry asks about P-symmetric positions. coincidentally, i happened to investigate these a few weeks back, and here's what i found: (i calculated by hand, so i'd be grateful for any confirmation.) there are 128 P-symmetric positions, 4 of which are M-symmetric. they form a subgroup of the cube group (of course) which is isomorphic to a direct product of 7 copies of C_2. in particular, each such position has order 2 (or 1) as a group element. thus, the answer to jerry's question > Call the 4-spot with all edges flipped t. Then, we certainly have > t'=t. Is this true of all positions whose symmetry group contains > sixteen elements? is "yes". for what it's worth, this group of 128 positions can be generated by the seven elements superflip pons asinorum four spots slice squared ( U2 D2 ) eight flip ( FB UD RL FB UD RL ) four pluses ( R2 F2 R2 U'D F2 R2 F2 UD' ) four swapped corner pairs ( D' B2 U'D F2 U2 L2 B2 L2 B2 U2 L2 F2 U ) however, these positions are not all locally maximal; for instance U2 D2 is not. mike From patrick@athos.med.auth.gr Fri May 12 09:10:24 1995 Return-Path: Received: from athos.med.auth.gr by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA01708; Fri, 12 May 95 09:10:24 EDT Date: Fri, 12 May 1995 15:33:12 -0200 (GMT-0200) From: Patrick X-Sender: patrick@athos To: Alan Bawden Cc: Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk, CUBE-LOVERS@life.ai.mit.edu Subject: Re: unsubscrib In-Reply-To: <8May1995.031910.Alan@LCS.MIT.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a complaint to make about the way mr. Allan Bawden treats cube -lovers. 1)Alot of people are not sure how to join a group when they start out to join one. In fact in most cases the people are new to the Internet , and in order to learn how to do things in the famous net , they can join a news group . (I am not sugesting that joining a news group teaches them about the internet but its one of the things they can do) 2)Now if Mr Allan responds to their mistakes very rudly ,e.g On Mon, 8 May 1995, Alan Bawden wrote: > Date: Mon, 8 May 95 09:11:57 DST > From: Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk > Subject: unsubscribe > To: CUBE-LOVERS@life.ai.mit.edu > Cc: > > unsubscribe > > For crying out loud, do -not- send administrative requests to the -entire- > mailing list. You're the third idiot to make this mistake recently, so I > guess I really do have to bother everybody myself with a reminder. > 3)"you're the third idiot--" etc I mean one gets quite upset about the whole thing and one begins to question if it's worth it joining the news group if they are so rude. I can assure you it's a good thing we communicate by computer, because a lot of harm might have been caused on the person of Mr. Allan were he speaking straight to a person---I'm sure he does'nt speak that way to anyone (even to his kids should he be married with children) 4)I sugest Mr. Allan be firm but polite . It's best to keep the correspondence bussness - like. In that way we still remain friends ,and quite understand what is expected of us to do. > THINK! THINK! THINK! If 5) It sounds like Mr. Allan thinks that the qube member doesn't think. For people interested in cubing thats an insult. We think of ourselves as people who can think --on an overage better than most people. you wanted to stop your subscription to a > magazine, would you send postal mail to -all- of the other subscribers? > > Send all administrative requests to: > > Cube-Lovers-Request@AI.MIT.EDU > > Everybody got that? > Medicine is for every one Bravo to Doctors without frontiers Zimbabwe will always be there From ed@odi.com Fri May 12 09:47:07 1995 Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA03706; Fri, 12 May 95 09:47:07 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA07906; Fri, 12 May 1995 09:44:14 -0400 Return-Path: Received: from heinz.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA25891; Fri, 12 May 95 09:44:14 EDT From: Ed Schwalenberg Received: (ed@localhost) by heinz.odi.com (8.6.12/8.6.12) id JAA13150; Fri, 12 May 1995 09:44:13 -0400 Date: Fri, 12 May 1995 09:44:13 -0400 Message-Id: <199505121344.JAA13150@heinz.odi.com> To: patrick@athos.med.auth.gr Cc: Cube-Lovers-Request@ai.mit.edu, Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk, CUBE-LOVERS@life.ai.mit.edu In-Reply-To: Patrick's message of Fri, 12 May 1995 15:33:12 -0200 (GMT-0200) Subject: unsubscrib Organization: Object Design, 25 Mall Rd, Burlington, MA 01803 - 617-674-5337 Date: Fri, 12 May 1995 15:33:12 -0200 (GMT-0200) From: Patrick I have a complaint to make about the way mr. Allan Bawden treats cube -lovers. 1)Alot of people are not sure how to join a group when they start out to join one. Alan's complaint is not about people who are trying to join; they might legitimately be confused about how to go about it. However, to prevent the sort of idiocy that he's complaining about, he sends each new member of the list a "welcome" message that, among other things, says something like "Please SAVE this message so you will know how to unsubscribe when you later decide to do so." If you fail to read his polite-but-firm message and proceed to do exactly what he warns you not to do, you must expect him to get legitimately angry. From SCHMIDTG@beast.cle.ab.com Fri May 12 09:58:46 1995 Return-Path: Received: from beast.cle.ab.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA04759; Fri, 12 May 95 09:58:46 EDT Date: Fri, 12 May 1995 9:58:43 -0400 (EDT) From: SCHMIDTG@beast.cle.ab.com To: cube-lovers@ai.mit.edu Message-Id: <950512095843.20201a78@iccgcc.cle.ab.com> Subject: Rubik's Robot At the IPC show, a trade show for industrial controls held in Detroit this week, Kawasaki had a Rubik's cube solving robot. The robot has two arms and hands and a video camera. The robot is handed a scrambled cube, orients the cube in front of the camera until it has seen enough faces to deduce the current state of the cube; displays the number of moves required for its solution; and then solves the cube using both hands (grippers). The robot is capable of manipulating the entire cube using only its hands, without relying on anything else such as a flat surface. Unfortunately, I missed the show so this information was obtained second hand. -- Greg schmidtg@iccgcc.decnet.ab.com From mouse@collatz.mcrcim.mcgill.edu Fri May 12 10:35:18 1995 Return-Path: Received: from Collatz.McRCIM.McGill.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA06674; Fri, 12 May 95 10:35:18 EDT Received: (root@localhost) by 22790 on Collatz.McRCIM.McGill.EDU (8.6.10 Mouse 1.0) id KAA22790; Fri, 12 May 1995 10:35:04 -0400 Date: Fri, 12 May 1995 10:35:04 -0400 From: der Mouse Message-Id: <199505121435.KAA22790@Collatz.McRCIM.McGill.EDU> To: cube-lovers@life.ai.mit.edu Subject: Re: unsubscrib Cc: patrick@athos.med.auth.gr Since Patrick went public with his[%] complaint, I'll defend publicly, even though neither one is really on-topic for cube-lovers. I hope Alan won't get too upset, and I really hope this doesn't turn into a flamewar; cube-lovers has been notably free of them in the time I've been on it. [%] Gender assumed from the given name. > I have a complaint to make about the way mr. Allan Bawden (Whose name you consistently misspell, incidentally, thus being rather rude to him yourself. You also make many (other) spelling mistakes, but this one you make consistently.) > treats cube-lovers. > 1)Alot of people are not sure how to join a group when they start out > to join one. In fact in most cases the people are new to the > Internet , and in order to learn how to do things in the famous net , > they can join a news group . > (I am not sugesting that joining a news group teaches them about the > internet but its one of the things they can do) You seem to be under the impression that cube-lovers is a "news group". It's not; it's a mailing list. If you don't know the difference and can't find anything local to explain it, send me mail privately and I'll try to explain it. Yes, it's true, that's one of the things newbies can do. But that does not mean that it's a good thing to do, nor that it's reasonable to try to do it without first learning the correct way to do it. And when someone stumbles into a milieu without having first bothered to learn the rudiments of etiquiette as practiced therein, I don't feel it's unreasonable to meet that someone with a certain degree of rejection. > 2)Now if Mr Allan responds to their mistakes very rudly ,e.g I notice your address is in Greece, so I'll excuse this on grounds of ignorance. In English, one does not use titles (such as Mr.) with given names. It would be just "Alan" (not "Allan", since he's Alan Bawden, not Allan Bawden), or "Mr. Bawden". >> Date: Mon, 8 May 95 09:11:57 DST >> From: Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk >> Subject: unsubscribe >> To: CUBE-LOVERS@life.ai.mit.edu >> Cc: >> >> unsubscribe >> >> For crying out loud, do -not- send administrative requests to the >> -entire- mailing list. You're the third idiot to make this mistake >> recently, so I guess I really do have to bother everybody myself >> with a reminder. > 3)"you're the third idiot--" etc I mean one gets quite upset about > the whole thing and one begins to question if it's worth it joining > the news group if they are so rude. I don't consider it excessive to be a little harsh to people who are being that rude. When Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk was subscribed to the list to begin with, he[%] was sent a document explicitly describing how to unsubscribe. [%] Gender assumed from what looks like a given name in the address. If a _subscribe_ request goes to the whole list, it's still someone stumbling in in ignorance. But at least it can mostly be excused as ignorance. An _unsubscribe_ request can't; anyone with cause to send an unsubscribe request must already have subscribed, and thus been told the correct way to unsubscribe. > 4)I sugest Mr. Allan be firm but polite . It's best to keep the > correspondence bussness - like. In that way we still remain friends > ,and quite understand what is expected of us to do. I suggest you cut "Mr. Allan" some slack. I have participated in and mailing lists for many years now, and overall, Alan Bawden is one of the best list admins I've ever seen. Yes, it would be better if he[%] could remain firm and polite in the face of such provocation. But (apparently unlike you) I don't expect perfection from him. [%] Again, gender assumed from the given name. (English needs a good gender-neutral animate set of pronouns.) Perhaps that merely reflects on the poor crop of list admins available. I don't think so; I certainly doubt I would do much better. Perhaps you feel you could do better; I invite you to try. Start up a list of your own and see how it goes. >> THINK! THINK! THINK! If > 5) It sounds like Mr. Allan thinks that the qube member doesn't > think. I'm inclined to agree. If Frank=Lindgreen%DATLING%HHASPR@lng.hha.dk had thought enough to bother rereading the instructions sent when he subscribed to the list, or even had bothered to learn basic netiquette for Internet mailing lists in general, he would have known better than to send the unsubscribe request to the whole list. > For people interested in cubing thats an insult. We think of > ourselves as people who can think --on an overage better than most > people. "can think" != "do think". As is often amply demonstrated on the net. >> Send all administrative requests to: >> Cube-Lovers-Request@AI.MIT.EDU >> Everybody got that? This is important enough to bear re-quoting, I feel. der Mouse mouse@collatz.mcrcim.mcgill.edu From news@nntp-server.caltech.edu Fri May 12 11:45:39 1995 Return-Path: Received: from piccolo.cco.caltech.edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA11038; Fri, 12 May 95 11:45:39 EDT Received: from gap.cco.caltech.edu by piccolo.cco.caltech.edu with ESMTP (8.6.7/DEI:4.41) id IAA23880; Fri, 12 May 1995 08:45:36 -0700 Received: by gap.cco.caltech.edu (8.6.7/DEI:4.41) id IAA24684; Fri, 12 May 1995 08:45:34 -0700 To: mlist-cube-lovers@nntp-server.caltech.edu Path: whuang From: whuang@cco.caltech.edu (Wei-Hwa Huang) Newsgroups: mlist.cube-lovers Subject: Re: Rubik's Robot Date: 12 May 1995 15:45:33 GMT Organization: California Institute of Technology, Pasadena Lines: 18 Message-Id: <3ovvqt$o3a@gap.cco.caltech.edu> References: <950512095843.20201a78@iccgcc.cle.ab.com> Nntp-Posting-Host: accord.cco.caltech.edu X-Newsreader: NN version 6.5.0 #12 (NOV) SCHMIDTG@beast.cle.ab.com writes: >At the IPC show, a trade show for industrial controls held in Detroit this >week, Kawasaki had a Rubik's cube solving robot. The robot has two arms and >hands and a video camera. The robot is handed a scrambled cube, orients the >cube in front of the camera until it has seen enough faces to deduce the >current state of the cube; displays the number of moves required for its >solution; and then solves the cube using both hands (grippers). The robot >is capable of manipulating the entire cube using only its hands, without >relying on anything else such as a flat surface. Unfortunately, I missed >the show so this information was obtained second hand. More information can be found by the WWW. I remember putting a link to it on one of my pages at http://www.ugcs.caltech.edu/~whuang/. -- -- Wei-Hwa Huang (whuang@cco.caltech.edu) http://www.ugcs.caltech.edu/~whuang/ Proponent of rec.games.computer.puzzle From alan@curry.epilogue.com Fri May 12 15:03:16 1995 Return-Path: Received: from curry.epilogue.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA24195; Fri, 12 May 95 15:03:16 EDT Received: (from alan@localhost) by curry.epilogue.com (8.6.8/8.6.6) id PAA09069; Fri, 12 May 1995 15:05:36 -0400 Date: Fri, 12 May 1995 15:05:36 -0400 Message-Id: <12May1995.144956.Alan@LCS.MIT.EDU> From: Alan Bawden Sender: Cube-Lovers-Request@ai.mit.edu To: Cube-Lovers@ai.mit.edu Subject: troublemakers and newbies Folks, please let's not have any more discussion of mailing list maintenance on Cube-Lovers. Let me be the only person to break that rule. I try to do that as rarely as possible. That's why I usually wait for more than one person to make the canonical "unsubscribe" mistake before saying anything in public. (Unfortunately, the way people always copy the bad example makes it necessary to offer an occasional public correction.) You don't see the mail that goes to Cube-Lovers-Request. If you did, you would know that public discussions like this always prompt other people to drop their subscriptions. Almost every off-topic message is the last straw for somebody out there. Please help Cube-Lovers keep it's subscribers -- let me be the only person who sends messages like this. - Alan From mouse@collatz.mcrcim.mcgill.edu Mon May 15 16:16:34 1995 Return-Path: Received: from Collatz.McRCIM.McGill.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA07931; Mon, 15 May 95 16:16:34 EDT Received: (root@localhost) by 2780 on Collatz.McRCIM.McGill.EDU (8.6.10 Mouse 1.0) id QAA02780 for cube-lovers@ai.mit.edu; Mon, 15 May 1995 16:16:29 -0400 Date: Mon, 15 May 1995 16:16:29 -0400 From: der Mouse Message-Id: <199505152016.QAA02780@Collatz.McRCIM.McGill.EDU> To: cube-lovers@ai.mit.edu Subject: Re: Is there a symbolic cube program? Back last November, Dave Eaton wrote > Is there a program that allows you to type in Singmaster-style moves > and then prints out the resultant state, something like this (not > actual results): > INPUT: (R U2 R3 U2)2 > OUTPUT: (fur,drb,rdf) (fr,dr) I can't recall whether anyone offered such a thing or not. I think there were some related programs, but nothing quite like this. Anyway, there is now. :-) Sample run: % twist > .set SLICER CUBER R' L `SLICER' defined > (SLICER U)4 Cube: u b u l u u u u u l u l f f f r r r b u b l l l f f f r r r b b b l l l f d f r r r b d b d f d d d d d b d Cycles: (ub)+ (ul)+ (fd)+ (bd)+ Already centered > .set WRENCH LAST `WRENCH' defined > WRENCH U WRENCH U' Cube: u b u u u u u f u l l l f u f r r r b u b l l l f f f r r r b b b l l l f f f r r r b b b d d d d d d d d d Cycles: (ub)+ (uf)+ Already centered > (R U2 R3 U2)2 Cube: b u d f u u f u u r r r u f b l l r f b u l l l f f u r r r b b b l l l f f f l r r b b b d d u d d d d d d Cycles: (ul,ur,fr) (ulb,urf,flu,frd,bru) Already centered > SLICER U Cube: u u u f f f u u u f d f r r r b u b l l l l l l f d f r r r b u b l l l f d f r r r b u b d b d d b d d b d Cycles: (u,b,d,f) (ub,bd,df,lu)+ (ur,uf)+ (ulb,ubr,urf,ufl) Centred: (ul,fu,fr,dr,br,ur,fd,fl,dl,bl) (ulb,fur,lfd,ldb)+ (ubr,frd,drb)+ (ufl)+ > WRENCH CUBEU2 CUBEL WRENCH' (CUBEU2 CUBEL)' Cube: u u u l u u u u u l u l f f f r r r b b b l l l f f r f r r b b b l l l f f f r r r b b b d d d d d d d d d Cycles: (ul)+ (fr)+ Already centered > The program is up for anonymous ftp from collatz.mcrcim.mcgill.edu in /games/cube/twist.c. You have not a prayer of compiling it under anything but gcc as it stands, though I think it would be relatively easy (but perhaps rather ugly) to turn it into vanilla C. But with gcc 2.6.3, it builds fine for me on a Sun under SunOS 4.1.3 and a NeXT under NeXT release 2.1, and probably most other machines too. Read the comment header for a fuller description of its capabilities. der Mouse mouse@collatz.mcrcim.mcgill.edu From bagleyd@source.asset.com Tue May 16 11:06:02 1995 Return-Path: Received: from source.asset.com by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA21834; Tue, 16 May 95 11:06:02 EDT Received: by source.asset.com (AIX 3.2/UCB 5.64/4.03) id AA44189; Tue, 16 May 1995 11:07:21 -0400 Date: Tue, 16 May 1995 11:07:21 -0400 From: bagleyd@source.asset.com (David A. Bagley) Message-Id: <9505161507.AA44189@source.asset.com> To: cube-lovers@ai.mit.edu Subject: DINOSAUR RUBIK'S CUBE Hi I just completed coding a new puzzle called xdino. It is the Rubik's Dinosaur Puzzle recently mentioned. (A cube with diagonal X cuts.) All those who have X should be able to run it. Also I updated the rest for the puzzle collection as well. It is available at ftp.x.org in /contrib/games/puzzles in separate files. It will also be available at sunsite.unc.edu in /pub/Linux/games/x11 as xpuzzle-4.10.tgz Any problems with the compilation ... let me know. It has been tested on Linux, SunOS, Solaris, HP-UX, and VMS. Here is the README file: Updates: xpuzzles (4.10) Random number generator included. All puzzles have been put through Sun's cc and lint xdino added Bug fixed in xmlink. It moved correctly but was hard to turn. Bug fixed with control key of xpyraminx. It turned the whole puzzle the wrong way. New control key moves for the 2D version of xskewb. More freedom in movement in xoct and xpyraminx using control+shift. (Later updates to individual puzzles will now be 4.10.1 etc. No more different minor version numbers for each puzzle.) xpuzzles (<4.10) Removed lint warnings and added a VMS make.com . Conservative guess for random number generator. A super Makefile to make all puzzles. Puzzles now have undo, save, and recall features. xmball and xmlink intitialization bug fixed. xmball and xmlink added, both need more efficient methods to draw a sector. xrubik only save and undo bug fixed. After a save, undo did not work. auto-solver - sincere thanks to Michael B. Martin Some older versions used Motif (3.x), XView (2.x), and SunView (1.x) xrubik is currently the only one in this collection with a auto-solver. The collection includes: SLIDING BLOCK PUZZLES xcubes: expanded 15 puzzle xtriangles: same complexity as 15 puzzle xhexagons: 2 modes: one ridiculously easy, one harder than 15 puzzle ROTATIONAL 3D PUZZLES hold down control key to move whole puzzle letters that represent colors can be changed in mono-mode xrubik: a nxnxn Erno Rubik's Cube(tm) (or Magic Cube) auto-solves 2x2x2 and 3x3x3 (non-orient mode). xpyraminx: a nxnxn Uwe Meffert's Pyraminx(tm) (and Senior Pyraminx), a tetrahedron with Period 2, Period 3, and Combined cut modes and it also a sticky mode to simulate a Halpern's Tetrahedron or a Pyraminx Tetrahedron xoct: a nxnxn Uwe Meffert's Magic Octahedron (or Star Puzzler) and Trajber's Octahedron with Period 3, Period 4, and Combined cut modes and it also includes a sticky mode xskewb: a Meffert's Skewb (or Pyraminx Cube), a cube with diagonal cuts, each face is cut with a diamond shape xdino: a Dinosaur Rubik's Cube, a cube with different diagonal cuts, each face is cut with a "X" xmball: a variable cut Masterball(tm), variable number of latitudinal and longitudinal cuts on a sphere, where the longitudinal cuts permit only 180 degree turns. COMBINATION ROTATIONAL AND SLIDING 3D PUZZLES hold down shift key to move whole puzzle letters that represent colors can be changed in mono-mode xmlink: a nxm Erno Rubik's Missing Link(tm) Newbies (especially DOS users 8-) ): MS DOS/MS Windows & Mac users, sorry no port currently available. What you need: 80386 or better, or Risc, etc. UNIX (or even VMS): Linux and FreeBSD are freely available. X: XFree86 is freely available on Linux and FreeBSD distributions. gunzip: freely available from GNU and the above distributions. tar: freely available from GNU and the above distributions. What you do: After transfering the PUZZLE file to your machine gunzip PUZZLE.tar.gz tar xvf PUZZLE.tar (tar xvzf PUZZLE.tar.gz may work as a short cut) Then read the README generated by the above command. Questions about the above or how to find out more about puzzles, no problem, my mail address is: bagleyd@source.asset.com From BRYAN@wvnvm.wvnet.edu Thu May 18 10:17:25 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA24497; Thu, 18 May 95 10:17:25 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 8692; Thu, 18 May 95 09:29:25 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 5434; Thu, 18 May 1995 09:29:25 -0400 Message-Id: Date: Thu, 18 May 1995 09:29:24 -0400 (EDT) From: "Jerry Bryan" To: , "Cube Lovers List" Subject: Re: more on the slice group In-Reply-To: Message of 05/11/95 at 17:57:14 from mreid@ptc.com On 05/11/95 at 17:57:14 mreid@ptc.com said: >jerry asks about P-symmetric positions. coincidentally, i happened >to investigate these a few weeks back, and here's what i found: >(i calculated by hand, so i'd be grateful for any confirmation.) >there are 128 P-symmetric positions, 4 of which are M-symmetric. I can confirm your count. These positions are called X class positions in Dan's taxonomy. That is, there are 124 positions Y unique up to M-conjugancy for which Symm(Y)=X1 or Symm(Y)=X2 or Symm(Y)=X3, where X1, X2, and X3 are the three conjugate subgroups of M in Dan's taxonomy of subgroups which contain sixteen elements. Hence, we describe the 124 positions as being class X positions. The 4 M-symmetric positions are also X-symmetric, but we don't count them as class X. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From BRYAN@wvnvm.wvnet.edu Thu May 18 11:30:01 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA00211; Thu, 18 May 95 11:30:01 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 0025; Thu, 18 May 95 11:28:37 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 0519; Thu, 18 May 1995 11:28:37 -0400 Message-Id: Date: Thu, 18 May 1995 11:28:36 -0400 (EDT) From: "Jerry Bryan" To: , "Cube Lovers List" Subject: Re: more on the slice group In-Reply-To: Message of 05/11/95 at 17:57:14 from mreid@ptc.com On 05/11/95 at 17:57:14 mreid@ptc.com said: >one of these subgroups is the group of symmetries that preserve >the U-D axis. call this subgroup "P". (this is also the group >of symmetries of the intermediate subgroup of kociemba's algorithm.) >there are 128 P-symmetric positions, 4 of which are M-symmetric. >they form a subgroup of the cube group (of course) which is >isomorphic to a direct product of 7 copies of C_2. in particular, >each such position has order 2 (or 1) as a group element. If I understand your definition of "P" correctly, the same group is called X1 in Dan's taxonomy. X2 similarly preserves the F-B axis, and X3 similarly preserves the R-L axis. Hence, there are three conjugate subgroups of G which preserve a major axis, and each contains 128 elements: there are 128 X1-symmetric positions, 128 X2 symmetric positions, and 128 X3 symmetric positions. I was bothered by your statement that there were 128 P-symmetric positions at first because I was equating "P-symmetric" with "X-symmetric" rather than with "X1-symmetric". There should be 376 X-symmetric positions -- 124 that are X1-symmetric and not M-symmetric, 124 that are X2-symmetric and not M-symmetric, 124 that are X3-symmetric and not M-symmetric, and 4 that are M-symmetric. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU From BRYAN@wvnvm.wvnet.edu Fri May 19 10:35:47 1995 Return-Path: Received: from WVNVM.WVNET.EDU by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA25707; Fri, 19 May 95 10:35:47 EDT Received: from WVNVM.WVNET.EDU by WVNVM.WVNET.EDU (IBM VM SMTP V2R2) with BSMTP id 7520; Fri, 19 May 95 09:01:34 EDT Received: from WVNVM.WVNET.EDU (NJE origin BRYAN@WVNVM) by WVNVM.WVNET.EDU (LMail V1.2a/1.8a) with BSMTP id 8484; Fri, 19 May 1995 09:00:53 -0400 Message-Id: Date: Fri, 19 May 1995 09:00:52 -0400 (EDT) From: "Jerry Bryan" To: "Cube Lovers List" Subject: AntiSlice Under M-conjugacy Mark Longridge's antislice results are as follows: > arrangements arrangements >Moves Deep (2q or anti-slice moves) (4q or double anti-slice moves) > > 0 1 1 > 1 6 9 > 2 27 51 > 3 120 265 > 4 423 864 > 5 1,098 1,785 > 6 1,770 2,017 > 7 1,650 1,008 > 8 851 144 > 9 198 > ----- ----- > 6,144 6,144 We now have the following M-conjugacy results (2q moves only, still working on 4q moves). Level Positions Local Maxima 0 1 0 1 1 0 2 3 0 3 10 0 4 37 0 5 93 1 6 166 2 7 147 7 8 89 12 9 21 21 ---- 568 The level 5 local maximum is (U'D')(FB)(FB)(UD)(L'R'). The position is not its own inverse, but we can use as an inverse (U'D')(FB)(FB)(UD)(LR). Hence, (U'D')(FB)(FB)(UD) forms a nice "middle" of the sequence. In fact, the (U'D')(FB)(FB)(UD) position in some ways seems more interesting than the local maximum itself. Does it already have a name? I have not verified if the length of the local maximum is 10q in G, nor if it is a local maximum in G. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Robert G. Bryan (Jerry Bryan) (304) 293-5192 Associate Director, WVNET (304) 293-5540 fax 837 Chestnut Ridge Road BRYAN@WVNVM Morgantown, WV 26505 BRYAN@WVNVM.WVNET.EDU