Currently I am calculating the
maximal distance in stage 1.  It will take a bit of time because I have to
consider 2,217,093,120 possibilities.  But I think that the method I have
is feasible.

> how much time do you anticipate the job will take?
A few days. I started yesterday night at 2:30 AM, it is now 11:05 PM. I have
calculated the distances for approximately 145 million configurations. The
majority of the work has been done sinc 6:00 PM. (I am using 39 SGI Indigo's,
1 Large SGI, 2 processors of an SGI file server and the scalar (SPARC)
processor of an FPS, so it is lots of computer time!)
> it seems that we'd
> get a much better improvement (of kloosterman's bound) by calculating
> the maximal distance in stage 2. of course, this requires going through
> 19,508,428,800 possibilities (nearly 9 times as many). is this feasible?
Right. But is not feasible, at least I do not see possibilities at this
moment. My estimate is that it would take much more than 9 times as much.
The reason is that the algorithm as I have organized it allows a lot of
shortcuts. What I do is in the space of order 2048 * 2187 * 495 assign to
each processor in turn a slice of the 2048 dimension. Within that slice,
going from 0 moves until every configuration has been assigned a distance,
a path is searched for the given distance. The major shortcut comes when
a path is found. Using configurations with known distance, U, D, L and R
turns are applied and also F2 and L2 turns to calculate new distances.
For those moves the flip does not change. This makes that I have to search
paths for only about 10% of the cases. I see no way (yet) to do similar
things for phase 2.

dik