【2ch】圧縮アルゴリズム【オリジナル】

おい、おまえら圧縮ソフト作ってみませんか？
中途半端に圧縮されて拡張子が.2ch

可哀想に・・・

ベースはブロックソートで.
GPL以外は認めない！

圧縮対象を .dat ファイルに限定した圧縮とか？

何故、「作ります」 ではなく 「作ってみませんか」 なのだろう。

AAの圧縮に特化したものを作りなさい

>>6
なるほど。ﾖｻｹﾞ

作ります。じゃなくて作りませんか？にした理由は
プログラムを始めたばかりで一人では無理そうだったからです。
みなさんで協力していけたらいい物ができるのではないかと。

君は何ができるんだい？

学校でCを習ってはいますが、できると言えるほど教えてもらってないです。
クラスでは出来る方ですけど。

構造体やポインタなんて全然まだで、配列ができる程度です。

AA圧縮かぁ・・・。ランレングスかけてハフマン符号化するくらい？

スペースが多いし、ランレングスでもけっこう圧縮できるかもな。
>>1は習作として作ってみれ。

時間はかかるかもしれませんが、頑張ってみます。

俺がカオス理論の授業中に発明した圧縮方法を試すときが来たかな。

ＡＡのみを対象として圧縮プログラムのコンテストを開いてみるとか。
未知のＡＡ５個くらいに対して、一番いい圧縮結果を出したソフトが優勝。

AAの分野においては既存の圧縮アルゴリズムに勝てるものを作るの？

おもしろそう

>>15
うん

一般のデータとAAデータの差異ってどんなのがある？
AA固有の特徴が見つかるとナイスってことだよね？

上でもでていたけど、同じ文字が続けて使われやすいとか、
使われやすい文字が限られてるとかじゃないかな。

半角スペースと全角スペースの連続するある程度のパターンをテーブル化しとくと略せそう。
とにかく所有するテーブルが鍵になるのでは？

テーブルを256個くらいつくっとけば大抵のAAいけるんじゃない？

対象AAとの差異がが少ないAAテーブルのなかのAAの番号と、
そのAAと対象AAとの差分を圧縮した結果をつなげる。

dat圧縮るならレスをぶつ切りにして個々に22の圧縮をかけてつなげる。
あるいは差分を圧縮せずにつなげて全体を圧縮。

gzipより効率のいい圧縮になるとは思えないな・・・

>>24
gzip なんか、全然圧縮率良くないじゃないか。
LHAよりも悪いんだぞ。
bzip はそれらよりももっと良いし。

>>24
AA専用だったらさ、MP3みたく多少劣化しても元絵が判別できればOKということに
すれば、かなり圧縮できたりしないかな？

>>26
似た文字は置き換えちゃうとか？

やっぱ 1 と l と | は一緒扱い？

>>28

AA職人が泣くぞ。

>>29
そう。それが一番のネックなんですが

>>26
ピクセル単位で命懸けてるAA職人に失礼かと。

わ。30の24は26の間違いです......鬱氏
>>31
やっぱダメっスか......

31っす。
>>32
うん。俺職人じゃないけど、モナ板住人なんで。

それこそ各 AA に UID ふって、AA サーバに登録・参照できるようにするとか。

>>34
それは圧縮とは言わない。

>>35
お馬 さん

このスレの全文をたった４８バイトに圧縮してみますた。

http://pc3.2ch.net/test/read.cgi/tech/1028570486

2ch/tech/1028570486
まで圧縮できないか？

pc3/tech/1028570486かな。
tech/1028570486までは逝ける。
1028570486はlong intで表現できるからtech(4byte)。
tech等はテーブルを持ってindexは1byteで表現しちまおう。
よって、このスレは5byteで表現できる。

某板には英文字のスレがあるのだが。

じゃあ、16進でスレ番号は5byteで

あとはレス番号が 1-1000 なので 10bit で扱える。
これで、少なくとも 2ch に存在するAAなら7byteで表現化農家

昔のスレには、10000レスとかあるが。無視かえ？

板1byte:スレ:5byte:レス:2byteで8byte。

マジな質問で悪いんだけど、結構最近のモノも含めた圧縮理論を勉強する上でわかりやすい本ってないかな？
オススメあったら教えて。

馬鹿でもなんとなくわかる本希望で

>45
Cマガの先月（7月）号

圧縮扱ってる本て少ないしな。
素直にデータ圧縮ハンドブック読んでおくのがいいかと。

>>45
英語でも良いなら
Kluwer Academic Publishers "Compression and coding algorithms"
がおすすめ。

日本語は参考になる本が少ないからな〜
データ圧縮ハンドブック と C MAGAZINE 以外には、
文書データ圧縮アルゴリズム入門くらいしかないが、絶版だし。

そもそも、圧縮自体が研究が進みすぎて下火になっているという罠。
画像圧縮の方は盛んだけどな。
何か画期的な圧縮法を>>45が発明することを期待する。

textだけど二次元的なつながりで考えて圧縮、ってのは面白いかもね。 でも圧縮関係の思いつきはほとんどが特許とられてる気もするが。

線画に変換してから圧縮。解凍時にオートトレース。とかは駄目？

>>50
その方が、圧縮率が悪くなりそうだよ。
基本パターンやカッコなどの対応をあらかじめ学習しておくのがAA向きか。

オートトレースで済むなら職人はイラン。

>>52
小さいサイズのAAなら職人技が光るけど、
大きいサイズだとツールを使ったものも多いよね。

LZHアルゴリズム開発者ですが何か？

というか、AAが対象というか、可読文字のみが圧縮対象となるから

>>54
ああ特許の件で何も影響力が無かったカスか、まあいらっしゃい

>1
いっそのことマイナーな圧縮アルゴリズム使ってみないか？
おれはBPEぐらいしか知らんが。

JPEGの圧縮ってどうやってるんですか？

逆手に持って絞ります。

モナー系に限定すれば、（　´∀｀）とか（　・∀・）が大量に出てくるから、
かなり圧縮できそう。

くっ、この糞ｽﾚを利用して
JPEG圧縮ﾌﾟﾙグラムを作ろうとしたがやはり無理か。

