view release on metacpan or  search on metacpan

bin/qbix/qbix  view on Meta::CPAN

#         turn (if found) in solution
#       another util should convert @corn/@edge lists into compact
#         representation
#       maybe interactive chooser (similar to QbixRube.exe) can be
#         made to specify @corn/@edge lists easily
#       underlying, search might employ MySQL with many databases &&
#         tables to narrow lookup
#       possible corner positions is 8! = 40320 which can be represented
#         by a word (to extract each component, start looking for 8 value
#         by dividing by 7! [save remainder for next one], then by 6!...)
#         644Bqc5 - This doesn't work!  They've got to be separated.
#       some possibilities: (8 corns w/ 3 rots, 12 edges w/ 2 rots)
# kilo-  2^10 =                      1,024
# eRot: 2**11 =                      2,048 (sum must be even so infer last)
# cRot: 3**7  =                      2,187 (sum of rots % 3 = 0 so infer last)
# cPos:   8!  =                     40,320
#   ref: 2**16=                     65,536      2 bytes (word)
# mega-  2^20 =                  1,048,576
# eR*cR:      =                  4,478,976
#   ref: 2**24=                 16,777,216      3 bytes
# eR*cP:      =                 82,575,360
# cR*cP:      =                 88,179,840
# ePos:  12!  =                479,001,600
# giga-  2^30 =              1,073,741,824
#   ref: 2**32=              4,294,967,296      4 bytes (doubleword)
# eR*cR*cP:   =            180,592,312,320
# eR*eP:      =            980,995,276,800
# cR*eP:      =          1,047,576,499,200
# tera-  2^40 =          1,099,511,627,776
#   ref: 2**48=        281,474,976,710,656      6 bytes
# peta-  2^50 =      1,125,899,906,842,624
# eR*cR*eP:   =      2,145,436,670,361,699
# eR*cP*eP:   =     39,553,729,560,576,999
# cR*cP*eP:   =     42,238,284,447,744,999
#   ref: 2**56=     72,057,594,037,927,999      7 bytes
# exa-   2^60 =  1,152,921,504,606,846,976
#   ref: 2**64= 18,446,744,073,709,699,999      8 bytes (quadword)
#   ref: 2**66= 73,786,976,294,838,299,999      8 bytes && 2 bits
# eR*cR*cP*eP:= 86,504,006,548,979,799,999
# 18*(15**16):=118,231,350,402,832,999,999     17 moves (TheoreticalMax)
#   ref: 2**67=147,573,952,589,676,999,999      8 bytes && 3 bits
# zetta-2^70=1,180,591,620,717,411,303,424
# yotta- 1,208,925,819,614,629,174,706,176      2**80
#
#   Since quadword (64bits) is a good index but falls short, segment
#     space at least by Total (eR*cR*cP*eP) / QuadWord size
# totl/qword: =           4.68939159145521
#   maybe create 8 separate tables (or databases) for each of the first
#     possible corner positions then just qword indices thereafter
#   since space is so precious, let computation handle more... like
#     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 &&
#          traverse the path until the right one yields the solution.
#          This probably also needs to be done for each possible up
#          side too so for each of the 24 possible front sides (since
#          each could have 0-3 clockwise turns to start) there would
#          be 4 possible up sides for each which yields 64 possible
#          tests for any initial state.  This mechanism is rather
#          convoluted but it will probably save enough disk space
#          to be well worth it.
#   maybe lookup could return a byte of both turns for last (11th)
#     possible edge flip or last possible corner position
#   maybe best to store 32 or 64bits of turn answers with each lookup
#     (instead of just 8) for consistency && efficiency... these would
#     store 8 or 16 answer turns per data lookup (which also conveniently
#     brings lookup index under 64bit threshold too)
#   last unused possibility in turn answer (16th in 4bit) can be a rare
#     hint that the 3rd possible side (index[2]) is being turned twice
#     for this turn && that it does designate the opposite [back] of front
#     (which means that if 3rd side is turned twice && all 4 bits aren't
#     set, then 4th possible side must be opposite [back])
#   actually, now that I think of it, it seems that there's a big problem
#     since any lookup state could be arrived at from many routes (when
#     solving) so the omitted information would have to be divined at
#     every lookup which nullifies all data's usefulness... which means
#     that for any given lookup (aka rubestate is the key), there must
#     be a clear value for which absolute side to turn how much.  4bits
#     (16 values) could be used to store mixing since previous turn
#     (which is closer to the root of the tree) is known && cannot be
#     side of current turn but the reverse path for solving would get
#     lost at every turn [value] it found... which means the value at
#     any possible key must provide answer for each possibility so
#     every value could assume side 0 [white] is always front && side 1
#     [red] is always up to save space on orientation data but then we
#     still must store all 18 possible turns (which would wastefully
#     require 5bits) or assume all turns are clockwise [forward] (which
#     wouldn't be so bad since there's no concept of previous turn to
#     avoid again anyway) && store all 6 possible turns (which would
#     still wastefully require 3bits)
#         21 3bit values (63bits) could be packed into a single 64bit
#       lookup result... 64th bit could be flag to designate turn as
#       last turn to (aka first from) solution
#         possibility 7 && 8 in each 3bit value could be used to
#       signify that side 0 [white] is being turned again (7) or for
#       a third time (8)... might be faster to ignore possibility 7
#       && 8 since they can't add any useful information && would only
#       add to average overhead
#     maybe use corner positions 8*4*2=64 to name databases... positions
#       6*5=30 name tables in each database... positions 7*3=21 packed
#       3bit values per lookup... which leaves eR*cR*eP
#       (2,145,436,670,361,699 possibilities) as unique key per table
#       && 64bit value results