一つの活用形に複数の読みがある場合

昨日、「オリジナルの anthy の方で『来んな』を出せるように出来ない、D2T35 も有効化できない」とか騒いでましたが、やっぱり単純ミスでした。

それはすぐ直せたんですが、別の問題に気づいてしまった。

カ変「来る」やサ変「する」は、語幹そのものが変化するというか、語幹と活用語尾の区別がないので、活用形そのものが辞書に登録してある。他の動詞は語幹だけ。

しかも、例えば「する」の場合、未然形は「さ」「し」「せ」と 3つもある。命令形も「しろ」「せよ」の 2つがある。

しかし、anthy には一つの活用形に複数の読みがあるという前提がない。「さ」も「し」も「せ」もすべて「サ変『する』の未然形」で同じ扱いになる。従って、いくら付属語グラフで未然形「し」と未然形「せ」で接続を分けても、区別なく両方に接続してしまう。
(「さ」は「させる」「される」を辞書に登録してあれば実質的に不要と思われるので入ってない。また、カ変とサ変「する」以外は語幹と活用語尾が分かれており、付属語グラフでいくらでも対応出来るので問題は起こらない)。

同じ事がカ変終止形「来る」と「来ん(「くんな」の「くん」)」でも起こる。

「そんな基本的なこと、今ごろ気づいたんか」と言われそうですが、そうなんですよねぇ、参ったね。
というわけで、色々ゴチャゴチャといじって、「同じ活用クラスの同じ活用形でも区別できるように」とやってましたが、結局、非常に不細工な方法でしか回避できなかった…。

興味のある奇特な方は、明日出す予定の depgraph改の
　anthy/wtype.h
　src-worddic/ptab.h
　src-worddic/wtab.h
あたりを以前のと見比べて下さい。
【追記】5/4
説明するのが面倒 & 変更箇所はごくわずかだったのでこう書いたんだけど、何か却って勿体つけて興味を惹こうとしてるみたいだな…、これじゃ。
簡単に言うと、品詞コードをもう一つ作って、「する」なら

　品詞コード SRV : し し する する すれ しろ
　品詞コード SRV2: せ ○ ○ ○ ○ せよ

という風に分けることで区別した、ということです。

depgraph: 「文末」属性 - 【追記】5/2

anthy の depgraph には「文節の終端」(「@」単独、もしくは「S?@」)は指定できるが、「文末」という属性はない。
もしあれば、

　週末には|見んな|散って|しまう
　誰が|来んな|落書きを|書いたのか
　夢かな|えてくれよ

といった、文の途中に終助詞が来てしまうタイプの誤変換は直せると思う。
「ぶんせつのくぎりかたとかのはなしはどうなるのだろう」も、n文節最長一致モードでも、

　文節の|区切り方とかのは|なしは|どうなるのだろう

と、若干改善されるはず。
また、「終わらね」「知らね」「違うんじゃね」等を出せるようにしても、副作用の誤変換はほぼ起こさないはず。


でも「文末」属性って、具体的にはどう定義したらいいんだろうか?
単純に考えれば「これより右側に次の文節が来ることはない」ということになると思うが、「絶対に来ない」「来ることはありえない」とするとマズい。句読点や閉じ括弧、疑問符、感嘆符といった記号類はあり得る。
「後ろに次の文節がない(最後尾の文節である)か、後ろの文節が単漢字のみの文節である」なら OK、そうでなければスコアを大きく下げる、とか? 「単漢字のみの文節」は「単漢字の"記号のみの"文節」にできればいいけど、漢字も非漢字も品詞コードは「KJ」で区別がないから無理か。読みが記号かどうかで区別できそうだけど、あまりスマートじゃないかも。

続きを読む

お返事色々

句読点を多めに入れる感覚で「;」を打っていけば、 多分、読みを入力するのと同時にタイプしていても、 それほど気にならない様な気がする。

同感です。
区切り文字は何がいいかは自分も試行錯誤中です。押しやすさから言えば、「変換」キー、「無変換」キー、「スペース」キーあたりだろうとは思うものの、それはフロントエンドを改造しないとできないと思うので、自分には…。