>>61
そんなことは俺が許さん!!!!(嘘

>>62
何で？

ﾈﾀをﾈﾀと見抜ける物でないと(略

鬱出汁脳。

ネット上にある、違法でない巨大ファイル(RedHatのISOなど)を利用して圧縮←遅いのでHDに一回DWN
([ISOと圧縮対象ファイル]の[同じデータ]を探してISOのデータアドレスをアーカイブに書く)
回答時はネットに接続して、ISO参照の部分だけISOから抜き取って解凍。
DQNだと思われなら無視なされて結構です。

>>65
なに言ってんだかさっぱりだけど
恒常性の無いデータなんか
使いモンにならんぞなモシ

>>65
DQN
どうせなら辞書鯖用意して巨大共通辞書ファイル置くってのはどうか。

＞65
そのISOファイルへのポインタが消費するバイト数　＞
ISOファイルを利用することによって節約できるバイト数

になる予感。

用意するもの
･巨大鯖
･クライアント
･高速回線
ユーザがファイル圧縮を選択するとファイル内容が巨大鯖に転送されます。
……書いてて面倒くさくなってきたので続きはTHComp参照。
案外実現できそうな気がしない？

思い出した・・・この流れ・・・
昔導き出された結論はこうだ・・・
「インデックスのサイズが圧縮元のサイズと同じになる」

１０年ほど前のある論文で、文字化された全世界の文章全てを圧縮すると
１８GBに収まるってのがあった
この辞書を各クライアントが持つってのはどうかな？

当時は夢の容量だったから、だからどうしたレベルだったけど今ならいけそうだね

「文章」圧縮だけなら、それでもいいけどね。

>>57
BPEって特許からむのかな。
Cマガの記事は読んでないのでよく知らないけど、
セクションサイズを可変にするのはダメ？
255種類のByteが出現するまで読み込んで、
その中で最も多いペアを出現していない残りの１種類のByteに置き換える。
セクションのデリミタとしてもう1Byte予約しておかないとダメか。

>73
俺もCマガの記事は読んだこと無いけどBPEの作者は特許取らない
ような事を言ってたらしいよ。

たしかBPEでは200種のByteが出てくるまで読みこんで(これを１ブロックとする)
その中から最多頻度のペアから順次残りの56種に割り当てて
圧縮していって圧縮が効かなくなるか256種使いきるまでやって
ペア表(軽く圧縮)・ブロックサイズ・圧縮データの組を順次出力してたと思う。

BPEが実際に使われた例は1しか知らないな。(除自作プログラム)

>>74
なるほど。そもそもブロックサイズは固定じゃなかったのか。
適当に前処理すれば圧縮率上がりそうな感じするね。

こんな前処理を考えてみた。
　ブロックソーティング→ランレングス圧縮→BPE(Byte Pair Encoding)

※ランレングス圧縮を間にはさむのは、ブロックソートすると同値の連続が多くなり、
　それをそのままBPEするとその連続の個所で無駄にペアが消費されるから。

でも本当に圧縮率が上がるかどうかは不明(汗

RLE→BPE は太るよね。
それをやるなら普通に BWT→MTF→BPE なのかな。

BPEってもっと効率の良いブロックサイズを決定する方法がある気がする。

>>77
>RLE→BPE は太るよね。

あ、RLEでビット単位の操作が入るようなのだとBPEは効きにくくなるな。
テキスト専用の圧縮にするなら0x00を長さ表示の開始コードに割り当てれば
実際の圧縮の場合は問題無いかも。
#それとも、まだ勘違いしてる？

>それをやるなら普通に BWT→MTF→BPE なのかな。

あと、ここ↓の2.14.15をみるとBWT→MTFよりMTF→BWTの方がいいみたい。
　http://www.ingnet.or.jp/~kojif/mu/comp/bwt.htm

>BPEってもっと効率の良いブロックサイズを決定する方法がある気がする。

このへんは良い方法思いつかないな。
以前自分で作った(拾ったコードを改変した)やつではデフォルトのパラメータ使ってたし。

> #それとも、まだ勘違いしてる？
BWT→RLEの時点で、前後のByte同士の関連は無くなってると思っただけです。

> あと、ここ↓の2.14.15をみるとBWT→MTFよりMTF→BWTの方がいいみたい。
「２．１４．５　メモ」のこと？
そこに書いてある“MWT”ってのは何なのかわかんないけど、
BWT→MTFよりMTF→BWTの方がいいという意味では無いと思いますよ。

そこに書いてあるのは、BWT後のデータを効率よく圧縮する方法として、
まずMTFで0（ゼロ）を増やしてからZero-Runをかけると良いってな意味かと。

通常（未圧縮）の文書に MTF すると、サイズが大きくなることが多いよ。

>>71
現在、世界中のサーバに格納されているテキスト文書を
URIの形をインデックスの表現とすると考える。
このURIリストを圧縮することで、世界中の文書を圧縮できたと仮定する
これは、実際は間違いだが、下限値を記述することにはなる。

4億のサーバがあると仮定。各サーバが10文書持つと仮定。
URIの長さがIPアドレスの長さ4byteの2倍程度に圧縮できると仮定。

4億×10×8 = 29.8 GByte

結論： 18GBではとても無理だ！

>>81
まあ10年前なら18GBを楽に割りそう
ネット環境の発達が文書量のインフレを加速してますな

>>80
MTFかけただけならサイズは増えないだろ。

>>83
BWT->MTF->... よりも MTF->BWT->... の方が大きくなる場合が多いってことでは？

>79
おれはMWTってのをBWTの誤植って解釈してた。
多分MTFのMとBWTのWTが混ざったんじゃないかな。

>84
Cで簡単なコード書いて試してみた。
Cのコード自身にそれぞれの変換をした結果をLZH(lh5)で圧縮して圧縮率を見たら
　無変換 　　　　41.1%
　BWT->MTF　　14.1%
　MTF->BWT　　19.2%
になった。

使い方
a.exe option input output
　option
　　b　BWT->MTF
　　m　MTF->BWT

制限
　入力ファイルは65536Byte以下

動作確認
　CYGWIN_98-4.10 名無し 1.3.12(0.54/3/2) 2002-07-06 02:16 i686 unknown
　gcc version 2.95.3-5 (cygwin special)

コンパイル
　gcc bwt_mtf.c -o bwt_mtf -Wall -O6

※30分で書いたコードだから間違いあるかも。

↓ソースをLZH圧縮＆uuencodeしたもの。
begin-base64 644 bwt_mtf.lzh
RQAtbGg1LU4CAACbBQAA1hRpPSAC4ApNCwABQnd0TXRmLmMbAEGgjeqRXkzC
AQBPDntdTMIBAJhjFUhMwgEFAAALyAAAAe5ju9Gmo75yQ9/7tJtbThwBMeDB
SR8CyMi+dkITS23rjql7ht6hlYfG7//u60AIrFY+Bi5gNG0271oTJrrlPmqX
KhXp1Z7tzr4IqUJ8vsjl1ojYju3DproD63bgB7/V8IQyd/fjyGu3N+UliErB
Evn41I+lvePcvxko2PSKTUsNqkShBEYOXaN9ojSdddKQoPQTgLJGawOfEP3k
JSaoqYCFHi4hBULEJKLEdwK1O8hMp/PQMSaSe3Jo65iRQYtLEbIvZFIMNdnz
eFhBnxgEaYLZei68xLzXEwTKpeRDgygjMxOPC9edCRFJQajTCHYUBoaf72vT
pjha7kh+VSqVtkI1hcP6qZk6wPmsqt0PQ/h9Uw6sgTQTBfDDzgR1fKulaKFz
f6tC4o9Z9GLvycaomCfhXKT8xCLf0iBoMyJOUKf+VpIWSzlb1JsnY2TuIZ+L
WMNzPNJp9MMISPhHSeL4ufN/KlE7kguM/oERfK/1Ctp3uxoDg0mB3LCPKd/L
ykbAIFJ/atlSWiJCXi4RU+UhnZawD02ujL2e33esIEJ2GCBVa/vmJwrg7DZ2
JkzxCOYMb9hvhdYIQuEaS7DpJi26MQx11Ux9TY9IFFcNE5SzmMGExbxlfbY1
hmk1qqO87uxz3IXJqeZGw0JswYiqOHbR2+AdzMQb+ccrQg7m0jLFJg/w1cBm
6H4SW2faIxtERa7+cQW0R/T5+ya0RlPNFXrX4NTiKyqBKl6h8ftovxp9bcob
E86h4yqHusqHNupQs9tPm7ci5c6fu78cGMFmDAAA
====

>>85
> おれはMWTってのをBWTの誤植って解釈してた。
大丈夫、大抵の奴はそう思うから。

MTF->BWTの逆にするとサイズが大きくなるのは有名な話だとおもてた。
少なくとも圧縮に関する研究や職業ならMTFがどういうものか知てるので。

>>86
有名な話だと思ってたってことはどっかに解説でもある？
検索してもBWT->MTFしかでてこない。
むしろ↑これが有効なことの方が有名な気がする。

MTFがどういうものかってのは…まんまの認識じゃあまいってことなのか
MTF程度にどうもこうもないと思うんだが（煽りとちゃいますよ）

圧縮について語るなら、たとえば
ttp://www.hn.is.uec.ac.jp/~arimura/compression_papers.html
にリストアップされてるような論文が理解できないとだめだよね。

ttp://www.ingnet.or.jp/~kojif/mu/comp/bwt.htm
あたりの入門用の解説を読んでもたいしたことは書いてない。

あらかじめ辞書データを登録しておけばなんとかなりそうだね。
本体はでかくなるが。

sage

おりじなるぅ

俺はどんなファイルでも圧縮できるソフト作ったぞ。

2ch圧縮プログラム用辞書には"DQN"、"オマエモナー"、"逝ってよし"などの単語を
登録すれば宜しいか｡

>>92
それが本当なら今すぐ特許を取れ。

>>93
実際そんなに使われていない罠

板毎に上位30スレぐらい取ってきて単語の頻度調べてハフマンコード表作って、
それを初期状態とした動的ハフマン使ったら結構圧縮きくかも。

# 眠い頭で考えたからツッコミ歓迎。

>>92
全てのファイルを1バイト以下にできるということだな？

>>92
すべてのファイルを1ビット未満にできると！？

>>98
1ビット未満ってことは0だな？


それはさておき，少し前にランダムデータに対して圧縮できるって話出てたけど
あれはどうなったんだろう。

>>99
1ビット未満は即0ではないのだが・・・まぁいいや。
再帰的に繰り返せば同じことだから。

＞それはさておき，少し前にランダムデータに対して圧縮できるって話出てたけど
消えたのではなかろうか。
http://www.zeosync.com/ が404エラーになる。

>>100
無知で申し訳無いんだが，今のコンピュータでビットより高い分解能の単位は表現できるの？
（日本語おかしいかも知れんが許してくれ）

0.7 bit x 10 個 なら 7 bit だろ。

>>102
あ，要するに

7ビット中に10個のファイルの内容を格納する

という意味でつね？納得しますた。

>>103
まぁ算術符号なんかは実直にその概念を実装したものなわけだ。小数ビットの。
一方、ZLなんかも見た目は違うけど、実態は同じ。

>>96
誤解してるのかもしれないが、何故動的ハフマンを使う必要が・・。
別にストリームで圧縮するわけじゃないでしょ？

圧縮率は高いけど
もの凄く処理時間がかかって現段階では実用にならない
アルゴリズムってあるの？

>>106
全てのファイルが1〜十数バイトになるってのが昔あったよ（ｗ

>>106
円周率圧縮

>>107
まじ？
それって、シャノンの情報理論とかに反してない？

>>109
　この宇宙で存在しうる全てのデータにインデックスを付けるとしても、せいぜい256bitもあれば十分です
は真でも、全てのデータを256bitに圧縮出来るというのは別の話です。

よく勘違いする人がいるので気をつけましょう

>>108
円周率の数列から目的のデータを検索して
その出現位置でデータを表すってこと？

おまえら、AAに特化ってんだから既存のAAを数百種類プログラムに内蔵させて
それとの差分のみを圧縮すればいいだろ？

シャノンの情報理論に基づきデータの偏りを均一化するんだ。

ああ、テーブルを持ちたくないってことか。すまぬ。

>>113
初期状態のハフマンコード表を作るって言ってるんで、それは違うんじゃない？
あくまで推測ですが、動的ハフマンなら出現頻度の偏りの変化に追従できるから
高圧縮になると考えているのではないかと思われ。

MTFがどういうものかってのは…まんまの認識じゃあまいってことなのか
MTF程度にどうもこうもないと思うんだが（煽りとちゃいますよ）

>>109
あと復号方法も考慮に入れてません(アカシックレコードが必要)

>>115
MTFは情報源の特性（無記憶とか定常とか）によって左右されるから気をつける。
最近、EffrosらによってBWTの冗長度が理論的に証明されたけど、
そこではMTFについてかなり細かく（実はそうでもないが）分析がされてたよ。

円周率使用したって、圧縮にはらなんだろｗ

>>111 それだと逆に増えそう・・・

じゃあ円周率のほかにexp(素数)も使ってくれ

public: searchBit()
　if (assyukuPattern == 0) {
　　int i;
　　while(searchPI(i++))
　　　;
　} else {
　　int j;
　　long sosuu;
　　while((long = getSosuu(j++)) != 0)
　　　int i;
　　　while(searchExp(i++, Sosuu)
　　　　;
　　}
　　put("ok");
}

private: getSosuu() {
//preaseWrite
}

private: searchPI() {
//preaseWrite
}

private: searchExp() {
//preaseWrite
}

>>119
圧縮可能だったら、圧縮するんだよ。無理ならやらなければいい。
それにたとえ確立が低くても、LZHやZIPが圧縮できたら神だろ？

>>121
素数は http://pc3.2ch.net/test/read.cgi/tech/1018657457/ に頼め

擬似コード

long searchBit(bit* data, long assyukuPattern)
//とにかく探す
　int i;
　if (assyukuPattern == 0) {
　　searchPI(i++);
　} else {
　　searchExpSosuu(&data, i++, assyukuPattern)
　}
　return i;
}

long searchPI(bit* data, long offset) {
//PIを検索する
}

long searchExpSosuu(bit* data, long offset, long sosuuno) {
//expSosuuを検索する
}

long expSosuu(long n) {
//getSosuuで取得した素数を(1/2)乗し、PIと同じく無限小数化する
}

long getSosuu(long n) {
//n番目の素数を返す(もちろんテーブルを引く)
}

作れ

>>119
> それにたとえ確率が低くても、LZHやZIPが圧縮できたら神だろ？
限りなく低いので却下

>>114
いや、だから初期状態のテーブルはプログラム側でもって、圧縮したファイルには
入れないんでしょう。

URRって圧縮には使えないのかな？

>>119
PPMZとかで再圧縮した方がはるかに縮みそうだ。

>>128
URR って「万能数値表現法」のこと？
ちょっと資料読んでみたけど、算術符号や、（二分）木による数値圧縮法、
などが近い考えなのではないかとふとおもた。

っていうかプログラムがローマ字なのに萎えた

円周率、素数とか言ってる奴は間違いなく偏差値４０以下の高卒（藁

圧縮可能ならと言ってるが、その情報を付加するんだから情報量は基本的に増える
ことになるんだよ。円周率やら素数やら増やせば増やすほどな
それらのパターンを増やし、全ての情報パターンを表せるようになったときに
圧縮前のデータとおなじビット数が必要になることに気がつくんだよ（藁

くだらんこと言ってないで確率統計でもやってろ痴呆

口は悪いがまったく131の言うとおりだ

今日は自作自演が多いですね。

>>131
ネタにマジレスするなよ…

>>134
オマエモナー

もう現在の圧縮率で限界近いからな
あとがんばっても５％も減らないだろ

シャノンのどうたらってやつ？
でも、BWTはアレを無視した手法強引にエントロピーを低下させてるんでしょ？

どーでもいいけど非可逆圧縮でいいんじゃない？
圧縮くわしくないけどさ
とくに2chのログなんてかなり省略できると思う

↑を圧縮


非可逆圧縮でよくない？
圧縮ｼﾗﾈｰﾖ
特に2chのログﾅﾝﾃｶﾅﾘ省略ﾃﾞｷﾙｻ

>>138
下のやつを展開するとどうなるんですか？

ﾔﾊﾟｰﾘ、2ch専用の圧縮形式なんだから２ｃｈの性質を使わないとな〜。

人工無能を搭載してありがちな反応を数パターン予測して、
その中から一致するパターンがあればそのパターン番号を出力、
失敗したら通常の圧縮って手もあるな。

つまり、擬似コードで書くとこんな感じな。

void 圧縮(前ﾚｽ, レス) {
　array= 人工無能(前レス);
　for(i=0; i< array.size; i++) {
　　if(レス== array[i]) {
　　　出力(i);
　　　(・∀・)ｶｴﾚ!;
　　}
　}
　出力(予測ｼﾊﾟｰｲ);
　出力(通常圧縮(レス));
　(・∀・)ｶｴﾚ!;
}

やっぱ2ch独特の定型文をテーブルで持つのが良いのでは．
この場合，圧縮率の高いスレは内容の少ない糞スレである確率が高い．

>>141
　原文と一緒に圧縮して何%圧縮出来たかで　作者が同一か判定するというのがあったけど
　圧縮率でクソスレ率を出すのも面白いかもね。

>>137
ﾜﾗﾀ。むちゃくちゃ言うなよ。
エントロピーとエントロピーレートは似て非なるもの。

「あいうえおかきくけこさしすせそたちつてと」
　を
「とてつちたそせすしさこけくきかおえういあ」
　の反対と見るようなロジックってありました？

とりあえず圧縮して「.2ch」になれば圧縮比なんてどうでもいいって。
つーかlzhでいいです。

>>145
よくないです・・・・・lzhが拡張子だと、デフォルトではunlhaの方に渡されちゃうよ。

>>146
そりゃ環境依存だ。うちではlzhには何の関連付けもしていない。
unixだと関係ないしな〜

>>147
まぁ結局そうなんですが、やはり.lzhは避けた方がいいのでは。

あのさ、サーバーでごみのようにあるdatをlzhで圧縮すると
負荷がかかりまくるでしょうが。
単純にhttp://をEsc文字　<a href= を　\
アラーム文字 とかでいいと思うんだけどなー

>>149
あふぉだな
そんなくだらんことしないでgzipしたほうが圧縮率あがるんだよヴォケ
殆どgzipで転送してんだからくだらん加工してサーバーに余計な負荷かけるな史ね

ﾀﾞｳｿ症の>>150がいるスレはここですか？

>>150
うわー、おっかなーい。藁

>>150
はいはい。怖い怖い。
ぶるぶる〜



藁

いや、まじめに考えようＹＯ！

>>151=>>152=>>153

>>155
151と152と153を同一フレーズに圧縮したら非可逆になっちまうだろうが。
まあ展開結果は「クソレス3件」だけでも構わんがな。

>>156
真面目に考えんなＹＯ。
つーか思いついた。
２ｃｈ語を特定の数字に置き換えんの。
1,オマエモナー 2,ＹＯ 3,逝ってよし 4,１よ 5,藁・・・・・（２ｃｈ語続く）

だれか作ってくださいお願いします。,5,

>>157
>>95

どうやら小学生がいるな。
特定の文字を数字にしたら
今度は数字を符号化しないといけなくなるじゃん。

予約語が２５６個あって、１バイトで置き換え。
それ以外は原文字のままで１バイトずつ。
で、それら８個集めて別のフラグバイトにどっちかを示すビットを立てていく。

>>160
全部 9bits にするぐらいなら予約語を escape した方が縮むんじゃ…
よっぽど頻繁に出てくればともかく、平文が 9/8 に膨らむと大きそう。

>>155
お前は自作自演を見破れないのか？

LZSSベース。
ただし、ファイルの先頭より前の部分に2chで頻出する文脈を詰めておき、
そこを初期のスライド窓の位置とする。

圧縮・展開ソフトが固定データを持ってなきゃいけないのが重大な欠点か。

>>163の方法でいいと思うよ

　　　　 　　　　　 ＿＿＿
　　　　.　　　　　 |（･∀･）|
　　　　　.　 　 　 |￣￣￣　　　ｼﾞｻｸｼﾞｴﾝ共和国
　　　　　　　　　△
　　　　　　　 △ｌ　|
　　　＿＿△|_.田 |△＿＿＿＿＿
　　　　　　|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿

共和政なのか…

>>138 辺りみたいに、不可逆にしてみるとか…
圧縮時はその時点での 2ch から頻度表作って詰めて、
展開時には初期の辞書で置き換えられた部分は無視するの。
…無視するなら、圧縮前に削除しちゃった方がいいか…

というか全部あぼーん

万一のときに聞いておきたいんですが
圧縮アルゴリズムを発見（発明）した時、
特許とかの申請はどういう風になるんですか？

ﾄｳｷｮｳﾄｯｷｮｷｮｶｷｮｸ

ﾘｬｸｼﾃT.T.K.

http://tmp.2ch.net/test/read.cgi/sisou/1032255483/l50

>>169
「情報処理」にソフトウェアやアルゴリズムの特許についての話が連載中。読め。

別に圧縮しなくても 2ch ってヘッダ付けるだけでいいじゃん

>>169
そんなことも知らない奴には発明なんて無理

>165-166 ﾜﾗﾀ

>169
とりあえず2chにアルゴリズムをＵＰ汁。そして各所からリンクを張られろ。
どこかの香具師が勝手に特許とっても申請前に既に一般に知られていれば
特許を無効にできると思われ。

　　　　 　　　　　 ＿＿＿
　　　　.　　　　　 |（･∀･）|
　　　　　.　 　 　 |￣￣￣　　　ｼﾞｻｸｼﾞｴﾝ民主主義人民共和国
　　　　　　　　　△
　　　　　　　 △ｌ　|
　　　＿＿△|_.田 |△＿＿＿＿＿
　　　　　　|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿

>>177
>>とりあえず2chにアルゴリズムをＵＰ汁。
これが一番危険と思うんですよね
２ｃｈに書き込んだのはすべて２ｃｈのものってことになってますから。
まずどっかのサーバーにウプした時点で著作権だけは保持できるはずなんですので
そのあとここに書き込むかもしれません。（まぁ無理かな、いちをおテスト中です）

>179
＞２ｃｈに書き込んだのはすべて２ｃｈのものってことになってますから。
そうなのか、知らなかったよ。
じゃあジオとかを避けて適当にＵＰしてそのＵＲＬを2chに晒すのがいい鴨な。

以前、会社でＰＧやってる香具師が、退職時に自分の作ったコードを
自由に使えるようにする為に、会社で使う前に自分のＨＰにＵＰしてた
という話を聞いたことがあるよ。

>２ｃｈに書き込んだのはすべて２ｃｈのものってことになってますから。

んなわけねーだろ。というわけで晒しあげ。

掲示板の書き込みの著作権は管理人に帰属するとか。

そんな訳ねーだろ、って判例出てなかったっけ？>>182

著作権は作った時点でお前のものだアフォ。中学からやりなおして来い。

それに今話してるのは特許の話しだろ。小学生からやりなおして来い。

確認したいんですが
圧縮アルゴリズムが違うものでの圧縮は一回は効果ありますよね？
たとえばlzh形式をbzip2で圧縮できたりとか、、。

>>185
圧縮に関するすべての勉強をやり直せ。話はそれからだ。

ん〜
あほばっか

指摘されてるほうねｗ

>>178
タモンって誰よ？

>>185
確かに効果あるが
その効果はバイト単位(一部を除き)でしか確認できないと思う
逆に増えることもある思う

>>189
オマエも勉強を…

$ md5sum.exe xyzzy-0.2.2.230.lzh
9ca53116f068eed6de59ac6540f1a036 xyzzy-0.2.2.230.lzh
$ bzip2 xyzzy-0.2.2.230.lzh
$ ls -l xyzzy-0.2.2.230.lzh.bz2
-rw-r--r-- 1540494 xyzzy-0.2.2.2lzh.bz2
$ bunzip2 xyzzy-0.2.2.230.lzh.bz2
$ md5sum.exe xyzzy-0.2.2.230.lzh
9ca53116f068eed6de59ac6540f1a036 xyzzy-0.2.2.230.lzh
$ ls -l xyzzy-0.2.2.230.lzh
-rw-r--r-- 1544223 xyzzy-0.2.2.230.lzh

>>190
んじゃこれをわかりやすいように馬鹿に説明してみてください。

>>191
KB単位で効果があるように見受けられるが？
ってゆーか何でわざわざMD5？

LZHはヘッダ部分が随分冗長な構成になっている。
そのため、SOLID圧縮が有効であることからわかるように、
bzip2などで再圧縮すると、そのヘッダ部分でわずかながら圧縮される。

しかし圧縮部分自体は、LZSS+Huffmanという構成で、
特にHuffmanがエントロピー符号であることから、再圧縮効果は期待できない。

>>191は、>>193でわかったのだろうか

わかりました。
サンクスです。理論的に意味がないというわけですね

脳みそが圧縮されてる人の集うスレ

俺の脳は8bit

俺の脳は140億ビット（人間はこれぐらいだって言われてなかったっけ？

脳みそなんて2bitあれば十分なんです。偉い人にはそれがわかるのです。

>>198
記憶容量と処理能力は別物だと思われ。
もし、しなぷすの結合のオンオフが1ビットに等価ならば、
2^140億の組み合わせがあるわけで・・・

それなりの会社にはimidasが置いてある筈です。
imidas2002のパソコンカテゴリに答えが書いてあったはず

ところで本題に戻すけど、

AAの圧縮なら、その絵のキャラクタインデックスとポーズを符号化するのはどう？
意味が通じればいいので、非可逆でよいわけだし、
キャラクタインデックスに20ビット、ポーズに12ビットもあれば十分。
セリフ部分やその他の特殊効果に費やすビット数を除けば、
32ビットから48ビットもあれば、AAを表現できそうだ。

例：
（ギコ猫、左向き、セリフ「逝ってよし」）
とか、
（モナー、上半身と下半身分離、ポインタ>>1）＋（斬鉄剣モナー、左右、擬音「ザシュッ」）
とか。

大体誰が、非可逆でいいって言ったんだ？

>>193
エントロピー符号という用語は初めて知ったよ。

ちょっとぐぐってみたんだけど定義が良く分からないので
もしよければ教えて下さい。

>>204
エントロピーを達成するような符号を、エントロピー符号という。
エントロピーとは、理論的に達成可能な圧縮限界のこと。
確率 p[i] が与えられているときに H(P) = -Σp[i] log p[i] がエントロピー。

エントロピーレートを漸近的に達成する符号で、
a priori な知識なしに達成するものを、ユニバーサル符号という。
エントロピーレートとは、１記号当たりの漸近的なエントロピー。

Shannon情報理論を扱った本なら、一番最初に書いてあるから読むべし。
つーか、圧縮を知りたいなら、まずエントロピーありきだから、
エントロピーを知らないと、「1/100圧縮」や「何でも圧縮」といった、
とんでも圧縮法を提案してたたかれることになる。

エントロピーは常に増大する

>>206
それは物理学の方だね！
局所的にエントロピーを減らすことは出来ても、
系全体では必ず単調非現象にあるんだね！

もしかしてここは学生さんしかいませんか？

>>205
サンクスコ

でもハフマン法の平均符号長(L)ってエントロピー(H)に対して
H≦L＜H+1
だからエントロピーを達成できない場合もあるのでは？

>>209
対象が無限長なら大丈夫。

>>210
対象が無限長、という条件だけでは不十分と思われ。
例えばＡとＢという二つの記号からなる情報源を符号化すると
0と1になって圧縮しようがない罠。

昨日、講義でエントロピーを習ったよ！　情報理論だっけかな？
そんときは -p*log_2 p は情報量みたいな言い方してた．

まだ，勉強してないからあれだけど
「エントロピーとは、理論的に達成可能な圧縮限界のこと。」
なんていわれると激しく違和感を感じる．

世界を震撼させるかもしれない圧縮アルゴリズム
をあと一週間で発表します、今デコーダーの作成中です
期待してください。

>>211
Huffman符号は整数長の符号しか構成できないので、
メール欄にある通り、アルファベット拡大が必要ですな。こりゃまた失礼。

あげ

どんなの？良かったらすぽんさーになるよー

>>213

>>213
単語に分割して重み付けによって符号化する手法ですか？
それって、LZ77とLZ78まぜた方法LZFG,LZYGとは違うのですか？
（LZ77の一致位置を、単語の区切りにしか設定できない制限を置くというやつ？）

どんなデータでも1バイトに収まります。

すべてのデータを1バイトで納めた人間は
天才をはるかに超えた存在だ

この40年で、人類が生みだしたデータは18エクサバイトになるらしい。
しかし、後18ヶ月もするとさらに18エクサバイト増えるらしい。

>>219
「天才をはるかに超えた存在」・・・つまり馬鹿ってことだな

>>218
但し、復元できません……ですか？

>>221　いや、
「あらゆるデータをまるで乱数のように復号しますので、
必要なデータを見つけるまで復号しつづけてください」
って感じだろ・・・

GCAで使われとるらしい
RangeEncoderってなんじゃらほい

>>223
マイクロ波で加熱する圧縮方法

>>224
なるほど、ＧＣＡってすごいですね。
だから糞重いのか

圧縮したものを圧縮するとか、
むちゃくちゃ圧縮とかいう話ではありません。
むしろ圧縮率は極端にわるいです。
ただハフマンかブロックソーティングと組み合わせれば
使いものになるかもしれません。
私は科学畑の人間でないので
既出の概念かどうかをここで確認させてもらおうという話です。

>>226
圧縮の基礎だけでも勉強しておいた方が良い。
圧縮は、「圧縮 ＝ モデル化 ＋ 確率統計（確率推定） ＋ 符号化」で構成される。
算術符号やHuffman符号は、（それ単体が「圧縮」を構成するものだが）符号化。
モデルはn次マルコフ連鎖とか、実装で言えばPPMやMTF、ブロックソーティングも該当する。
確率推定はモデル化や符号化に統合されていることが多いが、
次に a の出る確率は 1/2 である、と計算すること。

>>226の何かを　Ｘ　としよう。>>226が考えているのは、

「Ｘ ＋ 符号化」あるいは「モデル化 ＋ Ｘ」となる。
上記の「圧縮」の概念図に照らし合わせると、Ｘは確率推定を含む部分に相当する、
と推測される。

・・・で、>>226のアイデアって何？

>>223
rangecoder は算術符号の一種で、
Jonesの考案した整数による算術符号を改善したものに相当する・・・のか？

参考にしたところ：
ttp://www.compressconsult.com/rangecoder/
ttp://www.tomozo.ne.jp/yamazaki/download/doc_basic_compression.htm#RangeCoder
ttp://www.isl.cs.gunma-u.ac.jp/~shingo/labo/algo.html

ｳﾜｰﾝ

先生
暗記しておくってのはダメですか？

不可逆圧縮でよければ

意見、賛成、反対、ＡＡ、get、煽り、荒らし、長文、吉野家

くらいに圧縮できるな。

例：
1 名前：デフォルトの名無しさん 投稿日：01/01/01 01:01
意見
2 名前：デフォルトの名無しさん 投稿日：01/01/01 01:02
2get
3 名前：デフォルトの名無しさん 投稿日：01/01/01 01:03
>>1 反対
意見
4 名前：デフォルトの名無しさん 投稿日：01/01/01 01:04
>>3 荒らし

こんな感じじゃだめか？

不可逆でいいんならレスを自動生成しろよ。データは1のレスだけにできるぜｗ

どうして２ｃｈは、こうもアフォばかりが集うのか…。
まぁ、アフォを社会から隔離しておくにはちょうど良いシステムかもな。

おまいら、もっと学習しる！！データ圧縮に関してあまりにも無知すぎる。
まずは、ぐぐれ！

レスを茶筅(or案山子)で分割
↓
使用頻度の高い単語を文字コードで使われていないコードに置換
※例. 逝って→0x7743(コードは適当)
↓
2chのスレを解析して作った頻度表を初期状態として
動的レンジコーダで圧縮。
↓
(゜Д゜)ｳｰ

>>234
それはLZ77+78から派生するアルゴリズムとか、
7bit-ASCII(0-127)の単語を(128-255)に割り当てる手法などで、
すでに提案されている。

>>234
言葉遣いが滅茶苦茶なので、形態素解析が満足に出来ない罠。
「うつだしのう」ひとつとっても、変換がばらばらなので統計情報も偏らない・・・

>>212
＞まだ，勉強してないからあれだけど
＞「エントロピーとは、理論的に達成可能な圧縮限界のこと。」
＞なんていわれると激しく違和感を感じる．

なぜ？ まさかお前はエントロピー以上に圧縮できるとでも主張する気か？

思うに計算機の0101の概念を作った人が
言ってる理論を覆すのは無理と思われ。

>>237
エントロピーは無記憶情報源モデルとして求めた値なので
それ以外のモデルを使って圧縮すればエントロピー以上に圧縮できる。

山奥のしぃ先生を見てると
ランレングスも効きそうな気がする。

>>239
お前もうちょっと勉強してから発言しろよな。
無記憶情報源以外のモデルを使ったら、そのモデルの上での
エントロピーがあるだろうが。

某大学のﾃﾞﾝﾊﾟ中間発表
ttp://isweb43.infoseek.co.jp/art/dempzone/up/2002101123025890.pdf

やめろってのｗ

>>240
ここでそのスレタイを聞くとは

>>237
うまく言えないんだが, 212 は例えば 205 の
>エントロピーを達成するような符号を
のような言葉の使い方に違和感を覚えてるんだと思う.

俺も知りたいんだけど, こういう言い方ってするんだっけ ?

>245
するよ。

>>245
俺の周辺だけ？と思ったのでぐぐってみた。「エントロピー 達成する 符号」
あ、大丈夫そうだ。
誤り率とか、冗長度についても「〜を達成する符号」ということが確認できた。

すると未知のモデルを発明（発見？）すれば、既知のモデルによるエントロピーを上回って圧縮できるのか。
究極のモデルを使えばどんなデータも0bitに圧縮できるな。

>>233
いうだけいって、何も説明できない
アホの大将

こいつ以上のアホは、そうは居ない

どうして２ｃｈは、こうもアフォばかりが集うのか…っ…！
まぁ、アフォを社会から隔離しておくにはちょうど良いシステムかもなっ…！

おまいら、もっと…！もっと…！学習しる！！データ圧縮に関してあまりにも無知すぎるっ…！
まずは、ぐぐれ！

つーかさ、いくらでも小さく圧縮することは可能なんだよ。問題は

ち　ゃ　ん　と　元　に　戻　せ　る　か　ど　う　か

だということに気づけ。そうすれば、元に戻せるためには
もともと持っていた情報量（エントロピー）より小さくできない
こともわかるだろ。

かなり中途半端ですが
手元のエンコーダー、デコーダーでデータの整合性がとれたので公開します。
わからないところがあれば説明します。
http://www61.tok2.com/home/jnc/

サンプルのjnc.plはまだ4Kバイトを越えたファイルを処理できません。
使い方は、
jnc.pl -e filename エンコード->*.jncファイル生成
jnc.pl -d *.jnc　デコード　->D*ファイル生成

エラー吐きまくりますが処理に問題はないはずです。

ぶっちゃげて言うと
8バイト(64bit)のかたまりを、
65bit/59bit/52bit/45bit/38bit/31bit/24bit/17bit
にしてしまおう、ということです。

>>213
ついでにこのスレを圧縮した場合の圧縮率を教えて please

>>213
8byte分取り出して、各bitの0/1が全8byteで一致した列を省く
というところまでは分かったが、その後が分からん

あああ今分かった。イメージ図と説明のところのデータって違うのか...

>>255
そうです、説明のところは
#!/usr/b　（64bit)をどのように59bitに圧縮してるかの説明です。
ちょっとＷＥＢぺージはいいかげんなのでそのうち書き直します。

全8byteで一致しないとまったく圧縮されないというのが痛いぞ
ASCII文字列かUTF16文字列かのっぺりとした画像ぐらいしか思いつかない

そうですね、
ただ８バイトのうち縦2列のビット[16bit]がそろえば圧縮はできるんですが。
圧縮できる８バイトブロックと、圧縮できない８バイトブロック
にバッファを分けて、それぞれにハフマンなりなんなりをかける、、、
とかまぁいろいろ考えているのですが。

>>213いくつか気になった部分のひとつ。本題じゃないところばかりだけど
＞これまでのバイト（単語）レベルでの圧縮と違いビットレベルでの圧縮

ほとんどの圧縮手法がバイト入力にしているのは、
別に手法としてバイト入力でなくちゃいかん、というわけではなく、
単にプログラム上の処理の面倒さや、動作速度の向上が理由といえる。
論理的な理由としては、アルファベット拡大を行うと最適になるからということもある。

事実、論文ではバイナリ入力で説明し、実装ではバイト入力というのが普通。

テストプログラムはエンコード部分が間違ってるみたいです
1010Byteを越えたファイルでは処理が失敗します。

これ…だめだめじゃない？

>261
最初からうまくいくわけないYO!

みなさんがんば

新しい圧縮方式は・・・

1) 圧縮率が既存のものより格段に優れている　　例）PPM
2) 理論的に面白い　　例）CTW
3) 新しい概念に基づいている　　例）ブロックソート法、文法による圧縮

のどれかが成立しないと、評価されないよ。
たとえば、○○法を改良して圧縮率を向上させました、というのは認められないことが多い。
これから圧縮を考える人は注意してね。

