From reid@math.berkeley.edu Fri Aug 27 22:23:04 1993 Return-Path: Received: from math.berkeley.edu by life.ai.mit.edu (4.1/AI-4.10) for /com/archive/cube-lovers id AA27534; Fri, 27 Aug 93 22:23:04 EDT Received: from jacobi.berkeley.edu.berkeley.edu by math.berkeley.edu (4.1/1.33(math)) id AA22114; Fri, 27 Aug 93 19:22:49 PDT Date: Fri, 27 Aug 93 19:22:49 PDT From: reid@math.berkeley.edu (michael reid) Message-Id: <9308280222.AA22114@math.berkeley.edu> To: Dik.Winter@cwi.nl, cube-lovers@life.ai.mit.edu Subject: Re: Diameter of cube group? dik winter says > > first do 6 checkerboards of order 2 (F2 B2 R2 L2 U2 D2) and then do > > superfliptwist. in other words, the group product of these two elements. > > As they commute I did it the other way around. But I am highly > suspicious that you tried it yourself. 10 minutes and only down > to 22 turns. But continuing, possibly for weeks/months. ok, you caught me; i'd already tried this one myself. :-) but apparently i wasn't as patient as you. i just remember that it ran for a long time without doing better than 22 face turns. the point to be made here is the following: the length of time the program takes for a given position depends significantly on how far it must search in stage 1. this seems to make any claim about how long the program takes to crunch an average position meaningless. my experience is that it varies greatly depending upon the position. i think it would be more informative to stratify this information. i.e., how long it takes to search 12 moves in stage 1, and how short a solution is produced. and then the same info for 13 turns, then 14, etc. what i've been amazed by (and continue to be) is that searching only 13 or so moves in stage 1 is sufficient to produce very short solutions for many positions. something i'd thought about trying, but never got around to is trying random positions created by twist sequences such as: F1 R1 B1 L1 F1 R1 B1 L1 F1 R1 B1 L1 F1 R1 B1 L1 F1 R1 B1 L1 or some random string of about 20 quarter turns of the faces F,L,B,R. a string of length 12 or 13 will be solved quickly (by the inverse of the original string). however, for length 17 or so, the program won't find the inverse of the original string until it is searching 17 moves deep in stage 1. this suggests that perhaps these positions may be harder for the program to handle. but are they harder than random positions? i don't know. mike