階乗計算を高速化する数学的な「最適な」ベースはありますか？
背景：楽しみのために、私は自分のbignumライブラリを実装しています。（-：これは私の最初の間違いですか？:-)。n階乗（n！）の正確な値（10進数）を出力することにより、内部表現と回帰テストで使用されるさまざまなベースを実験しています。
私のbignumライブラリが整数を表し、乗算を行う方法では、時間は内部表現n！の「1」ビットの総数に比例します。内部表現で2、4、8、16、2 ^ 8、2 ^ 30などを使用すると、特定の数値に対してまったく同じ「1」ビットの総数が得られます。
間違いがない限り、基数18で表される階乗（n！）は、基数10または基数16または基数19で表される同じ値よりも「1」ビットが少なくなります。したがって、（原則として）基数を使用します。 18を使用すると、10進数または2進数の2 ^ w基数または基数19を使用するよりも、bignumライブラリの実行速度が速くなります。これは、n！基数10または基数16または基数19よりも基数18で印刷した場合、より短いか、より多くの「末尾ゼロ」があるか、またはその両方です。基数18よりもさらにうまく機能する他の基数はありますか？言い換えれば、nを表すベースはありますか？ベース18よりもさらに少ない「1」ビットで？
これは、「bignumライブラリと素数判定アルゴリズムの便利なベースは何ですか？」の重複ではありません。「2と3の因子がたくさんある、大きな階乗であることがわかっている整数を処理するための最適なベース」は、「小さな因子を持たず、おそらくプライム」。（-：階乗計算を高速化していますか？おそらく他の種類の計算を犠牲にして-私の2番目の間違いですか？:-)
編集：例：
(decimal) 16! ==
(decimal ) == 20,922,789,888,000 // uses decimal 14 "1" bits
(dozenal ) == 2,41A,B88,000,000 // uses decimal 10 "1" bits
(hexadecimal) == 130,777,758,000 // uses decimal 18 "1" bits
(octadecimal) == 5F,8B5,024,000 // uses decimal 14 "1" bits
（私は多かれ少なかれ右側の数字をコンマなしで保存し、それにメタデータのオーバーヘッドもあります）。（「ベースを増やすと、特定の数値を表すために使用する「1」ビットが少なくなる」、または「ベースを増やすと、特定の数値を表すために使用するゼロ以外の数字が少なくなる」と考える人もいるかもしれません。例は、それが常に正しいとは限らないことを示しています。）
各桁を小さな整数（「int」または「longint」または「byte」）として格納しています。数字を保存する他の合理的な方法はありますか？私のコンピュータはこれらの整数を2進数で格納していると確信しています。各「1」、「2」、「4」、「8」、および「G」の数字は1つの「1」ビットを使用します。各「3」、「5」、「6」、「9」、および「A」の数字は、2つの「1」ビットを使用します。各「7」および「B」桁は3つの「1」ビットを使用します。各「F」桁は4つの「1」ビットなどを使用します。
この値（16！）の10進数と8進数の両方の表現には、14"1"ビットが必要です。そのため、以前の計算で間違いを犯しました。すべてのnについて、nを表します。8進数では、同じ値を10進数で表すよりも「1」ビットが常に少ないとは限りません。しかし、疑問はまだ残っています。大きな階乗を格納するために必要な1ビットの数が最も少ない他の「最適な」ベースはありますか？
誰かが尋ねます：「あなたはそれらの番号をどのように保存しますか？」さて、それはまさに私の質問です-nの形の数を保存する最良の方法は何ですか！？内部的には、基数10、2の累乗の基数、基数18、またはその他の基数の数字を使用できます。どれが一番いいですか？これらの整数を1Dの数字配列として内部的に格納できますが、すべての桁を格納するには長さが必要です。100を印刷する合理的な方法はありますか？そのような配列なしで10進数で？