１バイトのデータを圧縮する場合は、
１バイトは、２５６通りのデータ表現が限度だから、
どっかに２５６通りのデータを記録しておけば、
１バイトの圧縮結果のデータサイズは、
２５６通りあるデータの、どれかを示すだけでよいから、
サイズは、1ビットから８ビットになる。

よって、
４Ｇバイトのデータを圧縮する場合は、
４Ｇバイトは、２の８×４Ｇ乗　通りのデータ表現が限度だから、
どっかに　２の８×４Ｇ乗　通りのデータを記録しておけば、
４Ｇバイトの圧縮結果のデータサイズは、
２の８×４Ｇ乗　通りあるデータの、どれかを示すだけでよいから、
サイズは、1ビットから　２の８×４Ｇ乗バイト　になる。

>>264
で、4G+1バイトのデータはどうやって圧縮すんの？

この手法だと、どんなサイズのデータ（宇宙大のデータ）であっても、
圧縮結果は、1ビットになる可能性がある。
この素晴らしさは、たとえようがなく、
ＤＱＮには分かりようが無いのが残念だが、
我等が国王は、大いに喜び給うであろうことは、断言して誤りがないのである。

概ねハフマンと同じじゃん。

まぁなんか書いてくれるとたすかるよ。
ちょっと俺にはわからんが。
みなさんは圧縮するテストファイルってのは何つかってます？
圧縮してないファイルってBMPかWAVかTXTぐらいしか思い浮かびませんが。

どっかに　２の８×４Ｇ乗　通りのデータを記録しておかなければいけないぶんハフマンよりはるかに劣る

で、２の８×４Ｇ乗　通りのデータの大きさは具体的に
どれぐらいになるんだ？

>268
とりあえず俺の使った事のあるテストデータ。

・その圧縮ソフトのソースコード(@>>85)
・ゲームの吸出し画像(＠自作画像用非可逆圧縮形式開発時)

>>268
普通は Calgary とか Canterbury のコーパスを使う。
画像や音声の場合は、別のセットを使うこともある。

いっそ元のファイルサイズより大きくなるつーのはどうだい？

>>273
ファイルの先頭に非圧縮であることを示すフラグ「0x00」を付加する圧縮？法。
もし完全復号可能であることを求めるなら、もう少し工夫が必要だが。

>>264=266
それって正しいの？だとしたら、ノーベル賞ものだよ。

>270
だいたい785億Ｇバイトぐらいである。

現在の日本のＨＤ出荷量を、年間４０００万台として、
平均記憶容量を、３０Ｇとすれば、
４０００万×３０Ｇ＝１２億Ｇ
だから、現在のペースでＨＤを出荷していけば、
７８５÷１２で、６６年後には、私の手法を実験する環境が日本に整う。
が、既に外国の政府から、投資を受ける手はずになっておる。
よって、研究はそこの機関で行なう。
日本は、いくら催促しても反応がなく、取り合ってもらえそうにない。

>>276
＞３０Gとすれば・・・
一昔前ですね。

>277
そうである。

>>270
それはURI表現と何が違うのか、どういう利点があるのかと、小一時間…

>>276
データそのものが指数関数的に増え、今後１年間で、
今までの５０年分のデータに匹敵する量のデータが生成されそうです。
したがって、実験に供給可能なHDD容量はそんなにありません。
つーか、「〜億GB」は気持ち悪い表現だと思う…

>>275
情報理論では、ノーベル賞が与えられることはありません。
あるとしたらチューリング賞。

＞データそのものが指数関数的に増え、今後１年間で、
＞今までの５０年分のデータに匹敵する量のデータが生成されそうです。
＞したがって、実験に供給可能なHDD容量はそんなにありません。
日本はこれだから困る。
可能性を追求しようとするというのは、そういった無理な実験設置も惜しみなく
建設することなのだ。
この辺が諸国の精神と異なる。
この精神は、お国柄の違いというものではなく、理論的解釈能力レベルでの問題である。
そして、日本にその能力が欠けているのは、ざっと見たところ
精神未熟国家政府であるとしか言えない。

281のような優秀な頭脳が国外に流出するのは遺憾の極みである。
だが本人のたっての希望とあらば止める必要もないだろう。
幸い281を国外に輸送するのに妨げとなる条約はない。今日にでも梱包すべきだろう。

ここで愚痴言わないで
首相にメール送れ

>>281
日本はデータ作ってなんぼの国ですから、
データの生成を停めると、国が滅びます。

ちなみに>>279のはなしは、全世界規模の話だと思う。

根本的に間違っている部分に誰も突っ込まないのは、ねたに遠慮してるから？
4GBのインデックスで記録できるデータの種類は、(2^8)*4Gではなく2^(8*4G)通りである。
そしてもし、(2^8)*4G だとしても、必要容量は 2^((2^8)*4G) bits だ。
これは、66年後でも実現不可能な容量だ。
それどころか、宇宙の全粒子を使っても不可能だろう。

そもそもこれもおかしい。
＞２５６通りあるデータの、どれかを示すだけでよいから、
＞サイズは、1ビットから８ビットになる。
256通りのパターンを明示するのに必要なビット数は、
256という前提知識があっても1ビットから8ビットは不可能。
特に上限を8ビットにする場合は、256通りのどれひとつも8ビット未満のビット数で符号化することは不可能。

自演を自演と見抜けない人は（略

>285
＞根本的に間違っている部分に誰も突っ込まないのは、ねたに遠慮してるから？
＞4GBのインデックスで記録できるデータの種類は、(2^8)*4Gではなく2^(8*4G)通りである。
そうである。
私の書いた
＞４Ｇバイトは、２の８×４Ｇ乗　通りのデータ表現が限度だから、
これは、2^(8*4G)の意味である。

＞そしてもし、(2^8)*4G だとしても、必要容量は 2^((2^8)*4G) bits だ。
よって、これは意味の無い文である。

＞これは、66年後でも実現不可能な容量だ。
否、実現可能である。
＞それどころか、宇宙の全粒子を使っても不可能だろう。
その見解は、誤りである。

＞そもそもこれもおかしい。
＞＞２５６通りあるデータの、どれかを示すだけでよいから、
＞＞サイズは、1ビットから８ビットになる。
＞256通りのパターンを明示するのに必要なビット数は、
＞256という前提知識があっても1ビットから8ビットは不可能。
この見解は、誤りである。最少は、１ビットで可能ある。

＞特に上限を8ビットにする場合は、256通りのどれひとつも8ビット未満のビット数で符号化することは不可能。
私の論文を、読んでいないとしか解釈できない、見解である。
が、勘違いを予想すると、
285よ、では私の論じた圧縮方法で、８バイトのデータを圧縮する場合、
最も圧縮できた場合は何ビットのデータに圧縮できるか、
また、最も圧縮できない場合は、何ビットのデータになるか。
これを、答えてみなさい。

んで？
それはURIとはどう違うんだ？

