view release on metacpan or  search on metacpan

bin/qbix/qbix  view on Meta::CPAN

#     normally any possible move would be one of the 6 sides in one of
#     3 possible turns (clockwise [aka forward], counter [back], or twice)
#     which results in 18 possible movements at every juncture.  It would
#     be immensely valuable (space-wise) to store only 16 possible values
#     per turn since only 4bits would be needed instead of 5.  This
#     can probably be accomplished if you assume that the client has
#     chosen a front side before doing a move lookup.  The client would
#     likely pursue many incorrect paths but that would be acceptable
#     if one right one could ultimately be determined.  The steps the
#     client software would have to take are as follows:
#       0) save a backup of the entire state of the initial rube
#       1) lookup based on state
#       1b) if lookup found result, follow path for each possible front (6)
#       2) else try each possible turn of each of the 6 sides && try to
#           find a lookup with a result from any of those
#       3) make random turns && return to step 1
#         *note* as soon as any lookup returns a result (no matter what
#          side was turned which direction to get there) it means that
#          some previous turn (maybe a different one than was actually
#          performed) results in an optimal solution so pretend that
#          each of the 6 possible front sides are the real front &&