[next] [prev] [up] Date: Tue, 14 Jan 92 12:49:16 -0500 (EST)
[next] [prev] [up] From: Dan Hoey <hoey@aic.nrl.navy.mil >
[next] ~~~ [up] Subject: A new upper bound: 91 QT

I just wrote a quick program to count the number of QT to move from
the full cube group to the subgroup generated by <F^2,B^2,L,R,T,D>.
Thistlethwaite computed that this takes at least 7 HT in the worst
case. The surprisingly good result is that it also takes only 7 *QT*
in the worst case. This reduces the upper bound I posted Friday to 91
QT.

I had wondered if the worst cases could be reduced by choosing a
different pair of faces to restrict to half-twists. Unfortunately,
the all-edges-flipped position is one of those that requires at least
7 HT (and so 7 QT), and by symmetry it cannot be improved.

Allan C. Wechsler <ACW@YUKON.SCRC.Symbolics.COM> analyzed his own
cube-solving method, finding that:

For example, flipping two edges in place takes 22 qtw.

This can be done in 16 QT, though I don't know if that is the best
known. Any pair can be flipped with a conjugate of the 14 QT slice
mono-op FOTAROFATO-RAM TAFORATOFA-ROM (FT'RF'T L'R B'TR'BT' LR').
Adjacent and antipodal pairs require the introduction of a
non-cancelling QT in the conjugator.

Obviously a lot could be gained from tweaking the earlier part of
the algorithm to guarantee that I don't need to do this at the end.

Probably, but it's hard to make that guarantee. The problem is that
unless you flip edges in place with no other action (the very problem
you're trying to avoid) you may affect the later choices in the
algorithm, making the earlier tweaks wrong for that branch of the
algorithm.

For instance, the 7-QT method my program found solves the orientation
of all the edges (using a particular non-standard labeling of the
orientation that, when solved, is invariant under F^2, B^2, L, R, T,
and D). But it may permute edges, and permute and twist corners, so
it may not form a useful part of an arbitrary cube-solving algorithm.
It works in Thistlethwaite's only because he is careful in all
branches of the rest of the algorithm never to mix up the orientation
of those edges.

Dan Hoey
Hoey@AIC.NRL.Navy.Mil


[next] [prev] [up] [top] [help]