　　_、_
（;　,_ﾉ`)

2^(8*4G)
1の後ろに0が400000個くらいつきそう

参考：無料大数 = 1の後ろに0が64個

>>287
＞＞特に上限を8ビットにする場合は、256通りのどれひとつも8ビット未満の
＞ビット数で符号化することは不可能。
＞私の論文を、読んでいないとしか解釈できない、見解である。

285じゃないんですが、論文ってどれでしょうか。
ぜひ読んでみたいのですが。

>>287
もう一つ教えて下さい。
785億GB というのはどうやって算出された値なのでしょうか。
2^(8*4G)通りの全てのデータを表現するためには、2^(2^(8*4G))ビットの容量が必要です。
しかしここから 2^(2^(8*4G))/8 をどう考えても785億GBにできません。
それとも上の前提が間違っているのでしょうか。

正しい数式を教えて下さい。お願いします。

>>291
自称天才の主張する圧縮は確かに可能だよ

16進数を2進数で表して、上位桁の0を消せば
0x01 = 1
0x02 = 10
0x80 = 10000000

1ビット〜8ビットに圧縮できる。

>>293
んでそれは可逆じゃないよな

>>294
元のデータサイズが”初めからわかっていれば”可逆

2バイトデータなら
0x0001 = 1 = 1バイトの 0x01 の圧縮結果と同じ
0x0002 = 10
0x0080 = 10000000
0x8000 = 1000000000000000

だから自称天才の圧縮技術は 4G バイトぴったりのデータは（ごくわずかに）圧縮できるけど、
4G+1バイトのデータは圧縮できない。
しかも自称天才はこれを圧縮にではなく識別子の生成に利用しようと言うとんでもなくばかげたことを言っているらしい。

>>294
prefix-freeじゃないコードを生成するんですね。
それなら>>293も知ってました。
インデックスが2つ並んだ場合でも復号するものだとばかり思っていました。

＞285じゃないんですが、論文ってどれでしょうか。
＞ぜひ読んでみたいのですが。
264である。

＞もう一つ教えて下さい。
＞785億GB というのはどうやって算出された値なのでしょうか。
その場で、適当に概算である。
そのときの、思考はこうである。
「データサイズは、ビット数に比例して増えると見て、
　そのデータを２進数で全て紙に記述すると、
　０と１で産め尽くした直角三角形ができる。
　この直角三角形は、感覚的に正方形の１/２の面積である。
　よって、正方形の面積が分かれば、直角三角形の面積は分かる。
　正方形の面積は、(2^(8*4G))×４Ｇであるから、
　本題となる答えは、(2^(8*4G))×４Ｇ/２で求まる。」

まず、２の３２Ｇ乗を求めた。
２の３２Ｇ乗を行なった場合、０は幾つつくかを考えた。
２を乗算する場合、
1,2,4,8,16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,6556,１０万
となる。この数列を見ると、ケタ数が上がるに要する乗算回数は、
４、３、３、４、３，３
となってるので、平均値としては、（４＋３＋３）/２＝５で、
５回の乗算を行なうと、１ケタ上がる、つまり０が１個増えるとなる。
ということは、２の３２Ｇ乗で、０が幾つ付くかというと、
３２Ｇ／５＝２７４８７７９０６９４．４個
次に、数値は幾になるかというと、小数点以下が４なので、
０があと一つ付くには、０．６必要となるから、
これは１０進数とみていいと判断し、
先頭の数値は、４と予測する。
ということで、指数表示を用いて表すと、
４×１０^２７４８７７９０６９４
とする。
７８５億は、適当に暗算しただけであり、正確ではないのである。

>>298

2^10 ≒ 10^3 を使うと簡単に概算できますよ。
2^(8*4G) ≒ 10^(10.7 * 10^9) = 10^107000000000

＞「データサイズは、ビット数に比例して増えると見て、
実際には、異なる。

なんか天進法の　逝かれた方と似たような事言ってるな

ttp://www.crt.or.jp/~kokochi/hen_semi.htm

仏教でよくでてくるデカい値っていくつだっけ

＞2^10 ≒ 10^3 を使うと簡単に概算できますよ。
この定理は知らない。
そして、
＞2^(8*4G) ≒ 10^(10.7 * 10^9) = 10^107000000000
どうして、こうなるのかも知らない。

＞仏教でよくでてくるデカい値っていくつだっけ
なゆたであるが、本題の方が大きい。

正確に考えると、
2^(8*4G)通りの全てのデータを記録するのに必要な容量は、以下の式と文で求まる。

「２^a × (a+1)
　このうち、aは、０から３２Ｇまで変化し、それは加算してく。」
　
答えの単位は、ビットである。

>>302
無量大数（10^68）が日本で知られる値だが
マイナーなものだと非不可説不可説（10^121）なんてのもある。

ここ勉強になりますね。

お経だな

google には勝てまい。

おまいら全員アフォでつか？

ところで、当初からの疑問だったのですが、
8ビットで圧縮（索引付け）できる256通りのデータって、何ですか？？？？？
それこそインデックスに等しい00からffの256パターンではないですか？？？？

たとえば、3ビットで圧縮できる8通りのデータって、
000 001 010 011 100 101 110 111
の8種類ですが、これを3ビットの索引で表現しても、
全く圧縮されたことにはなりませんよね。
まあ始めからわかっていたことですがｗ

ちなみに8ビットで表現可能なデータが n>8 ビットであると主張するつもりなら、
そのnビットのデータの種類は2^nで、明らかに256より大きいため、
8ビットではすべてを表現できませんので、あしからず。


＞＞2^10 ≒ 10^3 を使うと簡単に概算できますよ。
＞この定理は知らない。
定理じゃなくて、2^10 = 1024, 10^3 = 1000 という事実ですが。
しかも 10^3 の方が小さくなるため、４×１０^２７４８７７９０６９４
よりもはるかに小さく概算されるのですが、
それでも、
＞４×１０^２７４８７７９０６９４
は、
765億GB どころか、765億GBの52×10^1616928864倍よりも大きく、
66年で765億GB増えると仮定しても、この宇宙が生まれてから今日経ったとしても達成できず、
1秒間に765億GB増えるとしても、7×10^1616928855年以上かかります。

あ、ミスった。

52×10^1616928864, 7×10^1616928855
は、それぞれビットなので、/8 して比較してください。影響ないですが。

＞295
＞だから自称天才の圧縮技術は 4G バイトぴったりのデータは（ごくわずかに）圧縮できるけど、
＞4G+1バイトのデータは圧縮できない。
否。誤りである。
宇宙大のデータであろうとも、１ビットに圧縮できる可能性を持つと既に説いてるではないか。

>>312
たとえば、１０個データがあったとして、1ﾋﾞｯﾄでどうやって
選び出すのよ？

アプリケーションを宇宙全体と考えれば、どんなデータでも０ビットで圧縮
できるぞ。

＞313
１０個のデータのうち、そのときに必要となるデータを０。
それ以外のものは１から始まる多少長いビットとする。
同様に宇宙大のデータでも任意のデータを１ビットに圧縮できる。
どうだ、みごとな圧縮だろう。

＞の8種類ですが、これを3ビットの索引で表現しても、
＞全く圧縮されたことにはなりませんよね。
＞まあ始めからわかっていたことですがｗ

293を見なさい

＞ちなみに8ビットで表現可能なデータが n>8 ビットであると主張するつもりなら、
＞そのnビットのデータの種類は2^nで、明らかに256より大きいため、
＞8ビットではすべてを表現できませんので、あしからず。

８ビットで表現できるデータの種類は、２５６個よりも多いと言ってるのか？

＞定理じゃなくて、2^10 = 1024, 10^3 = 1000 という事実ですが。
数学的に事実であることは、承知している。

＞＞４×１０^２７４８７７９０６９４
＞は、
これは、概算をした場合の途中の数値であって、本題の答えではない。
また、概算による答えであっても、
＞765億GB どころか、765億GBの52×10^1616928864倍よりも大きく、
この位の見当には、なるであろう。

＞66年で765億GB増えると仮定しても、この宇宙が生まれてから今日経ったとしても達成できず、
こういったことを言うのは、やめなさい。

315は、偽者である。

＞こういったことを言うのは、やめなさい。
かわいい♪

＞８ビットで表現できるデータの種類は、２５６個よりも多いと言ってるのか？

違う違う。
8ビットで表現できるデータは、>>293の方法を用いても、圧縮できないことを言っている。
たとえば、圧縮データ「１」があったとき、
それが「もともと８ビットの索引であった」ことを知らなければ一意に復号できない。
この「もともと８ビット」を圧縮データに追加すると、
「８ビットを超える」ということ。

＞319
＞それが「もともと８ビットの索引であった」ことを知らなければ一意に復号できない。
＞この「もともと８ビット」を圧縮データに追加すると、
＞「８ビットを超える」ということ。
私の手法は偉大なので、そんなせせこましいことをしなくても圧縮できるのだ。

＞315は、偽者である。
そういうことはやめなさい。

飽きたので、寝ます。
理論ができたなら、論文に書いて、
情報処理学会、電子情報通信学会、情報理論とその応用学会、
のどれかに投稿することをお勧めする。
データ圧縮では日本の三大学会だから。

日本では理解されないというなら、IEEE か ACM あたりが圧縮のメジャー。

要するに、
すべての通りの異なるデータを用意した場合、
あるひとつのデータを指す索引は、ひとつの
データと同じ大きさを持つ。
ってことだな。

>>

>>322
前に1/100圧縮がこの板で話題になったとき、
「アカシックレコードの索引を圧縮データとする」
というのがあった。
今回の理屈と全く同じ。結論も同じ。
「索引のサイズが圧縮対象と同じサイズで意味が無い」

確率をつかえば、作成データ数と索引サイズを小さくできるのでは？

>>325
それ、普通の圧縮。

そろそろ終りにする。付き合った諸君らに感謝する。

８ビットのデータを圧縮した場合、
そのデータには、識別子を付ける。

１ビットで表現した０が、００００００００
１ビットで表現した１が、０００００００１
２ビットで表現した０１が、００００００１０
２ビットで表現した１０が、００００００１１

といった具合。
で、一番最後では、

８ビットで表現した１１１１１１１１が、１１１１１１１１

となり、識別子が８ビットになってからは、データサイズは減少しない。
平均圧縮効率は、５０％になる。

が、言うまでもないがこの圧縮方法（っていうのだろうか）は、
あらかじめ全データパターンの記憶領域を必要とするので、
全然現実的ではなく、バカバカしい。
そして、そんなに多くの記憶領域の確保が可能ならば、
圧縮という技術すら必要なくなり、発想としてでないだろう。

すなわち、これ、「物の追求の空しさ」である。
物を追求しても、結果なる製品に真の価値（マジレスのような価値）は伴わないのである。
ただし、時と場合により、製品は価値を持つ。

最後に言っておく。
全データパターンはプログラムで簡単に生成できるので、非常に有効だ。
だから、私は自分を天才であると言っているのだ。

誰も理解できない（>>293はおしい）このスレには用は無い。
が、結局天才は孤独だったのだ。

>>327
>８ビットのデータを圧縮した場合、
>そのデータには、識別子を付ける。

>となり、識別子が８ビットになってからは、データサイズは減少しない。
>平均圧縮効率は、５０％になる。

だから、その圧縮されたデータの元のサイズが８ビットだったのはどうやってわかるの？
元サイズが８ビットだった「１」と、３２ビット（４GB)だった「１」はどう区別するの？

とりあえず、天才圧縮法は終わりな。

つーか、ム板に特化した圧縮法ならいいのでは？
プログラミングだの、データだのを変える。

＞327
訂正
誤：２ビットで表現した１０が、００００００１１
正：２ビットで表現した１１が、００００００１１

もう、どうでもいいんだろうけど。

>>330
やあ、建設的ですな。
とりあえず、AA圧縮法の続きを話しましょうか。

>>331
つーか、圧縮して無いじゃん。
要するに、いんたーねっとでhttp://untara.kantara.2ch/tensai.zipって
のをクリックすると、ファイルをダウンロードするよね。
つまり、http〜からの文字列だけ見ると、あたかも、数十バイト
しかないように見える。
ってことでしょ。つーか。サーバ側で圧縮できるようにしてくれ。

>>333
それはすでに>>279で指摘されている。
もうやめましょう。>>291が>>310の・・・欄で言ったとおりだから。

＞だから、その圧縮されたデータの元のサイズが８ビットだったのはどうやってわかるの？
＞元サイズが８ビットだった「１」と、３２ビット（４GB)だった「１」はどう区別するの？
そうゆう事を言ってたワケ。
私の言ってた圧縮方法は、固定サイズのデータを対象となってるな。

可変サイズのデータを用いた場合、
４Ｇ以内で表現できるデータ個数は、、、。格段に増える。
４ビットの場合で、
０
００
０００
００００
１
１０
１００
１０００
０　　　　　（がいしゅつ）
０１
０１０
０１００
１　　　　　（がいしゅつ）
１１
１１０
１１００
０　　　　　（がいしゅつ）
００　　　　（がいしゅつ）
００１
００１０
とかってなる。
これも、１つごとのデータに識別子を付けるから、圧縮効率は５０％より悪化。

>>335
理論はわかったから、早く作ってくれ。

＞336
作っても意味ない。

誰も理解できなさそうだし、国王も別のことにご注視されておられるし。

>>338
国王って・・・そもそも日本じゃないってことかｗ

プログラムでデータを作るとか言ってる奴も高卒ＤＱＮ

ある情報を吐き出すプログラムを作った場合
その情報のパターンを記述するのに、パターンと同じ情報量が必要だろヴォケ

8ビットを他の８ビットのインデックスで持つと言ってるのとかわらねぇんだよアフォ

そんなこともわからないのにプログラムなんかするな。邪魔だカス

やはり最強はグーゴルコンプレックスとかいまさらなことを言ってみるテスト
googol=10^100
グーゴルコンプレックス=10^googol

熱雑音を拾うとかしないとデータを作るのはむつかしいねえ

糞スレを糞スレと見抜くエンジンを組み込んで、糞スレを無視して不可逆圧縮。これ最強。

＞糞スレを糞スレと見抜くエンジンを組み込んで、糞スレを無視して不可逆圧縮。これ最強。
しかし、そのエンジンは自分で作る必要がある。
自分にとって糞スレか否かの判断は、自分にしか分からないからだ。

激しくウザイ＞オレ天

>340
＞ある情報を吐き出すプログラムを作った場合
＞その情報のパターンを記述するのに、パターンと同じ情報量が必要だろヴォケ

それは誤りである。
一定の規則で数値が並んだ場合、その規則をコードで表現すれば良いのだ。
従って、
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆
　最も表現情報の少ない規則　を表すコードを、生成するプログラム
　こそが、圧縮サイズにおいては、最適なる圧縮プログラムである。
　　　　　　　　　　　　　　　　　　　オレ天　２００２　１０／１６
★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆★☆

ここにおいて、私が究極の定理を示したことにより、
究極なる圧縮方法も、明らかとなる。私に感謝せよ。

グーグルコンプレックス … グーグル使わないと不安に感じる病気

>>346
＞一定の規則で数値が並んだ場合、その規則をコードで表現
だから、それは情報理論の基礎中の基礎でしょう。

>>340の表現がまずいのかもしれないけど、
＞その情報のパターンを記述するのに、パターンと同じ情報量が必要
は、無ひずみデータ圧縮では「当然」の記述。
無ひずみ圧縮とは、情報量を変えずに見た目の長さを短くすること、です。
情報量が変化するのは有ひずみ圧縮と呼ばれます。

なお、＞プログラムでデータを作るとか言ってる
については、文法による圧縮に代表される手法が該当し、
この「プログラム」に必要な表現の長さが、元のデータよりも短くなる
ような表現が存在するならば、圧縮が行われたことになります。

たとえば、001001100 -> S->AAB, A->C1, B->1C, C->00
という文法(データ生成プログラム)に変換し、その文法を符号化する訳です。
代表的なものにMPMなどがあります。

もしかして>>340の記述は>>328についていったのかもしれないが、
この場合は、数え上げ符号に相当します。
数え上げ符号は Cover らによって考案された手法で、
オレ天圧縮同様、インデックスを得てそれを符号化する手法ですが、
理論的な証明が行われている、何ら問題ない手法です。
復号の際に、インデックス「n番目」をプログラムで記号列に復号します。

このスレはお馬鹿な人たちの発言を楽しむもので、
>>348さんのように圧縮に詳しい人が出てくると面白みが減る、と言ってみるテスト。

＞>>346
＞＞一定の規則で数値が並んだ場合、その規則をコードで表現
＞だから、それは情報理論の基礎中の基礎でしょう。
否。基礎は、連続データの個数表現と言えよう。
また、データから有効となる規則を見出すのは、
圧縮技法では、中以上の部類と言えよう。

＞>>340の表現がまずいのかもしれないけど、
＞＞その情報のパターンを記述するのに、パターンと同じ情報量が必要
＞は、無ひずみデータ圧縮では「当然」の記述。
＞無ひずみ圧縮とは、情報量を変えずに見た目の長さを短くすること、です。
情報量が変わらなければ、圧縮とは言わない。
340は、どうなってしまったのか。

＞情報量が変化するのは有ひずみ圧縮と呼ばれます。
それは、単なる”圧縮”のことである。
ひずみ　がとうかしたのか。

＞なお、＞プログラムでデータを作るとか言ってる
＞については、文法による圧縮に代表される手法が該当し、
文法による圧縮とは、如何なるものか。

＞この「プログラム」に必要な表現の長さが、元のデータよりも短くなる
＞ような表現が存在するならば、圧縮が行われたことになります。
それは、私が346で既に述べた。

＞たとえば、001001100 -> S->AAB, A->C1, B->1C, C->00
これは、何か。
＞という文法(データ生成プログラム)に変換し、その文法を符号化する訳です。
＞代表的なものにMPMなどがあります。
それが、どうしたのか。

＞もしかして>>340の記述は>>328についていったのかもしれないが、
＞この場合は、数え上げ符号に相当します。
＞数え上げ符号は Cover らによって考案された手法で、
＞オレ天圧縮同様、インデックスを得てそれを符号化する手法ですが、
＞理論的な証明が行われている、何ら問題ない手法です。
＞復号の際に、インデックス「n番目」をプログラムで記号列に復号します。
それが、どうしたのか。

今回のカキコには、意味の無い発言が多々あり、３４０の動揺が伺えることから、
「３４０は精神年齢が低い」
と、ここに公言する。

＞>>348さんのように圧縮に詳しい人が出てくると面白みが減る、と言ってみるテスト。

「３４８は、一般人より、圧縮技法の知識がある　ようだ」
とは、言える。

オレ天は、もう少し圧縮の勉強をしてから書き込んだ方がいいよ。
情報理論や圧縮のほとんどの教科書に、>>348と同じくらいの内容が
書かれているから、１冊でもいいから買うことをお薦めする。

＞＞この「プログラム」に必要な表現の長さが、元のデータよりも短くなる
＞＞ような表現が存在するならば、圧縮が行われたことになります。
＞それは、私が346で既に述べた。

これは、50年も前に述べられたことですよ。
オレ天さんの圧縮法は、さきほども数え上げ符号に類似するといいましたが、
それに関係するせめて
Shannon,Kolmogorov,Lynch,Davisson,Cover,Rissanen
の論文くらいは読みましょう。
最低でも、Shannon と Rissanen の理論(あるいは圧縮法)を知らないと、
どこへ行って、何を喋っても恥をかきます。

今までオレは天才だと…とその他の人、どちらが正しいのかわからなかったのですが
情報量やひずみの有無を「無意味な発言」としているのをみて
オレは天才だと…が単なるDQNであることがわかりました
ありがとう>>348 そして、さようならオレは天才だと…

ちなみに>>348はどちらかというと>>340に向けての発言です

みんな！　これ以上オレは天才ださんをいじめないであげて！
彼は、世間から疎まれて、もう2chにしか居場所が無いの。
そして、自分を存分にアピールできるこのスレを見たとき、
彼はそこに第二の人生をみつけた！
だからこれ以上、オレは天才ださんをいじめないで、お願い。

でも、反論を見たときの彼、ちょっと嬉しそうだった。

348よ。
自身の発言をする前に、私の発言に対する答えを、まずしなさい。
ひとまず、私の返答は以下である。心して読みなさい。

＞オレ天は、もう少し圧縮の勉強をしてから書き込んだ方がいいよ。
なぜか。
＞情報理論や圧縮のほとんどの教科書に、>>348と同じくらいの内容が
＞書かれているから、１冊でもいいから買うことをお薦めする。
それら圧縮技術を知る必要は、どういったものか。

＞これは、50年も前に述べられたことですよ。
だから何か。

＞オレ天さんの圧縮法は、さきほども数え上げ符号に類似するといいましたが、
＞それに関係するせめて
＞Shannon,Kolmogorov,Lynch,Davisson,Cover,Rissanen
＞の論文くらいは読みましょう。
なぜか。

＞最低でも、Shannon と Rissanen の理論(あるいは圧縮法)を知らないと、
＞どこへ行って、何を喋っても恥をかきます。
なぜか。

356は、偽者である。

>>357
所詮あなたは過去の人。過去の再現をしてるだけ。早く現代に追いつきなさい。

データの圧縮技術は、その必要性を見出した人がいたときから、
ずっと行なわれてきたのは、当然だろう。
オレは、ＬＺＨを初めて知り、ＺＩＰやＵＮＩＸで使われるのを知ったぐらいだ。
２６４は、ネタで遊んでただけ。
ただ、オレ天の定理は正しいと思ってる。
が、この定理も、もうがいしゅつであることは、余りにも明らか。
（新規なら、いきなりここに書かないよ）
それに対し、３４８が知識で迫ったみたいだから、ちょっとからっただけ。わりぃ。＜読者
というより、オレ天に対して知識で迫っても意味ないと思うぞ。
次回は、もう少しマジレスに近いことをしようと思う。

オ天ウザイ

つーか、からかわれたのはオレ天の方だろ、気付けよ。

オレはからかわれてない。からかわれてないんだー。

日下部２世がいるスレはここですか？

357が偽者であるということは明らか

ウザイ・・・プ逝１とため張るな

俺天ってプログラマー？

私はプログラマではないが、そんな私でもすばらしい圧縮手法を考えた。
それをここで伝えたかったのだが、理論がどうこういう者がいて、
私の考えにけちをつける。
その者たちは、理論よりも大切なことがあるということを理解できない愚か者だ。

概算で66年後にできるといったら、それでは不可能だという。
宇宙が終わっても不可能だという。そんな馬鹿なことはありえない。
大宇宙に匹敵するデータすら１ビットにできる手法もあるのだから、
2^(8*4G)ビット程度のデータを格納できないはずがない。
理論的には不可能でも、66年よりももう少し時間がかかるだろうが、
いつかは可能なのだ。
もう少し発言内容を深く考えてから、反論を述べてほしかった。

>>368は偽者

>>369
すまん、混乱してきた。
>>368は今までのオレ天と同じことを主張しているようだが、
それを偽者という>>369は、では、何が違うと言うつもりだ？

つーか、みんな暇だねぇ。汚天のネタに付き合うなんて。

>>368
理論よりも大切なことってなんだよ(ｗ
妄想か(ｗ

>>368
理論が説明できないなら、実装して証明してみせろ。
話はそれからだ

8*4G*(2^(8*4G))は、宇宙に存在する粒子の数よりもけた違いに大きいのだが、
どうやってそれを記録しておくつもりなんだろう・・・
漏れにとって、オレ天の手法で一番のなぞ。

オレ天のアルゴリズムで圧縮したファイルの拡張子には
.o0X
を推してみるがどうか？

それにしても>>360は日本語滅茶苦茶すぎ。

２６４は、ネタであって、もう終了したのである。
が、２６４で述べていることは、事実である。

350と357の文は、３４８をからかったものと言ったが、
３４８に対しては、「からかった」とはならない。
このような文を、「ＤＱＮ相応の文」と言う。
もし、読者がいた場合、３４８に対する「ＤＱＮ相応の文」によって、
それに気ずかずに不快なる思いをした者がいた場合を考慮して、
読者に、
＞それに対し、３４８が知識で迫ったみたいだから、ちょっとからっただけ。わりぃ。＜読者
と示したまでである。

＞374
＞8*4G*(2^(8*4G))は、宇宙に存在する粒子の数よりもけた違いに大きいのだが、
8*4G*(2^(8*4G))　これは何か。

また、
＞宇宙に存在する粒子の数よりもけた違いに大きいのだが、
こういったことを言うのは、やめなさい

＞こういったことを言うのは、やめなさい

どうしてですか？
宇宙に存在する原子の数って10^150程度（おそらく、違っていても誤差は少ないはず）
といわれていますよね？
もし、10億倍くらい間違っていたとしても、10^159程度ですし、
1000兆倍くらい間違っていたとしても、10^165程度ですよね？？

一方、4GBのデータのすべての組み合わせは、8*4G*(2^(8*4G))ビット必要で、
（>>291さんの主張はここが間違いといえば間違いでしたね。
　3ビットの場合 3*2^3=24ビット 000,001,010,011,100,101,110,111）
もし宇宙の全原子がそれぞれ１ビットの記憶が可能で、
それを使ったHDDがあったとしても、
これは上の値より、どうあがいてもはるかに大きいわけですが・・・

>>375
大文字小文字を区別しない環境(Windows95など)があるので、
統一したほうがよいかと思われ。

360と376はともに偽者である。
いいかげん、偽者だらけでうんざりしてきた。
が、真実を伝えるために、読者に語りつづけようと思っている。

３７６は私だが、360と３７９は偽者。

結局おれてんの奴のは圧縮後のデータだけから圧縮前のデータを
復元できないのに圧縮と言っているわけか。

＞宇宙に存在する原子の数って10^150程度（おそらく、違っていても誤差は少ないはず）
＞といわれていますよね？
なぜか。
本当に、そういうことを言うのはやめたほうがよい。

＞結局おれてんの奴のは圧縮後のデータだけから圧縮前のデータを
＞復元できないのに圧縮と言っているわけか。
私ははじめから４GBのデータに固定した話をしていた。
例を８ビットで示したが、これは同じ手法が使えるということで、間違いではない。
もちろん4GB+１バイトのデータも復号できるのである。

>>382
> 例を８ビットで示したが、これは同じ手法が使えるということで、間違いではない。
間違い。

> もちろん4GB+１バイトのデータも復号できるのである。
出来ない。

γ符号を使えば、ある特定の１データだけは１ビットに圧縮できる。
しかし、それが誰にとって役に立つデータになるのか、
そしてその役に立つ確率はどれくらいか、を考えれば、
おのずとオレ天の手法が役に立たないのか、がわかる。

誰かが言っていた数え上げ符号は、その辺をうまく構成するため、役立つのである。

２６４で私が述べた圧縮技法、
通称「オレ天２６４」であるが、
以下の要素を提供する場合は、作って与えよう。

公務員/サラリーマン
　年収の　１／２６４の日本銀行券　（最低　１０００円）
フリーター
　年収の　１／２６４／２の日本銀行券　（最低　１００円）
その他
　場合による
学生
　自作ソフト（吟味あり）

なお、これは予約制である。
また、「オレ天２６４」の開発期間は、１週間〜３週間とする。

仕様である
　対応ＯＳ：Windows95/98 シリーズ
　圧縮可能最大ファイルサイズ：４Ｇ以上
　（ただし、ＨＤに依存する）
　必要ＨＤ空き容量：圧縮ファイルサイズに依存

注意
・Windows95/98シリーズの最少ファイルサイズは、１バイトなので、
　圧縮したファイルのサイズは、最少で１バイトになる。
・なお、この件について興味を持った場合は、
　以降のレスの経緯をしっかり読んで、個人で状況を把握せよ。

>>385
オレがもう作ったって。圧縮ソフトはな。復号ソフトはまだだが。
ちなみに圧縮して出来たファイルの中身は0xDE。
復号ソフトを作れたら誉めてやるよ。
つーか、そこの仕様に復号できると書いてないのはわざとか(ｗ

単純に実装する場合でも、
ビット列を先頭から順に見ていって、0を消していくだけだろ？ ＞オレ天２６４

379,380,382は、偽者である。

＞つーか、そこの仕様に復号できると書いてないのはわざとか(ｗ
復号は可能である。

>>388
オレのを復号してくれないと信用できないね。ウソか(ｗ

382は、本物に近づくベクトルにある。

＞オレがもう作ったって。圧縮ソフトはな。復号ソフトはまだだが。
マジレスか。？

＞>>388
＞オレのを復号してくれないと信用できないね。ウソか(ｗ
間違っているからである。

本物って本物のｷﾃｨか？

オレはもう飽きたので次のオレ天にパスする。あとは任せた。

とりあえず俺天のおかげで面白くなってますな

あるデータ列があるとする。
複雑な数式といくつかの種を検討、
そのデータ列に非常に似通ったものがでる「数式」「種」「差分値」を圧縮データとする。
理論上「差分値」をなくすこともできるが、圧縮に時間がかかりすぎるため現実的ではない。

というかしょっぱなから現実的っぽくはないが、データ列をうまい具合に分割して
いくつかの「数式、種、差分値」でデータ列全体を表現できないだろうか。

>>391
>>382が偽者だというなら、宇宙の原子数についての解答ももらいたいものだが

>>394
ええと、それは数値圧縮法の一種で、すでにあると思います。
文献は今手元にないのですが、IEEEの論文でした。

オレは天才だと分かりました、通称「オレ天」が足りません。
データ圧縮に強い方、また、圧縮なぞわからないが議論やあおりには強い方、
至急オレ天として書き込みを行ってください。

オレは天才だと分かりました

やっぱり一般人の考えつくようなのはすでにあるか。
データがなだらなかになる音データとかに強そうな圧縮だね、こりゃ

>>399
圧縮技術は、かなり研究され尽くされているから、
まったく新しいものを考えるのはなかなか難しい。

今現在は既存のもののすきまを埋めるような研究が圧縮では行われている。
もちろん、近年にも新しい圧縮法はいくつか考えられているし、
今後もその可能性は捨てきれない。

>>394の方法が、既存のもの以上の何かがあればいいわけで。
ちゃんと研究のレベルまで持っていくのも面白いかもしれない。
俺は数値圧縮が専門ではないので、内容にはコメントできないが。

>>385
Win95/98でファイルサイズ4G以上という仕様である時点でアウト。

アルゴリズムの有用性という観点から、人間にとって観測or生成可能な数列のみを対象としても、
有用性を失わないはず。なんで、指し示し、数え上げは URL + 時刻くらいで行えるものとする。

そうすると、なんらかの方法で非可算無限個ある平行宇宙の全てを破壊して世界線を常に一本に
保っておけば、情報理論的にはともかく、物理的にはこの指し示し＋タイムマシンだけでもとの
情報が再現できるはず。

どこかに穴あるかな。。。

>>402
タイムマシンだけでなく時間の情報も必要。

393は、偽者である。

>401

訂正(385
誤：圧縮可能最大ファイルサイズ：４Ｇ以上
正：圧縮可能最大データサイズ：４Ｇ以上
理由：Win95/98の制限による

＞保っておけば、情報理論的にはともかく、物理的にはこの指し示し＋タイムマシンだけでもとの

何を言ってるのか分からないが、
402は、幼稚であることを、ここに公言する。

究極の圧縮？スレ（現在dat落ちでどっかいった）に昔書き込んだネタ

圧縮関数 ：
与えられたデータから1引く｡
例 ： 1011→1010
全ビット0の場合 ： 0000→111

解凍関数 ： 与えられたデータに1足す｡つまり上の逆｡

こいつを使えば、n回目に圧縮したサイズ≧n+1回目に圧縮したサイズ、となる｡
どんなデータでも最終的に0ビットまで圧縮してくれるという優れもの｡藁
当然可逆｡こりゃ凄えや！

407よ。
それは、すなわち、圧縮対象のデータ全てが、
リトルデンディア、もしくはビッグデンディアによる、数値と見なしているのである。

そして、圧縮したデータは、その数値そのものとなるから、サイズは変わらず圧縮になっていない。
また、データの先頭に０があった場合、復号ができないバグがある。

ここで、読者に優秀なる問答を、与えてやろう。

３２０×２４０×６０×８６４００　バイト
この量のデータを出力する、１Ｍバイト未満のコードがある。
これは、１Ｍバイト未満のコードが、
３２０×２４０×６０×８６４００　バイト
を表現することが可能だということを意味する。これを復号とする。
そして、この復号に２４時間かかるとする。
いったい、１Ｍバイト未満のコード　とは、おおよそ　どういったものか。

>>409
わかんないので答えを書いてください。

鳩時計シミュレータ

>>409
そのデータは60fpsの動画か？

あのな、コードを情報源と考えれば、
定常有限状態情報源であっても、無限長のデータを生成できるんだよ。
だから、１M未満のコードでも、いいんだ。

だけど、逆は常に成り立つわけじゃないんだ。
ある無限に長いデータを観測しても、情報源を特定することは不可能。

したがって、その問答は、問題設定に意味が無い。

ブロックソーティングを複数回行うのって意味ある？

>>413
データ依存（Canterburyコーパスの kennedy.xls では非常に有効）。
一般には意味が無い。

ブロックソーティングはMTFの拡張であるから、
その問題はMTFを複数回おこうなう問題に帰着できる。

はい、みなさんこんにちは！
新しくオレ天に採用されました、俺は天才だと分かりましたです！
以後よろしくお願いします。
ゆんゆん電波に答えていきたいと思います。

まず最初のお便りから。
＞8*4G*(2^(8*4G))は、宇宙に存在する粒子の数よりもけた違いに大きいのだが、
＞どうやってそれを記録しておくつもりなんだろう・・・

これはですね。原子一個が１ビットしか記録できないという仮定が間違いっすよ。
実はつまようじが8*4G本あれば解決です。
つまようじの端から端の空間を2^(8*4G)個に分割します。
その分割した空間上の１点に原子を１個配置します。
これで8*4Gビットの１つの値が記録できました。
あとは、8*4G本のつまようじに同様に原子を配置していけばOK!

こつは、有限個の原子を使うのではなく、
無限に分割可能な空間を使うことですね。

じゃね！

そういや今月号のCマガ(明日18日発売)の特集に
「オープンソースの圧縮ツール「yz2」」ってのがあるね
ＤｅｅｐＦｒｅｅｚｅｒの開発者さんだから結構濃い目の内容かも

まあ、厨房な俺にはたぶん理解できんだろうが・・・鬱

YZってまったく使われてないけどなんか理由でもあんの？
ＧＣＡの方が出たのが後の割には結構使われてるよね、１部の人間に。
やっぱ圧縮アプリはユーザーインターフェースが大事なのか、、、
ＧＣＡが２００１年公開
ＹＺ１．２が１９９９年公開
なの？そこらへんが分らん。

＞まあ、厨房な俺にはたぶん理解できんだろうが・・・鬱

正直、圧縮技術のことで、そんな真剣にかんがえんでいいだろ。

>>417
Noah使ってるからyz1にも対応はしてるが確かに使ってないな。
一度だけざっと使用感をテストしただけ。
で、結局今は7zipとか使ってる。

やっぱ、たとえ個人だけで使ってても知名度とか第一印象が大きいかもね。
Noahみたなフロントエンドとして動作するソフトを除いては。

>yz
正直圧縮率よくない

やまざき氏は圧縮を専門にしているわけではないので、
圧縮率の向上自体には積極的興味はないようです。

ttp://www.tomozo.ne.jp/yamazaki/download/doc_basic_compression.htm
こんな文章を書いておられるが、さて、明日のCマガはどうなんだろ。

The Archive Comparison Test
http://compression.ca/

なんかここのテスト結果見ると、
一般的に知られてるものをはるかに超える圧縮率の形式があるのだが…
まぁ、上には上がいるもんなんだろうな。

圧縮率だけだったら、ACTの上位に登録されているツールを使えばいいということで。
漏れはunix系OSを渡り歩いているのでgzip,bzip2 (+tar)しか使わん。

>>422
ん？ どの手法のこと？
海外および国内の論文に掲載される内容は、1から2年以上古い内容なので、
実際には論文の実験結果よりも若干高い性能が現在の圧縮性能であることと、
論文などでは圧縮率を稼ぐことだけが主眼ではないので、
圧縮率を売り物にするACTへ登録するツール類は、
圧縮率向上の細かい技を使っているものが多いです。

>424
なるほどなぁ〜
確かに圧縮ツール話の多い掲示板やなんかだと
「実際に使った場合に想定されるファイルに対してどれだけ圧縮率を稼げるか」
みたいな話が多いわな。(俺は内容までは理解できてないけど)
勉強になりますた。

>>414
ｻﾝｸｽｺ

MTFも単純に先頭に持ってくるんじゃなくて二番目に持ってくる亜種なんてのもあるようですね。
面白いなぁ。

＞421のリンク先

間違いというか、思想的な相違を１つ指摘しよう。
それは。

＞この文章を読んで、一人でも多くの日本人が圧縮アルゴリズムに興味を持ってくれたら幸いです。

である。

圧縮アルゴリズムは、
「一人でも多くの日本人が興味を持つ」
ほどの物事ではない。

409の答えである。

一人、６０ＦＰＳ（一秒間に６０コマ描画する）の動画だと言ったが、
非常に惜しい。
動画は、一般的には、３０ＦＰＳだからである。

答えは、１Ｍバイト未満のゲームである。
３２０×２４０は、解像度である。
６０は、６０ＦＰＳである。
８６４００　は、６０秒×６０分×２４で、一日の秒数である。

そして、復号ができても圧縮ができないと言った者があったが、
オレ天定理によれば、可能である。
この、ゲーム動画の圧縮に近いものとして、ＭＰＥＧがあったろう。

圧縮率上げても展開遅ければ使えないような気がする。
>>MPEG
ＭＰＥＧより綺麗で高い映像圧縮技術も理論上できるが、
今の石の速度じゃ使い物にならない。
ＭＰＥＧ２を良く睨めっこすれば分かるがブロック単位に分れてるのが分かる。
この垣根を外せば理論上はmpegより高い+綺麗ができる。

>406

>402は、幼稚であることを、ここに公言する。
で、４０２の反応が無いので、意外と思ったことである。

４０２の言うことは、こうである。
宇宙が一定時間の間隔（Ｔ時間）で生成するデータを、１次元配列にするというものだ。
そして、Ｔ時間がたてば、また１次元配列を生成する。これで、２次元配列になる。
そして、２次元配列の要素を選択するのに、タイムマシンを使うと言ってるのだ。

このような思考を展開する、その心意気は非常に感心である。

漏れはゲームより鳩時計を支持する。

　 ／￣￣￣￣￣
＜　あなたは意味の無いことをしています！
　 ＼＿＿＿＿＿
　　 　⌒　⌒　⌒
　　 ＿⌒　⌒　⌒＿＿
　　/:::::Λ＿Λ:::::::::::::::/
　/::::::(∩;´Д｀)∩ :::::/
/:::::::(　　　　　 ／::::/ 　ﾁｬﾗｯﾁｬﾗｯﾁｬｰﾝ
￣￣￣￣￣￣￣￣

俺の考えでは　宇宙中にある全てのファイルにインデックスを付けても256ビット=32バイトもあれば足りるね。

なにせ
光の速度 3*10^8 m/sec
プランク定数 6.6/10^34 joule*sec
陽子質量 1.67/10^27 kg
宇宙寿命　約 4*10^17 sec
宇宙質量　約 3*10^11 Ωh^2M/Mpc^3

これらの定数を積したって 300bitにもみたないのだから

確かにインデックス付けは可能でしょう。
しかしインデックス付けと圧縮は別物だと何度言わせれば気が済むのですか。

433は逆に300bitのインデックス付けは宇宙の全容量をフル動員しても不可能といいたいのでは

あははっ、今は私がオレ天なのに、古いやつがうざいなぁ。

＞動画は、一般的には、３０ＦＰＳだからである。
うわー、そんなこと言っちゃっていいの？いいの？
ぷぷーっ

これって本当か？

↓　↓　↓
http://www.dream-express-web.com/space-trust.htm

これって本当か？

↓　↓　↓
http://www.dream-express-web.com/space-trust.htm

>>438
NGワードに追加しますた。

ここで諸君に、大いなる智慧を与えてやろう。
私に感謝しなさい。

そもそも、データ圧縮とは、その形跡を残すシステムを作ることであるのは、
諸君もオレ天定理によって、ようやく分かったところであると思う。

が、形跡を元にしてシステムを作るのは、
非常な困難を伴うのは、諸君も感じてるところであろう。
システムから形跡を生成するのは、容易である。

この例えは、次に当てはまろう。
何も考えずに、生きるのは容易である。
が、与えられた情報から真実を究明するのは、非常な困難である。

すなわち、諸君らが生きるにおいて感知する情報には、
その情報となる原因があり、それは、諸君にとって諸々の疑問ともなっているであろう。
それら疑問を解明すべく、大本のシステムを知るべく生きることは、
丁度、形跡を元に、その形跡を生成する最適なるシステムを模作するのと同様である。

そして、模作することなくして生きることも可能である。

諸君は、今、あるデータを生成する最適なるシステムを、
まさに模作しようかという、思考状態にまで、私に導かれてきた。

が、ここで人生と異なる点がある。いや、過去と異なる点と言えば良いであろうか。
諸君が、最適なるシステムを作ろうとするにおいて、その対象となる形跡は、
一定ではないのである。
それは、そうであろう。圧縮対象のデータは、その都度変化する。

（省略されました・・全てを読むにはここを押してください）

（省略されました・・全てを読むにはここを押しても無駄くさい）

諸君は、仏教というものの影響を、大きく受けているであろうと思う。
仏教は、正しさの追求である。
が、その正しさとは、何であるか、考えたことがあるであろうか。
正しさとは、誰が決めたのか。
それは、仏陀と言われるが、どうして仏陀の正しさに、
我々が畏怖し、従わねばらならなく、従わないと生きれないのか。
これが、分かるであろうか。
問題を理解してから、瞬間的に分からない場合は、分かっていない。

そして、その回答を、例え私に教えられても、
それは、汝が本当に分かったことにはならない。よって、
私の示した回答を知った時点で、
私の言う創造的思考への成長は無くなるであろう。
が、私は、語り続ける。

回答から示そう。










それは、一言で言えば
「謙虚を識れ」
ということだ。
仏陀の教えに従わずして、謙虚さは育まれない。

これは、どうゆうことか分かるであろうか。
それは、
「自分が、自分より高いと分かった存在に対し、
　それ相応の、礼儀を尽くさねばならない」
ということだ。
この礼儀が無い者に、何があろうか。
何も無いのである。
例え、この世にある数万の書物から、数億の知識を得たところで、
礼儀が無ければ、その者は、なんら価値を有さない。
また、
例え、この世にある数万の作用を生成するシステムを、作ることができようとも、
礼儀が無ければ、その者は、なんら価値を有さない。
こうしたものだ。

ここまで読めば、資本主義、あるいは、能力主義が、
幸福を生じる制度でないことは、明らかであろう。
なぜなら、謙虚や礼儀を知らない者でさえ、
その知識や能力があれば認められ、
その結果、その者は、能力や知識を行使する行為を続けることとなる。

が、既に言ったように、礼儀を知らずして、
いくら知識や能力があり、それを元に、如何なる結果を出そうとも、
それには、なんら価値は無いのである。
なんら価値は無い物事が、大量に出まわればどうなるか。
時を経ずして、それは消えて行くであろう。
そして、それを維持しようとすればするほど、過ちを重ねることとなろう。
そして、過ちを重ねれば重ねるほど、
または、過ちが維持されればされるほど、真実は影をひそめるであろう。
真実が影をひそめれば、ひそめるほど、世の中は暗雲とあろう。
そして、いつしか真実が分からなくなる。
すると、義理が真実として、まかりとおるようになり、
その結果、義理であるから苦しみを生じる。
が、苦しみの原因が分からず、ここにきて「妥協」という精神が生じ、
この苦しみを、まぎらわず為に、人間の感覚を麻痺させるのである。
それは、アルコールから始まり、各種の洗脳であろう。

しかし、馬鹿な話しである。
人が、その人に、苦しみを与えることを創り、
そして、その苦しみを無くそうと、人自体を麻痺させる。
馬鹿な話しである。
苦しみが起きた場合は、その苦しみの原因を究明し、
その原因を是正しなければならない。
それを、人を麻痺させることで回避するのであるから、
余計に人は、真実から遠ざかることになる。
いったい、諸君らは、何をやっているのか。

人よ。汝等が犯せし過ちは、己にとっても自覚できていない。
そうしたところにまで、過ちは重ねられており、精神が麻痺してるのだ。
義理とは、人が作ったものであろう。
そうしたものを、畏怖し、そうしたものに縛られてならない。

オレ天のアク禁依頼出してきました。
オレ天さんは名前欄をfusianasanにしないと一週間以内に
ム板から追い出されます

よって、
オレ天定理に基き、その性能を発揮する圧縮システムを考える以前に、
諸君は、「謙虚さ」というものを知らねばならない。
そして、過去の過ちを自覚せねばならない。
それなくして、
オレ天圧縮は、語れない。
まず、「謙虚さ」を知りなさい。

詭弁のガイドラインによく当て嵌まるレスだな
>>447乙。

＞人よ。汝等が犯せし過ちは、己にとっても自覚できていない。
＞そうしたところにまで、過ちは重ねられており、精神が麻痺してるのだ。

その通りである。
よって、人において一番過ちな存在は、
「慢心」である。
そして、この慢心が非常に大きい者は、
私の経験によれば、企業人（役員系）である。

以後放置で逝こう＞おぉる

>451　りょうかーい

ひとまず圧縮に関しては、話しが完結してしまったが、
ついでなので、幾らか話そう。

「謙虚さを知りなさい」と述べたが、
いったい何に対して、謙虚になるかが疑問かもしれない。

謙虚になる対象は、自分より崇高なる者であり、
これは、何も仏陀に限ったことではない。
そして、これ自体は、当然のことであろう。

が、私が述べた、謙虚になる対象とは、
何であるか、分かったであろうか。
分かった者は、見込みありと言えよう。

私が、謙虚になれと言った対象は、
各自の潜在意識が知っているであろう、
「仏法」である「正法」である。
すなわち、因果応報、愚痴の戒め、等である。
私は、諸君らが、その意識のある深さにまで、
仏法が浸透していると思っている。
その、仏法に対して謙虚になれと、言っていたのだ。
その仏法こそ、仏陀から、あるいは神から、
教えられてきた「正しさ」ではないだろうか。

http://science.2ch.net/test/read.cgi/math/1034782298/l50

で、みんなＣマガ読んだ？？

漏れ頭悪いのかサパーリ。誰か解説キボン。

yz2の記事のアルゴリズム解説以外の部分と
ひんろーださんのページと
編集後記のやっさんのページだけ立ち読みした。

Ｃマガは高すぎる、半額でいいぐらいだ

今から書店いってCマガ立ち読みしてくる。

458じゃないけど、立ち読みしてきた。
圧縮に関しては何も得ることが無かった。
yz2はソースプログラムも読んだことあるし、直接解説を聞いたこともあるから。

yzよりGCAの作者をぶん殴りたい

>>460
なぜ？ fjで暴れているから？

>460-461
SYNさんって、なんで嫌われるのかな。

yzより圧縮率高いじゃん。ブロックソートだから当然と言えば当然だけど。

まあ、議論はもうこのくらいでいいよ、
ＧＣＡやｙｚ２を超えるアーカイバをサクッと作ってみろや。
おまいらの腕ならそれが可能なんだろ？

>>463
PPMをベースにすれば、はじめから超えている

ＧＣＡって既出の理論でソートを少し最適化しただけで
後出のくせに圧縮率もたいしたことないし、処理遅いのに
なんでこんなにありがたがられてるんだか理解できないな。

嫌われてるっていうのは、良くしらないけど
そういうところにあるんじゃない？

>>465
割れ物でよく使われてるから。

解凍すべき物がそこにないなら、誰も使わんでしょ。

>>465
圧縮率が大したことあるから。

作者が嫌われるってのと
作ったソフトの性能にはあんまし関係は無いのでは？
坊主憎けりゃ袈裟まで憎いっての以外には。

>>465
いまどき微々たる圧縮率の差を競うのは時代遅れだよな
50%も圧縮率が優れていればﾏﾝｾｰなんだが
実際は平均より数%程度で激ノロで偉そうにしてれば
叩かれて当然だろう..

>>469
50% っても zip で 100 -> 97 ぐらいのやつが 100 -> 94
ぐらいになってもあんまうれしくないね。
あと zip で 100 -> 24 ぐらいのやつが 100 -> 12
ぐらいでも面倒くさいから zip でいーじゃんとか思う。

圧縮が効かないデータでは立場がさらに苦しいな > GCA

>GCA
たいていCabのLZX最高圧縮の方が縮むんであって使ってない

>>472
そりゃあ、向いてないファイルに使ってるからでない？
ＧＣＡは主にテキスト、あるいはアニメ画像なんかに向いてるのだが。

最近はCBTに抜かれてます＞GCA

おまいらXPointer使って圧縮して見れ

>>474
というか、テキストなら7z・RARのPPMdが最強かと。

>>465
たしかにガイシュツの理論だが実装が難しいんだよ、BWTは。
圧縮率はｶﾅｰﾘ高いほうだよ、圧縮比率比較しているサイト行ってみな。
嫌われているのは処理が遅いからだろう。

>>477
BW変換なんてそんなに難しい方じゃないと思う。
suffix-arrayの構築による手法が何種類もあるから、それを使えばいいし。
力任せでも何とかなる。suffix-treeだっていい。

しかし、PPMを実装するためには、せめて8次〜20次の文脈を扱いたいから、
どうしてもsuffix-treeの知識が必要だし、
suffix-treeだけでは素のPPMすら実装は難しい。

圧縮のアルゴリズムって基本的に偏りを利用してると思うんだが、
偏りがあまりないデータだと圧縮率が悪くなるよな。
意図的に偏りを作り出すことって出来ますか？
もちろん可逆でbit数の増加が無視できる程度で。

>>479
ブロックソートやMTFは考えとしてはそれに近い。
というより、文脈が。
もっといえば、情報源を高度に推定していくことに近い。

>>479 モデル化しる

>>480
情報源を高度に推定って具体的にどうやればいいんでしょうか？
回帰分析みたいな感じですか？

>>482
MDLとかAIC規準ではなかろうか

>>482 データマイニングしる

最近だと、PPMTなんてものもあるらしい。
でもユニバーサルではないよなぁ？
http://citeseer.nj.nec.com/teahan01combining.html

>>483
算術符号とか動的ハフマンのようなものですか？

言葉だけ中途半端に知ってる厨房の集まりだなここは。

>>487
こんばんは、厨房その１です。
恥ずかしながら、仰るとおりです。

>>478
suffix-tree と パトリシアトライの区別がつかないんだけど…

>>489
同じです。
派閥(?)によって呼び方が違うだけのようです。

>>490
さんきゅ

やばい、、すごい圧縮アルゴリズム開発しちまった・・・。
今HDDにあるファイルで手当たり次第テストしてるが、MAXでも元サイズの12％にしかならない。
（しかもlzhやzip,jpgなどのファイルでも！）
ちょっと怖くなってきた。。
（当然可逆圧縮。）

詳しくはいえないので簡単に言うと複素数平面を使用した圧縮。（＋Zオーダー）
辞書とかは持たずにほぼ数式のみで成り立ってる。

こんなんになるとは夢にも思わんかった・・。

祭の予感？

>>492
そのネタは1年ほど前に見たことがあるような…

>>492
ソースあげれ.もしくはバイナリ.

今は特許考えてるんで、ソース・バイナリともにあげるのはちょっと無理。
（バイナリ解析されると怖いんで）


改善点はスピード。
これが今のところかなり遅い。（同種系の３〜５倍くらい遅い）

じゃあ圧縮データサンプル出せ
特許つったって公開されるんだから
ソース出したって変わらんと思うがな。

>>492
中途半端なネタは最悪。

お前の頭で理解できるようなアルゴリズムか、
このスレの誰も理解できないような複雑なアルゴリズムを出せ。

>>498

複雑なアルゴリズムは圧縮にはむかないとおもわれ。

>>492

このサイトでもう少し圧縮について基本的なことを勉強したほうがいいですよ。
ttp://www.ingnet.or.jp/~kojif/mu/comp/

偏りがあまりないデータ ＝ 疑似乱数
な罠

age

>>492

ﾀﾜﾗ

>>497
ソース公開すると(下手したらバイナリ公開も)特許は取れなくなるかと。

とりあえず、特許申請するまえに
伊藤家の食卓にハガキだしとけ

>>504
ですね。
学会発表なら特許取得もできるので、すぐさま
情報処理学会、電子情報通信学会、情報理論とその応用学会、IEEE、ACM
のどれかに投稿しる！
レターの形でもいいから。

その方法での圧縮は算術演算以上にならないことがすでに証明されています。
従って、単なるネタ。

×算術演算
○算術圧縮

全てのデータに対して圧縮率が高い圧縮方法は難しいが、
特定のデータに対してなら劇的に圧縮率を上げることができると思う。

たとえば、実行ファイルなら実行ファイルの特徴があり、
その構造を整理することで大幅な圧縮が可能だろう。
つまり、圧縮・解答ソフト自身がMFCやglibなどを持っていて、
それを辞書として使えば、そのライブラリを使って作られた
ファイルは圧縮データにライブラリを含まなくても良くなる。
また、ループや関数呼び出しなどの制御構造を解析すれば、jmp文と
目的アドレスデータを大幅に削除できる。

また、画像や音楽の圧縮もJPEGやMPEGよりフラクタル理論を使った方が
圧縮率が高くなることが知られている。

>>509
データの種別に応じて圧縮法をチューニングするのは、
あるいは専用の圧縮法を使うのは、ツールとしては確かに有効です。
しかし、圧縮理論で最も重視される性質の一つである、
ユニバーサル性を失うことになるため、拒絶する人は多いかもしれません。

>フラクタル理論を使った方が
これは現在のところ、どちらとも言えない状態です。
というのも、たとえば画像データは有限画素値で有限画素数であるため、
フラクタル変換した場合の情報の相似がいまいちだからです。
そのため、計算機上のデータに対してはフラクタル圧縮はそこそこにしかなりません。

しかし、フラクタル発見の効率はよいため、
・画素の類似性を計測するためにフラクタルを使う（文脈として使う）
・線形走査法（ヒルベルト走査など）に組み合わせて、１次元上でのフラクタル圧縮を行う
などの研究が行われているようです。

>>492
寒いですよ。ネタバレバレ。頭が悪いこともバレてます。
もっと圧縮の勉強をしてから書いてください。

492はもともとものすごく冗長なデータしか持ってなかったのかも知れないよ

>>500
おまえばかだな。

>>512
lzhやzipが、さらに圧縮できていることを考えると、
ファイル名が
00000000000000000000000000000000000000000.txt
のようなものだったと思われる。

>>514
新圧縮ｷﾀ━━━━━━（ﾟ∀ﾟ）━━━━━━ !!
0KByteのファイルを作り、ファイル内容をBASE64でエンコードして名前に設定
完璧!!

492に釣られている香具師がいっぱいだな(w

>>515
圧縮カコイイ！

T-RangeCorder
ttp://homepage2.nifty.com/rohizuka/ka/pa_003_a.htm

>>518
ぐはっ、これでひっかかったの4回目です。宇都田。

>>518
一生、呪ってやる。

凄まじい圧縮といえばテキストでしょ。
１つの文字を１，２バイトまで圧縮できるんだから。
究極のモデル化だね。
解凍するために必要なデータは膨大だけどね（フォントデータ）。
但し、ない文字は使えない、または外字を入れると
サイズが膨大になるという欠点も持っている。

さらに圧縮かけると最強。
実はテキストって凄いのですよ。

電波ｷﾀ─wwﾍ√ﾚvv~(ﾟ∀ﾟ)─wwﾍ√ﾚvv~─ !!!

>>521
おまい、それ静的辞書法っていうってこと知ってます？

>>523
するとUnicodeはごく僅かに劣化する非可逆圧縮でつかね？

あのさ、>>521
640x400の時代にね。
画面を8bitx8bitで区切る。
同じ図形に同じ番号ふる。
最大で4096パターン。
頻繁に出現する番号に小さいのを当てる。
・図形個数出力。
・図形データ出力。
・マップ出力。
・ハフマンライブラリを経由してファイル出力。
2画面目では変化のある部分だけについて上の
パターンを適用する。
って動いた時、これは静的辞書法？動的辞書法？

>>525
ﾈﾀにﾏｼﾞﾚｽ(ﾌﾟ

>>525だって十分ﾈﾀだよぉ

メタファイルでいいじゃん　

圧縮前
sample.txt
Rｼﾅd儁eｷ｡h"; I �J喨

↓

圧縮後
Uu+9vO++hQVk5YSBZe+9txnvvaFoBSI7IAIgSSAgICDCgAEBSgHllqg=.txt
sample

＞言葉だけ中途半端に知ってる厨房の集まりだなここは。

ちがいます。保健体育だけ中途半端に知ってる厨房の集まりです。ここは。

たとえば、
ああああああああ
というのがあったら
8あ
と圧縮する

>>531
ランレングスがどうかしましたか？

その方式だと

Boooooooooooooooom!

位だと思われ。圧縮できるのは。
まぁ、辞書の話になるんだろうな。

うへうへうへへへへへ
↓
3うへ4へ

こうなっていくのか。辞書か。そうか。

>>532
RLEって辞書必要だったのか…

>>534
いや、いろいろ突き詰めていくとそっちの方向に向かうなってこと。

>>535
で、結局 LZ77 か LZ78 の類似品になるわけですね…

10バイトのデータがあるとする。
そこから、2バイトのCRC値を得る。

そのCRC値を元に、それが得られるようなデータを複数求め、
元のデータがその何番目に当たるかを求める。
もし、256番目以前であれば、元のデータは、CRC値と番号の合計3バイトで表す
ことができる。

256を超えた場合、9バイトで試してみる。それでもダメな場合、8バイトで試してみる。
どうしてもダメな場合、ダメであったことを表す1ビットのフラグをつけ、
元のデータをそのまま保存する。

>>537
時間がやたらとかかるよーな…

あとさぁ 00 00 00 00 00 00 00 00 00 00 から
そのCRC値になるまでインクリメントして256個だけ、
っつー事であれば 圧縮できるのは
00 00 00 00 00 00 00 00 ?? ?? みたいな並びばっかにならんか？

インクリメントする必要もないし、0から始める必要もない。
他の圧縮方法で圧縮できそうなデータは故意に飛ばせば良い。

ある文脈の次に出現する記号を、
入力データの先頭から順番に出力していく
という感じのモデルって既にあるでしょうか。
性能はイマイチ。

例えば、記号を{ a, b, c }の３種類として
入力データを{ abcacacabca }とする。

まず、a の次に出現する記号を順番に出力すると

bccb

となる。b, c についても同様に出力すると

bccb cc aaaa

となる。以上。

説明の為に多少簡略化してあり、
この出力だけでは当然復元できません。
（このやり方なら入力データの頭と尻の記号が必要になる）

速度・メモリを無視すれば、オーダーを増やしていっても復元可能です。
（aaの次の記号を出力、baの次の記号を出力・・・）

>>540
データ量が減ってない気がするんですが。

>>541
モデルだからな。

>>541
その後、適当に符号化します。
540の出力結果はブロックソート法を甘くした感じになります。

>>543
また、アルファベットのみの場合には妙に効果があるってヤツ？

>>544
そうですね。性能は悪いですけど．．．

>>540-543

漏れの少ない脳みそを検索した結果だな……(・∀・)ｲｲ！。行けると思う。

マジで。

ttp://210.153.114.238/img-box/img20021025185801.zip

>>540 を実装してみた。符号化してないのでサイズ増えるけどｗ
復元の為の付加情報は符号化のときに一緒に折り込むのがいいかな？

>>547
>符号化してないのでサイズ増えるけどｗ

その処理を通す前と通した後のデータをそれぞれLZHか何かで適当に圧縮してみそ。
それで圧縮率が変わるようならモデルとしては優秀なんじゃない。
なるべく大きなデータがいいね。当然jpegやmp3はダメだぞ。

age

>>547
コンパイルしてないけど、
入力データの最初と最後に記号a を付加して、
それごとエンコードすれば、復元の為の付加情報は必要なくなると思う。
どっちがいいのか分からないけど。

...aaa abcacacabca a

>>550 それはダメ。復号できない。

>>551

＜エンコード＞
入力：a abcacacabca a

aの次：abccba
bの次：cc
cの次：aaaa

出力：abccbaccaaaa


＜デコード＞
入力：abccbaccaaaa

aの数：6個、bの数：2個、cの数：4個より、

abccba cc aaaa

とわかり、aから始まるので、順にたどれば、

aabcacacabcaa

となり、先頭と最後を取り除けば、

出力：abcacacabca


ダメかな…。

>>552
よーわからんが 最後の a って付加する必要ある？

>>552
いいんじゃない？
その方法なら先頭にa(実際の実装なら'\0'か？)を付けるだけで良いと思う。
あと、その方法、なんかBlockSortingの復号みたいだな

#自分でも>>540を実装してみたけど逆に圧縮率落ちた。鬱。

> よーわからんが 最後の a って付加する必要ある？
たぶんない。
デコードの際、各記号の数を数えるときに都合がよかったのかな。

>>554
大量の文脈を使えばある程度効果はあると思うけど、
力不足で実装できませんでした。

>入力：abccbaccaaaa
>aの数：6個、bの数：2個、cの数：4個より、

なぜ「cの数：4個」とわかるのか？と小一時間問い詰めたい。

>>556
cという文字の前に来ている文字が４個、また最初の文字はaなので、cは４個
じゃないのかなぁ・・・

結局突き詰めていくと、
逆転文字列をブロックソートした状態になるんじゃないか？

>>556
「aの数：6個、bの数：2個、cの数：4個より」
というのは、デコード時の入力データ「abccbaccaaaa」
の各記号の個数を数えただけです。

エンコード時、最初と最後にaを付け加えることにより、
上のように単純に数えることができると考えたんだと思いますが、
余計だったかもしれません。
理屈は>>557の通り。


> 逆転文字列をブロックソートした状態になるんじゃないか？
ですね。
出力結果がブロックソート法より良くなることは無いです。

みんな既存の考え方にとらわれすぎ！

新しい発想でかんがえようよ！

定石やあるゴリ図無なんてｸｿ倉枝よ！

もう全部算術圧縮でいいよ。

>>561
符号化はもうほとんど算術符号になってるよ。
一部の分野でGolomb符号などが使われているくらい。

今問題にしているのはモデル化の話。

>>561
算術符号は特許問題がやっかいなので使わぬが吉。
RangeCoderにしとけ。

>>563
RangeCoderも白っぽいけど灰色という罠

ソースを書こうよ

// 希望の圧縮率にできる限り近い圧縮をおこなっちゃうよっ
bool compresser(void *soce　//圧縮対象メモリ
　,int soce_size　　　//圧縮対象メモリサイズ
　,void *dest　　　　//展開先メモリ
　,int dest_size　　 //展開先メモリサイズ
　,int compress_rate)　//希望の圧縮率
{
　　if( compress_rate<1 || 99<compress_rate ){
　　　　printf("1〜99 の間で指定しろや！");
　　　　return false;
　　}

　　for(int i=0,w=0; i<soce_size; i++){
　　　　if( (rand()%100) > compress_rate )　　continue;

　　　　if( dest_size>=w ){
　　　　　　ptinrf("展開先ちゃんと確保しろや！");
　　　　　　retunr false;
　　　　}
　　　　dest[w++] = soce[i];
　　}

　　print("%d％に圧縮しますた[ハート]",w*100/soce_size);
　　return true;
}

確かに非可逆圧縮だな。

圧縮率間違ってないか？
99を指定すると無圧縮に…

File file = new File(filename);
file.open();String content = file.readAll();file.close();
file.rename(Base64.encode(content));
file.open();file.write(filename);file.close();

　　　　　　∧＿∧　 　 　　∧＿∧
　　　　　_（　´∀｀）　　　　（´∀｀　）
　 三(⌒), 　　　ノ⊃　　　 （　>>1 .） 　 糞スレは　　
　　　 ￣/　/)　 ）　　　　　 |　|　　|
　　　 . 〈＿）＼_）　 　　　 （__（_＿_）
　　　　　　　　　∧＿∧　　.∧＿∧
　　　　　　　　 （　　´∀）　（´∀｀　）
　　　　　 　≡≡三 三ニ⌒)　>>1 .） 　　 立てるなって
　　　　　　　　/　 /)　 ） ￣.|　|　　|
　　　　　 　　〈＿_）＿_）　 （__（_＿_）
　　　　　　　　 　 ∧＿∧　 ,__ ∧＿∧
　　　　　　　　　 （　　　 ´）ノ　）:;:;)∀｀）
　　　　　　　　　 /　　　￣,ノ''　>>1 .　） 　　言ってるだろうが
　　　　　　　　 Ｃ　　　/~　/　/ 　 /
　　　　　　　　 / 　 /　〉 （__（＿_./
　　　　　　　 　＼__）＼）
　　　　　　　　　　　　　　　　　　　　　 ヽ ｌ /／
　　　　　　　　　　　　∧＿∧(⌒) ―― ☆ ―――
　　　　　　　　　　　 （　　　　） /|ｌ　　／/ | ヽ 　　ヴォケがーー！
　　　　　　　　　　　（/　 　　 ノｌ|ｌｌ ／　/　|　 ヽ
　　　　　　　　　　　 （Ｏ　　ノ 彡''　 　/　 .|
　　　　　　　　　　　　/　 ./ 〉
　　　　　　　　　　　　＼__）_）

>>568
おお、そだな。 0-99の乱数発生だな。
rand関数 滅多につかわんので、まちがえちまった。 % 演算把握の問題って向きもあるが。

>　if( ((rand()%100)+1) > compress_rate )　　continue;

こんな感じでかんべんしてくれ。

540のは面白いと思う。1次の文脈だけ利用するんだね。

BlockSortingみたいにMoveToFrontにして前の出力との
位置の差を算術符号かstart-step-stop符号で符号化す
れば圧縮できるだろう。

たぶん、素の(0次の)MTFよりは良くて、BlockSortよりは
悪い、実に中途半端な圧縮率が得られてスレの主旨に
ぴったりでは。速度も中間になる(BSよりはだいぶ速い)
はず。

そんなんで圧縮できるわけねーだろ。

>>573
圧縮は当然できるだろ。
0次のMTFと比べてどうかはわからんが。

できるわけねーだろ。
なんでできると思うんだ？

>>572
1次に限らずとも可能ですよ。
おっしゃるとおり、2次程度の540 → MTF → 算術でそれなりに縮みます。

大量の文脈を使用する場合、>>547のソースでいう code_count の
扱いが問題になると思います。

>>576
いや、これ次数を高くしたらつまんないと思う。
普通のPPMコーダとかの、高次混合モデルを
作るやつの方が良くなっちゃう。

単にバッファを1MBくらいに大きくしてみれば？

> いや、これ次数を高くしたらつまんないと思う。
そうかもしれませんね。
ただ、1次と2次の性能の差はかなり大きかったです。

バッファは8Mでテストしたと思いますが、
これを増やしてもそれほど意味は無いはず。

>>578面白い圧縮法ですね。bigramに限ったブロックソートみたいな。

>>572
0次と1次じゃなくて、1次と2次では？ 540のアルゴリズムは2次の
エントロピーコーダですよね。

すごいすごい。めどがついたら、ぜひupして欲しい。

http://piza.2ch.net/tech/kako/980/980257360.html
こんなのがあった…。

ttp://210.153.114.238/img-box/img20021027004155.zip
>>572を実装しますた。頻度表も>>552と同じような方法で追い出し。

SSS符号はイマイチな予感（LZFGで使ってるの位しか知らない…）。
次のアプローチとしてはSSSの代わりに連長＋RangeCoderを導入するか
二次化なんだろうけど、さて。

>>582
イマイチなのは当然だろう。
>>572は圧縮でもソートでもない。無意味な作業。

（ ´_ゝ`）ﾌｰﾝ



