アカウント名:
パスワード:
同社の圧縮方式は理論上は実現可能なものだが,確実な立証にはまだ何年もかかるとしている
可逆圧縮だったら、エンコードしてデコードしたものを元ファイルと 比べるだけでOKな気がしますが、何を言いたいんでしょうね?
ひょっとして、この方式が適用できる確率を気にしているのかな。 ジャンルを限定しても1%とかだったら、実用になりませんものね。
そんな事は書いてありません。CRCを使った エラーチェックでは、展開データが壊れている事を 発見するのに失敗する可能性がある、 と書いてあるだけです。展開に失敗する確率ではありません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
立証に何年も? (スコア:1)
可逆圧縮だったら、エンコードしてデコードしたものを元ファイルと
比べるだけでOKな気がしますが、何を言いたいんでしょうね?
ひょっとして、この方式が適用できる確率を気にしているのかな。
ジャンルを限定しても1%とかだったら、実用になりませんものね。
Re:立証に何年も? (スコア:1)
例えば、メモリを100TB使用するとか、計算量が膨大すぎるとか。
BlockSortingも、論文通りに実装するとデータ量の2乗のメモリが必要だというのをどこかで見た記憶があります。
Re:立証に何年も? (スコア:1)
Re:立証に何年も? (スコア:1)
確実な立証にはまだ何年もかかるとしている
> 可逆圧縮だったら、エンコードしてデコードしたものを
> 元ファイルと比べるだけでOKな気がしますが、何を言いた
> いんでしょうね?
元記事に「今回の理論ではランダムなデータ列を100分の1に圧縮し、完全に再現することができるらしい」
と書いてあるので、「ある特定のランダムなデータ列」は圧縮できるけれど、それ以外のデータ列だと自信ないな、ってなところでしょか。(ははは
〜◍
Re:立証に何年も? (スコア:1)
みんつ
Re:立証に何年も? (スコア:1)
チューリングマシンの停止問題と最適化コンパイラの関係みたいに。
Re:立証に何年も? (スコア:0)
なんでひらたくNP完全(もしくはNP困難)って書かないんですか?
仮にそうだとしても、当然ながら素姓の良い近似解が得られる見通
しがあるからこそ、発表しているわけでしょう。今どき新しいNP
完全な問題を見つけただけでは、まったく面白くないですから。
Re:立証に何年も? (スコア:1)
チューリングマシンの停止問題は不確定性原理の話であって、
NP完全とは別の話ではなかったでしょうか。
Re:立証に何年も? (スコア:1)
Re:立証に何年も? (スコア:1)
というように、「圧縮+伸張して、元ファイルと比較する」程度の経験則では「確実な立証」とは言えないですし、「確実な立証にはまだ何年もかかる」というのも、それほど変な話とも思いませんけどね。
Re:立証に何年も? (スコア:1)
そんな事は書いてありません。CRCを使った エラーチェックでは、展開データが壊れている事を 発見するのに失敗する可能性がある、 と書いてあるだけです。展開に失敗する確率ではありません。
Re:立証に何年も? (スコア:1)
でも、初期の bzip2 って「稀に展開できない」ってバグありましたよね。
Re:立証に何年も? (スコア:1)
>「確実な立証」とは言えないですし、
「経験則」という言葉が出たということは、残念ながら意図を
汲み取ってもらえなかったようです。
意図していたのは、「理論が怪しかろうが、証明が難しかろうが、
可逆圧縮である以上、エンコード時に常にデコード&チェックを
行えば、ツールとしては安全確実に使えますね」ということです。
実用上の点では、エンコードが正しいことの証明は重要でなく、
むしろエンコードが行える可能性(確率)の方が問題となります。
それから、bzip2の話ですが、40億分の1というのは32bit CRC
チェックがデータ破損を見逃す確率です。bzip2の実装やアル
ゴリズムに既知の問題があるわけではありません。
Re:立証に何年も? (スコア:1)
「比較」だけでは、安全に使うことはできませんよね。
みんつ
Re:立証に何年も? (スコア:1)
> 手順・パラメータで行われることが期待できないとしたら...
可逆圧縮で、エンコード側とデコード側のアルゴリズムやパラメータを
変える必然性がある用途って何かありますか?
Re:立証に何年も? (スコア:1)
エンコード側がデコードの際に期待するパラメータを、デコード側が期待できない、ってのはいかにもありそうな。そういう意味では、アルゴリズムの必然性からそういった場合もある、という可能性を指摘したまでです。
エンコード関数y=f(x)に対して、デコード関数x=f-1(y) が大量にある場合や、f-1(y,s,t,u,...)なんて時には、期待通りのパラメータが必ず使用されるというわけではないのでは。
他の投稿にもあるように、f-1(y)を見つけるだけでもかなりの演算量を使ってしまう場合もあるかも。f-1(y) が存在しない場合や、収束しない関数となってしまう場合もあるかも。
みんつ