From cube-lovers-errors@mc.lcs.mit.edu  Wed Dec 23 17:40:01 1998
Return-Path: <cube-lovers-errors@mc.lcs.mit.edu>
Received: from sun28.aic.nrl.navy.mil (sun28.aic.nrl.navy.mil [132.250.84.38])
	by mc.lcs.mit.edu (8.9.1a/8.9.1-mod) with SMTP id RAA08319
	for <cube-lovers-outbound@mc.lcs.mit.edu>; Wed, 23 Dec 1998 17:40:01 -0500 (EST)
Precedence: bulk
Errors-To: cube-lovers-errors@mc.lcs.mit.edu
Message-Id: <36816C59.1204@hrz1.hrz.tu-darmstadt.de>
Date: Wed, 23 Dec 1998 23:19:05 +0100
From: Herbert Kociemba <kociemba@hrz1.hrz.tu-darmstadt.de>
Reply-To: kociemba@hrz1.hrz.tu-darmstadt.de
To: cube-lovers@ai.mit.edu
Cc: michael reid <reid@math.brown.edu>
Subject: Re: Optimal Cube Solver
References: <199812222337.SAA26516@adams.math.brown.edu>

michael reid wrote:

> since this big table is sparse, we don't need most of it.  what i
> should do is have another table (11880 char's) to transform "sliceedges"
> into permutations of four edges.  the location of the four R-L slice
> edges determines the location of the four F-B slice edges, so we only
> need to know how they're permuted.  thus the big table can be replaced
> by one with 1680 * 24 shorts that gives the permutation of the eight
> U and D edges.  it no longer would have error-checking (i.e. making
> sure we don't get an invalid entry in the big table), but that could
> be installed with another simple table lookup, if desired.
>
> with this new mechanism, only about 543K of tables would be needed,
> the largest being a lookup table which tells how "sliceedges"
> transform under face turns.  this is much better than the 6 megabytes
> of tables i'm currently using.  i don't know why i didn't think of
> this earlier!
>
> mike

Is it necessary to use the table for the map from the "sliceedges" to
the 1680 "4 out of 8"-coordinate at all? I think you constructed this
"helper"-coordinate, because a 11880*11880 table-size was too big and
1680*1680 was reasonable. But 11880*24 also is small (just twice as much
as the lookup table which tells how "sliceedges" transform under face
turns).

In the way I construct the sliceedge-coordinate x, the x mod 24 gives
the permutation part, x/24 the location part. So I could compute the
edge-coordinate  at the start of phase 2 with M[x][y mod 24], where x
and y are the RL- and FB-sliceedge coordinates and M is a table with
11880*24 shorts. So I need only one tablelookup to get the coordinate.

Herbert