Namazu-users-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

hikari wrote:
> 
> > 単語1を含む文書IDの総数のBER数値のバイト数＋単語1を含む文書のスコア値のBER
> > のような気がしますが、如何でしょうか？
> > BER圧縮は可変長なので、かならず偶数にはならないと思うのです。。
> の方が正しいと私は思います。
> 文章ID間の距離が127以下であるのと、スコアが127以下である時に限定して、文章数
> ｘ２は正しいので。

きちんと調べきれていないので誤解があるかもしれませんが、なんだか 
mknmz と namazu で処理が違うような気がしてきました。

nmz/hlist.c の nmz_get_hlist() では、明確に 2 で割った値を使って
います。そして、
 文書ID の総数 + スコアの総数 = 文書の総数 * 2
という前提で処理が書かれています。

ところが、mknmz の write_index_sub() を見たところ、
文書の総数 * 2 とは扱っておらず、BER圧縮されたデータのバイト数と
みなして処理を行っています。

これは非常にまずいような。

> つまり、BER圧縮整数値の最小単位1byteをそれぞれ差分ＩＤとスコアに使っていると
> いう仮定が、文章数ｘ２という仮定を成り立たせていますが、
> 上限ストップ機能は組み込まれていませんので、それは間違えていると思われます。
> プログラム的にも、それを前提にしている部分は、スコアと文章ＩＤの値によって具
> 現しうる問題を内在していることになります。

そのようです。

> hikari wrote:
> 
> 例として補足です。
> つまり
> ============
> 単語A
> スコア128
> 文章ID1
> ==========
> の場合
> スコア2byte+ID1byte=3byteなので、
> 3という値が先頭に格納され、
> 奇数の事象が生じるということです。
> 文章ＩＤも同じような原理で、127を越えれば、色々と。

127 までならは両者に違いはないため正常動作するが、127 を越えるた時は、
正常に動作していないのではないかという気がしますね。
(といっても、namazu 側では該当単語が含まれていない文書も余計に含める
程度の影響なので、実害はほとんどないと思われますが。)

ところで、mknmz, namazu のどちらの処理が正解だと判断すべきでしょう。
http://www.namazu.org/doc/nmz.html.ja
からすると namazu の処理が正解だと思うので、mknmz 側を修正すべきでは
ないかと思います。

他の namazu クライアントは 
http://www.namazu.org/doc/nmz.html.ja
の仕様に従って作られているのではないかとも思いますし。
(実際、私はそうやって作っていたしなぁ。)
-- 
=====================================================================
寺西 忠勝(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