アカウント名:
パスワード:
たとえば、そこそこのデータのCRC16とMD5を作成し、データ長とともに転送します。それを受け取った側ではbrute forceでデータを復元するような感じです。一応断っておきますが、あくまで例なのでこの方法で出来るとは私も思いませんし、大体出来たとしても気が遠くなるような速度です。これの非常に数学的で効率的な方法を編み出したと。
Shanonの定理に抜け道が見つかると言うのは考えづらいですが、これで事前にあらゆるデータプールが存在していると言うことになっていると、実際には最初に無限大のデータを転送していることになりますから、Shanonの定理に反しているとはいえないと思います。
Shanonの定理に抜け道が見つかると言うのは考えづらいですが
多分抜け道はないと思います.記述長という考え方が 統計っちゅうか機械学習の分野にあります. THComp [nurs.or.jp] とも関係があるのですが,要するに(圧縮後の)データ長 + 圧縮ルールの記述長 を考えなければならんということです. 前者が通信媒体上を流れる量や,(圧縮後の)ファイルサイズに 対応して, 後者が圧縮・伸張に必要なデータ・規則に 対応します. # THComp は後者が巨大になっていくアルゴリズムと # いうことが出来るでしょう. ですから,件のアルゴリズムはマスターデータっちゅうか encode/decode のためのルールが複雑怪奇大鑑巨砲的な ものになっているのではないかと推測します.
「自然発生パターンを意図的に作り出して,エントロピーライクなランダムシーケンスを形成するもの」
ま,20bit 約 100万 通り全てのパターンを 1万パターン(13~14bit) で記述するのはどだい 無理な話だと思います.ありがちなパターンはそれぐらいまで 圧縮できるけど,逆に膨れ上がる(30bit 要する)場合もある というのがオチではないかと思います.
ありがちなパターンはそれぐらいまで 圧縮できるけど,逆に膨れ上がる(30bit 要する)場合もある というのがオチではないかと思います
# つまり、RLEの得意な分野が徹底的に苦手になる?ま、そうであればRLEと組み合わせればすむ話ですが。
# そういえば、昔見たFARってグラフィックフォーマットは複数アルゴリズムを選択するようになっていたな・・・ああいうアーカイブフォーマットは二度と出てこないのだろうか
ただ、どっちにしてもそんな単純な方法ではRC5-128bitを解く方が2^32倍ましな速度にしかならないと思います。
無限のデータの中の任意の部分をインデックシングできるためには、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
推測 (スコア:1)
たとえば、そこそこのデータのCRC16とMD5を作成し、データ長とともに転送します。それを受け取った側ではbrute forceでデータを復元するような感じです。一応断っておきますが、あくまで例なのでこの方法で出来るとは私も思いませんし、大体出来たとしても気が遠くなるような速度です。これの非常に数学的で効率的な方法を編み出したと。
Shanonの定理に抜け道が見つかると言うのは考えづらいですが、これで事前にあらゆるデータプールが存在していると言うことになっていると、実際には最初に無限大のデータを転送していることになりますから、Shanonの定理に反しているとはいえないと思います。
Re:推測 (スコア:1)
> ことの出来るようなジェネレーターでないでしょうか?
おそらくそうでしょう。
さらに勝手に推測してよければ、私はリー・ヨークの定理に触発されたものではないかと思う。
理屈では任意のビット列を生成するような初期値を求めることができる。
ただし、コンピュータでは数値を離散的にしか扱えないから、すぐに周期的になってしまって、"あらゆるビットシーケンス"はとうてい無理。
あの正方形内に、現実データにありがちなパターンを良く生成するような線の引き方(関数)を見つけたということかな。
まあ、そんな単純な話じゃないとは思うけど。
Re:推測 (スコア:1)
多分抜け道はないと思います.記述長という考え方が 統計っちゅうか機械学習の分野にあります. THComp [nurs.or.jp] とも関係があるのですが,要するに(圧縮後の)データ長 + 圧縮ルールの記述長 を考えなければならんということです. 前者が通信媒体上を流れる量や,(圧縮後の)ファイルサイズに 対応して, 後者が圧縮・伸張に必要なデータ・規則に 対応します.
当たりに,その雰囲気を感じます. 何というか・・・世界シミュレータを作るような ものに思える.# THComp は後者が巨大になっていくアルゴリズムと
# いうことが出来るでしょう.
ですから,件のアルゴリズムはマスターデータっちゅうか encode/decode のためのルールが複雑怪奇大鑑巨砲的な ものになっているのではないかと推測します.
#『と』な雰囲気もちょっと感じる
ま,20bit 約 100万 通り全てのパターンを 1万パターン(13~14bit) で記述するのはどだい 無理な話だと思います.ありがちなパターンはそれぐらいまで 圧縮できるけど,逆に膨れ上がる(30bit 要する)場合もある というのがオチではないかと思います.
Koichi
Re:推測 (スコア:1)
# つまり、RLEの得意な分野が徹底的に苦手になる?ま、そうであればRLEと組み合わせればすむ話ですが。
# そういえば、昔見たFARってグラフィックフォーマットは複数アルゴリズムを選択するようになっていたな・・・ああいうアーカイブフォーマットは二度と出てこないのだろうか
Re:推測 (スコア:0)
無限にある元データ候補の中から、なんらかの方法で「答えっぽい」のを一つ選ぶことができても、それが正解って確証はどこにもないわけで…
Re:推測 (スコア:0)
なら元データ候補は、無限じゃないですね。
ごめんなさい。はやとちりでした。
それでも、元データの候補がいくつか出てくる可能性はありますね…
もし
Re:推測 (スコア:1)
ただ、どっちにしてもそんな単純な方法ではRC5-128bitを解く方が2^32倍ましな速度にしかならないと思います。
Re:推測 (スコア:0)
いまの計算機の能力では実用的ではないですね。
MD5もCRCもこういう用途のために作られたわけじゃないでしょうし…
でも、イメージとしては良く分かりました。
このMD5やCRCのかわりに、情報の圧縮に適した「何か」を用いているのでは、ってことですね。
Re:推測 (スコア:0)
インデックスの長さも無限じゃないといけないと思うぞ、と。
Re:推測 (スコア:1)
Re:推測 (スコア:0)
それって結局、利用されるデータの性質に依存する圧縮法だから、現状の汎用ロスレス圧縮アルゴリズムと比べて、劇的によくなるとは思えないんだけどな。