[next] [prev] [up] Date: Wed, 22 Feb 95 18:28:13 -0500
[next] [prev] [up] From: michael reid <mreid@ptc.com >
[next] [prev] [up] Subject: Re: Run Times, Storage Requirements, etc.

jerry writes about his search for superflip in 22q:

 [ ... ]                                   However, I had to spread the
runs over a couple of weeks to keep our operators from shooting me.

isn't it amazing how they never seem to fully understand the importance
of this stuff!


Finally, the 82 tapes for positions 11 moves from Superflip were
matched against the 82 tapes for positions 11 moves from Start, again
taking about 10 hours. (I also checked the shorter lengths along the
way, but it didn't take anywhere near as long for the shorter lengths).

i think this can be done much more efficiently. well, at least if you
set things up properly in the first place.

suppose that you use an order (for sorting positions) in which the corner
configuration is more significant than the edge configuration.

then, for each position X on your huge list, you need to check if
repr(X superflip) is on the list. since superflip only affects edges,
the corner configuration of X superflip is the same as that of X.
thus the same holds for repr(X superflip) and repr(X) = X. therefore,
you only need to look for repr(X superflip) nearby in the sorted list.

now, for each corner configuration, load all the positions on your list
with that corner configuration into memory (it shouldn't be too many),
superflip them, compute representative elements, and look for "halfway"

this way, there's no need to sort or store all the positions 11q from
superflip (although it wouldn't be hard using this).

of course this also works for pons asinorum and its composition with
superflip. but it does require that things were set up properly in the


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