早々に破綻

したYo　orz｡NFKC使おうとした方法は｡｡｡

なぜ駄目なのか?

理由は簡単､可逆性がない｡例えば､U+2162は"III"を1文字で表す｡当然のコトながら､NFKCに書けると結果は"III"となる｡そりゃそれで良いのだけど､機種依存文字を嫌う人の場合*1はなっから､U+2162なんて使わずに､IIIとタイプしてしまうコトはよくある｡コーなったときに､U+2162とIIIに等価性を持たせつつトークンナイズするとなると､トークンナイズの結果が､どっちの場合も一致しなければならにゃ駄目なわけで｡これを実現するには､かなりリソースを喰う操作が必要になってくる｡互換等価性に関するテーブルは多分探せば出てくるけど､これを加工して､インデックスを作ったとしても､総当たりで文字を比較していかなけりゃならず､あまり現実的じゃなくなる｡*2

じゃーどーするか?

妥協案で､NFCに変換してしまってその上でbi-gramTokenizeを実行する形に設計変更ていうのが､今のところの自分なりの答え｡異音同義を突き詰めすぎると､多分形態素解析+αあたりまで行ってしまいそうだし､そこまで行くともはやあたしの手に余る｡今でさえ迷路に迷い込んであっぷあっぷしてるのに　orz

と､ここまで考えた時点で今日は時間切れ｡明日はこの方針でどのようにclassを作るのかまで行けたら僥倖だな　orz

*1:あたしも､その傾向が強い

*2:逆の場合は､1文字見れば良いだけなのであまり問題にはならない｡ちなみにこれは互換等価性のごく一部の話においてと言う但し書きは付く