では次のネタどうぞ。

単にシャッフルしてるだけじゃん。
なんでこれで圧縮できると思うの？

>>585
MTFとは違う特徴をもったアルゴリズムを作りたかったからだろう。
実際、MTFでは理論的・実践的にいまいちな場面というものが存在する。
普通の定常無記憶情報源での比較ではなく、
特殊な状況で役に立つアルゴリズムというのを考えてみるのもよい。

オレは上の関連で論文を一本書いた。

このスレには

情報理論の分かるヤツと
分からないけどとりあえずコードを書いて分かったつもりになってるヤツと
分からないのでひたすら煽るだけのヤツがいゐ…

>>587
分からないのでひたすら煽るだけのヤツ

>>588
同意。何かを分析した気になっている。

情報理論をわかっているっぽい人には、
とりあえず情報理論の教科書でもあげてもらうか。

>>590
そして逆ギレ。

>>540
限定ソート？

>>591
いや、オレもいちおー専門だから。

せんもん・・・何にもせんもん・・・

>>592
一言で言うとそうなりますね。
単なる最大限定ソート。
次数を上げるとまさに限定ソートそのものです。

M.BurrowsとD.J.Wheelerが最初に考えたのが
540のような感じじゃないかなと思ったり。

(´-`).oO(7行のSさんってこのスレにはいないのかな…？)

持っている本

韓太舜・小林欣吾、情報と符号化の数理、培風館
植松友彦、現代シャノン理論、培風館
情報理論とその応用学会編、情報源符号化 無歪みデータ圧縮

他にはデータ圧縮関連の和書洋書、アルゴリズム関連の本、
情報処理学会、電子情報通信学会、IEEE、などの論文集。

540で圧縮できないという人は何を根拠に言ってるのでしょう。

MTFで「何記号前に出現したか」の平均符号長は1次エントロピーに
漸近するのに対し、540だと2次エントロピーに漸近すると思うのですが。

>>598
わかっている人は、
MTFやブロックソートと同様、記号をかき混ぜているだけで長さは変わらない
ということがちゃんとわかっているから、大丈夫だろうけど。

わかっていない人は、
そもそも>>540の手法とMTFやブロックソート法との比較もわからないのだと思う。

いや、>>540 が面白いこと考え付いたのが悔しくて
わからない人の振りをして荒らしてるだけかも…
ってのは考えすぎか。

いや、実装してみてもやっぱり大して圧縮できないんだけど。

つーか、本当に、何を根拠に圧縮できると思うの？
MTFは記号の出現頻度を故意に変えることで圧縮率を高めるし、
ブロックソートは同じ記号をまとめることで、圧縮率を高める。

だけど、これは本当に単に並べ替えてるだけ。
なぜこれで圧縮率が変わると思えるのか、それが知りたい。
どういう理論？

>>601
たとえ数パーセントでも圧縮されるのなら、>>1の出した仕様に適合すると思われ。

いーからとっとと作ってうｐしろよ
仕事おせーな

abababababababab
↓
a:bbbbbbbb
b:aaaaaaaa
↓
符号化する、だろ。

馬
馬馬　→　驫


1/3に圧縮できますた

>>602
だから逆転した文脈1次モデルだろ？

ちょいと試してみた。Calgury Corpus全体の1次エントロピーは5.362bits/symbol
1次のハフマンで最適に符号化したとして5.868bits/symbol
(符号表その他のオーバーへッドは除く。以下同じ。)

単純なMTFの出力の1次エントロピーは5.119bits/symbol
後段にハフマンを用いると5.591bits/symbol

540+MTFの出力の1次エントロピーは、
ブロックサイズ(bytes) エントロピー(bits/symbol) ハフマン符号(bits/symbol)
4096 4.142 4.577
16384 4.043 4.489
65536 4.005 4.460
...
全部1ブロックに入るとき 3.994 4.452

なので、算術符号を用いれば最高で3.994bits/symbolくらいまで圧縮できる。
ハフマンだと4.452bits/symbol

面白いのは最後段にStart-Step-Stop符号を用いたときで、全部1ブロックに入
るとき、
(3, 2, 9)符号を用いると4.830bits/symbol
(2, 2, 8)符号を用いると4.509bits/symbol
(1, 2, 9)符号を用いると4.388bits/symbol
と、符号によってはハフマンより良い結果になる。

ちなみに、gzip -9だと2.606bit/symbol
bzip2 だと2.190bits/symbol
まで圧縮される。

>>602
こんな簡単なことが本当に分からんなら
もう口を出すな。

>>603
いや、この方法自体では圧縮はされないどころか、かえってデータ量が増える。

だから、二次圧縮後のサイズを比べてみたんだけど、この方法を使わない場合に比べて、
ほとんど差は無かった。
こう書くと、「ちょっとは差があったのか？」と聞かれると思うが、それは言葉のあやで、
この方法を使った方が小さくなることもあり、大きくなることもあり、
平均してみると、使わない方がどちらかというと小さくなる。
「使わない方が大きくなる」と言うほどは差がないので「ほとんど差は無かった」と書いただけで、
使った方が少しは小さくなるというわけではない。
で、どういう理論を思っているのかを聞いたわけ。

例えば、>>605のようなデータは、元のデータがもともと圧縮率が高く、ab2で表せる。
二次圧縮後に差が出るとは思えない。

ちなみに、>>608が延々と書いてあることを訳すと、
「ハフマンより算術符号の方が圧縮率が高い」ということね。

>>611
> 「ハフマンより算術符号の方が圧縮率が高い」ということね。
もう一つ付け加えると
「540+MTF+SSSは、立派な圧縮アルゴリズムといえる」ということだ。
(少なくとも、1次のハフマンや単純なMTFよりは圧縮率が高い。)

参考までに、テストに使ったコード(最初の段)を抜き出しておく。
このあとMTF+(arithmetic or huffman or SSS)してくれ。
　struct chain { struct chain *next; }; /* ただのchain */
　int i, count;
　unsigned a;
　struct chain *p, *list, **head, **tail;
　unsigned char *buffer;
　if ((buffer = malloc(block_size + 1)) == NULL ||
　　　(list = calloc(sizeof(struct chain), block_size)) == NULL ||
　　　(head = calloc(sizeof(struct chain), 256)) == NULL ||
　　　(tail = calloc(sizeof(struct chain), 256)) == NULL) {
　　/* エラー */
　}
　while ((count = fread(buffer, 1, block_size, stdin)) > 0) {
　　putchar(buffer[0]);
　　buffer[count] = buffer[0];
　　for (i = 0; i < 256; i++)
　　　head[i] = NULL;
　　for (i = 0; i < count; i++) {
　　　a = buffer[i];
　　　if (head[a] == NULL)
　　　　head[a] = tail[a] = list + i;
　　　else
　　　　tail[a]->next = list + i;
　　　list[i].next = NULL;
　　　tail[a] = list + i;
　　}
　　for (i = 0; i < 256; i++)
　　　for (p = head[i]; p != NULL; p = p->next)
　　　　putchar(buffer[p - list + 1]);
　}

やってみたが、やっぱり圧縮率は変わらないぞ。

復号化。MTFと(arith or huff or SSS)の復号は済んでるとする。
　int i, count;
　unsigned a;
　unsigned char *buffer;
　unsigned *ptr;
　if ((buffer = malloc(block_size + 2)) == NULL ||
　　　(ptr = calloc(sizeof(unsigned), 257)) == NULL) {
　　/* エラー */
　}
　while ((count = fread(buffer, 1, block_size + 1, stdin)) > 0) {
　　buffer[count] = buffer[0];
　　for (i = 0; i < 257; i++)
　　　ptr[i] = 0;
　　for (i = 1; i < count; i++)
　　　ptr[buffer[i] + 1]++;
　　for (i = 0; i < 256; i++)
　　　ptr[i + 1] += ptr[i];
　　a = buffer[0];
　　for (i = 1; i < count; i++) {
　　　putchar(a);
　　　a = buffer[ptr[a]++ + 1];
　　}
　}

callocの引数の順序が逆だった…欝
結果には影響ないけどね。

一つ聞きたいんだけど、どういうデータで比較してるの？
俺はCのソース使ってほとんど差がでないんだけど。

だからCalgury Corpusだってば。
データ圧縮の標準データセット。
これ知らないなら本当にモグリだな。

>>617
もしかして対象データのサイズが小さいとか。
どんな手法でもそうだけど、数十バイトを半分にするのは、
数百メガバイトを半分にするよりもいくぶん難しいよ。

自分の知っていることを書いてモグリって言う奴が多いよな。
自分が知っていることは相手も知っていると思うんだろうか。

最近出まわってる7zip形式って何？

Mozillaのソース(約1万1千行, 334294バイト)でやってみた。

MTF+SSS(3,2,9) 254543バイト
540(ブロック64KB)+MTF+SSS(1,2,9) 170454バイト

おいおい。カルガリコーパスは本当に常識だよ。
圧縮プログラムの比較はたいていこれを使う。

>>618はスペル間違えてるけどな（ｗ
(正しくはCalgary corpus)

Calgury Corpusって何？
初めて聞いたよ。
俺ってモグリだから、Calgary Corpusくらいしか知らねーや。

音 たむさんの｢awareness｣ っていう作品が見れるＨＰ知りませんか？
誰か教えて下さい、お願いします。

使い慣れない単語だとスペルミスがあるんだよね。

小さいCソース(90行)でやってみた。
元: 1920バイト
MTF+SSS: 1470バイト
540+MTF+SSS: 1022バイト

結局540で圧縮できないとか騒いでたやつは
何が理解できなかったの？
２次エントロピーというのが理解できないとか？

>>628
いや、試してダメだったと言ってるって事は、
情報理論が理解できてないだけでなく
アルゴリズムも理解できてないらしい。

全く理解できない。
なんで俺のところではうまくいかないんだ？
本当に他のところではうまくいってるのか？
ちょっと実行ファイル出してみろよ。

MZ

・圧縮率1/2のケース
女男女男女男女男女男女男　→　娚娚娚娚娚娚

・圧縮率1/3のケース
女男女男女男女男女男女男　→　嫐嬲嫐嬲
女女女女女女女女女女女女　→　姦姦姦姦

>>630
ネタでした〜

>>630
ところでmove-to-frontとstart-step-stopは理解できてるのか？
ちょっとどういう理解か説明してみ？

Canterbury corpusも使おうYo!

>>630
日頃の行ないが悪いからそういうことになるんだ

とりあえず、なんでエントロピーが低くなると思うのか、それを説明してみろよ。
でなきゃ、実行ファイルを作れるソース全部あげてみろ。

まだ理解出来ねーでやんの（フ゜バカはほっとこうぜ。

>>608は偉い。スペルミスを除いて。

ところでstart-step-stopってどうコーディングすればいいのか分かりましぇん。
いろんなパラメータで実験してるところから見て恐らくstart,step,stopを
渡せばそのパラメータで符号化・複合する汎用ルーチンを使ってるんじゃないか
と思うんだけど、もしそうなら是非見せて欲しい。

 車
車車　→　轟
龍龍　→　龖（たしかこれの1/3圧縮バージョンもあったはずだがWindowsにはない？）

こんなんでどう？read_bits, write_bitsは適当に作って。
long read_bits(size_t nbits);
int write_bits(unsigned long bitvector, size_t nbits);
int flush_bits(void)
int sss_read(int start, int step, int stop)
{
　int bits = start;
　int base = 0;
　int code;
　while (bits < stop && (code = read_bits(1)) != EOF && code == 0) {
　　base += (1 << bits);
　　bits += step;
　}
　if (code == EOF || (code = read_bits(bits)) == EOF) return EOF;
　return code + base;
}
int sss_write(int start, int step, int stop, int code)
{
　int bits = start;
　int base = 0;
　int limit = (1 << start);
　while (bits < stop && code >= limit) {
　　write_bits(0, 1);
　　base = limit;
　　bits += step;
　　limit += (1 << bits);
　}
　if (bits < stop) write_bits(1, 1);
　return write_bits(code - base, bits);
}

>>640
全然圧縮されねーぞ。やっぱネタ？

つーか、適当に「作って」って言ってるんだから、
完成してないんだよな。
完成してないものは試しようがない。
従って、圧縮されたと言ってるのは妄想。

>>640
ｻﾝｸｽｺ!! あとでじっくり読んでみます。

>>641
否定派は否定するならするでもっと真面目にやってください。
工夫しないネタは只のゴミです。

中途半端なくらいが一番２ｃｈっぽい

無駄に凝ってるのが2chっぽいんだろ？

>>644
でもビット入出力ルーチンも書けない>>642はどうかと思う
あと素っ頓狂なことを言っている>>641もどうかと。
SSS符号は、単なる符号なんだからモデルをちゃんと作らなくちゃ、圧縮できるはずがない。
そのためのMTFであり>>540なんだろうに。

猿でも分かるように説明してみる。
高い頻度で出現する記号ほど出現間隔は短くなる。頻度の偏りが大きいと
間隔の平均値は小さくなる。これを利用したのがMTF。

「１つ前の記号がxであるときの記号aの出現頻度P2(a,x)」は、
単なる出現頻度P1(a)より一般には偏りが大きい。たとえば、Cのソースだと
改行文字の後に#が出てくる確率は、他の文字の後に出てくる確率よりずっと
高い。

なので、640のように「１つ前の記号」ごとにまとめてMTFで出現間隔をとると、
１次のMTFより平均値が小さくなる。

最悪で、前の記号と無関係（P2(a,x)＝P1(a)）の場合でも、640は１次のMTFと
同じになる。（１ブロックごとに１文字ふえるだけ。）

s/640/540/

/* 2chエンコーダ完動ソース (1/3) */
#include <stdio.h>

#define BLOCK_SIZE 65536
#define ALPHA_SIZE 256
#define ALPHA_BITS 8

unsigned long bitbuf;
size_t bufbits;
void write_bits(unsigned long c, size_t bits)
{
　bitbuf = ((bitbuf << bits) | (c & ((1 << bits) - 1)));
　bufbits += bits;
　while (bufbits >= ALPHA_BITS) {
　　putchar(bitbuf >> (bufbits - ALPHA_BITS));
　　bufbits -= ALPHA_BITS;
　}
}
void flush_bits()
{
　if (bufbits > 0)
　　putchar(bitbuf << (ALPHA_BITS - bufbits));
　fflush(stdout);
}

/* 2chエンコーダ完動ソース (2/3) */
void sss_write(int start, int step, int stop, int code)
{
　int bits = start;
　int base = 0;
　int limit = (1 << start);
　while (bits < stop && code >= limit) {
　　write_bits(0, 1);
　　base = limit;
　　bits += step;
　　limit += (1 << bits);
　}
　if (bits < stop) write_bits(1, 1);
　write_bits(code - base, bits);
}
int mtf_array[ALPHA_SIZE];
void mtf_write(int alphabet)
{
　int i;
　int u, next_u;

　for (u = mtf_array[0], i = 0; u != alphabet; ) {
　　next_u = mtf_array[++i];
　　mtf_array[i] = u;
　　u = next_u;
　}
　mtf_array[0] = u;
　sss_write(1, 2, 9, i);
}

/* 2chエンコーダ完動ソース (3/3) */
unsigned char buffer[BLOCK_SIZE];
long list[BLOCK_SIZE], head[ALPHA_SIZE];

int main(int argc, char *argv[])
{
　int i, count;
　unsigned a;
　long p;

　for (i = 0; i < ALPHA_SIZE; i++)
　　mtf_array[i] = i;
　while ((count = fread(buffer, 1, BLOCK_SIZE, stdin)) > 0) {
　　mtf_write(buffer[0]);
　　buffer[count] = buffer[0];
　　for (i = 0; i < ALPHA_SIZE; i++)
　　　head[i] = -1;
　　for (i = count - 1; i >= 0; i--) {
　　　a = buffer[i];
　　　list[i] = head[a];
　　　head[a] = i;
　　}
　　for (i = 0; i < ALPHA_SIZE; i++) {
　　　for (p = head[i]; p >= 0; p = list[p])
　　　　mtf_write(buffer[p + 1]);
　　}
　}
　flush_bits();
　return 0;
}

/* 2chデコーダ完動ソース (1/3) */
#include <stdio.h>
#define BLOCK_SIZE 65536
#define ALPHA_SIZE 256
#define ALPHA_BITS 8
unsigned long bitbuf;
size_t bufbits;
long read_bits(size_t bits)
{
　int c;
　while (bufbits < bits) {
　　if ((c = getchar()) == EOF) return -1;
　　bitbuf = ((bitbuf << ALPHA_BITS) | c);
　　bufbits += ALPHA_BITS;
　}
　bufbits -= bits;
　return (bitbuf >> bufbits) & ((1 << bits) - 1);
}
int sss_read(int start, int step, int stop)
{
　int bits = start;
　int base = 0;
　int code;
　while (bits < stop && (code = read_bits(1)) >= 0 && code == 0) {
　　base += (1 << bits);
　　bits += step;
　}
　if (code < 0 || (code = read_bits(bits)) < 0) return EOF;
　return code + base;
}

/* 2chデコーダ完動ソース (2/3) */
int mtf_array[ALPHA_SIZE];
int mtf_read(void)
{
　int i, v, code;
　if ((code = sss_read(1, 2, 9)) == EOF) return EOF;
　v = mtf_array[code];
　for (i = code; i > 0; i--)
　　mtf_array[i] = mtf_array[i - 1];
　mtf_array[0] = v;
　return v;
}

unsigned char buffer[BLOCK_SIZE + 2];
long ptr[ALPHA_SIZE + 1];

size_t read_block(void)
{
　int count, c;
　for (count = 0; count < BLOCK_SIZE + 1 && (c = mtf_read()) != EOF; count++)
　　buffer[count] = c;
　return count;
}

/* 2chデコーダ完動ソース (3/3) */
int main(void)
{
　int i, count;
　unsigned a;

　for (i = 0; i < ALPHA_SIZE; i++)
　　mtf_array[i] = i;
　while ((count = read_block()) > 0) {
　　buffer[count] = buffer[0];
　　for (i = 0; i < ALPHA_SIZE + 1; i++)
　　　ptr[i] = 0;
　　for (i = 1; i < count; i++)
　　　ptr[buffer[i] + 1]++;
　　for (i = 0; i < ALPHA_SIZE; i++)
　　　ptr[i + 1] += ptr[i];
　　a = buffer[0];
　　for (i = 1; i < count; i++) {
　　　putchar(a);
　　　a = buffer[ptr[a]++ + 1];
　　}
　}
　return 0;
}

うを、ちゃんと動くじゃんこれ！
しかも(ﾟдﾟ)ﾊﾔｰ！
でも圧縮率はたいしたことないね（ｗ

>>655
それは2ch版の仕様なので、製品版ならば圧縮率は向上します。


などといってみるテスト。

MTFで
・先頭じゃなくて二番目に持ってくる
・テーブルを256通り持って直前の文字で切り替える

少し良くなる（かも知れない）けどぱっとしないなぁ…

>・先頭じゃなくて二番目に持ってくる
すると先頭は変わらないが、先頭には何が入ってるんだ？

>・テーブルを256通り持って直前の文字で切り替える
データが小さいときは効くだろうね。

>・テーブルを256通り持って直前の文字で切り替える
ひょっとして540って、ソートなんかしなくても、
MTFのコンテクストを256通り持てば同じ事なんでは…

圧縮した
encode.exe < index.html > index.html.2ch

伸張した
decode.exe < index.html.2ch > index.html

感動した >all

>>655
だから、こんなんじゃ圧縮できないって何度も言ってんじゃん。
圧縮できてるのは、MTFのおかげ。既存のアルゴリズム。

>>661
意味不明。1次のMTFより圧縮率高いけど?

>>661
分かんないなら>>647読もうね、ボク。

>>658
二番目の文字が出た場合だけ、先頭と二番目を交換する。

エンコーダの後半を↓のように変えると二次MTFになる。ほとんど同じ結果が得られる。
unsigned char mtf_array[ALPHA_SIZE][ALPHA_SIZE];
void mtf_write(int context, int alphabet)
{
　int i;
　int u, next_u;

　for (u = mtf_array[context][0], i = 0; u != alphabet; ) {
　　next_u = mtf_array[context][++i];
　　mtf_array[context][i] = u;
　　u = next_u;
　}
　mtf_array[context][0] = u;
　sss_write(1, 2, 9, i);
}
int main(int argc, char *argv[])
{
　int i, j, c, last;
　for (i = 0; i < ALPHA_SIZE; i++)
　　for (j = 0; j < ALPHA_SIZE; j++)
　　　mtf_array[i][j] = j;
　last = 0;
　while ((c = getchar()) != EOF) {
　　mtf_write(last, c);
　　last = c;
　}
　flush_bits();
　return 0;
}

>>664
コードきぼんぬ

>>662
いったい何を根拠に圧縮率が高いと？
実際、ファイルサイズは大きくなるじゃんか。

>>667
ハァ？
ひょっとしてコンパイル＆実行のしかたも分からんのか…

>>668
ネタ？
実際に実行して見ろよ。

>>669
したよ？ Cのソースだと大体もとの50%くらいになるよね。

>>669
もうそのネタいい加減あきたよ。
>>647読んで分からんやつなら何言ってもムダだし。

俺のところでも圧縮率低くなるんだけど。

圧縮率が高くなるか低くなるかは知らないけど、
どっちにしても圧縮率低すぎ。

DOS環境の人はstdinをバイナリモードにしないとダメかもね。
でも、まさかそんな初歩的なところじゃないよね。

>>674
DOS環境ってWinも含むんでつか？(敬語

なんだか荒れてるようなので試してみた。。。
うちでも全然だめ。
えらく長いネタだったな。。。

80行かそこらで50%圧縮できれば上等だろ。

LinuxとFreeBSDとSolarisでは動いた。圧縮できた。

>>675
知らん。ANSI C互換なら動くはずだ。

CygWinでも動いたよ。
当然binmode.oをリンクしなきゃならんけど。

テキストモードで動かして「圧縮できませ〜ん」と泣いてた
やつらがいるらしい（フ゜フ゜

テキストモードだと圧縮できないの？
改行程度のことで大きくなるようなものでも圧縮って言うの？

圧縮ってデータを小さくすることだよ。
みんな知ってるか？(藁

俺んとこでも圧縮できない。もちろんバイナリモードで試してみた。
なんだよ、ネタかよ！

圧縮できないってやつは、できなってデータをどこかにうpしたら？
あるいは、Calgary corpusで試すかだ。
ちなみに paper1 で 4.679bpc だった。

>>685
もういいって。そのネタ、しつこいし、面白くない。
いつまで続くの？

い ろ ん な 意 味 で ネ タ が 出 尽 く し て ま い り ま し た 。

根本的に分かってないやつがいるな…元データはともかく、圧縮結果は当然バイナリになるんだから、
テキストモードで入出力できるはずがないだろ。

>>688
大きさの話をしてるんだよ(藁

Calgary corpusの圧縮結果(bytes)
データ: 圧縮後/元サイズ
bib: 66314/111261
book1: 470878/768771
book2: 361427/610856
geo: 75105/102400
news: 235941/377109
obj1: 13857/21504
obj2: 127266/246814
paper1: 31091/53161
paper2: 48992/82199
paper3: 28162/46526
paper4: 8030/13286
paper5: 7115/11954
paper6: 22117/38105
pic: 159535/513216
progc: 21760/39611
progl: 35562/71646
progp: 23932/49379
trans: 49036/93695

>>689
うわ、すげーバカ（藁
テキストモードって知ってるのか？
Cの入出力の話だぞ。

VC++でgetchar()が改行変換しないようにするにはどうやればいいの？
誰か教えて！

>>692できない。ファイルI/Oに書き換えろ。

Canterburry Corpusの圧縮結果
alice29.txt: 89224/152089
asyoulik.txt: 71590/125179
cp.html: 15010/24603
fields.c: 5541/11150
grammar.lsp: 1844/3721
kennedy.xls: 530275/1029744
lcet10.txt: 250429/426754
plrabn12.txt: 284824/481861
ptt5: 159535/513216
sum: 19919/38240
xargs.1: 2464/4227

圧縮できないと騒いでるのはネタだろ。
でなきゃzipファイルを圧縮しようとしたとか。

>>695
厨がこんなことに関心を持つとすれば、
エロ画像かエロ動画(w

あー、画像ね〜。
そりゃ元より大きくなるわな。
BMPなら圧縮できそうだが。

jpeg,gif,png,mpeg,motion-jpeg, mp3, etc.
すべてぎちぎちに圧縮しているので、
できたとしてもコメント部分などのヘッダ部だけだろう。

Calgaryコーパスのような実在データで、圧 縮 で き な い 証 拠 を提出できないのは、
540に反論して引っ込みがつくなくなったやつ、でよろしいですね(Y/y)

つーか、>>647 みたいな簡単な議論に反論もできないんだから、そもそも最初からついて行けてないんだろう。

とりあえず「データ圧縮ハンドブック」読んどけ
http://www.pearsoned.co.jp/washo/prog/wa_pro30-j.html

特筆すべき点は、圧縮率ではない。それよりも、

　.2ch　　と　　い　　う　　拡　　張　　子　　だ　　！！


というわけで、.2chをでほるとにして、引数をひとつだけとる
ようにしてくれませんかね。

>>702
コンソールアプリなら、
gzip, bzip2 互換のインタフェースの方が使いやすい。

まだやってんのか。しつこいネタだな。
画像どころかCソースでも圧縮できない圧縮法に何の意味があんの？

>>704
「圧縮できない」ネタうざすぎ。
なんの工夫もなく「圧縮できない」というウソを繰り返すだけのやつは
もう飽きたってば。

>>690 や >>694 のとおりCソースもほぼ50%に圧縮できている。
以後は >>647 >>690 >>694 に対抗したコメントを捏造するくらいの
工夫をせよ。

だから、ねつ造したコメントはもう飽きたってーの。
圧縮できた妄想患者はすれ違いだからさっさと出て行け。

まあまあ。
本人たちが圧縮できてると思ってるんなら、それでいいじゃん。
彼らはそれで圧縮して満足なんだし、圧縮できないと思えば
普通のアーカイバを使えば済むこと。

---------------終了---------------

「彼ら」って言うか、「彼」だけどね。

>>706-708
だから工夫しろって。
せめて >>647 に一言いってみろや。
２次のMTFと同等だから圧縮できて当り前だろ？

706=707=708 ウザイ氏ね

同等じゃねーよ。もう飽きたよ。お前こそ工夫しろ。

>>709
彼(ら)の頭ではうpされたコードどころかword countも理解できません。

>>711
647に一言いってみろや。なんにも言えないんだろ（藁

>>704-712
圧縮できる/できない で埋め立てるつもりか？

Calgary, 2chコーダ, ２次MTF, 元データ(bytes)

bib: 66314, 66687, 111261
book1: 470878, 470260, 768771
book2: 361427, 360827, 610856
geo: 75105, 76935, 102400
news: 235941, 235700, 377109
obj1: 13857, 14105, 21504
obj2: 127266, 126602, 246814
paper1: 31091, 31521, 53161
paper2: 48992, 49321, 82199
paper3: 28162, 28544, 46526
paper4: 8030, 8332, 13286
paper5: 7115, 7416, 11954
paper6: 22117, 22507, 38105
pic: 159535, 159648, 513216
progc: 21760, 22223, 39611
progl: 35562, 35849, 71646
progp: 23932, 24316, 49379
trans: 49036, 49343, 93695

優劣は微妙だが誤差範囲かも

ブロックサイズを大きくしていけば（順序が違うだけで）
平均符号長が２次MTFの出力に漸近するのは明らか。

アルゴリズムはともかく >>649-654 のプログラミングは
なかなか見事だと思う

拡張子2chにこだわるやつはいったい2chの何なんだ？
ただの名無しだろ？

yzなんとかみたいな、自分の名前を出すのは恥ずかしい行為だと思ったから2chにしたんだろ。
もっとも>>649-654は十分なアイデアが出尽くす前に2chエンコーダ・デコーダを
名乗ってしまったわけで、それはそれで名無しではあるが「俺が2chエンコーダ・
デコーダの作者だ」と主張しているようでいかがなものかと。

2chにこだわってるのは>>1か馬鹿

>>719
>十分なアイデアが出尽くす前に2chエンコーダ・デコーダを
>名乗ってしまった

もうここらでいいんじゃない？ 中途半端なところで。
こんな駄スレに次スレは立たないだろうし。

おい!も前ら！
>>649-654を試してみたよ。
>>649-654を圧縮してみたわけよ。
そしたら1.93KBが1.00KBになったわけよ。
で、驚きながら出コードしてみたわけよ。
そしたら511バイトになったわけよｗ

ネカマ口調で書いてみたけど、
なんかコンパイルでミスったのか？オレは。

一時期の勢いなら次スレ行くんじゃないかと思ったが、ネタが尽きて終わったか…
ま、これもひとつの2chではあるな。

>>722
main()の頭に
setmode (fileno (stdin), O_BINARY);
setmode (fileno (stdout), O_BINARY);
入れてみても駄目かい？

>>540 を文字単位じゃなくて
4ビット単位とか2ビット単位とか1ビット単位で
並び替えるとどーなるんでしょう？ 意味無し？

>>724

(1)次数に制限のない高次のモデルを使って、
(2)符号長を1bitより短くできるような符号化をするなら、
入力を短いbitで切ってもあまり関係ない。

540とSSSだとどっちも充たさないから短いbitで切ると損。

むしろ16bitずつ切ることを考えた方が良いのでは？

しばらく見ないうちにおもしろくなってるね。
テキスト系でだいたい半分。
当初の目的のAA系だとものによって２０％くらいまで減らせるようだ。

解凍がなかなか早いのもGood

>>651 のコードにバグがあると思う。
unsigned char buffer[BLOCK_SIZE];
は
unsigned char buffer[BLOCK_SIZE + 1];
としないとマズイのでは。

256通りにソートする替わりに直前の２バイト見て65536通りに
ソートしたらさらに圧縮率が上がったけど、けっきょく文脈ソートや
ブロックソートに近づいているようで鬱

おまえらに　.2chの拡張子を語れるちからはナイ

.DQNがおにあいだ

まずＤＱＮｋａｒａｈａｊｉｍｅｒｅ

>730
IMEを全然操れてないところがDQNぽくてナイス

拡張子 .AA

拡張子 .AAA（アスキー アート アーカイブ）希望

拡張子はいいから技術について語れろ喪前質

すでに似たようなのがありそうですけれども、LZ78系の辞書をMTFで管理するのはどうでせう。

compressなんかだと単純に出現順に割り当てた
符号語を出力しますが、それをさらにMTF+可変長符号で
頻度が高いものほど短くなるように符号化する。

あらかじめ決めた辞書サイズが溢れたら、MTFで
いちばん下のところ(最近使われていないところ)
を辞書から削除する。

>>735

辞書の捨て方はBTLZ(V.42bisに使われたやつ)に似ているが、
あれはMTF符号化をしていなかった気がする。

>>735
LZ78系だと基本的には辞書に登録する単語がどんどん長くなるわけだけど
そうすると新しく登録した単語ばかりが使われることになるだろうから
MTFが効かないような気もする。

最長不使用法で古い単語を捨てて辞書を小さく保つのは有効のはず。
単純なLZ78に組み込む場合はその処理に時間がかかるのがデメリットだけど
MTFに組み合わせるなら殆ど負担にはならないのが利点かな？

でも、辞書のエントリを単純に捨てるわけにはいかないよね？

そのエントリが他のエントリから参照されているかも知れないから。
その時はどうする？ 子供も全て捨てるか、「子供のいない最も古い
やつを捨てる」か。

LZ78とMTFは相性悪いよ。

MTFは「最近出てきたものがまたすぐ出てくる」とき良く圧縮できる。
LZ78は「一度出てきたものは辞書に登録して、
なるべく同じ出力を繰り返さない」ことを狙いとしている。

MTFはとりあえず簡単なモデル化をしたいときには便利ですが、
きちんとした符号化を考えた時、最適(とはいわないでも良好)なモデル化とはいいがたいです。
無条件に先頭に持ってくるのは少々乱暴な感じ。
出現率をきちんと管理できるのであれば、「移動させる」MTFは必要ないです。

>>465
GCAは実験的作品なので糞なのは認めます。ごめんなさい。
ただ、ガイシュツの理論だけではないです。
BWT+MTF+RangeCoderで作ってみるとわかりますが、
それだけではあまり圧縮率が出せません。

>>469
偉そうにしているように見えたら申し訳ないです。
内輪でゲーム用ツールとして公開していただけですので…。
勘弁したってください。

お、SYNさんだ。開発がんがってね(*^ーﾟ)ﾉ

>>460
気に入らないことがあるなら私に直接言ってください。
fjの方の方でしたら、知っていると思いますが、
「ヤりたい」のなら私はそれに付き合うつもりもあります。
某TRPG関連の方でしたら、本当の事実を知らないだけです。
その場合も私に連絡をください。真実をお伝えしますから。

わざと壊した.gcaファイルを配布する人や、ウィルス入りのファイルを
配布する人もいて、本当に困るよ…。

来ると思った。
まぁ公開アルゴリズムをつかいながGCAソース非公開
アーカイバプロジェクトへのGCA/APIの一部非公開
が問題だな

>>745
ソースを公開していないのは、仕様変更がしにくくなるからです。
そういう意味でGCAはまだ完成していません。真打はGCAではないですし…。
それにGCAみたいなしょぼいソフトのソースなど誰も見たがらないと思う。

話をアルゴリズムに戻すと、
限定ソートのメリットってほとんどないです。szipで使われていますが、
完全ブロックソートでも、あれに近いぐらいの速度が出ます。
完全＝大まかにソート(限定ソート)＋αなのですが、このαの部分って
ほとんどのファイルのデータでは極小なので、差はほとんど出ないです。

>>747
その割にB&Wはソートの高速化に苦労していたみたいだが。
特にバイナリで0x00が大量に続くようなとき、単純なソートだと
恐ろしく遅くなるよ。

だれだー７行スレに依頼したのはｗ

なんか見覚えのあるｺﾃﾊﾝが現れて偉そうなこと言ってると思ったらGCAか。
アルゴリズムがどうの言ってる暇があったら自己展開書庫のヘタレUIを改善して欲しいよ…

>>748
だから最初にランレングスしたり
ブロックのバイト列の終端にどの数よりも必ず大きく（小さく）なる値を割り当てて
比較長を短くしたりする、いろいろな工夫があるんだろ？

ちなみに、限定ソートはメリットが無いと言うが、
ブロックサイズを（完全と比べて）果てしなく大きく取ることが出来るので
ある種のデータではブロックが小さい完全ソートより
良好な結果を得ることが出来ると思うんだが。

>>751
だから単純なソートだと遅いから高速化に苦労してたって、>>748が言ってるだろ？

>>753
それならば、すでに先人が苦労した成果があるんだから
後からそれを利用するだけなら大した苦労も無いだろう。

>>754
話の筋を追えんやつだな（ｗ

>>750
SFXにそんな要望があるとは知らなかった。スマソ。
次のソフトで改善します。ありがとう。

>>752
そうなんですか？どうやったら出来るのでしょうか…。
完全も限定も、必要なバッファサイズはO(n)になりませんか？

限定ソートの利点：コードが小さい。
80行で完全ソート書いてみて >>SYN

7行スレに持ってけば7行未満で書いてくれそうだな（ｗ

コテハンが嫌われる理由がわかったようなきがする

>>757
オーダーにするとその通りだけど、限定ソートなら 1(n/2)+ちょっと で出来るでしょ。

なんかこっちではコテハン不評なのでやめます。

>>758
限定ソートほどじゃないけど、速度を気にしなければ、
普通に書いても2,30行ぐらいでいけます。
ちなみに展開の方は普通に10行ぐらいで書けます。

>>761
確かにバッファは減らせるけど、それによって確保できるブロックサイズは
精々数倍程度で、果てしなく大きくってほどじゃないと思うけど…
それにブロックサイズは無闇に大きくするとデータの揺らぎに対応できずに、
結果が悪くなることが多いです。

ホラでなく、昨年のクリスマスに
「540＋MTF＋ハフマン」
で圧縮ソフト組んだのですが。
MTFとハフマンはそこらへんから拾ってきたソース組み込んだだけだったけど。

いや、別にいいんだけどさ。

>>762
2〜30行ならうｐしてみろや
可変長符号だけで10行やそこらはかかると思うんだが
まさか最密充填コード？

ひかえおろうひかえおろう七行プログラマーじゃー

素人考えですが、圧縮率最強なら、たとえば
DVD-ROM片面２層の辞書を持っている、
有名な曲とか、定番の発言とか、全部入っている
そうしたらすごい圧縮できるんてじゃないでしょうか。

10MBのMP3が10KBに！、とか…
まぁそこまでは行かなくともですが、、まぁ多分、原理的に無理だから誰もしないんですよね、、失礼。

そういうアカシックレコード理論は狂おしいほどガイシュツ。

>>SYN
ソース公開しろとまでは言わんが、
GCAのMAC版、Unix版が無いのはいかがなものか？
自分でＧＣＡがヘボイと言っているのならそれは自分でゴミを垂れ流してることになるだろ

自分の作ったものに自信持てや

>>763
クリスマスに、ってのが泣ける｡
･ﾟ･(ﾉД`)･ﾟ･｡

