もう少し処理を洗って、考えないと…
OpenBSD(uaa@), Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
候補のチェックをkakasi/EUC版と同様にするのであれば、結局「候補の文字列をEUCへ変換可能かどうか」というチェックになってしまって、Unicode→EUCテーブルを外せなくなるという問題を抱えてしまう(せっかくUTF-8化するならそんなテーブルは外したい)。
ファイルから読みだしたものはwchar_t[]で管理していて、kakasiに渡すときはEUC化(unsigned short[])したものをchar[]と見立てて渡す…MeCabの場合はmulti-byte stringなchar[]に変換して渡す…得られた結果はその逆で。
変換候補と読みのチェックをwchar_t[](Unicode)←→unsigned short[](EUC)変換時に掛けているけど、これをどう再現するかが頭の痛いところ。MeCabの読みは平仮名ではなく片仮名なので結局変換処理を入れる必要があるから…ここで引っかけることはできそうなんだけど。
wchar_t(Unicode)→mbs(UTF-8)/MeCab→wchar_t(Unicode)/カナ→wchar_t(Unicode)/かな
kakasi/EUC版の場合は候補側と読み側の両方でチェックを掛けられたけど、MeCab/UTF-8版だと読み側でしかチェック掛けられないか…?
nwc2010-libkkc、を利用したCC100-jaのlibkkc辞書化を考えてみたけど…nwc2010-libkkcの読み仮名付与に使うkakasiをMeCabに変えることはできないかというのが一つの課題になりそう。別にkakasiのままでもいいのかもしれないけど、読み仮名を振れない物は変換候補にできない以上大きな辞書を持っているMeCabの支援はやっぱり受けたいなって(形態素解析でもMeCabを使うなら読み仮名もMeCabでというのが自然だし)。
MMDVMHostで自分が手を入れた部分にat()+try~catchなコードがあるけど、直すか放っておくか…C++0xなので放っておく、でいいのかな(find()はC++11だし)
find()だとイテレータを返してしまうし(end()のチェックをすれば良いのか)、単に存在チェックするのにat()+try~catchだと大袈裟だ、ということでcontains()なんだけどC++20ってのがなあ。 https://cpprefjp.github.io/reference/map/map/contains.html
libkkcとしてはtext-bigram-language-model.vala中で<UNK>についての処理は入ってるけど…何か積極的に対処してるようにも見えないなあ。
まあ、難しいことは後から考えるとしてまずは辞書を作るためにどんな感じの作業が必要かなーというのを洗い出せれば良いや。細かい部分を詰めるとかそういうのは詳しい人がやることだし(と面倒な部分からは逃げる)。
変換候補にできないものは<unk>に置き換える、という手法は…確かにそうなんだけど、既にN-gram化されている物に関しては複数の「この <unk> は」みたいなエントリが出た場合にどう統合するのかを考えないといけないから厄介。
N-gramを作成する以上「この 治療法 の evidence」に対しては「この/この ちりょうほう/治療法 の/の evidence/evidence」と出力しないとダメで…「この/この ちりょうほう/治療法 の/の」(evidenceを切ってしまう)出力はできない。辞書へ含めるに相応しいかどうかの判定は形態素解析よりも後にしないといけない。
既に形態素解析済/N-gram化済というデータだったからkakasiniよる読み仮名付与と合わせて辞書データに入れるかどうかのフィルタリングをしてしまったけど…多分この部分はもう少しマシなやり方はありそう。
いやいや、元のテキストデータがUTF-8なのでUTF-8辞書入れないとダメでしょ。
DebianでMeCab(日本語形態素解析システム)を利用する (2017/09/22) http://qs.nndo.jp/2017/09/22/865/
apt-get install mecab mecab-ipadic mecab-utils
と、mecab-ipadic-utf8を敢えて入れないという方針でいくか。libmecab2は依存性により自動インストールなのでいちいち記述しなくていいし、コード書く訳じゃないからlibmecab-devも(今のところ多分)要らないし。
MeCabの出力結果、読み仮名がカタカナというのがなあ…これは平仮名に変換しないといけないし、libkkc辞書を作るなら「よみがな/変換対象」形式にしないといけないので結局何かしらのコンバータが要るのは確かそう。
MeCabは基本的にEUCで動くが生成した辞書の文字コード次第…とにかくEUCなら変換対象はEUCで記されたものに限定されるのはkakasiを使っていた時と同様か。わかち書きモードがあるならそれは(ストレージ容量を食わずに済むので)助かるけど、読み仮名を別途用意するのがなあ… https://taku910.github.io/mecab/#format