From dik@cwi.nl Thu May 14 19:44:27 1992
Return-Path:
Received: from charon.cwi.nl by life.ai.mit.edu (4.1/AI-4.10) id AA00837; Thu, 14 May 92 19:44:27 EDT
Received: from boring.cwi.nl by charon.cwi.nl with SMTP
id AA08254 (5.65b/2.10/CWI-Amsterdam); Fri, 15 May 1992 01:44:25 +0200
Received: by boring.cwi.nl
id AA13499 (5.65b/2.10/CWI-Amsterdam); Fri, 15 May 1992 01:44:24 +0200
Date: Fri, 15 May 1992 01:44:24 +0200
From: Dik.Winter@cwi.nl
Message-Id: <9205142344.AA13499.dik@boring.cwi.nl>
To: cube-lovers@life.ai.mit.edu
Subject: Kociemba's algorithm
I am now trying to implement Kociemba's algorithm. The initialization parts
are done. To recap, it is a two stage algorithm. The first stage tries to
get to the subgroup generated by [R^2,L^2,F^2,B^2,U,D], the second stages
comes back to start.
The first stage uses a three dimensional coordinate system: twistyness,
flippancy and choosyness (where are the 4 middle slice edge cubies?).
The second stage uses (I think) also a three dimensional coordinate system,
all permutations: corner cubies, edge cubies not on the middle slice, slice
cubies. I found the maximal distance along each coordinate as follows:
stage 1:
twistyness: 6
flippancy: 7
choosyness: 4
This seems not in contradiction with his 10 moves or less on average.
stage 2:
corners: 13
edges: 8
slice edges: 4
I think this contradicts his 14 moves or less, there are configurations
that require at least 13 moves to get the corners correct. I would be
surprised if only one more move is needed to get everything correct.
*But* some of his best moves use a sub-optimal solution for stage 1!
Now if that could be quantified...
Next step is implementing the searching algorithms.
dik
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
dik@cwi.nl