最近の（でもないけれど）出来事／落書帳／仲間内のネタ／覚え書き／whatsnew

Anthy、 OpenBSD, FreeBSD / Phenom, Core-i5 で マルチスレッド／マルチコアの双方向探索に対応。
Sat,17 Sep,2011、 Tue,27 Sep,2011、 の続き。
マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に関連。

追記 Sun,02 Oct,2011：
ダイクストラ法の双方向探索の実装に呆れるぐらい単純なポカミスがあって、 双方向探索になっていませんでした。
と言う訳で、Sat,01 Oct,2011 の測定結果は削除します。

Tue,04 Oct,2011、 Wed,05 Oct,2011、 Sat,08 Oct,2011、 に続く。

Anthy、 OpenBSD, FreeBSD / Phenom, Core-i5 で マルチスレッド／マルチコアの双方向探索に対応。
Sat,17 Sep,2011、 Tue,27 Sep,2011、 Sat,01 Oct,2011、 の続き。
マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に関連。

開発中版のマルチスレッド／マルチプロセス対応完了版。
まだ実地試験を行っていません（Tue,04 Oct,2011 現在）。
（開発中版更新に付き削除）
バグが無ければ、これにて、 「文節数最小 ダイクストラ」、 「MBR ダイクストラ」、 「マルチスレッド／マルチプロセス対応」、 の開発を終了とします。   ソースレポジトリへのコミット作業は追いついていません。 やる気も尽きてます。

学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。
OpenBSD 4.8-RELEASE/amd64，Phenom 2.0GHz ４コア。

かな漢字変換ソフトの変換結果ベンチマークテスト：シングルプロセスシングルスレッド／シングルプロセスマルチスレッド／マルチプロセスシングルスレッド

