Namazu-devel-ja(旧)

["Hideyuki Takahashi" <k176@xxxxxxxxxx>]

高橋です。

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

簡単に実験をしたところ、検索においてはスピードはほとんど変わりませんでした。
mknmzでは、時間が少し増えていました。
今度もう少しまじめにテストして見たいと思います。。

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

おっしゃるとおり、ほとんど変わらないですね。
データ長は概算して16384以下(2byte)のものがほとんどだと思うので、
それが1byteになるだけですから。

>総文書数が増えれば増えるほど、単語xを含む文書数が増えるので、
>大量の文書を扱う場合にはメリットが出てきますかね。

もちろん文書数が増えるほど理論上は縮小されますが、
所詮1byte・・・
まぁ、「少しでもインデクスを縮小する」という
コンセプトをもとにしたので。

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

他のというとpnamazuを代表とした、検索クライアントのことでしょうか。
そっちのほうはあまり詳しくないもので。

>今のところ mknmz では制限を加えずにインデックスを作成し、
>namazu で最大ヒット数を指定して検索するというスタイルだったと思う
>のですが、インデックス作成時にも最大文書数を指定できるようにすれば、
>インデックスを小さくできるのではないかと思います。

なるほど。
個人的には、検索システムは再現率100%（絶対条件）で、
スコアの低いものはオプションで切り捨てる、というような
構造がベストだと思っているのですが、皆様いかがでしょう。

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

CVSの使い方がそもそもよくわかっていないのですが、
寺西さんがおっしゃっていることは、
HEADにある最新版のファイルを修正する、ということでしょうか。
差分のとり方はなんとなくわかるのですが、
それをCVSにアップする、ということでしょうか。

#　このMLの趣旨に合わない質問かもしれないです。
#　申し訳ございません。


図書館情報大学
　高橋英幸<k176@xxxxxxxxxx>