素数圧縮

まず素数に識別子を振る。 そして素数以外の数は、素数の積で表現する。 これだけ。 1子 2丑 3寅 4丑丑 5卯 6丑寅 7辰 8丑丑丑 9寅寅 10丑卯 11巳 12丑卯寅 13馬 14丑寅 15寅卯 無限進数にはなってしまうが、巨大な数を表現するにはこちらの方が効率が良い。 ビット列にこれを適用すればデータを圧縮できる。 計算力が凄まじい宇宙人はこの方法で数を表現しているかもしれない。

[Palantir]

掛け算割り算しかない場合実は便利では？ 足し算引き算したら爆発しそう

[dgen]

コンピュータで使うなら何bitで扱うかが問題だ。元の数が 64bit で識別子が 32bit だとすると元の数のままのほうが速度も容量も有利。圧縮しないほうが得になる。それより１０¹⁰⁰⁰⁰⁰⁰⁰⁰⁰⁰⁰進数のほうがいいな。

[ka-ka_xyz]

idに素数を振ってアクセス権限設定として素数の積を使う（read_acl=105の場合、user_id=3,5,7のユーザーがread出来る的な）というのを思い出したけど、ユーザやグループを増やしてくとわりかし簡単にInteger.MAX_VALUEに手が届く地獄

[knok]

任意のデータにそれぞれ固有の整数を割り当てるというネタをみたことがある

[hatest]

ｿｽｳ ←素数圧縮

[ROYGB]

似たようなことを考えたことはある。新たな記号は、前の数＋１（もしくは＋子）で定義する。たとえば丑＝子＋１、寅＝丑＋１、卯＝丑・丑＋１、辰＝丑・寅＋１みたいな感じ。丑と＋１だけで表記することも可能。

[programmablekinoko]

この方法って大小比較が難しいイメージがある（それぞれの素数の対数値を覚えて計算しなければいけない）

[maninthemiddle]

各素数に文字を割り当てる部分は主眼ではないのでは。 全てのファイルは突き詰めれば巨大な二進数なわけだし、巨大数の素因数分解が容易であれば(反実仮想)もっともだと思う

[nori__3]

識別子足りなくなるんじゃないの？

[brightsoda]

識別子すぐなくなっちゃうな… そうだいくつかの記号を一定の法則に沿って並べればそれが識別子になるんじゃね(n進数の発見)

[fraction]

見た目を圧縮して何が楽しいのやら。それはともかくラマヌジャンとかガウスは自然数把握因数分解だったかもね。

[madooka]

あっという間に識別子が枯渇しそうでピンとこないなー。追加ルールは面白いが計算量が気になる。このルールの方が効率が良い最大値を求めるのは体操としてアリかな。識別子の表現で食うデータ量を圧縮率で補える数