07/06/11 00:29:39 .net
>>392
すみません
あとでゆっくり読んで見ます。
プログラミングはサッパリなので、読むのに苦労します。
>>393
えええ
それは随分酷い設計ですな・・・。
あと、書いてて気づいたんですが
日本語検索に弱いってのは、ようするにトークン文字に 【】 とか2バイトの記号が含まれてないので
そもそも、【mp3】を形態素解析(もどき)で分割出来ないという話なんですよね？
う～ん。
本当に酷い設計ですな。
n-gramかSuffix Arrayを使った方が良いような・・・
メモリリソースを食べまくりだろうから、可変長n-gramを使って
登録時にうまい具合にハッシュ化するべきか、もしくは検索時に処理するべきか・・・
前者だとメモリの問題が(あと起動直後のログインラッシュ時のCPU負荷)、後者だとCPU負荷の問題があるねぇ。
やっぱ、後者でビタビアルゴリズムを使ってCPU負荷を減らしつつ、n-gramによる共起頻度探索をやってキャッシュを整備
ってのが、ベストか？
#受信したデータから順次クライアントで表示する方式だから、頻度の高い上位の結果を即座に返せば、後はゆっくり返しても体感上はスッキリ出来るはず
いや、試してないから、どうなるかサッパリだけどｗ