Fri, Mar 19 - Overlasting::Hatena

09:48 ひろお
08:30 朝なのだが、検索と圧縮の事だけ考えて、それ以外のことを棚に上げていた反動がきている。
08:15 全体的に「差分とって圧縮」してないからかな。この程度の語彙とエントリ数なのに。あなどれないな。
08:12 ぐっは。自分のMacBook上のVMに与えていたメモリではメモリが足りなかったというオチか。(500M+2G)
02:44 素朴過ぎてindexに4時間くらいかかるっぽい。終わってる。終わってるが、最初だからな。今後これより遅い事はない。
02:43 bigramとtrigramのindexを作ってみながら、寝る。
02:37 お、検索できとるな、大丈夫だ。今は大丈夫だという事にしておこう。。
02:32 おわわ、これは、もとのデータの10倍以上のデータ量になっている。うけるwwww
01:46 文書番号がランダムだといつ終わるのか分かんないww
01:32 終わらない。風呂入ってくるか。
01:30 文書番号をランダムにして突っ込んで、まともに動くか見てみよう。
01:29 10とか、ほとんど重複しないかと思ったら、意外と重複するな。。
01:28 検索結果の枝刈りを工夫してないから10gram indexを作って、どんなことになるか、みてみようかな。。。
01:17 元のファイルより大分小さいな。14%くらいか。重複しまくってるってこと？
01:14 お、indexしきれた。
01:13 今日のところはnの値を大きくしてクエリを投げてお茶を濁すか。。
01:12 あー、そうか、思い出した。このまま検索したら、文書量大杉で死ぬな。。ngram のヒット数を数えて上位だけ持ってこないといけないのか。
01:10 あー、住所とか、文書番号の差分圧縮がかなり効くよな。ひどいことになる予感。
01:08 122883 エントリか。お試しに丁度よさげ。
01:07 678だった。
01:03 即utf8にした。
01:03 く、sjisか。
01:00 2,7,8,9番目だけとって、789\t2とかにすれば良さげ。
00:57 あ、意外と小さいな。
00:56 郵便番号とかでやってみるか。
00:56 hashが初期状態のときにこけそうだったので対応した。
00:44 なんか、手頃なデータを突っ込んでみるか。。。
00:43 速度の差を知りたいから、綺麗にまとめたらブランチ切ろう。
00:43 ここまでで、大体、素朴な実装の速度は測れる気がするな。
00:41 ngramがちょっとでも一致した文書は持ってこられるようになったな。
00:20 @uchumik 早く健康になってください。ピザとか焼き肉とかラーメンとか行きたいです。 [in reply to uchumik]
00:20 @uchumik ライトノベル読む暇はあるのかwww [in reply to uchumik]
00:15 重複の削除できた。な。
00:14 @uchumik 2つめの病院行けばいいのにwwwww [in reply to uchumik]
00:09 おーけー。次は、検索して得た文書番号の重複を無くす。本当は、頻度を数えたいが頻度は一旦横においておく。
00:04 次は検索用クエリをngram分割。