アカウント名:
パスワード:
これ逆に考えたら理論上は281TBを10MBに圧縮できるってこと？
AAAAAA…で281TBなら、理論上は8bit+64bitの9byteに圧縮できるよ。
素直にうまいと思った
Aカップでトップとアンダーの差5cmで1カップ辺り2.5cm差なのでペタンは理論上AAAですよ
ダウトAカップでもトップとアンダーの差が10cm [wacoal.jp]ですよ
つまり…AAAAAまである！
NULL
8bit+49bitで8byteで可能じゃないですか。
281T 2^9 * (2^10)^4 = 2^49
どこか計算間違ってるかな。もしかして、long integerで64bitかな。
8byteでも9byteでもどっちでもたいした違いはないけど。
どうでもいいけど、それだとビット長の情報が足りてないのでは。まぁ、バイト単位に制限すれば3ビットで足りるけど。
> どうでもいいけど、それだとビット長の情報が足りてないのでは。
それは自分もあとで気づいたけど、49を表現するには6bitあればいいから、49bit+6bit=55bitで合計8byteで足りるはず。
フォーマット決め打ちじゃないと成り立たないけど。そんなこと言ってたら話しが振り出しにもどっちゃう。
意味のあるデータである必要はないよね掛け算、割り算、etc...
それ言ったら無限を1バイトまで圧縮できますがな。2.71828...→e3.14159...→πみたいな。
πはUTF-8では2オクテット（U+03C0）
パイの文字って1バイトで表現できたっけ?
ISO 8859-7 ならね。
あと、MZ-80系
学部の情報理論やっていれば、理論上はエントロピーまでいけるやんエントロピー限りなく低い冗長なデータなら理論上はいくらでも小さくなる
ちなみにZIPのプログラムのバグや誤動作は関係ないよ
そんなに大容量を圧縮できるならゲルまゆしぃにならずにすみそう
あらゆるファイルを1バイトに圧縮できる究極の圧縮プログラムTHcompを用いれば……
https://thcomp.org/pen/pfyp/thcomp/thc00.html [thcomp.org]
最初に圧縮する256個までで以降は2バイト、3バイト…じゃなかったっけ
一番最初のthcomp自身は0バイトですね。ファイルサイズ自体も情報になってる。理論上最長は11バイトだっけ。今時なら4～5バイトあたりにまで伸びてるかなぁ。
要するに短縮URLじゃないか
まぁ、もし今の時代にリアルに実装するなら、そういう事。アップローダーにファイルをアップしたらダウンロード用のURLが返ってくる（末尾がID）、という形で今日では普通に実用されてます。
しかし、当時はまだWWWもなく、URLの概念がなかった時代。ネットワークへの常時接続も高速通信も無い。人々がデータの代わりに識別子をやり取りし、その識別子から当たり前のように元データを参照できるなんてことは無かった時代なのです。
元ネタの作者もアップローダー＋IDという事は考えておらず、人類の生み出す全データに対する完全ハッシュという数学的ネタだったのだそうです。
とは言え、現実のインターネットとURLは、巨大なデータベースとデータへのハッシュに見える点では興味深くありますね。
このやり取りが行われていたBBSを運営していた会社の某中の人は、利用者がファイルの保存場所をどこまで意識するかという、トポロジー面で興味深い話だった、と書いていたのを覚えてますネタ話としてあの中で完結していたのもTHcompの見事な点だった
データを「そのデータを出力するプログラム」に変換することで圧縮するというのが強そう問題は、最高圧縮率を得ることが困難(というか最高圧縮率であることを証明することは不可能)なことだが
それをコルモゴロフ複雑性 [wikipedia.org]という
知らないなら黙ってろ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ふと思ったけど (スコア:0)
これ逆に考えたら
理論上は281TBを10MBに圧縮できるってこと？
Re: (スコア:0)
AAAAAA…で281TBなら、理論上は8bit+64bitの9byteに圧縮できるよ。
Re:ふと思ったけど (スコア:5, おもしろおかしい)
Re: (スコア:0)
素直にうまいと思った
Re: (スコア:0)
Aカップでトップとアンダーの差5cmで1カップ辺り2.5cm差なのでペタンは理論上AAAですよ
Re: (スコア:0)
ダウト
Aカップでもトップとアンダーの差が10cm [wacoal.jp]ですよ
Re: (スコア:0)
つまり…AAAAAまである！
Re: (スコア:0)
Re: (スコア:0)
NULL
Re: (スコア:0)
8bit+49bitで8byteで可能じゃないですか。
281T 2^9 * (2^10)^4 = 2^49
どこか計算間違ってるかな。
もしかして、long integerで64bitかな。
8byteでも9byteでもどっちでもたいした違いはないけど。
Re: (スコア:0)
どうでもいいけど、それだとビット長の情報が足りてないのでは。
まぁ、バイト単位に制限すれば3ビットで足りるけど。
Re: (スコア:0)
> どうでもいいけど、それだとビット長の情報が足りてないのでは。
それは自分もあとで気づいたけど、49を表現するには6bitあればいいから、49bit+6bit=55bitで合計8byteで足りるはず。
フォーマット決め打ちじゃないと成り立たないけど。
そんなこと言ってたら話しが振り出しにもどっちゃう。
Re: (スコア:0)
これ逆に考えたら
理論上は281TBを10MBに圧縮できるってこと？
意味のあるデータである必要はないよね
掛け算、割り算、etc...
Re: (スコア:0)
それ言ったら無限を1バイトまで圧縮できますがな。
2.71828...→e
3.14159...→π
みたいな。
Re:ふと思ったけど (スコア:1)
πはUTF-8では2オクテット（U+03C0）
Re: (スコア:0)
パイの文字って1バイトで表現できたっけ?
Re: (スコア:0)
ISO 8859-7 ならね。
Re:ふと思ったけど (スコア:1)
あと、MZ-80系
-- う～ん、バッドノウハウ？
Re: (スコア:0)
学部の情報理論やっていれば、理論上はエントロピーまでいけるやん
エントロピー限りなく低い冗長なデータなら理論上はいくらでも小さくなる
ちなみにZIPのプログラムのバグや誤動作は関係ないよ
Re: (スコア:0)
そんなに大容量を圧縮できるならゲルまゆしぃにならずにすみそう
Re: (スコア:0)
あらゆるファイルを1バイトに圧縮できる究極の圧縮プログラムTHcompを用いれば……
https://thcomp.org/pen/pfyp/thcomp/thc00.html [thcomp.org]
Re: (スコア:0)
最初に圧縮する256個までで以降は2バイト、3バイト…じゃなかったっけ
Re:ふと思ったけど (スコア:1)
一番最初のthcomp自身は0バイトですね。ファイルサイズ自体も情報になってる。
理論上最長は11バイトだっけ。今時なら4～5バイトあたりにまで伸びてるかなぁ。
Re: (スコア:0)
要するに短縮URLじゃないか
Re:ふと思ったけど (スコア:1)
まぁ、もし今の時代にリアルに実装するなら、そういう事。
アップローダーにファイルをアップしたらダウンロード用のURLが返ってくる（末尾がID）、という形で今日では普通に実用されてます。
しかし、当時はまだWWWもなく、URLの概念がなかった時代。
ネットワークへの常時接続も高速通信も無い。
人々がデータの代わりに識別子をやり取りし、その識別子から当たり前のように元データを参照できるなんてことは無かった時代なのです。
元ネタの作者もアップローダー＋IDという事は考えておらず、人類の生み出す全データに対する完全ハッシュという数学的ネタだったのだそうです。
とは言え、現実のインターネットとURLは、巨大なデータベースとデータへのハッシュに見える点では興味深くありますね。
Re: (スコア:0)
このやり取りが行われていたBBSを運営していた会社の某中の人は、利用者がファイルの保存場所をどこまで意識するかという、トポロジー面で興味深い話だった、と書いていたのを覚えてます
ネタ話としてあの中で完結していたのもTHcompの見事な点だった
Re: (スコア:0)
データを「そのデータを出力するプログラム」に変換することで圧縮するというのが強そう
問題は、最高圧縮率を得ることが困難(というか最高圧縮率であることを証明することは不可能)なことだが
Re:ふと思ったけど (スコア:1)
それをコルモゴロフ複雑性 [wikipedia.org]という
Re: (スコア:0)
知らないなら黙ってろ