>>768
身内用に作ったものを勝手に使用しているようなものなのに、なんでえらそうなんですか
もともと趣味で作ったもの。MacやLinux版をわざわざ出すわけないでしょう
圧縮方法もまだしっかり確立していないのに

今のはテスト版のようなもの。圧縮方法がしっかりときまったらソース公開や他OS版も考えるでしょう

きっとゴミかもしれないけど垂れ流してみたい年頃なんだよ。

ほら早く２、３０行で完全ソート圧縮かいてみせろや！

身内用なら身内だけに公開しろ
それだけだ

>>773
ブロックソート関連のWebページ逝けば３０行くらいで普通に載ってるぞ。

それに、bzip2のソースも実質そんなていど、といってみるテスト。

http://www5e.biglobe.ne.jp/~nanko-m/index.htm

>>775
最後の符号化も入れてか？

>>777
MTFが３〜４行、算術符号は５行くらいでかけるから、
qsort使ってよいなら、かなり短くなると思うよ。

>>778
もったいぶらずに早く書いてよ。

>>764
>>773
>>777
普通BWTは圧縮とは言わないから、符号化までは入れないでしょう。
後段の符号化をやらないで、ベタで垂れ流してもBWTであることには変わりないですし。

>>780
なあんだ。ホラかよ。
限定ソートが80行に対して２、３０行で書けるとかほざいときながら。

