From dik@cwi.nl  Sun May  3 21:43:51 1992
Return-Path: <dik@cwi.nl>
Received: from charon.cwi.nl by life.ai.mit.edu (4.1/AI-4.10) id AA13983; Sun, 3 May 92 21:43:51 EDT
Received: from boring.cwi.nl by charon.cwi.nl with SMTP
	id AA25853 (5.65b/2.10/CWI-Amsterdam); Mon, 4 May 1992 03:43:48 +0200
Received: by boring.cwi.nl 
	id AA00557 (5.65b/2.10/CWI-Amsterdam); Mon, 4 May 1992 03:43:47 +0200
Date: Mon, 4 May 1992 03:43:47 +0200
From: Dik.Winter@cwi.nl
Message-Id: <9205040143.AA00557.dik@boring.cwi.nl>
To: cube-lovers@life.ai.mit.edu
Subject: Are we approaching God's algorithm?

Because it might interest the readers and to be ahead of Peter Beck:
Saturday I received CFF (Cubism For Fun) # 28.
It has an interesting article by Herbert Kociemba from Darmstadt, who
describes his program to solve Rubik's Cube.  He states that he has not
yet encountered a configuration that required more than 21 moves.  A short
description follows:

Basicly the program consists of two stages, based on the groups:
G0:	[U,D,R,L,F,B]
G1:	[U,D,R^2,L^2,F^2,B^2]
G2:	I
The stages are from G0 to G1 and next from G1 to G2.  Note that the first
stage is the combination of the first two stages of Thistlethwaite, and
the last stages combine his last two stages.

His first stage can loosely be described as working in a three dimensional
coordinate system where the coordinates are resp. twist, flip and permutation.
He searches his way until the coordinate [0,0,0] is reached.  Most important
here is that he is able to find multiple ways.  The second stage is similar,
although he is not very clear here.

He uses lookup tables, but does not tell us how large his lookup tables
are.  But his program runs on 1 MByte Atari ST.  The heart is coded in
a few lines of 68k assembly, the remainder in GFA Basic.  As far as I
know GFA Basic it can be interpreted, but also compiled.  He does also
use tree pruning.

What he does is find successive solutions in stage 1 and fit solutions
from stage 2.  Letting the system run longer generally finds shorter
solutions.

His claims are on average less than 14 turns in stage 1, on average less
than 10 turns in stage 2.  But according to his article this is not completely
deterministic, so there is no proven upperbound.  Perhaps a proof can be
found; I do not know.  In practice he finds an upperbound of 21 moves, which
is indeed far better than other algorithms do obtain.

To take this in perspective here Thistlethwaites results from Singmaster's book:
Stage		1	2	3	4
Proven		7	13	15	17
Anticipated	7	12	14?	17
Best Possible	7	10?	13?	15?
(Are there configurations that require the maxima proven for Thistlethwaites
algorithm?)

Apparently the combination of stages largely reduces the number of turns
required.

In CFF 25 there was an article by Hans Kloosterman which did already improve
on the number of moves.  His stages 1 and 2 are identical to Thistlethwaites,
he has a third stage that combines the 3rd and 4th stages of Thistlethwaite.
He reports a proven maximum for his three stages of 7, 10 and 25 moves, so
slightly better than Thistlethwaites conjectured best figures.

Kociemba's algorithm appears however to be a big leap forward, although there
are no proofs yet.  One example:

In 1981 Christoph Bandelow wrote a book where he offered a prize for the
shortest sequence of moves that would flip every edge cuby and twists
every corner cuby.  The deadline was September 1, 1982; at that time the
prize was offered for a 23 move manoeuvre.  As Christoph writes:
	All solutions presented after the main deadline and shorter than
	all solutions submitted before were also proised a prize.  Using
	his very ingeneous new search program Herbert Kociemba, Darmstadt,
	Germany now found:
		DF^2U'(B^2R^2)^2LB'D'FD^2FB^2UF'LRU^2F'
	for 20 moves.
Kociemba himself writes about this:
	Our first solution had 12 moves in stage 1 and 14 moves in stage 2.
	In progress solutions 12+13, 12+12 and 12+11 were found.  However,
	as soon as we introduced manoeuvres of 13 moves in stage 1, we found
	successively 9, 8 and at last 7 moves for stage 2.  The program was
	stopped after treating about 3000 solutions.
