高橋です。
前回寺西さんにご指摘いただいたところを参考に
NMZ.iを縮小する方法を考えてみました。
現在のNMZ.iの構造は、
[単語xのデータ量][Docid][score]...
となっていますが、以下のようにしてみました。
[単語xのデータのBERSIZEの超過分][Docid][score]...
非常にわかりずらいですね。
つまり、最初のデータは、DOCIDとスコアの、BER圧縮したbyteが
2以上の場合、インクリメントします。
例えば、[Docid][score]
[127] [20] [128][10] [1][130]
の場合、128を超えるのは2つあるので、2が入ります。
もちろん、16384を超えると、+2になります。
ここで、単語xのデータのBERSIZEの超過分をextrabyte(x)とします。
それで、単語xのデータ量の求め方は、
NMZ.ii(x+1) - NMZ.ii(x) - extrabyte(x) - byte(extrabyte(x))
で求めます。
（BER圧縮を使うとほとんど1byte、1byteに一つの値が入ることが
多いのでbyte計算から読み込むデータ量を求められる）
NMZ.pについても同様にしました。
これにより、利点は、
１．データが圧縮！
２．NMZ.iから単語xのデータすべてを読まなくても、
必要データ量が求められる！
１．に関しては、約1.7MのNMZ.iが1Kほど縮小されました。
２．に関しては、hlist.cでのnmz_get_hlist()のトリックが
楽になっています。
改変したファイルを添付しますので、ご感想をよろしくお願いいたします。
ちなみに、変数のネームセンスがないため、不適当な名前を
つけているかもしれませんが、ご容赦ください。
むしろ良い案をいただけると助かります。
また、いっていることと違う、ここにバグがある等もありましたら
お教えください。
P.S.
このアルゴリズムを元に、更なる縮小化がぼんやりと頭にうかんでいます。
ですのでバシバシご意見をいただけるとうれしいです。
図書館情報大学4年
高橋英幸<k176@xxxxxxxxxx>Attachment:
namazu_data.tar.gz
Description: application/gzip-compressed