続きを読む

むう

anthy-9100h.patch13Bptn21.bz2(Mon,20 Apr,2009) で「;」(いわゆる半角セミコロン)を区切り文字にした場合に、「；」(いわゆる全角セミコロン)を出そうとしてみる。

プリエディットに「;」だけがある状態で、

　・F9(全角英数変換)を押す
　　　uim-anthy → 「；」(いわゆる全角セミコロン)になった(OK)
　　　scim-anthy → 無反応(NG)

　・SPACE(変換キー)を押す
　　　uim-anthy → プリエディットが空になり、その後 anthy が操作不能になった(NG)
　　　scim-anthy → 無反応(NG)

という結果に(scim-anthy は変化がないだけで操作できなくなるわけではない)。

区切り文字も通常の文字として扱うような仕組みが必要なんでしょうが、どうすればいいんだろう? 「\;」とエスケープされたら文字として扱う、とかかな? あるいは、「;」(区切り文字)だけで前後に他の文字がない場合は通常の文字として変換、とかでしょうか?

【追記】4/22
早くも修正されてました(Wed,22 Apr,2009 版)。ありがとうございます。
uim-anthy、scim-anthy どっちも問題なく変換できるようになりました。

文節区切り位置指定連文節変換 - 模擬実験 【追記】4/21

昨日の続き。

Anthy 本体やフロントエンドをいじらずに擬似的に実現できる方法を思いついた(例によって力技ですが)ので実際に試してみるテスト。

要件は、
　・区切り位置の指定には「;」(半角セミコロン)を使う
　・区切り位置は、ユーザが指定した部分は必ず区切り、それ以外は自動判別


【追記】4/21
G-HAL 氏がこの方式もすでに実装されてました(いつもながら素早い…)。こちらは以下のような「なんちゃって」ではなく、ちゃんとした実装なので、試すならこちら(anthy-9100h.patch13Bptn21.bz2)を使われた方がいいと思います。

(メモ: 「;」を区切り文字にした場合、「；」はどうやって出せばいいのか調べる)続きを読む

Firefox 拡張で日本語連文節変換 - "Kitsune"

Mozilla Re-mix さん経由で知りました。
「日本語IME環境が無くてもFirefoxで日本語入力ができるアドオン「Kitsune」」

Kitsune::Firefox add-ons
キーバインド一覧

正直、どういう場面で役に立つのか思いつけないんですが。
自分の PC なら IME 入ってるだろうし、他人の PC なら勝手に拡張とか入れちゃマズいでしょうし。

でも、一応興味はあるので入れてみました。

作者さんの名前からすると中国の方???

xpi 展開して中を見てみると、品詞コードは Canna のものでした。となると、当然「じゃあ、辞書は?」という疑問が出てくるわけで、sqlite の DB を dump して中を見てみた。
んん? これはどの辞書だろう? cannadic とも違うようだし…。自作? でも、SVN リポジトリの data/ 以下は空だな。ってことは、よそから持ってきたんでしょうね、きっと。cannadic を何らかの基準で絞ったものだろうか? あるいは、iroha か。説明の類が一切ないので分かりません。

にしても、javascript なのに一応それなりに使える感じでびっくりですね。

でも、文節の伸縮ができませぬ…。
これから実装されるのか、それとも、もしかしてそもそも不可能なのか…。
なんか、タイトルに思いっきり「連文節変換」と書いてしまったけど、そう言い切れるのかどうか、ちょっと心配になってきた…。
"擬似"連文節変換とかだったりして。間違ってたらごめんなさい。

区切り位置指定変換

(1ヶ月くらい前に書き始めたものの、うまくまとめられず、ずっと下書きに置いてあった記事ですが、「ひょっとして今がタイミング?」という気がしたので(Sat,18 Apr,2009)無理やり書き上げてアップした。でも、違う入力方式の話なので全然役には立たないと思われる。まあ、何かいいアイデアのきっかけにでもなれば…)。

SKK の入力方式は、

