From cube-lovers-errors@curry.epilogue.com Sun Jun 2 04:12:01 1996
Return-Path: cube-lovers-errors@curry.epilogue.com
Received: from curry.epilogue.com (localhost [127.0.0.1]) by curry.epilogue.com (8.6.12/8.6.12) with SMTP id EAA14161 for ; Sun, 2 Jun 1996 04:12:01 -0400
Precedence: bulk
Errors-To: cube-lovers-errors@curry.epilogue.com
Date: Sun, 2 Jun 96 00:17:03 EDT
From: hoey@aic.nrl.navy.mil
Message-Id: <9606020417.AA04623@sun13.aic.nrl.navy.mil>
To: Jerry Bryan
Cc: Cube-Lovers
Subject: Re: Compact Cube Representation for Shamir and Otherwise
I'm not sure this is so interesting to all of cube-lovers; e-mail me
if you have opinions pro or con.
Jerry writes of the standard S24 x S24 model, which uses 48 bytes per
position without packing. He also has a "supplement" representation
that uses one facelet from each edge and corner, for 20 bytes. He
packs them into 13 bytes on tape.
The way I did it the last time I worked on brute force was to
pack eight twelve-bit fields:
The orientations in two twelve-bit fields (2^11 and 3^7),
The edge permutation in four twelve-bit fields,
each of three base-12 digits (12^3), and
The corner permutation in two twelve-bit fields, each of
four base-8 digits (8^4).
Unpacking the fields can be done with native arithmetic or table
lookup. In the latter case, it is better to use 12*11*10 instead of
12^3 and 8*7*6*5 instead of 8^3.
Also, postmultiplying by a fixed permutation can be done with table
lookup without unpacking. I used this feature for twelve permutations
of particular interest.
I am somewhat rusty on the implications of using this representation
in conjunction with Shamir's algorithm. I think it provides an
ordering of the permutations that enables at least an approximation to
the random access you need, then you unpack it and do a better job.
Dan Hoey
Hoey@AIC.NRL.Navy.Mil