>>781
完全ソートなら30行で書けますよね？
限定ソートの方が、工程が多い分だけ長くなるということで。

>>780
始めは俺もBWTだけを書くという話だと思ってたよ。
もしかして>>777>>781はBWTを知らないんじゃないかと・・・

漏れがまだ学生だった頃の糞コードを見たら、
半数が空行やコメントのプログラムが、７３行だった。実質３０行台。
うはっ、われながらひどいプログラムだ。

>>768
スマソ。それは遅れていただけで、やる気が無いわけではないです。
確かに今のUIがヘボイことは認めざるを得ません。
ただ、UIの発展をどういう方向に進ませるべきか意見を聞きたかったのです。
結果はDGCAで出せると思います。
同時ではないですが、MAC、Linuxの予定もあります。

>>782
いや、bzip2のソースもBurrowsとWheelerの論文も読んでるけどさ。
限定ソートの高速なソースは現に80行かそこらであるわけよ。>>649に。
んで、ＳＹＮは限定ソートのメリットなんて無いとほざいたわけよ。
たった２、３０行で書けると。
ホラ吹くんじゃねーよ（ｗ

速度の差も極小と言ったよな。
30行で高速なブロックソート圧縮プログラム早くうｐして見せろや。

>>785
確かに>>649はそれはそれですごいが、
あれをBWTの限定ソートと呼ぶのはどうかと。
そんなことをいったら1次モデルもBWTの限定版になってしまうがな。

