ページへ戻る

− Links

 印刷 

tek1​/adv1 のバックアップ差分(No.4) :: OSASK計画

osaskwiki:tek1/adv1 のバックアップ差分(No.4)

« Prev[4]  Next »[5]
3: 2004-06-08 (火) 06:49:47 ソース[6] 4: 2009-11-17 (火) 12:07:37 ソース[7]
Line 20: Line 20:
-ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。 -ちなみに符号寿命という考え方は、LHAがたまに静的ハフマン符号を作り直しているらしいという話を聞き、なるほど効果がありそうだと思って入れた。実験したらいろいろ分かったので、全部を一気に切り替えるのではなく、複数の寿命を扱えるようにした。
 +
 +* UC0 vs ハフマン
 +-まず、たとえば0~255などといったある程度狭い数値しか扱わないと確実にわかっている場合、ハフマン符号のほうが圧縮率の観点では有利である。しかし、任意の32bitの数値をエンコードするなどの用途になると、もはや4G個のハフマンテーブルを並べるわけには行かず、かといって動的ハフマンでもこの数は扱いにくいし速度が出ないので、UC0が有利である。
 +-LHAで使われているらしい方法として、32bit数値をそのままハフマンにかけるのではなく、総ビット数(0~31)をハフマン符号で表して、後続のbitをそのままビットストリームに並べるという方法があるらしい。この場合後続は先頭の1bitは必ず"1"なのでこれを省略するようだ。この方法のほうが圧縮率がUC0よりもいいかもしれない。
 +-なんと言ってもハフマン符号の強みは、小さい数字ほど出現頻度が高いだろうというtek1での仮定を前提にしないところである。
 +-一方弱みとしては、静的ハフマンではどうしてもパラメータが多くなり(符号長リスト)、動的では展開速度が遅くなるということである。パラメータが多くなれば当然符号寿命は長くしないと割が合わない。そうなると状況に合わせてきめ細かくハフマン表を切り替えられないので、結局圧縮率はそれほど有利にはならず、結果的にtek1が善戦しているのだろう。
 +-ハフマンもUC0も展開速度を上げることはそんなに難しくはないが、速度を上げる方法を使うとプログラムは長くなる。速度を上げる方法を積極的に使わなくてもUC0は十分に速いが、ハフマンではtek0なみに遅くなる。
* スケーラビリティ * スケーラビリティ
« Prev[4]  Next »[5]