2: 2004-06-07 (月) 23:41:04  |
3: 2004-06-08 (火) 06:49:47 |
| | * [[tek1]]の続き | | * [[tek1]]の続き |
| - | -ここではtek0からのアイデアの連続性について書く | + | -ここではtek0からのアイデアの連続性やその他の読み物的なことについて書く |
| | | | |
| | * UC0のアイデア | | * UC0のアイデア |
| | //--いや、やっぱりフォーマットを変えよう。今しかフォーマットはいじれないわけだし（2004.06.03）。 | | //--いや、やっぱりフォーマットを変えよう。今しかフォーマットはいじれないわけだし（2004.06.03）。 |
| | -これはまさにUC0である。そして先頭にまとめることで100が先行したときのdの数と1000が先行したときのdの数との大小関係を、あえて逆転することもできるようになった（今まではもっぱらdの個数は増やしていくしかなかった）。この先行形式にしたとたんにベース値という考えも思いつけるようになった。 | | -これはまさにUC0である。そして先頭にまとめることで100が先行したときのdの数と1000が先行したときのdの数との大小関係を、あえて逆転することもできるようになった（今まではもっぱらdの個数は増やしていくしかなかった）。この先行形式にしたとたんにベース値という考えも思いつけるようになった。 |
| - | -思えばl2d3からtek0へ進化したときも同じような発想だった。つまり、無圧縮ヘッダ"1"と圧縮ヘッダ"0"のbitを全部前に集めてしまおうと考えて、それをL0a符号に置き換えたのである。L0aにしたことで無圧縮領域が長くなるときに"0"を並べるのではなくもっと短くすることができるようになり、tek0の圧縮率はl2d3よりもほぼ全てのケースでよくなったわけである。 | + | -思えばl2d3からtek0へ進化したときも同じような発想だった。つまり、無圧縮ヘッダ"1"と圧縮ヘッダ"0"のbitを全部前に集めてしまおうと考えて、それをL0a符号に置き換えたのである。L0aにしたことで無圧縮領域が長くなるときに"1"を並べるのではなくもっと短くすることができるようになり、tek0の圧縮率はl2d3よりもほぼ全てのケースでよくなったわけである。 |
| | | | |
| | -ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。 | | -ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。 |
| | + | |
| | + | * スケーラビリティ |
| | + | -l2d3やtek0では、圧縮対象のファイルは4GBまでしか考えていなかったし、将来拡張したくなったときのための拡張フラグなどをまったく残していなかった。 |
| | + | -tek1では（ちなみにtek2も）、いずれは大きなディスクイメージを扱うことにも配慮し、OSACMPヘッダ部分のファイルサイズゾーンにs7s符号を使って4GB以上を表現できるようにしたし、拡張フラグ類も準備した。 |
| | + | -tek1は圧縮率比較表でのMD:2mに象徴されるように（註：実はファイルフォーマット的にはMDも8MBまでとれる。現在制限されているのは、圧縮ルーチン側の都合に過ぎない）、大きなバッファメモリをふんだんに使うような、そんな形式に見えるかもしれないが、それは大いなる誤解である。 |
| | + | --MDはmaxdisのこと。maxdisを省略して書けるようになっている。 |
| | + | -tek1はしょせんl2d3やtek0の子孫であり、今までどおりMD:32kやそれ未満で使うこともでき（というか、今でもデフォルトはMD:32kであるし）、この場合バッファメモリは32KBしか要しない。UC0のパラメータテーブルも4つあわせて1KB程度であり、16bit環境でも容易に展開できる。l2d3やtek0と比べて消費メモリが増えたとすれば、せいぜいこのUC0パラメータテーブル1KBであろうが、しかしこれもLHAのハフマンデコード用テーブルに比較すれば、取るに足らない大きさである。 |
| | + | --上記は展開時の話である。圧縮時の消費メモリ量もMDに比例する部分があるので、MD:32kなら圧縮時の消費メモリも結構少なくなる。 |
| | + | --さらにいえばl2d3とtek0にあってはMDに何の制限もなく、100MBでも200MBでも許していたので、こっちのほうがよっぽどリッチではある（圧縮速度の問題があるので、今まで誰もやっていなかったとは思うが）。なお、tek1の8MBという上限はBS（ブロックサイズ）の8MBに起因する。ランダムアクセスを考えると8MB以上のブロックサイズは考えにくいので、問題はないだろう。もし問題があれば、有り余る拡張bitで16MB以上のブロックサイズをサポートすれば済む。 |
| | + | -tek1はこのように、小規模システムから大規模システムまでを単一のアルゴリズムと単一のフォーマットのみで連続的にサポートできるところがよいのであって、実際にこのフォーマットを活用する段階で、MDはいくつ以下でなければいけないとか、BS（ブロックサイズ）はいくつ以下である必要があるなどの制限を課したり課さなかったりすればよいのである。 |
| | + | -LHAは16bit時代に考えられた形式だからあれでよかったとか、あれで仕方がないなどという弁護を見かけたが、それはtek0に4GB制限があるのと同レベルであって、たいした理由にはならない。いかなる時代のいかなる環境であっても、汎用フォーマットとしてスケーラブルなフォーマットを制定することはできたのであるから。 |
| | + | --要するにパラメータ（ファイルサイズやバッファサイズ）のフォーマットに起因する上限がなければよいだけのことである。展開のことを考えれば、もちろん何らかの上限があるほうが好ましいが、それがいつか自らの可能性を縛る壁になるので、展開ルーチン側でチェックして対応できないものはできないといわせるほうが前向きであろう。 |
| | | | |
| | * こめんと欄 | | * こめんと欄 |
| | | | |
| | #comment | | #comment |
