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