1988年5月1日，私は PC-VAN の SIG SCIENCE（私が SIGOP をしていたところ） の第1ボード「オムニバス・ボード」（現「科学一般」）に次の書き込みをしました。
#1073/2867 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 5/ 1 15:39 ( 49) ＬＺＳＳ法によるデータ圧縮プログラム／奥村 ★内容 依然ある雑誌にＰａｓｃａｌで何かということで書いたのですが、その雑誌が休 刊中なので、ＴｕｒｂｏＣで書き直したものをアップします。 特徴は、圧縮率が非常に良いことと、符号化が非常に遅いことです。２分木など を使えば符号化は１桁速くなりますが、ＬＺＳＳ法そのもののアルゴリズムをはっ きりさせるために、できるだけシンプルに作りました。符号化に時間がかかっても、 アップやダウンの電話代を考えれば、少しでも圧縮率の良いもののほうが良いとい う考え方もあろうかと思います。 なお、これはソースのみです。ｉｓｈとｐｋｘａｒｃで解凍し、ＴｕｒｂｏＣな どＡＮＳＩ準拠のコンパイラにかけてください。 ……略…… （依然は以前の間違い）
「……略……」と書いた部分にソースコード lzss.c を PKARC で圧縮し ISH でテキスト化したものが埋め込んであります。
この lzss.c を始め，当時私が書いたものは当然ながら MS-DOS 形式のファイルです。文字コードは SJIS ですし，行末が UNIX 形式とは違う CR/LF で，しかも TAB が4桁です。 これでは不便なので，TAB だけは4個のスペースに直しておきました。 文字コード，行末，タイムスタンプは元のままです。
PKARC/PKXARC は PKWARE 社のシェアウェアで，当時は DOS 上の圧縮アーカイバの市場をほぼ独占していました。 ISH は 石塚匡哉 （いしづかまさや）さんが作られたバイナリ・テキスト変換ツールで， uuencode や BASE64 と違ってエラー訂正機能があり， 当時の文字化けの起こりやすいパソコン通信では必須のものでした。 UNIX 版の ish for unix もあります。 PKARC などの ARC 形式のアーカイブを UNIX 上で展開するには arc521e.tar.Z を使います。
ちなみに，欧文文字を全角で書くのは今からすれば異様ですが， 当時の PC-VAN のシステムは， 半角と全角を同じ行に混在させると行末部分が失われやすかったので， 欧文文字まで全角で書くことが多かったのです。
脱線しましたが，上記の書き込みをしたところ， 同じ日のうちにＲＯＭ男さん（CMA59466，園田豊英さん） からさっそく反応がありました。 5月4日には，まむしさん（ZED22472，三木和彦さん）が加わりました。 まむしさんの実験によれば，ARC と比べて圧縮率は数割良好， 速度はアセンブラで書けば ARC とほぼ同等まで上げられるということで， 話が白熱してきました。
他の人の転載許可を得ていないので，とりあえず私の書き込みだけ引用します。
#1083/1083 オムニバス・ボード データ圧縮アルゴリズムについて／奥村 ★内容 データ圧縮は、フロッピーディスクを節約したり、パソコン通信などでファイル のやり取りの時間（とお金！）を短縮したりするのに使います。 ＰＣ−ＶＡＮでよく使われているのが、ＰＫＡＲＣ、ＰＫＸＡＲＣです。これが どんなアルゴリズムを使っているのかは、寡聞にして知りません。いくつかの方法 から選択して使っているようですが、どなたか詳しいかた、お教え願えませんか。 され、データ圧縮のアルゴリズムでは、ハフマン法が昔から有名ものです。ハフ マン法については、いろんな本に出ていますし、『日経バイト』８６年１０月号に も解説があります。 ただし、ハフマン法には、ファイルを２回走査する、コード表が必要、２文字以 上の相関を考慮しない、という欠点があります。 これらの欠点をもたないいろいろな方法が考えられています。 ＬＺＷ法というアルゴリズムを使ったＣ言語のプログラムが、ＡＰ−Ｌａｂｏ編 著『ハードディスク・クックブック』（翔泳社 ’８７）という本にあります。こ のＬＺＷ法は、シンプルで速いため、オンラインでハード的に実現するのに向いて います。 ＬＺＷ法の元になった論文を書いたＬｉｖとＬｅｍｐｅｌは、別の論文で、もう 一つのアルゴリズムを提案しています。それに基づくＬＺＳＳ法というものをここ で紹介します。これは、圧縮率は非常に良いのですが、符号化は遅く、じっくりソ フトウェア的に圧縮率するのに向いています。解読は速いので、最初に手間がかか るだけです。 原理は簡単です。Ｎ文字のバッファを用意し、すでに符号化したＮ−Ｆ文字で始 まる文字列の中から、これから符号化するＦ文字の頭部と最も長く一致する文字列 を捜し、その位置と長さとを送るだけです。その際、両者の文字列に重なりがあっ てもうまくいきます。十分な長さの一致が得られなければ、符号化しない１文字を 送ります。最初のＮ−Ｆ文字は、ここではすべて空白に初期化しましたが、自分が よく使う言語の予約語を入れておいてもいいでしょう（他人には読めなくなる）。 バッファはリング状にするとメモリの節約になります。また、最長一致の探索に ２分木などを使えば符号化が（１桁は）速くなるでしょう。文字をそのまま送る部 分にハフマン法などを使うというのも可能かもしれません。バッファをもっと大き くすると、圧縮率も良くなります。もっとも、ファイルのサイズを超えては意味が ありませんが。この前のプログラムでは、バッファは小さめに選んであります。 どなたか、このアルゴリズムをつかって、ちゃんとしたアーカイバを作ってみま せんか。 パソコン通信のファイルを圧縮するためであれば、多少遅くても、１２００ボー より速ければ符号化の時間は無視できるでしょうから、需要はあると思います。 （誤植：Ｌｉｖ→Ｚｉｖ、され→さて）
当時は MS-DOS 上の MIFES というエディタで文章を書いてフロッピーに保存し， 電話をつないで一気にアップロードしていました。 誤植が多いのはあわてて書くためですが， 当時の私の使っていたモデムは 1200bps で， アップロード中に文章が読めるくらい遅いので， 間違いに気付くと手で訂正を入れることがよくありました。
画像圧縮についても議論が出ています。
#1118/1119 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 5/12 6:17 ( 4) ＬＺＳＳ＞画像データは苦手です／奥村 ★内容 ＬＺＳＳは、バイト単位のデータを圧縮するのに向いています。それも、同じバ イトのつらなりがよく現れるようなデータが向いています。 画像データの圧縮は、たとえば魔女さんがＱＬＤというプログラムを作っておら れます。この原理はわかりませんが、魔女さんもし見ていらしたら教えてください。
この魔女という人（男性です！）にはその後お会いしたことがあります。
#1164/1171 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 5/20 6: 4 ( 22) ＬＺＳＳ＞新しいのできました／奥村 ★内容 木の探索を使った新しい版ができました。従来のＣ版より１桁ほど速くなったと 思います。まむしさんのアセンブラ版よりも速いと思います。これをさらにアセン ブラで書けばますます速くなるでしょう。 あまり速いので、バッファの大きさＮを２倍にしてしまいました（つまりＥＩを １だけ増しました）。これは固定である必要はなく、ファイル長を超えない範囲で なるべく大きくなるように、ファイルごとに決めたほうが、圧縮比が良くなるでし ょう。あまり大きくすると、圧縮比はかえって悪くなります。このあたり、いろい ろ実験してみる必要があると思います。エンコードされたファイルの最初の部分に、 どういうパラメータで圧縮したかを書いておくとよいでしょう。将来のアルゴリズ ムの改良に備えて、第何版のＬＺＳＳでエンコードしたかも書いておく欄もあった らよいと思います。 アーカイバとしての機能はありませんので、使いづらいと思います。ただ単一の ファイルを縮めるだけです。まむしさんの新しい版に期待しましょう。きっとＰＫ ＡＲＣを凌ぐ最強のアーカイバになることでしょう。 アップしたＬＺＳＳ．ＩＳＨは、まずＩＳＨでＬＺＳＳ．ＬＺＳに直し、さらに まむしさんのアーカイバＬＺＳＳ．ＥＸＥで解凍します。すると、ＬＺＳＳ．Ｃが できます。ＴｕｒｂｏＣなどのＡＮＳＩ準拠Ｃでコンパイルしてください。 なお、このＬＺＳＳ．ＣをＴｕｒｂｏＣ１．５でコンパイルしたものは、スモー ルモデルで１０７７６バイトです。ｐｒｉｎｔｆ（）を自前のプリントルーチンに 変えるとさらに１Ｋバイトほど小さくなります。まむしさんも、ＴｕｒｂｏＰａｓ ｃａｌのかわりにＴｕｒｂｏＣで開発されたら、ＥＸＥがもっとコンパクトになる と思いますよ。
当時は Borland（現 Inprise）の Turbo Pascal が人気のコンパイラでした。 私も一時はそればかり使っていました。 しかし，世の中は ANSI C に移ろうとしていた頃です。 私はまむしさんより一歩先に Turbo Pascal を捨てて Turbo C に移行しました。
#1172/1177 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 5/21 6:29 ( 11) ＬＺＳＳ＞ＣＲＣもあったほうがいいですね。／奥村 ★内容 ヘッダについては、将来のことも考えて設計すべきでしょうね。 画像圧縮も、そのうち考えてみたいと思います。ＬＺＳＳは、０の列とか、同じ パターンの繰返しを縮めるだけで、一般にはＱＬＤなど専用のものに比べて弱いで しょうね。 また、ＡＴＯＫ．ＤＩＣを圧縮してみましたが、案の定、あまり縮まりません。 これは、辞書ファイルの性格上、同じバイト列（単語）が何度も現れないためだと 思います。人間の書く文章（特にプログラムのソースコード）は、同じ語が何度も 現れるので、ＬＺ系の圧縮アルゴリズムにかかりやすいのです。同じプログラムで も、実行コードは、特にアセンブラで書いた冗長度の低いタイトなコードは、縮ま りにくいことがあろうかと思います。 ＺＯＯはどういうアルゴリズムなのでしょうか。
5月22日には MASSAN 氏（現 massangeana こと 益山健 氏）が自己解凍版を作ってくださいました。
#1199/1199 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 5/23 6:17 ( 10) データ圧縮＞ＬＺＳＳ，ＬＺＷ，……／奥村 ★内容 ＬＺＳＳはＺｉｖ−Ｌｅｍｐｅｌ−Ｓｔｏｒｅｒ−Ｓｚｙｍａｎｓｋｉという ４人の人の名前をつなげたものです。前者２人のアルゴリズムを後者２人が改良し たのです。 ちなみに、ＬＺＷはＷはＷｅｌｃｈです。 ＬＺＷについては、私がここで下手な解説をするより、次の本を読まれたほうが いいと思います。Ｃのソースもついています。 ＡＰ−Ｌａｂｏ『ハードディスク・クックブック』 しょう泳社（しょうは羊へんに羽）、１９８７年、２２００円 まむしさん、ｔｈｒｅｓｈｏｌｄは（ｅｉ＋ｅｊ＋１）／（８＋１）ですから、 ｅｉ＝１２，ｅｊ＝４ではまだ１でよいのです。割り算は切捨てします。
ご隠居こと数学者の大久保謙二郎先生も参加されました。
#1208/1208 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 5/24 6:18 ( 10) データ圧縮＞ＡＲＩＴＨＭＥＴＩＣ……／奥村 ★内容 今朝はＡＲＩＴＨＭＥＴＩＣ ＣＯＤＩＮＧの勉強をすこししていました。 ふつうのフＦＦＭＡＮ（ちがった、ＨＵＦＦＭＡＮ）ＫＯＤＩＮＧ（ちがった ＣＯＤＩＮＧ）を改良して、情報量を極限にまでもっていったものというふうに 解釈しました。でも、１文字単位でコーディングしているかぎりは、そんなにメ リットがあるとも思えません。もちろんＨＵＦＦＭＡＮよりずっといいですが。 折衷案として、ＬＺＳＳで１文字出すところをＡＲＩＴＨＭＥＴＩＣ ＣＯＤ ＩＮＧで（確率はＡＤＡＰＴＩＶＥに変化させて）出せないか、ちょっと考えて みます。ＨＵＦＦＭＡＮのようにうまくいかないか。いずれにしても、ＬＺＳＳ で１文字送出する部分は、もうすこしなんとかなりそうな気もします。 ご隠居先生、どうでしょうか。
5月30日には，まむしさんの lzarc 2.0 ができました。
#1235/1235 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 5/31 6: 9 ( 68) ＬＺＳＳ＞もうＰＫＡＲＣは要らない／奥村 ★内容 まむしさんのＬＺＡＲＣはなかなかたいしたものです。これでもうＰＫＡＲＣは 要らなくなりました。 質問、感想を言わせてください。 パラメータのデフォルトは１１、４なのでしょうか。 ＲＥＦＬＥＸの説明がよくわかりません。 引数を間違えたためアーカイブが作れなかったような場合にも、エラーメッセー ジが出なかったり、０バイトのアーカイブファイルができてしまったりすることが あります。 海外に輸出（？）するためには、英語版ヘルプの英語を練る必要があるかもしれ ませんが、この辺は英語ＳＩＧ常連のご隠居先生のほうが詳しいと思います。 あとはＺＭＹさんの版ができて互換性がどうなるか、われわれ消費者（？）にと って心配なことですが、速い（あるいは流通に力を入れた）ほうが生き残ることに なるのでしょうか。ＺＭＹさん、進行はどんな具合ですか？ 完成したらここにア ップしてください。 ＰＫＡＲＣにあってＬＺＡＲＣにない（あるいはその逆の）オプションがありま す。比較のため、ＰＫＡＲＣ、ＰＫＸＡＲＣのヘルプを挙げておきます。英文ヘル プのお手本にもなると思います。 ……略…… これを書いてからソースの残りがアップされているのを見つけました。まむしさん どうもありがとうございます。さっそく勉強させていただきます。
まむしさんはアセンブラの名人です。
#1239/1239 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 6/ 1 6: 3 ( 2) ＬＺＳＳ＞ソースを見て感激しました／奥村 ★内容 あのややこしい木のアルゴリズムがアセンブラで書いてあるのを見て感激しまし た。とても私にはできないことです。三木さんどうもありがとうございました。
せっかくだから雑誌で発表しようという話になりました。
#1266/1267 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 6/ 9 6:14 ( 8) 原稿募集＞ご隠居さん、魔女さん、まむしさん、皆さん／奥村 ★内容 先日ＴｈｅＢＡＳＩＣの人にデータ圧縮が話題になっていることをちょっとお話 ししたところ、みなさんに原稿を書いていただけないかというようなことでした。 もしよろしかったら、たとえばご隠居先生に算術圧縮、魔女さんに画像圧縮、まむ しさんかＺＭＹさんにＬＺＡＲＣ、ＭＡＳＳＡＮに自己解凍、……といった具合に 分担して原稿（＋プログラム）を書いてみませんか？ せっかくこのＳＩＧに書き 込んでいただいても原稿料をお払いすることができませんので……。もしご賛同い ただけましたら、ご連絡いただければ幸いです。上に挙げました以外のかたのご協 力も歓迎いたします。
6月25日には，まむしさんの LARC 2.10 ができました。
折しも SEA (System Enhancement Associates, Inc., Wayne, NJ) が PKWARE に対して訴訟を起こしました。 SEA は ARC という名前の DOS 用 LZW 圧縮アーカイバをシェアウェアとして売っていました。 しかし，PKWARE の PKARC は ARC に互換で，ARC よりずっと高速でした。 この裁判の様子が philkatz.zip というファイルに収められています。 1992年に SEA は日本の会社に売却され，かつての社長 Thom Henderson は小さなプロバイダをしながら悠々自適の生活を楽しんでいるようです （といってもたぶん私より若い人ですが）。
★ PKWARE の Phil Katz は2000年4月14日に亡くなったそうです。 享年37歳。
#1391/1391 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 8/ 3 6:14 ( 14) Ｑ＞訴訟問題？／奥村 ★内容 ＳＥＡがＰＫＷＡＲＥに訴訟を起こしているとは知りませんでした。それで、どん な雰囲気なんでしょうか？ ＡＲＣのヘッダ形式の著作権もあるのでしょうか。 だとするとＬＡＲＣのように独自の構造にするほかないですが。 他にＺＯＯとかいうのもあるそうですが（私は使ったことないのですが）、それは どんなふうになっているのでしょうか。 そもそも私は元祖ＡＲＣも使ったことがないのです。ソースはちょっと見たことが あるのですが、どうも他人の書いたものは読む気になれない……。 それから、そうですか、ＭＩＸでもＬＡＲＣが話題になっているのですか。知りま せんでした。 ＳＴＳのほうで本を出す計画があり、その本（２巻本）のディスクサービスになに かアーカイバをつけるとかいうので、ＬＡＲＣも候補にあがっていたことがあったの ですが、最近の話ではＰＫＡＲＣを入れてしまおうとか聞いています。ＰＫＡＲＣな どはシェアウェアですがディスクサービスに含めてよいものでしょうか。
#1396/1396 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 8 8:48 ( 18) 大変！ＰＫＡＲＣがなくなる／奥村 ★内容 ＧＶ（ＳＩＧグローバル・ビレッジ）の垂れ幕に「……これは，いまアメリカで 問題になっているフロッピヴィールスとは無関係ですが，いささかやっかいなバグ だったらしいので，差し替えます」とあったので、バグフィックス版と思いきや、 じつは名前フィックス版だったのです（バグもあったのかもしれないが）。あのＰ ＫＡＲＣ、ＰＫＸＡＲＣの名はなくなり、かわってＰＫＰＡＫ、ＰＫＵＮＰＡＫと いうパックマンみたいな名前になってしまいました。 これはＰＫＷＡＲＥ社とＳＥＡ社との間の合意によるもので、ＰＫＷＡＲＥ社は 今までの代償にＳＥＡ社に非公表の額を払い、ＰＫＷＡＲＥ社のソフトのソースコ ードの使用を許し、さらにロイヤルティを払って来年１月末までは名前を変えた上 でＡＲＣ互換ソフトを配布できることになったようです。その後はＡＲＣ互換ソフ トは配布できなくなるとのことです。 よくわからないのですが、これはひょっとして、現在の．ａｒｃファイルが将来 のＰＫＷＡＲＥ社のアーカイバでは読めなくなる可能性があるということではない かと思います。 まむしさんのＬＡＲＣは、名前は「ＡＲＣ」の３文字が入っていますが、ＰＤＳ だし、ヘッダも非互換だから、問題ないと思います。なんならＬＰＡＫなどと改名 しますか。それともＧＮＵ（ＧＮＵ’ｓ Ｎｏｔ ＵＮＩＸの略）にならってＬＮ Ａ（ＬＮＡ’ｓ Ｎｏｔ ＡＲＣの略）とでもしたら？（これは冗談）。
SIG SCIENCE は科学のフォーラムなのに， データ圧縮ばかりで燃えている状態でした。
#1551/1551 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 8/27 17: 9 ( 8) どうも（ｃ）ＳＨＯさん／奥村 ★内容 ほんとにみんな、世界的なソフトができるみこみができてきたので、のりに のっちゃっています。私じしんも悪のりぎみかな。 科学の話がぜんぜんありませんね。もっとも、圧縮アルゴリズムも、りっぱ なソフトウェア科学のテーマですが。 データ圧縮は、ここまで来た以上、ｐｋａｒｃに追いつくか追い越すか、 やれるところまでみんなでアイデアを出し合ってやっていきたいと思います。 結果はザベのおそらく１２月号にみんなで発表して、それで完成ということ になると思います。
そしてついに……。
#1552/1553 オムニバス・ボード ★タイトル (SCIENCE ) 88/ 8/27 22: 3 ( 11) 驚異の圧縮アルゴリズム完成！／奥村 ★内容 その名もＬＺＡＲＩという。ＬＺＳＳとＡＲＩのあいのこである。 実験結果： LZSS3.C 5164 bytes PKPAK -> 2641 LZSS3 -> 2086 LZARI -> 1973 LZSS3.EXE 27906 bytes PKPAK -> 23312 LZSS3 -> 20786 LZARI -> 18733 まだコードがきれいでないし、動作はあまり確認してないが、アップします。
8月28日からは圧縮の話を第2ボード「トピカル・コンファレンス」 に移動しました。ここは後に「計算機と算法」という名前になりました。
#276/1976 計算機と算法 ★タイトル (SCIENCE ) 88/ 8/28 7:22 ( 36) データ圧縮・今までの経過／奥村 ★内容 ことの起こりは、私が次のようなプログラム（Ｃ言語）をアップしたことから始 まったらしいのです。 1073 88/ 5/ 1 ＬＺＳＳ法によるデータ圧縮プログラム／奥村 現在のＬＡＲＣの作者、まむしさんがさっそく眼をつけてくださいました。 1086 88/ 5/ 5 ＴＰ４へのＬＺＳＳの移植 まむし 1087 88/ 5/ 5 <<< lzsspas.lzs for all OSs ( use ish ) [ 40 lines ] >>> ＱＬＤの作者として名高い魔女りかさんも登場です 1123 88/ 5/12 画像圧縮について。 魔女 1209 88/ 5/24 ＱＬＤの圧縮方法は縦横圧縮と色圧縮です。 魔女 大久保先生は算術圧縮を紹介してくださるなど、いろいろお世話になりました。 1153 88/ 5/17 <<< ENCODE.ARC for MS-DOS ( use ish & arc ) [ 278 lines ] >> 1154 88/ 5/17 <<< ENCODE.ARC for MS-DOS ( use ish & arc ) [ 278 lines ] >> ＭＡＳＳＡＮさんも参加していただき、いよいよ本格的になりました。 1179 88/ 5/22 ＬＺＳＳ＞はじめまして MASSAN 1180 88/ 5/22 LZSS>self extract version [ﾔｸ180Ln] MASSAN そのうち、みんなで研究成果を原稿にまとめて発表しようという話になりました。 1266 88/ 6/ 9 原稿募集＞ご隠居さん、魔女さん、まむしさん、皆さん／奥村 まむしさんが大作のＬＡＲＣを発表されました。もうすぐ新しい版もできると思 いますが、いまのところの最新版は次のものです。 1319 88/ 6/29 ＬＡＲＣソース１転載／奥村 1320 88/ 6/29 ＬＡＲＣソース２ 1321 88/ 6/29 ＬＡＲＣソース３ 1322 88/ 6/29 ＬＡＲＣソース４ 1368 88/ 7/19 ＬＡＲＣバグフィックス版３／３（ＮＩＦＴＹより転載・奥村） 1367 88/ 7/19 ＬＡＲＣバグフィックス版２／３（ＮＩＦＴＹより転載・奥村） 1366 88/ 7/19 ＬＡＲＣバグフィックス版１／３（ＮＩＦＴＹより転載・奥村） ８月に入ってからは、もうオムニバスボードはほとんど圧縮関係だけになってし まいましたので、特にここに挙げる必要はないでしょう。ＲＯＭ男さんはＸ６８０ ００に移植されました。Ａｎａさんは実用的な算術圧縮ユーティリティを作られま した。ＭＡＳＳＡＮさん、まむしさんが次々にアルゴリズムを改良されました。 今までデータ圧縮の事実上の標準となっていたＰＫＡＲＣが訴訟に負け、来年１ 月でなくなることになりました。 ＬＡＲＣがいろいろなところで注目され始めました。技術評論社のパソコン通信 Ｊｕｐｉｔｅｒのソフト・サービスの圧縮にＬＡＲＣが採用されました。 このボード（トピカル・コンファレンス）は当分のあいだ圧縮専用といたします ので、よろしくお願いいたします。
#285/1976 計算機と算法 ★タイトル (SCIENCE ) 88/ 8/28 20: 9 ( 26) ＬＺＡＲＩさらに圧縮率向上（２６行）／奥村 ★内容 ここまでくると執念ですね。一致位置のエンコードも確率分布を考えて最適にし ようと思ったのですが、ａｄａｐｔｉｖｅ（分布を相手に合わせて変える）な方法 では時間がかかるので、適当に固定したものです。変更ヶ所のみアップします。 ｉｓｈとｌａｒｃで解凍してください。前回の修正と合わせて意味をもちます。
私が算術圧縮ばかりやっていたので，9月20日にＲＯＭ男さんが， Huffmanの方が速いのではないかと指摘してくださいました。
#387/1976 計算機と算法 ★タイトル (SCIENCE ) 88/10/ 1 6:21 ( 9) ＲＯＭ男さんの指摘について／奥村 ★内容 ＬＺＳＳ＋ＡＲＩより＋ＨＵＦＦＭＡＮの方がよいのではないかというご指摘、 ウームそうですね、ＨＵＦＦＭＡＮの方が速いでしょうか。圧縮率はＡＲＩの方 が若干よいのですが。 よくわからなかったのですが、２段がまえでするということは、最初に頻度表 を作ってしまうということでしょうか。そうすれば、頻度表もいっしょに送らね ばならず、小さいファイルではかえって大きくなってしまいます。アダプティブ （頻度を更新しながら変換していく）の方がその点便利です。 いずれにしても、やってみないとわからないかもしれませんから、やってみて くださいませんか。
11月11日になると，NIFTY のほうで LZARI の算術圧縮部を Huffman に置き換えた LZHUF を作った人がやはり出たということを， まむしさんが教えてくださいました。 これが後に LHarc や LHA で有名になる吉崎栄泰さんでした。
#567/1977 計算機と算法 ★タイトル (SCIENCE ) 88/11/12 6:15 ( 20) ＬＺＨＵＦやっぱり出ましたか。／奥村 ★内容 そこまでやってくださるかたがあるとは楽しみです。 ＨＵＦＦＭＡＮにもいろいろあって、コードを固定にする（最初に全文を走査 して度数分布表をつくる）ものから、いろいろなアダプティブな（つまりローカ ルな度数分布でコードを変化させる）ものまであるようですが、このへんはＲＯ Ｍ男さんが詳しいかな。そのＬＺＨＵＦはどんなふうにしているのでしょうか。 私はＮＩＦＴＹにも入っているのですがどうも勝手がわからなくてあそこにいく と迷子になるのです。 ごく最近まで横須賀にもＮＩＦＴＹのノードがあることを知らなかった。 まむしさんのＦＳＤＲに行ってもどの会議室をのぞけばよいのか、また ＰＣ−ＶＡＮのようにタイトル一覧を見て読みたいものだけを番号で選ぶ 方法がわからなくて、最初のいくつかを全文読まされてそのうち電話代が 心配になって切ってしまうというありさまです。ジャッカルさんも元気で やっているのかな。 ＮＩＦＴＹにもサイエンスができたのですね。挨拶の書き込みをしてき ましたが、やはり会議室を選択的に読む方法がわからず、ご無沙汰してい ます。朝日のサイエンスネットにもＩＤをもらったのですが、あそこも ボードに入るなり最初のアーティクルが全文出てきてびっくりする。やは り慣れているＰＣ−ＶＡＮが使いやすいです。ＡＣＳ，ＰＣＳも幽霊会員 でしたが会費切れでもう入れません。 あれ、話がそれてしまいましたが、ぜひそのＬＺＨＵＦ見たいですね。
というわけで，私も苦労して NIFTY に入って LZHUF.C をもらってきて，
このころから，私は圧縮だけでなく AT 互換機や TeX にも凝り始めています。
12月25日，吉崎さんがついに LZHUF を元にしたアーカイバ LHARC を作られたというニュースが入ります。 さっそく許可を得て27日には PC-VAN に転載しました。
リンクはご自由にどうぞ。
松阪大学 奥村晴彦 okumura@matsusaka-u.ac.jp
Last modified: Thu Apr 27 08:49:17 JST 2000