　・通常はかな直、変換したいところだけ変換
　　→ 単語変換なので文節区切りの誤りがない。というか、そもそも変換したい部分の頭とお尻をユーザが指定してるので、変換エンジンは間違えようがない
　　→ 「変換不要な部分(ひらがなのままでいい部分)が変換されてしまう」ということがない
　・送りありと送りなし(「活用語か否か」とほぼイコール)で変換操作が異なる
　　→ 「いた(居た)」と「板」のように連文節変換方式では同じ読みになって混同されるものを区別して変換し分けられる。

という 2つの点で高い変換精度を実現している。
反面、操作がその分面倒で細切れになり、入力に時間がかかる。

対して、連文節変換方式は、「どこが変換の必要な部分か」とか「どこで区切るべきか」とか「活用語か否か」といったことをユーザは一切気にせず、とにかくベタな読みだけを入力、変換エンジンが返してきた変換がおかしかったら後からそこだけ直す、という方式。
ユーザは、入力時は、とにかく読みを入力することだけ気にしていればいいので、入力は速い。変換時も、たとえ変換エンジンが返してきた結果が酷かったとしても、直すのにそれほど時間がかかるわけではない。

お題として与えられた同じ文章を入力する場合で考えると、自分がやった場合、SKK に不慣れな点を考慮しても、多分連文節変換方式での方が倍くらいのスピードで入力・変換できると思う。Anthy を使っても。
つまり、「入力・変換操作を複雑化させることで変換精度を上げる方式」より、「入力・変換操作は単純にして(その分初発の変換精度は前者より落ちる)、後から誤りを訂正する方式」の方がトータルでは早く入力できると思われる。

そういう意味では連文節変換方式の方が優れていると言えると思う。
(開発コストのことは、ここでは勘定に入れないことにする)。

にもかかわらず、連文節変換方式はユーザからは結構不評だったりする。「バカ」とか「イラつく」とか言われる。他方 SKK は、操作の面倒さに文句を言われることもあるが、それでも「操作に慣れてしまえば快適」と言われることが多いように思う。連文節変換から SKK に乗り換える人も結構見かける。

これは偏に、「連文節変換エンジンが返してくる変換結果がユーザにとってはストレスを感じさせるから」ということに起因すると思う。

ユーザには「期待する変換結果」がある。物事が期待通りに行かないと人はストレスを感じる。常に思い通りになるわけではないと分かっていても、頻繁に思い通りにならなかったり、期待からあまりにかけ離れた結果が返ってくると、やはり頭に来る。「なぜそういう結果になるのか」が理解できないとさらにストレスになる。そして、一般ユーザは変換エンジン内部のことなど当然知らないので「なぜそうなるのか」など理解できず、ストレスが溜まる一方ということになる。

そんなこんなで、連文節変換エンジンは往々にしてユーザにストレスを感じさせてしまい、心証を悪くしてしまうのだと思われる。変換精度が悪ければ悪いほどそうなる。

「速く入力できるかどうか」より「気持ちよく快適に入力できるかどうか」の方が大事なのだ、という考えは十分「あり」だと思うし、それが SKK を好む人の心理なのではないかという気がする。「速く入力できるかどうかという"結果"も大事だが、入力・変換時の"過程"も大事だ」ということだと思う。

ここまでが前置き。

続きを読む

自作 depgraph 更新(4/8)

忙しかったり、つまらないところでつまづいてたりで遅くなってしまいましたが、更新しました。

【変更点】
・depgraph の作業漏れをやっつけた
・anthy.dep のサイズが 300KB を超えたので、depgraph/mkdepword でこれまで遷移条件の部分は一行にまとめていなかったのをまとめるようにして、30KB程減らした
・G-HAL 氏のパッチを当てずに、anthy に直接当てるパッチも用意した(一応本家に送るための準備のつもり。でも、送るかどうかはまだ迷ってる)


【使い方】
1. alt-depgraph-090408.tar.bz2 を展開

$ tar xvjf alt-depgraph-090408.tar.bz2
$ cd alt-depgraph-090408/

2. anthy-9100h のソースを取ってきて alt-depgraph-090408/ に置く

3. apply_patches.sh を実行

