Jun Oizumi
vagus****@gmail*****
2010年 6月 2日 (水) 01:32:13 JST
大泉です。 > 現在、変換毎にファイルを open し、parse し、探すという実装になっ > ています。 > ここは、データの形式と検索方法の二つの方向で改善が望まれますか。 > > (1) データの形式 > > もし、データの形式を、prefix を共通部分とする文字列という形式にすると、 > ファイルの大きさはだいぶ小さくできますよね。 > > 例えば、現在の形: > > 0010010 #CNS 北海道札幌市北区北十条西 北海道札幌市北区北十条西1丁目 北海道札幌市北区北十条西2丁目 北海道札幌市北区北十条西3丁目 北海道札幌市北区北十条西4丁目 > > は、"北海道札幌市北区北十条西" が 0 のエントリとすれば、 > > 0010010 #CNS <0> <0>1丁目 <0>2丁目 <0>3丁目 <0>4丁目 > > と短く収められます。 > > 今、4MB 以上もありますもん。 「変換毎にファイルを open し、parse」するならファイルサイズは小さい方が いい訳ですね。 それに関連して思いついたことがあるのでちょっと。 といっても、大したことではないですが。 現在、品詞コードは "CNS" になっていますが、これは、別に "CNS" でなければ ならない理由はなく、"CN" でもいい。 (ちなみに、alt-cannadic では CNS は不使用で、地名はすべて CN です) "CN" にすると、1行につき "S" の 1バイト分小さくなるので、ファイル全体では (1 * 行数)バイト小さくなります。 昨日上げた zipcode.t は 125,897行なので、125,897バイト小さくできます。 # 昨日上げた zipcode.t は「1行1エントリ」形式にしてありますが、 # Anthy 同梱の zipcode.t のように「1行複数エントリ」形式にすると行数が減るので # 減らせるバイト数もその分減りますが。 ファイル全体のサイズからすればささやかかもしれませんが、"CNS" にしておく 理由は何もないので、"CN" にしてしまっていいと思います。 もっと言うと、郵便番号辞書の品詞コードが「地名」というのも何か変なので、 新規に「無品詞」という品詞コードを作って、それに "N" とか "Z" とかアルファベット 1文字の品詞コードを割り当てれば、1行につき 2バイト分小さくなります。 が、「そこまでしなくても」という気もします。
