3: 2004-06-08 (火) 06:49:47  |
現: 2024-01-08 (月) 12:59:03 ゲスト |
| - | * [[tek1]]の続き | + | TITLE:x |
| | + | * [[tek1]]の続き [#n6cd3da5] |
| | -ここではtek0からのアイデアの連続性やその他の読み物的なことについて書く | | -ここではtek0からのアイデアの連続性やその他の読み物的なことについて書く |
| | | | |
| - | * UC0のアイデア | + | * UC0のアイデア [#rb30220d] |
| | -UC0符号は、tek0でのdfの発展型である。 | | -UC0符号は、tek0でのdfの発展型である。 |
| | --ここで少しおさらいしておくと、dfはd3の発展型であった。つまりd3→df→UC0ということになる。 | | --ここで少しおさらいしておくと、dfはd3の発展型であった。つまりd3→df→UC0ということになる。 |
| | -ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。 | | -ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。 |
| | | | |
| - | * スケーラビリティ | + | * UC0 vs ハフマン [#mf41a126] |
| | + | -まず、たとえば0～255などといったある程度狭い数値しか扱わないと確実にわかっている場合、ハフマン符号のほうが圧縮率の観点では有利である。しかし、任意の32bitの数値をエンコードするなどの用途になると、もはや4G個のハフマンテーブルを並べるわけには行かず、かといって動的ハフマンでもこの数は扱いにくいし速度が出ないので、UC0が有利である。 |
| | + | -LHAで使われているらしい方法として、32bit数値をそのままハフマンにかけるのではなく、総ビット数（0～31）をハフマン符号で表して、後続のbitをそのままビットストリームに並べるという方法があるらしい。この場合後続は先頭の1bitは必ず"1"なのでこれを省略するようだ。この方法のほうが圧縮率がUC0よりもいいかもしれない。 |
| | + | -なんと言ってもハフマン符号の強みは、小さい数字ほど出現頻度が高いだろうというtek1での仮定を前提にしないところである。 |
| | + | -一方弱みとしては、静的ハフマンではどうしてもパラメータが多くなり（符号長リスト）、動的では展開速度が遅くなるということである。パラメータが多くなれば当然符号寿命は長くしないと割が合わない。そうなると状況に合わせてきめ細かくハフマン表を切り替えられないので、結局圧縮率はそれほど有利にはならず、結果的にtek1が善戦しているのだろう。 |
| | + | -ハフマンもUC0も展開速度を上げることはそんなに難しくはないが、速度を上げる方法を使うとプログラムは長くなる。速度を上げる方法を積極的に使わなくてもUC0は十分に速いが、ハフマンではtek0なみに遅くなる。 |
| | + | |
| | + | * スケーラビリティ [#c0f7596e] |
| | -l2d3やtek0では、圧縮対象のファイルは4GBまでしか考えていなかったし、将来拡張したくなったときのための拡張フラグなどをまったく残していなかった。 | | -l2d3やtek0では、圧縮対象のファイルは4GBまでしか考えていなかったし、将来拡張したくなったときのための拡張フラグなどをまったく残していなかった。 |
| | -tek1では（ちなみにtek2も）、いずれは大きなディスクイメージを扱うことにも配慮し、OSACMPヘッダ部分のファイルサイズゾーンにs7s符号を使って4GB以上を表現できるようにしたし、拡張フラグ類も準備した。 | | -tek1では（ちなみにtek2も）、いずれは大きなディスクイメージを扱うことにも配慮し、OSACMPヘッダ部分のファイルサイズゾーンにs7s符号を使って4GB以上を表現できるようにしたし、拡張フラグ類も準備した。 |
| | --要するにパラメータ（ファイルサイズやバッファサイズ）のフォーマットに起因する上限がなければよいだけのことである。展開のことを考えれば、もちろん何らかの上限があるほうが好ましいが、それがいつか自らの可能性を縛る壁になるので、展開ルーチン側でチェックして対応できないものはできないといわせるほうが前向きであろう。 | | --要するにパラメータ（ファイルサイズやバッファサイズ）のフォーマットに起因する上限がなければよいだけのことである。展開のことを考えれば、もちろん何らかの上限があるほうが好ましいが、それがいつか自らの可能性を縛る壁になるので、展開ルーチン側でチェックして対応できないものはできないといわせるほうが前向きであろう。 |
| | | | |
| - | * こめんと欄 | + | * こめんと欄 [#edcfc8ef] |
| | | | |
| | #comment | | #comment |