$ chmod u+x apply_patches.sh
$ ./apply_patches.sh
Apply G-HAL's patch ? (Y/n): ← G-HAL 氏のパッチを使わない場合は「n|N」を、使う場合は「n|N」以外を答える

4. あとは、通常どおりの手順

$ cd anthy-9100h/
$ ./configure --prefix=/usr
$ make
$ sudo make install

(明日以降にもう少し親切な説明が書けたらいいなと一応思ってますが…)

自作 depgraph 更新(4/2)-【追記】

更新しました。

今回は depgraph 修正と corpus 例文追加がほとんどです。
depgraph は G-HAL 氏の備忘録をかなり参考にさせていただきました。多謝。

「店頭に並んでいなかった」が一文節になってしまうのは depgraph で対処したつもり。
「公開されることはないだろうけれど」「訂正すべきものでもないけれど」が一文節になってしまうのは、一応例文で対処して「ない」の前で区切るようにはしましたが、自立語部分が「公開」や「訂正」じゃないものの場合や「けれど」を「けど」にした場合などには、やっぱり一文節になってしまいます。

本当は「は」と「ない」の間で区切るべきなのは重々承知なんですが、なんで「はない」と繋がるようにしているかと言うと、区切ると例えば「問題は|ない」が「問題|花井」とかになってそれがあまりにウザいからなんですよねぇ…。これがまた直せなくて…。


全体としては、自分としては「depgraph は大体こんなもんでエエんちゃうかな?」という気になってるんですが(なので【お試し版】は外した)どうでしょうか。
※正直に言うと、モチベーションが尽きかけてるからというのも大きい。

【追記】4/4
depgraph で作業漏れを発見したので、明日あたりにまた出します。

霞って賢いんだね - 【追記】6/17

自分の場合、未登録語があったら直接 cannadic改をいじるので、これまで個人辞書ツールというのはほとんど使ったことなかったんですが、ちょっと調べたいことがあって霞を使ってみたら、賢いことを発見してちょっとびっくり。

まあ、自分が知らなかっただけの可能性大ですが。
でも、ちょっと感動したので、「知らない人もいるかも」という理由をこじつけて書いてみるテスト。

続きを読む

おおっ、こ、これは助かる

alt-depgraph、抜けているものをどうやって洗い出そうかと悩んでいたところに来ましたよ、奥さん。
何と言うか、もう「さすが」の一言です m(_ _)m

早速コピらせていただきました。

続きを読む

うーん

某所に「数詞がらみの合成語は確率を下るようにしてみた」とあったので試してみたのですが、やはり「|大体千部|」「|約千部|」になりました。「約千部」は「やくぜんぶ」で日本語としてはおかしいですが、テスト変換なのでそこは無視で。

普段自分がやっているように「update_params2 × 3」でやったので傾向が変わってしまったのかもと思い、anthy-9100h.patch13ptn20.2009225.alt-depgraph-090223.calctrans.tar.bz2 の corpus_info, weak_words でやってみましたが、同じでした。

何か間違えてるのかな?

でも、それはそれとして、もう一回数詞がらみはチェックしなきゃなと思うので、また hogedic 作ってみよう。

「make -j N」対策

多分、こんな感じで行けるんじゃないかと。
【追記】
G-HAL 氏にもっとちゃんとした対応をしていただいたので、そちらをお使い下さい(下のコメント欄を参照)。
次回はちゃんと修正したのを出します。

--- Makefile.am.orig	2009-03-02 20:30:28.000000000 +0900
+++ Makefile.am	2009-03-02 20:28:25.000000000 +0900
@@ -29,12 +29,12 @@
 mkdepgraph_LDADD =  ../src-main/libanthy.la ../src-worddic/libanthydic.la
 
 anthy.dep : mkdepgraph mkdepword $(DEPWORDS)
-	$(srcdir)/mkdepword
-	-@if test '$(srcdir)' != '$(builddir)'; then \
+	$(srcdir)/mkdepword ;\
+	if test '$(srcdir)' != '$(builddir)'; then \
 		echo "Copying files..." ; \
 		cp -p $(srcdir)/master.depword $(builddir)/ ; \
 		cp -p $(srcdir)/indepword.txt $(builddir)/ ; \