>>785
SYNの言うこといちいち真に受けるなよ（ｗ
だからコテハンなんてろくな香具師じゃないって。

>>787
じゃああんたのいう限定ソートって何？

>>785 お初です。
限定ソートにメリットが無いことは、各種論文でも言われていると思うけど。
本当にブロックソート関連の論文読んだの？

>>789
bzip2みたいに、せめて100kバイト程度のブロックであって欲しいな。

ごちゃごちゃ言い訳してないで
2-30行のソースとやら晒して見せろや
嘘つきヤロウ

>>791
bzip2のブロックと、限定ソートの長さ制限は意味が違う。

>>791
それだけかよ（ｗ
じゃあ#define直せば限定ソートになるのか？

>>785
あー、それなら私が悪かった。申し訳ない。
ソースコードが小さいというがメリットになると思っていなかったので。
ただ、速度を気にしないBWTは異様なほど小さく出来る。
選択ソートやバブルソート使ったら( ﾟДﾟ)ｺﾞﾙｧ！かもしれませんが。
しかし、ここはIDも出ないのですね。自分の発言がどれかわからなくなりそう。

ttp://member.nifty.ne.jp/DO/algorithm/blocksorting.htm
ここに載っているのにqsort使うと３０行くらいじゃないか？

>>792
まてまて、焦ってはいけない。
>>540から>>649が登場するまでだって、あれだけ時間がかかったのだ。
せめて１〜２日はまってやろうじゃないか。

>>762では速度が遅くても良いと書いてあるけど、
本当に速度を気にしなくても良いなら、qsortつかって7行プログラミングできそう。

>>798
がいしゅつです。
すでにBWTは7行プログラミングされてます。

800!
なんだもう7行で概出か・・・俺が間違ってたよ。

>>800
お前誰だよｗ

>>799
無かったぞ。それともたまたまdat落ちしているpart2にあったとでも？
都合がいいな。

ちゃんと圧縮まで出来ねーと無価値。

>>802
んなこたーない。
BWTに限らずデータ圧縮モデルは遺伝子解析や言語解析などでも使われている。

正直、短いだけのBWTなんてどうでもいいと思う。

>>804
J. Seward のオリジナルの実装や、Larrson-Sadakaneの実装、二段階ソート法は、
速い上にそこそこ短い（実質50-60行くらいか）。

その「実質」とかいう言い訳は見飽きた。

>>806
まったくだ。
いくら互換性や大量のコメントがあるからといって、実質を持ち出されてもね。
アルゴリズムそのものは単純なのにね。

いまさらブロックソーティングなんてどうでもいいと思う。
10年近くも前のアルゴリズムじゃないか。

>>806
アルゴリズムが同じでも、コーディング能力によって倍くらいコード長が違う。
ま、>>795,>>808と同じでいまさらBWTがどうしたなんかどうでもいいが。

「実質〜行」なんていう言い訳は見飽きたから、
さっさと30行で書いて見せろっつーの。

>>810
7行プログラミングスレにありましたよ

>>811
圧縮できる完動品が？

>>812
MTFとレンジエンコーダーもあるから、自分で組み合わせてみたら。

つーか、そもそもの発言は符号化までは含まない単体のBWTについてだったのでは？

あのな。540から延々「実際に圧縮できる」限定ソート（もどき）の
話してて、実際に完動するソースが出てて、
ソースのサイズ比べる話が出て、なんでそこだけ「符号化までは含まない
単体」の話になるんだよ。

>>814
知るかYo

>>815
そうかYo

>>815-816
も前らに聞いてないYo

>>814
それなら、その限定ソートの部分を完全ソートに置き換えればいいだけでは？
BWTは速度を気にしなければ、
・読み込んだバッファを２倍にして同じものをコピー(2行)
・インデックス生成(1行)
・ソート(qsortでも何でもいい)(1行)
・比較関数(2,3行)
・FirstIndexとソート結果のインデックスから文字を出力(4,5行)
で書けます。マルチで書けば、ほとんどが一行に収まります。

能書きはいいからさっさとやって見せろって。

>>819
7行スレのBWTを分解して>>649に組み込めYo

>>820
面倒だYo
お前がやってくれYo

書きたいものは何ですか　　難しいものですか？
スレの中もログの中も　　探したけど見つからないのに
まだまだ探す気ですか　　それより自分で書いてみませんか？
ＢＷＴを　ＢＷＴを　書いてみたいと思いませんか？
ウフッフー　　ウフッフー　　ウフッフー　　さーあー！

>>822
BWTは7行スレpart2にあったはず。現在dat中。

あーもう、ごまかすなよ

>>786みろよ。
なんでqsortつかったトロいソート書くんだよ？

七行part2のブロックソートって

#include <stdlib.h>
typedef unsigned char b;e(b*s,b*d,int c){unsigned*o,i=0,r;o=calloc(65536,4);c--
;for(i;i<c;i++)o[s[i]<<8|s[i+1]]++;o[s[c]<<8|*s]++;for(i=1;i<65536;i++)o[i]+=o[
i-1];d[--o[s[c]<<8|*s]]=s[i=c-1];for(;i;i--)d[--o[s[i]<<8|s[i+1]]]=s[i-1];r=--o
[*s<<8|s[1]];d[r]=s[c];free(o);return r;}

これと

#include <stdlib.h>
typedef unsigned char B;void d(B*s,B*d,int c,unsigned x){unsigned*o,i,a=0,t[256
];memset(t,0,1024);for(i=--c;i;i--)t[s[i]]++;o=calloc(65536,4);for(;i<256;i++){
memset(d+a,i,t[i]);a+=t[i];}for(i=0;i<=c;i++)o[(s[i]<<8)+d[i]]++;for(i=1;i<
65536;i++)o[i]+=o[i-1];*d=d[x];d[c]=s[x];d[c-1]=s[--o[(d[c]<<8)+*d]];for(i=c;i>
2;i--)d[i-2]=s[--o[d[i-1]<<8|d[i]]];free(o);}

これと

#include <stdlib.h>
enum{S=256};typedef unsigned char UC;int cmp(void*a,void*b){return memcmp(a,b,S
);}UC*bs(UC*s,UC*d){UC*p,**t,i;p=malloc(S*2);t=malloc(S);for(i=0;i<S;i++)p[i]=p
[i+S]=s[i],t[i]=p+i;qsort(t,S,S,cmp);for(i=0;i<size;i++)if(p== t[i])break;*d++=
i;for(i=0;i<S;i++)d[i]=t[i][S-1];free(p);free(t);return --d;}

これくらいだぞ

限定ソートって、なんかメリットあるの？
デコるときの複雑さと遅さを考えると、使う気になれない。

別に複雑でもないみたいだが。
ケツから復元していけば良いだけだろ？
まぁ、キャッシュは外れまくりそうだが…

>>827
デコードは完全ソートの方がシンプルで高速だよね。

このスレの伸び具合はネタがあるかどうかじゃなくて
必死なヤツがいるかどうかだったのか…

おまいら必死だな（藁

BrainFuck <[+-.,]>
http://pc3.2ch.net/test/read.cgi/tech/1036013915/

圧縮してくれ

なんか物凄くどうでも良いことで言い争ってるように見える…

>>830
pc3.2ch.net/test/r.i/tech/1036013915

少し短くしますた。

結論：Ｓ　Ｙ　Ｎ　逝　っ　て　よ　し
糸冬　了

never
never
uzeee

DGCAのソースは七行です

もうちょい実のある話をしなさい

でもまぁ、叩かれるだけマシだよなー。

話題にも上らないよりかは。。

そ、そんなことないですよっ！
ボクは、僕はyz2も大好きです！！

叩かれるのはイヤでつ。

っていうか、いつまでアルファなんだよ！＞yz2

Cマガの記事によれば もーすぐ新しいバージョン出るらしいけど。
ベータになるのか、アルファのまんまか、はたまた出ないのか？

yz3のアルファ版

yz3とDGCAは統合されます。

HSP 最高

>>844
初耳です。

> HSP（High Speed signal Processor）
> 各種圧縮／伸張フォーマット(*2)に対応した高速DSPです。
うーん。アルゴリズムと関係あるのか？

>>540みたいのってＡＡのｱｼｭｰｸにｲｲﾝｼﾞｬﾈｰﾉ?
同じ全角文字はたくさん出てくるだろうし
半角文字2つの同じ並びもたくさん出てくるだろうし。

まぁ、その、なんだ。
人様の作ったものに対して色々文句言ってるやつがいるが、
文句があるなら自分で作ればよかろう。
それも出来もしないなら、おとなしくいていろってこった。

>>847
激しく同意

>>847
同意。

>>847
まったく同意

847がSYNで、同意している奴らがGCA叩いてたアホどもだったらわらえる

>>851
SYNﾀﾝは>>847とは逆の意見という罠

download板での発言

578 名前：SYN 投稿日：02/01/23 22:44 ID:NsxsovNn
>>562
様々な改善案を教えていただけるだけでなく、本音で「ここが糞」
という意見が聞ける2chは、本当にありがたいです。

学生の頃書いた二段階ソート法によるBW変換（当時のコメント削って５０行）
もっと速いバージョンはバグが入ったので、今作りなおしている。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static unsigned char *pText;
static int gLen;
int compare(const void *a, const void *b) {
　int l = gLen - ((*(int *)a < *(int *)b) ? *(int *)b : *(int *)a);
　int r = memcmp((const char *)(&pText[*(int *)a]),
　　　　　　　　 (const char *)(&pText[*(int *)b]), l);
　return (r == 0) ? (*(int *)b -*(int *)a) : r;
}

int main(int argc, char *argv[]) {
　FILE *fp;
　unsigned char *str;
　int i, j, k, l, *aArray, *aNext, pos, list[256], sum[256];

　if (argc < 2) {puts("usage> exec infile"); return -1;}
　fp = fopen(argv[1], "rb");
　fseek(fp, 0, SEEK_END); gLen = ftell(fp); rewind(fp);
　pText = str = (unsigned char *)malloc(gLen +1);
　fread(str, 1, gLen, fp);
　str[gLen] = 0;

　aArray = (int *)calloc(gLen +1, sizeof(int));　/* これが suffix array */
　aNext = (int *)malloc(sizeof(int) *(gLen +1));
　for (i = 0; i < 256; i++) {
　　list[i] = -1;
　　sum[i] = 0;
　}
　for (i = gLen; i >= 0; i--)
　　if (str[i] > str[i +1])　sum[str[i]] += 1;
　　else {
　　　aNext[i] = list[str[i]];
　　　list[str[i]] = i;
　　}
　for (pos = i = j = k = 0; j < 256; j++) {
　　pos = i = sum[j] + pos;
　　for (l = list[j]; l >= 0; l = aNext[l])　aArray[pos++] = l;
　　qsort(aArray + i, pos - i, sizeof(int), compare);
　　for (l = i - sum[j]; l < i; l++) {
　　　if (aArray[k] == 0) k++;
　　　aArray[l] = aArray[k++] -1;
　　}
　}
　return 0;
}

うわーん、これもバグありのバージョンを持ってきちゃった・・・打つ。

>>853-854 におけるmain関数内の次の部分を置き換えてほしいでつ

int i, j, l, *aArray, *aNext, pos, list[256], sum[256], typeA[256], t = 0;

...

　for (i = gLen; i >= 0; i--)
　　if (str[i] > str[i +1]) {
　　　sum[str[i]] += 1;
　　　t++;
　　}
　　else {
　　　aNext[i] = list[str[i]];
　　　list[str[i]] = i;
　　}
　for (pos = i = j = 0; j < 256; j++) {
　　pos = i = sum[j] + pos;
　　for (l = list[j]; l >= 0; l = aNext[l])　aArray[pos++] = l;
　　qsort(aArray + i, pos - i, sizeof(int), compare);
　　typeA[j] = i - sum[j];
　}
　for (i = 0; t >= 0; t--) {
　　if (aArray[i] == 0) i++;
　　aArray[typeA[str[aArray[i] -1]]++] = aArray[i++] -1;
　}

＞856
よくわかんないけど最後のforはもっと長くループさせないとだめじゃない?
たとえば、最後までまわすとか
for (i = j = 0; j < gLen; j++) {

>>857
そうでつた。元のソースではそうなってたのに・・・撃つ。

超hoshu

AA の

圧縮方法は

文字サイズを小に！！

>>860-862
kterm + lynx で見て、unreadable にすればいいのだ！

>>863
Tiny なら、全体のバランスを調整するときに使ったことはあるが。
（IEのフォントサイズ小みたいに）

unreadable は本当に読めないし、つぶれるからいまいち。

http://pcweb.mycom.co.jp/news/2002/11/13/09.html
これってどうなのさ

>>865
強敵だな（ｗ

>865
lossyな圧縮か。比べてもあまり意味ないな…

ソースネクストは、JPEG/GIFなどの画像ファイルを圧縮してファイルサイズを縮小できる
圧縮ソフトを発表した。

使用されているCATアルゴリズムは、圧縮アルゴリズムを複数用いるこ とで、例えば画像
であれば「建物」「空」といったパーツごとに最適な圧縮アルゴリズムを選択し、ファイルサ
イズを縮小する。

同社調査によれば、3.33MBのJPEG画像が、ZIP圧縮の場合3.31MBにしかならなかった
ものを、114KBにまで縮小できた。

不可逆圧縮だが、見た目上はほとんど変わらない画像になる。複数のアルゴ リズムを
利用するにもかかわらず、　

「圧縮・解凍時間ともに短時間」　である点も 特徴だ。
http://pcweb.mycom.co.jp/news/2002/11/13/09.html

不可逆圧縮興味なし。

要するに画像を圧縮してるんであって、JPEGファイルを圧縮してるわけじゃない。
MPEG1をMPEG4にコンバートしてるようなもんだろ?
ZIPと比べてるのは不当表示だよ。

まさにMPEG4のオブジェクト圧縮に似てるね。

JPEG2000とか同じく不可逆で縮みそうなものと比べるべきだわな

で、これはなんてフリーソフトが元なの？

http://pc3.2ch.net/test/read.cgi/software/1034921591/483-

494：◆Ukspgzd3n6：sage：02/11/13 (水) 23:54 ID:3tJrW3s5
http://www.quikcat.com/
超縮は、↑の QuikCAT Messaging Optimizer の
日本語版・・・のような気がするなぁ。拡張子も同じ .qcf だし。
英語版だけど、試用できるっぽい。

495：名無しさん＠お腹いっぱい。：sage：02/11/13 (水) 23:57 ID:7Pz0RnHA
↑にあるのはただのデコーダなだけじゃない？

496：◆Ukspgzd3n6：sage：02/11/14 (木) 00:05 ID:SsZE8nfL
>>495
あ・・・そうだった。
でも、圧縮する方法あり。
http://www.quikcat.com/products/qmo/qmo_tryit.htm
要するに、[email protected] にファイルを
送ると､圧縮して返送してくれる。
ちょっと試してみる。

>>875
まだ [email protected] からの返事が無い。

ちなみに、フリーソフトの Compressed File Reader は 6MB もする。
何だかと思えば、解凍ルーチンの DLL が妙にデカい。


相当複雑なアルゴリズムなんだろうなぁ。多分。

>>876
> 相当複雑なアルゴリズムなんだろうなぁ。多分。
て、そんなこと無いな。(・∀・;)

そこへメールだしても、ファイル盗まれるだけ