He further states that the first solution in general takes 95 seconds, but
successive solutions take much shorter, and in general he finds one of less
than 22 moves in a few hours on his 8 MHz Atari.

What is clear is that one does not need the minimal solution in one stage
to get the minimal overall total.

dik
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
dik@cwi.nl

From dik@cwi.nl  Tue May  5 03:58:28 1992
Return-Path: <dik@cwi.nl>
Received: from charon.cwi.nl by life.ai.mit.edu (4.1/AI-4.10) id AA19673; Tue, 5 May 92 03:58:28 EDT
Received: from boring.cwi.nl by charon.cwi.nl with SMTP
	id AA01995 (5.65b/2.10/CWI-Amsterdam); Tue, 5 May 1992 09:57:54 +0200
Received: by boring.cwi.nl 
	id AA01813 (5.65b/2.10/CWI-Amsterdam); Tue, 5 May 1992 09:57:53 +0200
Date: Tue, 5 May 1992 09:57:53 +0200
From: Dik.Winter@cwi.nl
Message-Id: <9205050757.AA01813.dik@boring.cwi.nl>
To: cube-lovers@life.ai.mit.edu, reid@math.berkeley.edu
Subject: Re:  Are we approaching God's algorithm?
Cc: dseal@armltd.co.uk

 > > It has an interesting article by Herbert Kociemba from Darmstadt, who
 > > describes his program to solve Rubik's Cube.  He states that he has not
 > > yet encountered a configuration that required more than 21 moves.  A short
 > > description follows:

 > it would be nice to know how many patterns he has tested.

He does not say how many, but his article gives nine patterns that have been
published earlier in CFF for which he finds shorter answers.  Also more are
promised for future issues.

 > > His first stage can loosely be described as working in a three dimensional
 > > coordinate system where the coordinates are resp. twist, flip and permutation.
 > > He searches his way until the coordinate [0,0,0] is reached.
...
 > >                                                           He does also
 > > use tree pruning.

 > does he describe his method of "tree pruning"?  this would seem to
 > be the "intelligent" part of the program, i.e. recognizing when to
 > abandon a given approach.  if anyone has any insight on the tree
 > pruning, please let me know.

I can give some information.  What he does do is calculate in advance through
the three axis of his space the minimal number of moves needed to get at
[0,0,0].  This is used for tree pruning.  It obviously will not prune
everything (e.g. if you are at point [x,y,z] it may very well be that [x,?,?]
for other points requires less moves, and similar across the y and z
direction), but he tells that his pruning is very effective.  I do not know
how he prunes in the second case, because he does not completely describes
the coordinates of his second space, but I presume pruning is done in a
similar way.

 > it's not likely that this will lead to a proof of an effective upper
 > bound.  perhaps he can shave a few moves off the 42 obtained by
 > kloosterman, but i wouldn't expect him to prove an upper bound
 > anywhere near 21.
I think so too.  Moreover, it is difficult to take in account what he
found, namely that a minimal solution in the first stage does not guarantee
a minimal overall solution.

 > i believe that the diameters of the respective coset spaces are exactly
 > those numbers listed in the "Best Possible" line.  can anyone confirm
 > this?  i've finally written a few programs, and those are the diameters
 > i get.  i'm surprised that thistlethwaite didn't just do an exhaustive
 > search on these coset spaces.  perhaps it's just a matter of not having
 > the technology when he did his work (~12 years ago).
Well, apparently Thistlethwaite did not know that those were the diameters,
otherwise I have no explanation for the question marks as they appear in
Singmaster.

 >             now how about "superflip," and also "supertwist?"
I will try to contact him to see what he has to say about those.


From dik@cwi.nl  Thu May 14 19:44:27 1992
Return-Path: <dik@cwi.nl>
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

From dik@cwi.nl  Sat May 16 21:14:18 1992
Return-Path: <dik@cwi.nl>
Received: from charon.cwi.nl by life.ai.mit.edu (4.1/AI-4.10) id AA03345; Sat, 16 May 92 21:14:18 EDT
Received: from boring.cwi.nl by charon.cwi.nl with SMTP
	id AA14373 (5.65b/2.10/CWI-Amsterdam); Sun, 17 May 1992 03:14:15 +0200
