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