-	fi
+	fi ;\
 	./mkdepgraph $(builddir)
 
 noinst_DATA = anthy.dep \
--- Makefile.in.orig	2009-03-02 20:30:20.000000000 +0900
+++ Makefile.in	2009-03-02 20:28:49.000000000 +0900
@@ -491,12 +491,12 @@
 
 
 anthy.dep : mkdepgraph mkdepword $(DEPWORDS)
-	$(srcdir)/mkdepword
-	-@if test '$(srcdir)' != '$(builddir)'; then \
+	$(srcdir)/mkdepword ;\
+	if test '$(srcdir)' != '$(builddir)'; then \
 		echo "Copying files..." ; \
 		cp -p $(srcdir)/master.depword $(builddir)/ ; \
 		cp -p $(srcdir)/indepword.txt $(builddir)/ ; \
-	fi
+	fi ;\
 	./mkdepgraph $(builddir)
 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.

ただ、個人的にはいまいち「-j」の挙動が分からない…。

ソースとは別のディレクトリで正しくビルドできないバグ

追記に書いたこのバグですが、ようやく理解した。
完全に自分のせいですね、これは…。

・オリジナルの anthy では、実際に定義が書いてある *.depword を master.depword が直接 include して読み込んでる。
・自作 depgraph では間にワンステップ挟んで、定義ファイル → 形式変換した中間(?)ファイル → master.depword という形にしてある。
・srcdir != builddir の場合、中間ファイルは builddir に作成されるが、master.depword は srcdir にあり、include しようにも builddir を見に行くようにはなっていない。
・従って、実質的に indepword.txt の内容しか持たないスカスカな anthy.dep が作成されてしまう。

これが、alt-depgraph-090223 の状態だと思います。
間にワンステップかましたために、オリジナルでは想定されてない事態になってしまって上手く行かなくなった、と。
付属語が一切ないので、変換すると多分単漢字だらけになると思います。

で、何とかうまく回避できないかなと思って色々考えましたが、mkdepgraph.c が srcdir にある master.depword を前提にしている以上、結局 mkdepgraph.c をいじる以外ないんじゃないかという結論に達しました。

# ビルド時に master.depword に変更加えたりするのは、srcdir と builddir を別にする意味がなくなるからマズいだろうし…。
# anthy-conf がインストールされないならやりようがあるような気もするけど…

そして、まあ、何と言うことでしょう、既に G-HAL 氏が対応させて下さったので、自分でやらなくても良くなってしまいました。

G-HAL 氏には、私のヘマなのに修正までして頂いて、本当にありがとうございます m(_ _)m
プログラム部分を自分でいじらなくても良くなったというのは、本当に助かりました。

【お試し版】 自作 depgraph 更新(2/23) - 追記

更新しました。

使い方は中の README を見てください。
他に anthy-9100h のソースが必要です。

【変更点】
・depgraph を更新
・ターゲットを anthy-9100h に
・G-HAL 氏の patch を anthy-9100h.patch13ptn20(2/21版)に
・depgraph/Makefile.am, mkdepword がソースと異なるディレクトリでのビルドに対応していなかったのを修正(Thanks 匿名希望さん)
・corpus の例文及び辞書を若干調整(試行錯誤中)

注意: G-HAL 氏のパッチを使わせて頂いてますので、学習データの変換が必要になる場合があります。

オリジナルの Anthy もしくは patch1〜patch13ptn17 までの Anthy から patch13ptn18以降に移行する場合

とのことなので、ほとんどの人が該当するかと思います。
詳しくはこちらで確認して下さい(patch13 のところです)。

また、patch13 では「ビタビモード」と「n文節最長一致モード」とを設定で切り替えられますが、「ビタビモード」(デフォルトです)で使って下さい。「n文節最長一致モード」での確認はしていません。