Received: by boring.cwi.nl 
	id AA20529 (5.65b/2.10/CWI-Amsterdam); Sun, 17 May 1992 03:14:14 +0200
Date: Sun, 17 May 1992 03:14:14 +0200
From: Dik.Winter@cwi.nl
Message-Id: <9205170114.AA20529.dik@boring.cwi.nl>
To: cube-lovers@life.ai.mit.edu
Subject: Kociemba's algorithm

I have implemented it based on his description.  I am not yet completely
satisfied, but can give some results.  Both are the best I found after a
run of about 30 minutes.  (The numbers are first the number of moves to
get at [F^2,R^2,B^2,L^2,U,D], second the numbr of moves to complete.)

Superflip:
(11+10=21): F B R U^2 B^2 U' D' R^2 B' R L U F^2 L^2 D^2 B^2 D' F^2 D L^2 D

Supertwist:
(7+9=16): F R^2 L^2 U^2 D^2 F^2 B' R^2 U F^2 B^2 R^2 L^2 U^2 D' L^2

So clearly the supertwist is not even close to the opposite of start!

Currently the program needs still a bit of hand-tuning.  I am looking how
I can improve that.

dik
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
dik@cwi.nl

From dik@cwi.nl  Sun May 17 18:49:53 1992
Return-Path: <dik@cwi.nl>
Received: from charon.cwi.nl by life.ai.mit.edu (4.1/AI-4.10) id AA17456; Sun, 17 May 92 18:49:53 EDT
Received: from boring.cwi.nl by charon.cwi.nl with SMTP
	id AA29764 (5.65b/2.10/CWI-Amsterdam); Mon, 18 May 1992 00:49:49 +0200
Received: by boring.cwi.nl 
	id AA22984 (5.65b/2.10/CWI-Amsterdam); Mon, 18 May 1992 00:49:48 +0200
Date: Mon, 18 May 1992 00:49:48 +0200
From: Dik.Winter@cwi.nl
Message-Id: <9205172249.AA22984.dik@boring.cwi.nl>
To: cube-lovers@life.ai.mit.edu
Subject: Kociemba's algorithm

I have made my program a bit faster.  While previously the best I found for
superflip was a 21 move solution (even after 10 hours computation time,
actually the solution was found after about 30 minutes), I have now a 20
move solution, found after only 15 minutes:

Superflip:
(13+7=20): F B U^2 R F^2 R^2 B^2 U' D F U^2 R' L' U B^2 D R^2 U B^2 U

Some more information.  First a short recap.  Phase1 brings the cube in
the group generated by [F^2,R^2,B^2,L^2,U,D], phase2 brings him back
to start.  Phase 1 searches in the space generated by the three (orthogonal)
coordinates:
Twist (2187 entries), flip (2048 entries) and slice-edge-cube placing (495
entries).
Phase 2 searches in the space generated by the three (non-orthogonal)
coordinates:
Permutations of corner cubes (40320 entries), permutations of edge cubes
not in the middle slice (40320 entries) and permutations of the middle
slice edge cubes (24 entries).

While Kociemba originally did tree pruning based on the minimal number of
moves needed along single coordinates, I now use pairs of coordinates
(except that in phase 2 the 40320*40320 pair is not used of course).
This is part of the speed-up.  (Another part is that I do now disallow
successive moves of a single face, three or more consecutive moves of
opposite faces, and a move of an opposite face if the current face moved
is B, L or D.)

Program details: the program starts with phase1 allowing for succesively
1, 2 etc. until a maximal number of moves.  As soon as phase1 hits a
solution phase2 is called, again with a maximum number of moves starting
at 1.  This means that if the program runs long enough it will ultimately
find the shortest solutions (phase 1 might just solve it!).  But that wil
take a long time (of course).  For the superflip, the program has now
checked all phase1 solutions of upto 12 moves and is busy with 13.  It
found 792256 solutions of 12 moves (and that in less than 10 minutes)!

Some additional data about minimal paths along coordinates:
Phase 1:
twist:		6
flip:		7
choice:		5
twist+flip:	9
twist+choice:	9
flip+choice:	9

Phase 2:
corners:	13
edges:		8
slice edges:	4
corners+slice:	14
edges+slice:	12

Based on this I expect a maximal distance in phase 1 of about 10/11, and
in phase 2 of about 16/17.

dik
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
dik@cwi.nl

