Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Hideyuki Takahashi wrote:
> 
> 現在のNMZ.iの構造は、
> [単語xのデータ量][Docid][score]...
> となっていますが、以下のようにしてみました。
> [単語xのデータのBERSIZEの超過分][Docid][score]...
...
> ここで、単語xのデータのBERSIZEの超過分をextrabyte(x)とします。
> それで、単語xのデータ量の求め方は、
> NMZ.ii(x+1) - NMZ.ii(x) - extrabyte(x) - byte(extrabyte(x))
> で求めます。
> （BER圧縮を使うとほとんど1byte、1byteに一つの値が入ることが
> 多いのでbyte計算から読み込むデータ量を求められる）

アイデアは面白いですが、少々計算が面倒ではないかと思ったりします。

# 現状との比較ではなく、単に文書数にするのと比較した場合

> これにより、利点は、
> １．データが圧縮！
> ２．NMZ.iから単語xのデータすべてを読まなくても、
> 必要データ量が求められる！
> 
> １．に関しては、約1.7MのNMZ.iが1Kほど縮小されました。
> ２．に関しては、hlist.cでのnmz_get_hlist()のトリックが
> 楽になっています。
> 
> 改変したファイルを添付しますので、ご感想をよろしくお願いいたします。

データにも依存するのですが、単に文書数にする場合に比べて、
どれほど縮小されるでしょうか?
(さほど小さくならないのではないかと思いますが...。文書数が128を
超えないと小さくならないだろうし。)

1 のメリットに比べて 2 のデメリットが十分見合うかどうかがカギで
しょうね。
総文書数が増えれば増えるほど、単語xを含む文書数が増えるので、
大量の文書を扱う場合にはメリットが出てきますかね。
総文書数と平均単語xを含む文書数の統計情報があると、検討しやすい
ですね。

namazu コマンド(namazu.cgiを含む) だけがインデックスファイルを
読み込むわけではないので、多少インデックスが小さくなるよりは、
簡単に読み出せる方が良いとは思います。

# 個人的にはインデックスを小さくしたい理由がありますが。

> むしろ良い案をいただけると助かります。

いろいろ案を出していただいて楽しいです。良い刺激になります。

確か「単語xを含む文書数」の上限はなかったかと思いますが、これは
最大ヒット数以上は必要ないはずです。
今のところ mknmz では制限を加えずにインデックスを作成し、
namazu で最大ヒット数を指定して検索するというスタイルだったと思う
のですが、インデックス作成時にも最大文書数を指定できるようにすれば、
インデックスを小さくできるのではないかと思います。
(namazu 側では mknmz で指定した最大文書数までで、最大ヒット数
が指定できるというように。)

総文書数が多い場合でも、最大ヒット数をあまり大きくなくて良い
から、インデックスを小さくしたい場合には有効ではないかと
思ったりします。
(個人的には最大ヒット数は100もあれば十分ですから)

> また、いっていることと違う、ここにバグがある等もありましたら
> お教えください。

Namazu 2.0.12 を修正されているようですが、できましたら HEAD を
修正してください。
Namazu 2.0系はインデックスのフォーマットは変更できないしばりが
あるので、2.1系に手を加えるのが効率的です。
そのまま 2.1系に反映させることもできるでしょう。
また、修正ファイル全部ではなくて差分だけの方が良いです。

> P.S.
> このアルゴリズムを元に、更なる縮小化がぼんやりと頭にうかんでいます。
> ですのでバシバシご意見をいただけるとうれしいです。

期待しています。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E