系列	モード	変換所要時間	うち文節区切り所要時間	うち変換候補一覧生成所要時間
試験版	MBRビタビ(HID_IDI_IwDT)	4.42 [秒]	3.03 [秒]	0.114 [秒]
試験版	前方３文節最長一致	1.24 [秒]	0.0583[秒]	0.0868[秒]
開発中版	文節数最小 ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	1.34 [秒]	0.0230[秒]	0.106 [秒]
開発中版	文節数最小 ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し	1.34 [秒]	0.0226[秒]	0.106 [秒]
開発中版	文節数最小 ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り	1.43 [秒]	0.0341[秒]	0.116 [秒]
開発中版	文節数最小 ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り	1.44 [秒]	0.0353[秒]	0.118 [秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	1.44 [秒]	0.0388[秒]	0.120 [秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作(Wed,05 Oct,2011 改訂版)	1.43 [秒]	0.0361[秒]	0.117 [秒]
開発中版	文節数最小 ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り	1.73 [秒]	0.269 [秒]	0.110 [秒]
開発中版	文節数最小 ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り	1.71 [秒]	0.260 [秒]	0.108 [秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	1.97 [秒]	0.505 [秒]	0.110 [秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作(Wed,05 Oct,2011 改訂版)	1.97 [秒]	0.505 [秒]	0.110 [秒]
開発中版	MBR ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	4.29 [秒]	2.87 [秒]	0.125 [秒]
開発中版	MBR ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し	4.57 [秒]	3.15 [秒]	0.124 [秒]
開発中版	MBR ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り	4.61 [秒]	3.13 [秒]	0.134 [秒]
開発中版	MBR ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り	4.91 [秒]	3.44 [秒]	0.133 [秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	5.03 [秒]	3.52 [秒]	0.138 [秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作(Wed,05 Oct,2011 改訂版)	4.02 [秒]	2.54 [秒]	0.134 [秒]
開発中版	MBR ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り	5.16 [秒]	3.60 [秒]	0.129 [秒]
開発中版	MBR ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り	5.43 [秒]	3.88 [秒]	0.127 [秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	5.62 [秒]	4.07 [秒]	0.125 [秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作(Wed,05 Oct,2011 改訂版)	5.70 [秒]	4.12 [秒]	0.129 [秒]

備考：
「文節区切り探索時にスレッド制御有り」は、 シングルプロセスシングルスレッドで動作し、 セマフォ等の制御のみ行う。
「文節区切り探索時にプロセス制御有り」は、 シングルプロセスシングルスレッドで動作し、 共有メモリとセマフォ等の制御のみ行う。

評価：
文節数最小のスレッド有りにて、 片方向１スレッドでも双方向２スレッドでも、 結果がほとんど変わらない（OpenBSD の pthread なので、 片方向１スレッドも双方向２スレッドも１コアで実行されている筈）。   これは、双方向探索において、双方向探索が有効に機能して １スレッド当たりの探索領域が半減した為と思われる。
文節数最小のプロセス有りの結果は、 並列実行度が想定より遥かに低い事を示しているのだろうか？   あるいは、探索本体の処理時間は非常に軽量で測定結果には現れず、 双方向２プロセスのプロセス制御の量が 片方向１プロセスのプロセス制御の量の２倍になった、 と言う点のみが測定結果に出ているのだろうか？   スレッド／プロセスの制御無しの結果や、 スレッド制御有りの結果と比べてみると、 どうやら後者の「測定結果にはプロセス制御の量だけが表れている」の方が 有力そうだ。
MBR ダイクストラの スレッド制御有り片方向１スレッド／双方向２スレッドの結果を見ると （OpenBSD の pthread なので、 片方向１スレッドも双方向２スレッドも１コアで実行されている筈）、 文節数最小と同様に、双方向探索において、双方向探索が有効に機能して １スレッド当たりの探索領域が半減した為と思われる。
MBR ダイクストラのプロセス制御有り片方向／双方向、の結果と、 スレッド制御有り双方向の結果を比べると、 双方向マルチプロセス動作にて２コア稼働が有効に行われていないか、 プロセス制御の負荷が重いか、 どちらかと思われる。

結論：
OpenBSD においては、文節数最小でも、MBR ダイクストラでも、 スレッド制御やプロセス制御が重荷になっていて、 スレッド制御とプロセス制御を無くしたシングルコア動作の方が 高速な事がわかる。
Wed,05 Oct,2011 追記：
ダイクストラ法の枝刈りをチューニングした結果、 「MBR ダイクストラ」の「双方向２スレッド」にて 「１プロセス１スレッド，スレッド制御無し」の 処理速度を上回りました。
原作の「MBR ビタビ」と比べても 10％高速となりました。

FreeBSD 9.0-BETA3/amd64，Core i5 ２コア４スレッド 2.4GHz。

かな漢字変換ソフトの変換結果ベンチマークテスト：シングルプロセスシングルスレッド／シングルプロセスマルチスレッド／マルチプロセスシングルスレッド

系列	モード	変換所要時間	うち文節区切り所要時間	うち変換候補一覧生成所要時間
試験版	MBRビタビ(HID_IDI_IwDT)	2.00 [秒]	1.15 [秒]	0.0510[秒]
試験版	前方３文節最長一致	0.81 [秒]	0.0225[秒]	0.0414[秒]
開発中版	文節数最小 ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	0.85 [秒]	0.0156[秒]	0.0475[秒]
開発中版	文節数最小 ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し	0.84 [秒]	0.0134[秒]	0.0447[秒]
開発中版	文節数最小 ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り	0.88 [秒]	0.0557[秒]	0.0452[秒]
開発中版	文節数最小 ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り	0.87 [秒]	0.0458[秒]	0.0465[秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	0.87 [秒]	0.0570[秒]	0.0450[秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作(Wed,05 Oct,2011 改訂版)	0.87 [秒]	0.0652[秒]	0.0474[秒]
開発中版	文節数最小 ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り	1.56 [秒]	0.229 [秒]	0.0646[秒]
開発中版	文節数最小 ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り	1.57 [秒]	0.243 [秒]	0.0647[秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	1.69 [秒]	0.370 [秒]	0.0664[秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作(Wed,05 Oct,2011 改訂版)	1.66 [秒]	0.334 [秒]	0.0642[秒]
開発中版	MBR ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	1.91 [秒]	1.04 [秒]	0.0518[秒]
開発中版	MBR ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し	2.01 [秒]	1.15 [秒]	0.0592[秒]
開発中版	MBR ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り	2.54 [秒]	1.45 [秒]	0.0621[秒]
開発中版	MBR ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り	2.73 [秒]	1.62 [秒]	0.0622[秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	2.29 [秒]	1.17 [秒]	0.0663[秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作(Wed,05 Oct,2011 改訂版)	1.72 [秒]	0.644 [秒]	0.0641[秒]
開発中版	MBR ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り	3.26 [秒]	1.69 [秒]	0.0883[秒]
開発中版	MBR ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り	3.42 [秒]	1.84 [秒]	0.0920[秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	3.40 [秒]	1.87 [秒]	0.0801[秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作(Wed,05 Oct,2011 改訂版)	3.27 [秒]	1.83 [秒]	0.0824[秒]

備考：
「文節区切り探索時にスレッド制御有り」は、 シングルプロセスシングルスレッドで動作し、 セマフォ等の制御のみ行う。
「文節区切り探索時にプロセス制御有り」は、 シングルプロセスシングルスレッドで動作し、 共有メモリとセマフォ等の制御のみ行う。

評価：
Phenom な OpenBSD と、ほとんど同じ。
結論：
スレッド制御やプロセス制御が重くて、 2-core 4-HyperThreading 動作をしても、 かえって遅くなるらしい。   ただ、HyperThreading のパイプラインが詰まって 遅くなっている可能性も否定できず。   HyperThreading の無い CPU にて動作させると、 変わらないか、良い方に転ぶか、その辺りは不明。 手元に無いので試せません。
Wed,05 Oct,2011 追記：
ダイクストラ法の枝刈りをチューニングした結果、 「MBR ダイクストラ」の「双方向２スレッド」にて 「１プロセス１スレッド，スレッド制御無し」の 処理速度を上回りました。
原作の「MBR ビタビ」と比べても 15％高速となりました。

Wed,05 Oct,2011、 Sat,08 Oct,2011、 に続く。

Anthy、 OpenBSD, FreeBSD / Phenom, Core-i5 で マルチスレッド／マルチコアの双方向探索に対応。
Sat,17 Sep,2011、 Tue,27 Sep,2011、 Sat,01 Oct,2011、 Tue,04 Oct,2011、 の続き。
マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に関連。

開発中版のマルチスレッド／マルチプロセス対応完了版、 ダイクストラの双方向探索のチューニング(Wed,05 Oct,2011)版。
まだ実地試験を行っていません（Wed,05 Oct,2011 現在）。
現在、もうちょっと高速化できないか調整中（Wed,05 Oct,2011 現在）。
（開発中版更新に付き削除）

ソースレポジトリへのコミット作業は追いついていません。 やる気も尽きてます。

Sat,08 Oct,2011、 に続く。

Anthy 開発中版、 Sat,17 Sep,2011、 Tue,27 Sep,2011、 Sat,01 Oct,2011、 Tue,04 Oct,2011、 Wed,05 Oct,2011、 の続き。

もうちょっと高速化できないか版。
まぁ単純に、幾つかの関数をマクロ化しただけですが。
インライン化だと何故か、

../../anthy/wtype.h:312: sorry, unimplemented: inlining failed in call to 'anthy_wtype_include': function not considered for inlining
../../src-worddic/word_dic.c:684: sorry, unimplemented: called from here

MBR_DIJKSTRA_MODE               true
DIJKSTRA_MODE_LEFT_TO_RIGHT     true
DIJKSTRA_MODE_RIGHT_TO_LEFT     true
ENABLE_PTHREAD                  true

学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。
面倒になったので要所のみ計測。

OpenBSD 4.8-RELEASE/amd64，Phenom 2.0GHz ４コア。

かな漢字変換ソフトの変換結果ベンチマークテスト

系列	モード	文節区切りの誤答数	文節区切り正答中の第１変換候補誤答数	合計誤答数	合計正答率	変換所要時間	うち文節区切り所要時間	うち変換候補一覧生成所要時間
原作版	anthy-9100h(sourceforge.jp版)	26	16	42	58％	1.27 [秒]
試験版	MBRビタビ(HID_IDI_IwDT)	14	25	39	61％	4.28 [秒]	2.93 [秒]	0.112 [秒]
試験版	前方３文節最長一致	35	19	54	46％	1.23 [秒]	0.0571[秒]	0.0868[秒]
開発中版	文節数最小 ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	40	15	45	55％	1.32 [秒]	0.0224[秒]	0.104 [秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	40	15	45	55％	1.42 [秒]	0.0362[秒]	0.117 [秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	40	15	45	55％	1.94 [秒]	0.500 [秒]	0.108 [秒]
開発中版	MBR ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	14	25	39	61％	4.10 [秒]	2.71 [秒]	0.120 [秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	14	25	39	61％	3.88 [秒]	2.41 [秒]	0.133 [秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	14	25	39	61％	5.40 [秒]	3.86 [秒]	0.123 [秒]
試験版	MBRビタビ(HID_IDI_IwDT)（用例辞書無効）					1.60 [秒]	0.333 [秒]	0.0975[秒]
試験版	前方３文節最長一致（用例辞書無効）					1.12 [秒]	0.0317[秒]	0.0678[秒]
開発中版	文節数最小 ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し（用例辞書無効）					1.20 [秒]	0.0223[秒]	0.0796[秒]
開発中版	MBR ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し（用例辞書無効）					1.63 [秒]	0.319 [秒]	0.106 [秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作（用例辞書無効）					1.80 [秒]	0.405 [秒]	0.117 [秒]

備考：
「文節区切り探索時にスレッド制御有り」は、 シングルプロセスシングルスレッドで動作し、 セマフォ等の制御のみ行う。
「文節区切り探索時にプロセス制御有り」は、 シングルプロセスシングルスレッドで動作し、 共有メモリとセマフォ等の制御のみ行う。

vagus氏の alt-depgraph や alt-cannadic による変換結果改善や、 学習強化以外にも色々機能を追加・強化しましたが、その結果は、 原作版 anthy-9100h(sourceforge.jp版) の変換結果と、 試験版 MBRビタビ・ダイクストラの変換結果を、 比べての通りです。   ３％の改善が、大きいのか小さいのか。 その辺はよく判りませんが。 変換所要時間が３倍（MBRダイクストラ２コアモード）に なっている事だけははっきりしている訳で。

FreeBSD 9.0-BETA3/amd64，Core i5 ２コア４スレッド 2.4GHz。

かな漢字変換ソフトの変換結果ベンチマークテスト：シングルプロセスシングルスレッド／シングルプロセスマルチスレッド／マルチプロセスシングルスレッド

系列	モード	変換所要時間	うち文節区切り所要時間	うち変換候補一覧生成所要時間
試験版	MBRビタビ(HID_IDI_IwDT)	1.78 [秒]	0.990 [秒]	0.0444[秒]
試験版	前方３文節最長一致	0.74 [秒]	0.0212[秒]	0.0397[秒]
開発中版	文節数最小 ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	0.80 [秒]	0.0164[秒]	0.0529[秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	0.82 [秒]	0.0606[秒]	0.0437[秒]
開発中版	文節数最小 ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	1.66 [秒]	0.377 [秒]	0.0652[秒]
開発中版	MBR ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し	1.69 [秒]	0.890 [秒]	0.0499[秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチスレッド動作	1.64 [秒]	0.644 [秒]	0.0577[秒]
開発中版	MBR ダイクストラ 双方向，文節区切り探索時にマルチプロセス動作	3.18 [秒]	1.76 [秒]	0.0738[秒]

備考：
「文節区切り探索時にスレッド制御有り」は、 シングルプロセスシングルスレッドで動作し、 セマフォ等の制御のみ行う。
「文節区切り探索時にプロセス制御有り」は、 シングルプロセスシングルスレッドで動作し、 共有メモリとセマフォ等の制御のみ行う。

それでもまだ、PentiumD 3.2GHz(シングルコア) にて sj3, FreeWnn, Canna を動かした時よりも、 １桁半(sj3)〜３倍(FreeWnn, Canna) 程度、遅いんですよね……。
PentiumD 3.2GHz がクロック５割増しである事を考えて換算しても、 20倍(sj3)〜２倍(FreeWnn, Canna) 程度、遅いんですよね……。

Sun,16 Oct,2011、 に続く。

Anthy 開発中版、 Sat,17 Sep,2011、 Tue,27 Sep,2011、 Sat,01 Oct,2011、 Tue,04 Oct,2011、 Wed,05 Oct,2011、 Sat,08 Oct,2011、 の続き。

同梱辞書が間違えて 2010年版になっていたので、2011年版に訂正。
試験版から開発中版に分岐した後に、 試験版に加えた変更を開発中版にフィードフォワードするのを 忘れていたので修正。
（試験版更新に付き削除）(4945KiB)

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

安定版更新（と言うより公開準備済みだった物を公開）：(release.2011X20 版)
• autoconf & automake を全面的に導入。
• プロトタイプ宣言を全面改訂。
• 発動しないバグを修正（変数の型間違い、後処理の抜け、メモリリーク、OS依存処理、など）。
• 前リビジョンより２割前後高速化。
• configure にて --enable-benchmark オプションを追加。 各処理の時間計測機能を実装。
• 用例辞書を更新。

• 文節数最小法。
• MBRダイクストラ法。
• MBRダイクストラ法の双方向２スレッド実行による高速化。
• [実験版でも未実装] ブートストラップ学習データの自動読み込み。

↑ Sat,19 Nov,2011 追記：
相性問題が見つかったので更新しました。
→ Sat,19 Nov,2011

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

試験版更新：
• autoconf & automake を全面的に導入。
• プロトタイプ宣言を全面改訂。
• 発動しないバグを修正（変数の型間違い、後処理の抜け、メモリリーク、OS依存処理、など）。
• 前リビジョンより２割前後高速化。
• configure にて --enable-benchmark オプションを追加。 各処理の時間計測機能を実装。
• 用例辞書を更新。
• configure にて --disable-pthread オプションを追加。 pthreadを使用しない様に変更できる様にした。
• 文節数最小法を実装。
• MBRダイクストラ法を実装。標準設定をMBRダイクストラ法に変更。
• MBRダイクストラ法の双方向２スレッド実行による高速化。

• ［作業中］｛作業数日の見込み｝ブートストラップ学習データの生成。
• ［検討中］ブートストラップ学習データの自動読み込み。

Mon,14 Nov,2011 追記：
OS によってはコンパイルが通らないバグが見つかりました。 修正中。   OpenBSD だとコンパイル通って正常動作するんですがね。

Tue,15 Nov,2011 追記：
修正完了。

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

試験版更新：
• autoconf & automake を全面的に導入。
• プロトタイプ宣言を全面改訂。
• 発動しないバグを修正（変数の型間違い、後処理の抜け、メモリリーク、OS依存処理、など）。
• 前リビジョンより２割前後高速化。
• configure にて --enable-benchmark オプションを追加。 各処理の時間計測機能を実装。
• 用例辞書を更新。
• configure にて --disable-pthread オプションを追加。 pthreadを使用しない様に変更できる様にした。
• 文節数最小法を実装。
• MBRダイクストラ法を実装。標準設定をMBRダイクストラ法に変更。
• MBRダイクストラ法の双方向２スレッド実行による高速化。
• ブートストラップ学習データの生成。

• ［検討中］ブートストラップ学習データの自動読み込み。

• ［未着手］英単語の文節に付属語を付ける。
• ［未着手］所謂半角と全角の正規化。
• ［未着手］「100-0014」→「|東京都千代田区永田町|」

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

安定版更新：
• autoconf & automake を全面的に導入。
• プロトタイプ宣言を全面改訂。
• 発動しないバグを修正（変数の型間違い、後処理の抜け、メモリリーク、OS依存処理、など）。
• 前リビジョンより２割前後高速化。
• configure にて --enable-benchmark オプションを追加。 各処理の時間計測機能を実装。
• 用例辞書を更新。
• GNU/Linux でビルドできない問題を修正。

↑ Tue,22 Nov,2011 追記：
エンバグらしき物が見つかったので延期になる見込みです。
→ Tue,22 Nov,2011

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

試験版更新（Sat,19 Nov,2011 の４）：
• autoconf & automake を全面的に導入。
• プロトタイプ宣言を全面改訂。
• 発動しないバグを修正（変数の型間違い、後処理の抜け、メモリリーク、OS依存処理、など）。
• 前リビジョンより２割前後高速化。
• configure にて --enable-benchmark オプションを追加。 各処理の時間計測機能を実装。
• 用例辞書を更新。
• configure にて --disable-pthread オプションを追加。 pthreadを使用しない様に変更できる様にした。
• 文節数最小法を実装。
• MBRダイクストラ法を実装。標準設定をMBRダイクストラ法に変更。
• MBRダイクストラ法の双方向２スレッド実行による高速化。
• ブートストラップ学習データの生成。
• GNU/Linux でビルドできない問題を修正。

「MBR-ダイクストラ法の両方向探索」にバグが見つかりました。 MBR-ダイクストラ法の両方向探索を使用しないで下さい。 標準設定では「MBR-ダイクストラ法の片方向探索」になっています。
r833 でのエンバグだと言う所までは判っているんですがね。
「Sat,19 Nov,2011 の４」にて、エンバグ修正完了。

↑ Tue,22 Nov,2011 追記：
エンバグらしき物が見つかったので修正が入る見込みです。
→ Tue,22 Nov,2011

今回の Anthy 拙作パッチ更新の経緯。
ふと、思いたって Debian GNU/Linux でビルドしてみた （Debian のバージョン忘れた。どうやって確認するのだっけ？）。   ../configure が通らない orz
まず、htons() の存在チェックにて、

/usr/include/sys/types.h:72: error: two or more data types in declaration specifiers

とか言ってくる。 該当行を見てみると、mode_t が多重定義になっているらしい。 でも /usr/include/sys/* を見てみると、 #ifndef __mode_t_defined でロックしてある。   config.log の情報では足らないので、 手動で conftest.c を切り出してコンパイルしてみる。 autoconf側で #define mode_t int していた。   configure.ac と configure と照らし合わせてみると、

/usr/include/bits/stat.h:103: error: expected identifier or '(' before '[' token

とか言って、AC_TYPE_MODE_T にて判定を間違っていた。 どうやら

#if __WORDSIZE == 64
long int __unused[3];
#else

でコケているらしい。 GNU/Linux/i386 だと正常に判定され、 GNU/Linux/amd64 でだけエラーになるのね。   さて、なんで __unused が無いんだ？ /usr/include/bits/stat.h で __unused を使うなら、 /usr/include/bits/stat.h で __unused を定義しているヘッダファイルを 読み込むのが筋ってものだと思うが。

↑原因に気付いた。
*BSD には __unused と言うマクロが存在するのだが、 Linux にはそんなマクロは存在しないらしい。 その為、 Linux では「使っていない変数」の名称に __unused を使っており、 *BSD の __unused を前提にした書き方だと Linux でコンパイルが通らないらしい。   蛇足： カーネルがらみなので GNU/Linux ではなく Linux。
attribute __unused__ がらみを全部書き直さないと駄目か……。

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

試験版更新（Tue,22 Nov,2011 の４）：
• GNU/Linux でビルドできない問題を修正。
• エンバグらしき物の暫定修正。
  候補一覧のスコアリングが変な気がしたので調整。

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

安定版更新：
試験版更新：
• 今回の一連の作業におけるエンバグを修正。

Anthy 拙作パッチ。
ブートストラップ用の学習データを自分の所に組み込んでテスト中。
ただ、自前で学習したデータが４年２ヶ月分有って、 ブートストラップ用学習データはその半分の量だった。 文体も私とは合わないし、あまり効果無いかも。
自前の学習データが無い人にはそこそこ効くかもしれないけれど。

Anthy の変換の癖：「がいしゃ」：かな漢字変換の変換判定。
「|××|会社|」（|××|がいしゃ|）を変換しようとすると、 「|××が|医者|」（|××が|いしゃ|）になる癖が有る…… たぶん。
これは 「文節数が同じならば、より左側の文節が長い方が優先される」 というヒューリスティックのせいなのだけれども。   ……。   前方ｎ文節最長一致は、 そもそもこのヒューリスティックを使って変換を行っているし、 それ以外のアルゴリズムでも、評価が同じで選ぶのに困った時は 最後にこのヒューリスティックを使う事が少なくないと思う。 思うだけ。裏付けは取っていない。   この１例だけを挙げてみても、 「|××|会社|」（|××|がいしゃ|）を全部、 複合語登録するのは困難で暴挙だし。 今すぐにはこの１例しか思い浮かばないけれど、 他の文章でもありえるし反例も有るからから対処法が無くて困る。   読み仮名ベースあるいは漢字表記付きの 単語Ｎグラム方式とか文節Ｎグラム方式とかの 確率データベースを使う方式なら、 「|××|会社|」（|××|がいしゃ|）となる例文を データベースに突っ込めば、後はテキトーに何とかなるかも知れないが。 何とかならないかもしれないけれど。 Anthy で実装している 品詞ベース文節２グラム(?) だと、データベースでは品詞だけを持っていて、 単語の字句や意味は持っていないから、 例文を突っ込んでもどうにもならないんだよね。 かといって品詞……じゃなくて意味の分類を持たせると、 「分類を増やしたのに対応する分だけ例文も増やさないと いけないだろうけれどそれってどうやって用意するの？」とか、 「それって単語Ｎグラム(KAGAMI)や mozc と何が違うの？」と言う事態に （同じならわざわざ改造せんでも乗り換えりゃいい）。
で、困った挙句、 「変則文節２グラム （確率(頻度)が 0 と 1 しかないからＮグラムじゃないかも）の 生の例文を保持してしまえ、足りなきゃ例文を追加だ」 と言う暴挙に出たのが ブートストラップ学習データ方式だったりします ｛変則文節と言ったのは、 「(自立語 + 付属語) + (自立語)」形式で 保持している為、 単語では無いし（自立語や付属語が長くなると３単語以上になる事も有る）、 文節でも無いし（２文節目の付属語が無い）｝。   一応完成したのだけれども。 ブートストラップ学習データを読み込むのに Phenom 2GHz とか Core-i5 2.5GHz をもってしても （データ読み込みはシングルタスクなので マルチコア／マルチスレッド／マルチモジュールは効果有りません） 秒オーダーの時間がかかってしまい遅い。   あと、個人的な感想だと、 『「変則文節２グラムの生の例文」 を大量に持ってりゃ 「品詞ベース文節２グラム(?)」 いらないじゃん』、 とか言う、Anthy の全てを覆す様な印象も持っていたり。 『「変則文節２グラムの生の例文」 ＋ 「前方ｎ文節最長一致」』 でも、人によってはそれなりに使えるかもね。   まぁ、MBR ダイクストラや MBR ビタビなら、 「変則文節２グラムの生の例文」 に無い文章を変換した時に、 「品詞ベース文節２グラム(?)」 が役に立つ筈なのですけれども、 はてさてどの程度有効に機能しているのやら。

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

試験版更新（Sun,11 Dec,2011）：
• 起動時に必要ならブートストラップ学習データを読み込む様にした。
• 環境設定に ENABLE_BOOTSTRAP_RECORD 追加。
  自分で学習データを貯めている方は、 false にしてブートストラップ学習データを無効にした方が、 学習データの無駄が無くて良いと思います。
• ブートストラップ学習データ導入に合わせて、環境設定の初期パラメータを変更。
  個人用設定ファイルで学習データ量の設定を変更している場合、 設定によってはブートストラップ学習データが削除される場合があります。
• Doxygen用コメントの一斉修正。
• BENCHMARK に基本レコード（バイナリ）の読込時間を追加。
• 学習データの基本レコード（バイナリ形式）読込を mmap にした。
  学習データの基本レコード（バイナリ形式）読込が４％程度高速化。
• コーパス例文に追加。
  コーパス例文に追加に伴い、コーパス確率データベース更新。
  コーパス例文に追加に伴い、ブートストラップ学習データ更新。

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

試験版更新：
• Unicode 5.2 および 6.0以降の、 「CJK統合漢字拡張漢字C集合」，「CJK統合漢字拡張漢字D集合」に対応。 でも何に影響が有るのかは不明。
• 変換入力（読み仮名の入力）の正規化に対応。
• 単語辞書生成 （テキスト辞書 *.ctd , *.t からバイナリ辞書 anthy.dic への変換）の 正規化に対応。
• 個人用単語辞書読み出し（ $(HOME)/.anthy/private_words_default , $(HOME)/.anthy/imported_words_default , $(HOME)/.anthy/imported_words_default.d/* ）の 正規化に対応。
• 変換出力に正規化前を追加。

正規化のルール
• 数字：
  ASCII数字／所謂全角数字を、 ASCII数字に変換する。
• 記号：
  変換しない。
• アルファベット：
  ASCII小文字／ASCII大文字／所謂全角小文字／所謂全角大文字を、 ASCII大文字に変換する。
• ひらがな／カタカナ：
  所謂全角ひらがな／所謂全角カタカナを、 所謂全角ひらがなに変換する。

例１）
・「０1２３45」を入力すると。
→辞書の検索は「012345」で行なう。
→辞書に該当が有る場合、
  第１候補〜に辞書の内容を、
  最終候補前ぐらいに「０1２３45」を提示する。
→辞書に該当が無い場合、
  第１候補に「０1２３45」を提示する。

例２）
・「ａＢcD」を入力すると。
→辞書の検索は「ABCD」で行なう。
→辞書に該当が有る場合、
  第１候補〜に辞書の内容を、
  最終候補前ぐらいに「ａＢcD」を提示する。
→辞書に該当が無い場合、
  第１候補に「ａＢcD」を提示する。

例３）
・「あイうエお」を入力すると。
→辞書の検索は「あいうえお」で行なう。
→辞書に該当が有る場合、
  第１候補〜に辞書の内容を、
  最終候補前ぐらいに「あイうエお」を提示する。
→辞書に該当が無い場合、
  第１候補に「あイうエお」を提示する。
備考：「あいうえお」は単語辞書に登録されているので実際に行なう場合は注意。

例４）
・単語辞書（テキスト形式）に「さシａＢ０1 #T35*100 ＴＥＳＴ１」を登録すると。
→単語辞書（バイナリ形式）には、
  読み仮名：「さしAB01」，
  品詞等：「#T35*100」，
  かな漢字変換後の単語：「ＴＥＳＴ１」，
  が登録される。
備考：かな漢字変換後の単語は正規化されません。

例５）
・個人用単語辞書に「たチＣｄ2３ #T35*100 ＴＥＳＴ２」を登録すると。
→単語辞書（バイナリ形式）には、
  読み仮名：「たちCD23」，
  品詞等：「#T35*100」，
  かな漢字変換後の単語：「ＴＥＳＴ２」，
  が登録される。
備考：かな漢字変換後の単語は正規化されません。


以下、昔の覚え書き。

http://vagus.seesaa.net/article/147195627.html
2010年04月21日 - かな英字交じり文を一度に変換する方法のまとめ【追記】4/22
http://vagus.seesaa.net/article/147598915.html
2010年04月25日 - 全角/半角の違いを誰が吸収すべきか問題【追記】4/27,5/4
・ひらがな／カタカナの正規化はどうするのか。
→ ひらがなに揃えるのか、カタカナにそろえるのか。所謂半角に揃えるのか全角に揃えるのか全角半角を区別するのか。「う゛」と「ヴ」はどうするか。
→→ ええと、ひらがな全角が妥当？
・アルファベットの正規化はどうするのか。
→ 全部大文字なり小文字なりに揃えるのか、大文字小文字を区別するのか。所謂半角に揃えるのか全角に揃えるのか全角半角を区別するのか。
→→ 次項の英単語の件を考えると、大文字・小文字／全角・半角、問わず、ASCII 半角小文字に揃える。
・数値の正規化はどうするのか。
→ 所謂半角に揃えるのか全角に揃えるのか全角半角を区別するのか。
→→ 次々項の郵便番号の件を考えると、ASCII 半角に揃える。
・記号類の正規化はどうするのか。
→ 所謂半角に揃えるのか全角に揃えるのか全角半角を区別するのか。
→→ 次々項の郵便番号の件を考えると、ASCII 半角に揃える……のが妥当なのだけれども、フラグだけ立てて全角半角は元のままが良いか？

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」

試験版更新：
これにて、 『 辞書由来の単語に対して、 「全角に設定しているユーザには全角の候補を、 半角に設定しているユーザには半角の候補を優先して出す」 』 の件を除き、 当面（何か案が出てこない限り）、 バグ取りのみの保守モードに入る予定。
• アルファベットを変換した際に #T00 の候補を生成。
  「alphabetとか」を変換すると、 今までは 「|alphabet|とか|」と文節を切られていましたが、 新しく 「|alphabetとか|」と文節を切らない候補が出る様になりました。
  個人的には、 アルファベット入力時には無変換モードにする為、 今回の機能は使わないので、 バグ出しは私はできません。
• 環境設定にて、 ３桁及び７桁数字の 郵便番号辞書検索を切れる様にした。
• 000-0000 形式の郵便番号を変換した際に、 #CNS の候補を生成。
  今までは郵便番号辞書を検索する際には 「0010010」とか「００１００１０」とか入力して変換していましたが、 新しく 「001-0010」や「００１ー００１０」にて 郵便番号辞書の検索が出来る様になりました。
  デフォルトでは、 ３桁及び７桁数字の郵便番号辞書検索は無効に、 000-0000 形式の郵便番号辞書検索は有効に、 なっています。
  環境設定ファイルの、 ENABLE_ZIPCODE_3 , ENABLE_ZIPCODE_7 , ENABLE_ZIPCODE_34 , にて変更できます。
  個人的には、 郵便番号辞書検索機能は使わない （全部無効にして zipcode.txt をテキストビューワーで直接閲覧している） ので、 バグ出しは私はできません。

以下、昔の覚え書き。

http://vagus.seesaa.net/article/147195627.html
2010年04月21日 - かな英字交じり文を一度に変換する方法のまとめ【追記】4/22
・英単語をどう抽出するのか。英単語の自立語にどう付属語を付けるのか。
→ 連続するアルファベットを英単語と見做す。付属語は、新しい品詞を強引に紐付ける。
→→ 前項の正規化の際にアルファベットフラグを付ける。wordlist生成の際に、品詞を紐付ける。
→→→ 辞書に該当しない場合、大文字・小文字／全角・半角を原文ママにした候補が第１候補。

http://vagus.seesaa.net/article/147595521.html
数字に続くハイフンの入力【追記】4/25,4/27,5/4
「100-0014」→「|東京都千代田区永田町|」
→ いっそ、郵便番号専用辞書検索をやめて、通常辞書に郵便番号も登録したら手っ取り早い？
→→ 郵便番号辞書更新の際に、単語辞書丸ごと交換になって面倒。
→ 前項の正規化の際に数値フラグとハイフンフラグを付けて、フラグの並びから抽出する。



分類不能単語（追加案に含めるか否かも含めて分類不能）：
＃ この手の単語は、
＃ 何処までを公共の辞書に入れ、
＃ 何処からを個人辞書に入れるか、
＃ の判断が付かない。
#
あおぞらぎんこう #KK あおぞら銀行       ＃ 全国の地銀まで入れる必要が有るのか？
たいようゆうでん #KK 太陽誘電           ＃ 企業名の入れる入れないの線引きは？
「#KK 三菱東京ＵＦＪ銀行」が無いのだけれども……アルファベットのふりがなどうするんだ？
ひきだし #T30 引出                      ＃ びみょー。
#
めいしょう #KK 名証                     ＃ 投資や相場に興味が無い人は全く使わない。
ふくしょう #KK 福証                     ＃ 投資や相場に興味が無い人は全く使わない。
さっしょう #KK 札証                     ＃ 投資や相場に興味が無い人は全く使わない。
にっちゅうあし #T35 日中足              ＃ 投資や相場に興味が無い人は全く使わない。
＃ 日足（ひあし）は有った。
しゅうあし #T35 週足                    ＃ 投資や相場に興味が無い人は全く使わない。
つきあし #T35 月足                      ＃ 投資や相場に興味が無い人は全く使わない。
ねんあし #T35 年足                      ＃ 投資や相場に興味が無い人は全く使わない。
#
ばってい #T30 抜釘                      ＃ 外科医で無ければ、一生に１回使うか使わないかだと思う。
しまざい #T35 歯磨剤                    ＃ 「歯磨き粉」の本来の正しい名称らしい、けれど、使わない気が。
#
純_虚数         じゅん_きょすう         ＃ 数学やらない人は絶対に使わない。まとめて１単語にした方が良いか？
複素            ふくそ                  ＃ 数学やらない人は絶対に使わない。単体で登録する必要が有るのか？
実軸            じつじく                ＃ 数学やらない人は絶対に使わない。読み方合っていたっけ？
極_形式         きょく_けいしき         ＃ 数学やらない人は絶対に使わない。読み方合っていたっけ？
直交_形式       ちょっこう_けいしき     ＃ 数学やらない人は絶対に使わない。読み方合っていたっけ？
#
「三角波」（さんかくは）#T35 が無い、けれど……。
「ノコギリ波」も無い、けれど……。
「サイン波」も無い、けれど……。
「方形波」（ほうけいは）は有った。
#
「何処からを」（どこからを）が１単語にならなかった。「何処までを」は１単語になった。以前の案件と重複か否か未確認。品詞間違いか？
「未満しか」（みまんしか）が１単語にならなかった。「以上しか」は１単語になった。以前の案件と重複か否か未確認。品詞間違いか？
#

複合語辞書追加案：
鉛_蓄電池       なまり_ちくでんち       ＃ まとめて１単語にした方が良いか？
教導_団         きょうどう_だん         ＃ まとめて１単語にした方が良いか？「団」を接尾辞にした方が良いか？
保有_資格       ほゆう_しかく

単語辞書追加案：
正時            しょうじ
死に体          しにたい



要検討：

http://vagus.seesaa.net/article/147598915.html
2010年04月25日 - 全角/半角の違いを誰が吸収すべきか問題【追記】4/27,5/4
・辞書由来の単語に対して、
  「全角に設定しているユーザには全角の候補を、
  半角に設定しているユーザには半角の候補を優先して出す」
→ どうやってソースコードに落とし込むか？



追記：
http://twitter.com/#!/konosuke/status/175486169407176705
のすけ @konosuke
Anthyで「○○尽くし」が「づくし」で出ないと思ったら「ずくし」
で登録されとるのか。そういえば今でも辞書更新されてるのかなー
2012年3月2日