unsigned charを使用すると、 0から255までの数値を格納できます。
255（b10）= 11111111（b2）<=1バイトです
これにより、+、-、*...などの操作を簡単に実行できるようになります。
では、どうでしょうか。
255（b10）= 10101101（b2）
この方法に従うと、 unsigned charを使用して最大399を表すことが可能になりますか？
399（b10）= 11111111（b2）
誰かが最後の方法を使用して加算を実行するアルゴリズムを提案できますか？
8ビットの場合、どのようにスライスおよびダイスしても、可能な値は256（2 8 ）のみです。
次のような2-3-3形式で数字をエンコードするスキーム：
255 = 10 101 101
399 = 11 111 111
そこにあるこれらの3ビットシーケンスは、10ではなく8つの値（0〜7）しか表せないという事実を無視します（つまり、2番目の値は399ではなく377になります）。
トレードオフは、これは、合計82の値に対して数値（2つの値）（16の値）と（64の値）を取得することを意味します。'25[6-7]''2[6-7][0-7]''3[0-7][0-7]'
そのゲインの犠牲8は、以下を含む数値を表すことができなくなることです9：'[8-9]'（2つの値）、'[1-7][8-9]'（14の値）、'[8-9][0-9]'（20の値）、'1[0-7][8-9]'（16の値）、'1[8-9][0-9]'（20の値）、または'2[0-4][8-9]'（10の値） 82の値の。
そこでのバランス（82対82）は、8ビットデータ型に対してまだ256の可能な値しかないことを示しています。
したがって、エンコーディングスキームは欠陥のある前提に基づいているため、質問の2番目の部分（それらを追加する方法）は無関係になります。恐れ入ります。
タイプは、ビット数が表すことができる最大の符号なし値のルールによって決定された値との間のunsigned char値のみを数学的に保持できます。charの範囲を「改善」する方法はありません。代わりに、2バイトを保持するanを使用することをお勧めします。02552^n - 1nunsigned short
あなたは間違っています。
あなたのスキームでは、255は9ビットである010101101になります。先行ゼロは重要です。ここでは、8進数表現のようなものを使用していると想定しています。3ビット/桁。他の代替手段は、他のすべての数字を表すことができないことを意味します。
|0|000|
|1|001|
|2|010|
|3|011|
|4|100|
|5|101|
|6|110|
|7|111|
|8|???|
|9|???|
2進数の9は1001です。したがって、1桁あたり3ビットを使用することはできません。8と9を表す場合は、4ビットを使用する必要があります。ここでも、各桁を個別にエンコードしていると想定しています。したがって、あなたによると399は次のようになります：001110011001-12ビット。比較すると、バイナリは110001111-9ビットで399を実行します。
したがって、バイナリが最も効率的です。システムで0〜9の数字をエンコードすると、8ビットで情報を失うことなく格納できる最大数は99〜10011001になります:)
バイナリを考える1つの方法は、数値を見つけるためのログ検索の結果であるパスです。
数値を表すために必要なビット数を本当に凝縮したい場合、本当に求めているのは、バイナリの実行方法ではなく、ある種の圧縮です。
あなたがしたいことは数学的に不可能です。8つのブール値で256の離散値のみを表すことができます。
これをテストするには、10進数と2進数で可能なすべての値のグラフを作成します。つまり
000 = 00000000
001 = 00000001
002 = 00000010
003 = 00000011
004 = 00000100
...
254 = 11111110
255 = 11111111
255の後に、9番目のビットが必要であることがわかります。
を許可することはできますが255 = 10101101、それから逆方向に作業すると、0に達する前に不足します。
どういうわけか、別のカウントメカニズムを使用してより多くの値を格納できることを望んでいるようです。これは数学的には不可能です。PidgeonholePrincipleを参照してください。