【追記】2/26
G-HAL 氏のサイトを見て気づきましたが、ソースディレクトリとは別ディレクトリでビルドすると、ビルド自体は通りますが、depgraph/anthy.dep が正しく作成されず、従って anthy.dic もおかしくなるというバグがあります。別ディレクトリでビルドする場合は、G-HAL 氏のサイトから anthy-9100h.patch13ptn20.bz2 (Wed,25 Feb,2009版かそれ以降) と anthy-9100h.patch13ptn20.2009225.alt-depgraph-090223.diff.tar.bz2 (Wed,25 Feb,2009版かそれ以降) を落としてきて差し替えて下さい。

1. anthy-9100h.patch13ptn20-20090221.bz2 を削除
2. apply_patches.sh をエディタで開いて anthy-9100h.patch13ptn20-20090221.bz2 を anthy-9100h.patch13ptn20.bz2 に修正
3. apply_patches.sh を実行してパッチ当て
4. depgraph/Makefile.{am,in} へのパッチ当てに失敗するので、depgraph/Makefile.{am,in} を anthy-9100h.patch13ptn20.2009225.alt-depgraph-090223.diff.tar.bz2 のもので上書き
　$ cp depgraph/Makefile.{am,in} anthy-9100h/depgraph/
　$ rm anthy-9100h/depgraph/Makefile.{am,in}.*
　※ 「cp」コマンド(「-p」不可)でコピーして下さい。konquerer 等でコピーするとタイムスタンプを古いままにしてしまい、そのせいで ./libtool とか automake が実行され、挙句にエラーでこけます(Linux 環境)。

ソースディレクトリでそのままビルドする場合は問題ありません。

先に、次の cannadic改を出したいので、修正版はその後で出します。
ご迷惑をお掛けして申し訳ありません m(_ _)m

【お試し版】 自作 depgraph 更新

更新しました。
が、まだまだ試行錯誤中です。一応それなりには使えると思いますが、期待外れでも文句は言わないと約束できる方だけお試し下さい(脅かしすぎかな…。誤りやおかしなところの指摘は歓迎です)。

【変更点】
・depgraph を更新
・ターゲットを anthy-9100g に
・G-HAL 氏のパッチをパッケージに含めた(更新されると古いのは落とせなくなっちゃうので)
・corpus の例文を自作 depgraph に合わせて修正及び例文追加
・例文で使われている語で辞書にあるべきと思ったものを辞書に追加
・mkworddic/compound.t は外してたのを戻してみた

使い方は中の README を見てください。
他に anthy-9100g のソースが必要です。

注意: G-HAL 氏のパッチを使わせて頂いてますので、学習データの変換が必要になる場合があります。詳しくはこちらで確認して下さい(patch13 のところです)。

また、patch13 では「ビタビモード」と「n文節最長一致モード」とを切り替えられますが、「ビタビモード」(デフォルトです)で使って下さい。「n文節最長一致モード」での確認はしていません。


一応これで depgraph は一区切りにして、今は辞書のランク付け直し作業の方に戻ってます。今月末に出したいとは思ってますが…。

続きを読む

anthy-9100g - yomi hash の collision

辞書のビルドのところ見てて気になったんですが、

Total 436461 indexes, 607321 words, (6820 pages).
generated yomi hash bitmap (42387 collisions/436461 entries)

んー、9100e の頃と比べると倍増に近い気が…。

compound.t に大量に追加されたからかな。gcanna.ctd とかぶってるものが多い?

hash の collision て、「衝突したら空いてるところに入れるから別に出せなくなったりするわけじゃない、でもパフォーマンスはちょっと落ちる」って感じでしたっけ? よく知らない…。どのくらいまで大丈夫なんだろうか?

リリースラッシュ

ようやく一時(?)解放。週末は時間が取れる。でも、来週前半はまた何かありそうな気配…。
色々ストレスが溜まりまくってますが、仕事の愚痴はここには書かない。


ともあれ、今月は日本語入力関連のリリースラッシュでしたね。

続きを読む

ブログ更新してる余裕がない

だが、これだけは書いておきたい。


UTF-8 対応 scim-anthy ｸﾙ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

自分メモ

辞書や depgraph をいじり続ける意味があるのか考えるためのメモ。

続きを読む