基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
計算機の起動所要時間。
なんかブームらしいので測ってみた。
しかしまぁ、何度目のブームなんだろうねぇ。
OS: FreeBSD/i386 6.4-RELEASE、高速化等の処置は一切無し。
計算機：CoreDuo のシングルコアモード 1.6GHz。
電源ボタンを押してから起動完了まで：65秒、
但し、
BIOS チェック（メモリチェックは無し）、
HDD の起動OS選択メニューの時間待ち、
起動カーネル選択の時間待ち、
カーネルオプション指定の時間待ち、
合計約20秒を含む。
Linuxエミュレーションモジュールの起動は含むが、
Linuxエミュレーションの ABI起動は含まない。
起動完了から X の起動完了まで：15秒、
但し、
ユーザ指定のウィンドウマネージャーや
ログイン時に同時起動指定しているアプリケーションの
起動完了も含む。
OS: FreeBSD/amd64 6.4-RELEASE、高速化等の処置は一切無し。
計算機：Athlon64 3500+。
電源ボタンを押してから起動完了まで：50秒、
（同上）、
合計約15秒を含む。
（同上）。
起動完了から X の起動完了まで：20秒、
（同上）。
MS-DOS時代は、 電源ボタンを押してから30秒とか20秒とかで競っていた気がする。
Anthy の用例辞書の歴史。
「vagus氏 - 丘の道を登り - 2009年09月28日 - 覚書: anthy の複合語関連」
の件の関連の、今度こそ枝葉の部分だろう話。
ちょっと気になったので調べてみた。
※注意※
関係者の証言が一切無いので、あくまで憶測あるいは妄想のたぐいです。
2003/02頃の anthy-3800 か 3900 辺りで
udict 用例辞書の実装が始まる。
2003/07頃の anthy-4300 で
udict 用例辞書の公開が始まる。
2003年第４四半期頃から、
udict 用例辞書がうまくいっていないととれなくもない発言と、
統計的手法に興味が有るととれなくもない発言が、
見受けられる。
2004/07頃の anthy-5100 か 5500 辺りで
udict 用例辞書に関する言及がぷっつり途絶え、
同時期に ML にて
「統計処理的なことも試している」
「次の開発シリーズではアルゴリズム等を大胆に変更していく予定」
発言があり、
さらに同時に DIARY の更新が止まると共に主メンテナが交代している。
2004/07〜2006/04の間の anthy-6x00 と 7x00 は、
複合語の採用とデータベース構造の調整らしい。
2006/04頃に anthy-8x00 にてコーパス実装開始と同時に、
DIARY の更新が再開している。
また、コーパスにも用例辞書の機能が有る。
状況から憶測すると、
udict の用例辞書は、vagus氏の憶測通り、
放棄あるいはコーパスへ移行、かもしれない。
ついでに。anthy-9x00 は 2007/07頃からで
コーパスの例文増強らしい。
Anthy の用例辞書の話、昨日の続き。
「vagus氏 - 丘の道を登り - 2009年09月28日 - 覚書: anthy の複合語関連」
の件の関連。
udict 用例辞書の使い方が判らなかったので、調べてみた結果。
Wed,07 Oct,2009 追記： 用例辞書は、 ・udict の用例辞書 ・corpus の用例辞書 ２種類があった。下記の用例辞書は udict のみの話。 Thu,15 Oct,2009 追記： 読み仮名、付属語、品詞、は、使用していなかった。 テキストの元データからバイナリ辞書への変換さえ行っていなかった。 ----------------------------------------------------------- 用例辞書の仕様： 主な特徴： ・特定の変換内容の評価を高める事ができる。 処理条件： ・注目文節の、udict および corpus を使用しなかった場合の仮の第１候補が、指定したパターンと一致した時に検索が発動する。 ・評価を変更する文節は、注目文節の前後２文節の範囲（計４文節）で検索される。 ・評価を変更する文節に自立語が存在する事が必須条件。 ・注目文節や評価を変更する対象の一致判定は、自立語部分のハッシュが一致するか否かで行われる。 ・評価を変更する自立語の品詞（POS_* の項目のみで判定）が、 udict および corpus を使用しなかった場合の仮の第１候補と同じ品詞である場合のみ、 評価の変更を実行する。 ＃ src-ordering/relation.c の 98 行目「anthy_wtype_get_pos(ce->elm[ce->core_elm_index].wt) == pos」 備考：・udict にて読み仮名を指定しているが、ソースコード内で使用している部分は見つからない。 ・注目文節のパターンにて品詞を指定しているが、ソースコード内で使用している部分は見つからない。 ・既存の mkworddic/udict を見ると、括弧内に付属語が記述されている場合があるが、 ソースコード内では付属語の合致判定部分が見つからない。・既存の mkworddic/udict を見ると、読み仮名、付属語、品詞、の記述があるが、これらは使用していない。 自立語の変換結果のみ使用している。 udict の例： ------------------ ← 区切り文字列（先頭の - １文字が区切りのマークで、残りはコメント） さ () #K5 咲 ← 評価を高めたい候補 # ← # で始まる行はコメント さくら () #T35 桜 ← 注目文節のパターンその１ うめ () #T35 梅 ← 注目文節のパターンその２ たけ () #T35 竹 ← 注目文節のパターンその３ まつ () #T35 松 ← 注目文節のパターンその４ この場合、例えば以下の４種類の変換例では 「|桜の|[さく]|」 「|桜の|花が|[さく]|」 「|[さく]|桜|」 「|[さく]|花の|桜|」 ４種類とも適用対象と判定され、「さく」に対して評価変更を行うか否かの判定が実行される。 udict およびコーパス情報を使用しなかった場合の 仮の第１候補が「|待つが|[さく]|」（|まつが|さく|）だった場合、 udict には注目文節の自立語「待」に一致するパターンが無いので、処理は行われない （注目文節の第２候補以降に「松」が有っても無視する）。 仮の第１候補が「|桜が|昨|」（|さくらが|さく|）だった場合、 注目文節の「桜」はパターンに一致し、 前後２文節内にある「[さく]」の文節の候補の中に「咲」がある所までは一致判定となるが、 仮の第１候補の「昨」が POS_NOUN、udictで指示された「咲」が POS_V で、品詞不一致なので、 「咲」の評価変更は行われない。 ＃ 但し、corpus用例辞書の場合は品詞の一致条件が無いので、「咲」の評価変更は行われ、得点が２倍になる。 仮の第１候補が「桜の|割く」だった場合、 注目文節の「桜」はパターンに一致し、 前後２文節内にある「[さく]」の文節の仮の第１候補「割」と用例で指定された「咲」で品詞 POS_V が一致するので、 「咲く」の得点が１０倍される。 変更になった得点で並び順を計算しなおすと、「桜の|咲く」が第１候補になるでしょう、多分。 文節の評価計算の詳細は 「Wed,30 Sep,2009 補足：得点の計算方法：」を参照。 -----------------------------------------------------------
Anthy。
ユーザー辞書を private_words_default 形式から
imported_words_default.d 形式に変更した直後から、
ユーザー辞書を編集しようとすると anthy が落ちる現象に
遭遇するようになった。
たしか初めて遭遇したのは６月中旬頃。
で、今日もまた遭遇した。
そして今日、ようやく原因を見つけた。
テキスト形式の辞書の行頭に NUL文字が有ると、
バッファアンダーランでメモリを破壊（0を書き込む）していた。
該当メモリがスタック上にあるのだが、１バイトのずれなので、
隣のポインタ変数の最下位バイトか最上位バイトを破壊するか、
パディングに当たるか、
どちらかになる可能性が高いと思う。
ローカル変数の配置のオプティマイズとかされていると、
どうなるかわからないけれど。
パディングに当たった場合は発症しないし、
ポインタ変数に当たった場合でも
リトルエンディアンでポインタの最上位が元から 0 だったりすると
発症しなかったりする。
標準設定の vim でテキスト形式の辞書を編集すると、
編集中のファイルと同じディレクトリに一時ファイルが作られるのだが、
この一時ファイルも imported_words_default.d ディレクトリにあるので
anthy が辞書とみなして読み込んでしまう。
この一時ファイルは NUL文字を多分に含んでいるので、
その為に anthy がメモリ破壊を起こして落ちる。
vim で anthy の imported_words_default.d の辞書を編集する人なんて、
私以外にはいない様な気もするけれど。
emacs/mule は確か一時ファイルは作らないから、問題は起きないし。
仕様と言えば仕様だし、
anthy はこの手の仕様（入力は必ず規定通りになっていると想定する）が
てんこもりだから……。
uim-anthy で、無駄な子音を捨てない設定。
私は元々 kinput2-canna から uim-canna/anthy に移ってきた人なので、
標準設定の uim だと、色々と違和感が有る。
typo した時に子音が消えてしまうとか、
未確定で backspace した時に日本語の１文字単位で消えてしまうとか。
「uim hiki - CustomizeUim - 無駄な子音を捨てない」
の設定に変更しているのだが、それでもやっぱり微妙に違う。
で、web で
「かおりん氏 - たわごと - uimで英語交じりの文章を入力するために。 - 2009年10月 4日 (日)（原著：cametan氏）」
と言うのを見つけた。
私は、英語／平仮名語／カタカナ語をタイプする時は
固定入力モードに変えてから入力する人なので、
上記のサイトの目的とは全然違ったりするのだけれども、
挙動（typo した時に入力が残る）としては好みに近そうなので、
入れてみた。
uim hiki にある物よりも想定している挙動に近い感じで良さげ。
あとは、未確定で backspace した時に
タイプ内容の１キー単位で削除してくれる機能が欲しい所……。
uim のアノテーション機能／注釈機能、
「かおりん氏 - たわごと-別館 - 2009年10月6日 - ネタがないなら… 」
の話。
uim にアノテーション機能／注釈機能が有るのは知らなかったので、
調べてみた。
正確には、uim の、ではなくて、
skk のアノテーション機能／注釈機能を uim からでも使える様になっている、
らしい。
skk の注釈機能は、
辞書に「てすと /テスト;注釈/」とか書いて、
読み仮名：「てすと」、変換結果「テスト;注釈」で登録してやると、
変換候補の表示時は「テスト;注釈」と表示し、
変換確定時には「;」以降を削除して「テスト」で確定する、
と言う風になっていた。
uim の場合、変換確定時に、
skk.scm から uim/skk.c を呼び出して「;」以降を削除していた。
この方式のアノテーションなら、uim-anthy でも、
uim の anthy-utf8.scm , anthy.scm と
uim/anthy-utf8.c , uim/anthy.c の処理に同様の内容を追加して、
anthy の辞書のソースに注釈を書き加えれば、
すぐに実現できる様な気もしなくも無い。
問題になりそうなのは、
辞書のソースを書き変えるのが面倒なのと、
alt-cannadic を書き変えてしまうと canna で使えなくなる問題と。
変換用辞書と注釈用辞書で２つのデータベースを持つ方が、
構造としては美しいし、
メンテナンス性とか取り回しとかは良さそうなのだが。
……変換結果に「;」を入れたい場合、どうするのだろう。
CAD の dxf形式。
qcad で書いた dxf形式の図面を、
自前パーサで読み込んで使っているのだが。
文字エンティティの基準位置がずれている事に気付いた。
よくよく調べてみたら、５年だかもうちょっと前だかに
dxf の仕様のマイナー改訂が有ったらしいのだが、
その改訂版の仕様が公開されていない様な気がする
（探しても見つからない）。
どうもその頃からずっとずれていたらしいが、気付かなかったらしい。
仕方が無いので、安直に力技で線形解読法。
結論： dxf ver 2.0.4.8 にて。
旧仕様：group 72 と group 73 で文字の基準位置指定。
詳細は web で公開されている通り。
新仕様：group 71 で文字の基準位置指定。
旧仕様で指定 0、
上左 1、上中央 2、上右 3、
中央左 4、中央 5、中央右 6、
下左 7、下中央 8、下右 9、
らしい。
同時に、
group 72 に 0（旧仕様だと水平基準：左） か 2（旧仕様だと水平基準：右）、
group 73 に 0（旧仕様だと垂直基準：ベースライン） か 1（旧仕様だと垂直基準：下）、
の指定があるが、意味は不明。
SBI から届く筈のメールが届かない。
仕方が無いので、メール受信サーバのログを解析。
結果。
SBI のメール送信サーバが DNS に登録されておらず、
逆引き不可でメール受信サーバが TEMPFAIL を返していた。
さすが SBI だよ……。
Sat,31 Oct,2009 追記：
今見たら、
SBI のメール送信サーバが DNS に登録されていた。
ログはちゃんと点検していたらしい？。
----------------------------------------------------------------------------------- Unique Disc Identifier : [DVD-RAM:Matsushita Electric Industrial CO.,LTD.-M01J3004] ----------------------------------------------------------------------------------- Disc & Book Type : [DVD-RAM] - [DVD-RAM] Manufacturer Name : [Matsushita Electric Industrial Co. Ltd.] Manufacturer ID : [Matsushita Electric Industrial CO.,LTD.] Supplementary Info : [M01J3004] Formatted Capacity : [2,236,704 Sectors = 4.58 GB (4.27 GiB)] ----------------------------------------------------------------------------------- [ DVD Identifier V5.0.1 - http://DVD.Identifier.CDfreaks.com ] -----------------------------------------------------------------------------------
alt-cannadic-20090921。
「受光」（じゅこう）が出ない。
発光の反対語だから、品詞も同じだと思う。#T30。
専門用語かな？。
anthy 拙作パッチのバグを発見。
udict用例や corpus用例の加算点が、
変換結果の仮確定を変更する毎にどんどん加算されていた。
取り敢えずレポジトリのみ修正完了。
パッチと tar.lzma は、
vagus氏の所のスコアの件を再検討・確認してからの予定。
Anthy 拙作パッチに、用例辞書の仕様変更の試験版を追加。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
結論だけ言うと、用例辞書 udict の判定方法の挙動とスコアを、候補の選択時における拙作パッチの複合語と同じにした。 用例辞書 udict の場合： ・検索元に関して、仮確定が行われていない文節に関しては、全ての候補で判定を行う様に変更。 ・検索元に関して、仮確定した文節では、ユーザが指定した候補のみを判定する様に変更。 ＃ これまで：検索元に関しては、仮の第１候補となった候補のみを用いて探索。 ・変更先に関して、仮確定が行われていない文節に関しては、従来と同様に全探索。 ・変更先に関して、仮確定した文節では、ユーザが指定した候補のみにて操作を行う様に変更。 ・変更先に関して、品詞 POS_* の一致判定を削除。 ＃ これまで：変更先に関して、仮の第１候補となった候補と品詞 POS_* が一致した場合のみ変更操作を行う。 ・スコアの増加方法を、10倍から、UDICT_SCORE（現在は複合語と同点）を加算、に変更。 ・検索元に関して、検索元と変更先の両方の一致が見つかった場合、加点（UDICT_SCORE）を行う様に変更。 ＃ これまで：検索元に関しては、加点は一切行わない。 用例辞書 corpus の場合： ・一致判定の際に、仮確定した文節に関しては、ユーザが指定した候補のみを用いて判定する様に変更。 ＃ これまで：仮の第１候補となった候補のみを用いて探索。 ・スコアの増加方法を、２倍から、UDICT_CORPUS_SCORE（現在は UDICT_SCORE の1/6）を加算、に変更。 備考： 用例辞書 udict に「咲 ← 桜、梅、桃」と登録した時に、 「咲 → 桜」、「咲 → 梅」、「咲 → 桃」の加点も自動的に行われる様になる。 得点の加算方法を大きく変更したので、 例えば「満点の|干し」と連文節と単文節の両方で学習させても、 コーパス確率×用例１０倍×２倍で得点が60倍だか100倍だかになる「満天の|星」の方が強い、 と言う事が無くなる。 また、謎の品詞の判定を消したので、 例えば「桜→咲」および「股→割」と用例を登録した時に、 これまでは仮の第１候補が「|桜が|昨|シーズン|」とか「|またを|さく|」とかなると無視されていたのが、 用例が効いて「|桜が|咲く|シーズン|」とか「|股を|割く|」とかの得点が高くなる様になる。
スコアのバランスが、 「単文節の学習（２位） ＋ 複合語」 ＞ 「連文節の学習」 となっていたので、 「単文節の学習（２位） ＋ 複合語」 ＜ 「連文節の学習」 となるように連文節の学習のスコアを２割増。
↑*2 udict の用例辞書と corpusの用例辞書の両方に合致した時に、 corpusの加算スコアを優先して適用し udictの加算を無視していたので、 udictの加算を優先して corpusの加算を無視する様に変更 （udict の加算 ＞ corpusの加算）。
で。
Anthy の用例辞書の実装方法にて、困った事に気付いた。
原作版の Anthy の実装では、おおまかには、
と言う順番で処理している。
ので、
複合語辞書の内容は文節区切りの時の足しになるけれども、
用例辞書の内容は文節区切りの足しには全くならない。
……、
文節区切りの時には、複合語も文節毎に区切った状態で使っていて、
連結情報を見ていないから、大差無いかも？。
↑ Fri,23 Oct,2009 追記：
補足：
コーパスの確率のうち、
(2) で使われるのは trans_info データベースで、
(3) で使われるのは cand_info データベースです。
別のデータベースなんですね。どこが違うかまでは調べていません。
今更気付いた事。
半年位前に、
連文節の自立語部分だけ取り出して学習したらどうなるだろう、
と試していたけれども。
それって、ずばり用例辞書だわ……。
２文節ならば再利用率が 35％くらいで、
利用するにも無視するにも微妙なラインだった……。
連文節の付属語部分だけ取り出すと 70％超という再利用率が出ていたけれど、
これは「（付属語無し）＋（付属語無し）」の率が高いせいかもしれず。
原作版 Anthy の仕様の混乱。
Fri,16 Oct,2009 に続き。
ハッシュ値（＝「単語・自立語・付属語などの識別 ID」）の処理にて、
ハッシュ値無効のフラグが、
「-1」と「負数全部」と２種類が混じっていた。
ハッシュ値の計算では、
ハッシュ値が負数になった場合は符号反転をしているので、
問題は起きないと思われる。
＃ ハッシュ値 0 は「有効」らしい。
↑ 符号反転は、ハッシュとしては、さてどうなのだろう？
int型が 32bit の処理系で -2147483648 の符号反転をすると、桁溢れする。
この点は、
現行の大多数のアーキテクチャやコンパイラでは、
適当に溢れたビットを捨てて処理されるだけで、
例外等は発生しないと思うけれど。
数学の面から見ると、
-1 〜 -2147483647, -2147483648 が、
1 〜 2147483647, 0 に
マッピングされるから……、
一応、１対１対応は崩れていないのか。
数学的なハッシュの質の面が、よくわからん。
不特定の条件で余計な全ビット反転とインクリメントが入るなら、
質の面では良くない気もするけれど。
この場合は、最後に１回、入るか入らないかだけだから、
１対１対応なら問題無いかな。
Anthy。
そもそも、用例辞書の仕様は、それでいいのだろうか？
↑
「|桜の|咲き|。|」：「|佐倉の|先|。|」。
をみて、「文末にしたら減点」属性、とか思った。
たしか、付属語グラフの weak_conn で、そこそこ設定してあった筈。
Anthy の用例辞書。
いままで、用例辞書を利用する側のソースを見ていたけれど。
udict の元データから
udict のバイナリ辞書に変換する側のソースを見たら、
笑えた（注意：おもしろいから笑うのではありません）。
変換後の自立語の内容しか読み込んでいなかった。
読み仮名、付属語、品詞、は、読み捨てていた。
こりゃ、本当に（用例機能の）中途開発放棄か？
ざっと見た感じ、
udict 用例辞書で使っているデータベースの構造は
「キー１ ＆ キー２ → 値」の形になっており、
現状では、
「注目文節の自立語をキー１」、
「ペアにする文節の自立語をキー２」、
になっていた。値は使っていなかった
（正確には、値無しが用例該当無しのフラグ、値 1 が用例該当有りのフラグ。
実際の処理はヒヨっていて、値無しだと 0 が返ってくるので、
値 0 は使用不可）。
なので、１つだけ追加で値を使用する事ができる。
読み仮名、付属語、品詞、のうち、一番誤変換に効きそうな付属語を追加して、
「注目文節の自立語」＋
「注目文節の付属語」＋
「ペアにする文節の自立語」、
の３つを用例適用の条件にする事は可能。
但し、
キーペアに対して値は１つしか設定できないので、
付属語違いのパターンを登録できない。
それ以上に条件を増やしたい場合は、
データベースの構造から変えないと駄目。
corpus 用例辞書では、
キーを最大10個まで設定できるデータベースを使っているみたいなので、
そちらに差し替えれば増やせるのかもしれないけれど。
Fri,16 Oct,2009 追記：
付属語を「キーペアに対応する値」に突っ込むよりも、
「キーペアに対応する値」をフラグにして、
キーペアを拡張した方が融通が効く事に気付いた。
検索が増える分、処理は遅くなるだろうけれど。
vagus氏が危惧している様な、
検索の条件が甘いせいで誤適用を行って誤変換を起こす、
事は大きく減ると思う。
具体的には、
「注目文節の自立語をキー１」、
「ペアにする文節の自立語をキー２」、
にてキーペアに対応するフラグを検索。
フラグにて『注目文節の付属語の判定も行え』と指定されていたら、
「注目文節の内容（自立語＋付属語）をキー１」、
「ペアにする文節の自立語をキー２」、
にてキーペアを再検索。
再検索したフラグにて
『「注目文節の内容をキー１」、「ペアにする文節の自立語をキー２」、
にてこのキーペアにたどり着いた場合は用例適用』
と指定されていたら、用例のスコア加算を行う。
最初から
「注目文節の内容（自立語＋付属語）をキー１」、
「ペアにする文節の自立語をキー２」、
で検索しないのは、付属語のワイルドカードが指定できなくなるから。
付属語のワイルドカード指定の需要が有るか否かは判らないけれど。
あと、ハッシュ値を２パターン用いる事で、
ハッシュの誤一致率が (10%)^2 = 1% に減ってくれる事も、
ちょっとだけ期待。
現状の Anthy のハッシュ生成アルゴリズムだと、
自立語のハッシュ値が同じになってしまった時点で、
その後にどんな文字列を追加した所で、
追加する内容が同じならハッシュ値も同じになるのを忘れていた。
用例の歴史。
web で見つかった各種資料をまとみてみると。
但し、下記で言う所の用例が上記の用例と同等なのか否かは不明。
ATOK は、
1993年の ATOK8 で用例の機能を実装したらしい。
MS-IME系は、
1995年の MS-IME95 から用例の機能を実装したらしい。
WX系は、
1996年の WXG から用例と同等の機能を実装していたらしい。
EGBRIDGE は、
1996年から用例の機能を実装した？
Wnn系は、
Wnn6 の1999年だかの更新時に、
用例の機能を本格的に実装して大幅に強化したらしい。
300万用例だそうで。
Anthy のハッシュに仕様の混乱もしくはバグが有るのではないかと言う話、 Wed,14 Oct,2009の続き。
バグがあった。
よくよく確認したら、ハッシュ値無効のフラグが、
「0 のみ」と「-1 のみ」と「負数全部」の３種類が混じっていた。
が、ハッシュ生成関数では「負数全部」を無効のフラグとみなし、
「0」は有効として扱っていた。
コーパス処理部分ではハッシュ無効のフラグを「0 のみ」とみなしているので、
int型が 32bit のシステムでは約21億分の１の確率で、
必ず処理を間違えるバグがあります。
それから、自立語部分、付属語部分、にて、
ハッシュを求めた結果のバッファの初期化で 0 を代入している。
変換候補一覧のバッファ初期化だと -1 を代入している。
用例辞書の検索だと、
udict 用例だと「-1 のみ」を無効とみなしているが、
corpus 用例だと「負数全部」を無効とみなしていた。
ここまでバラバラだと治す気にならない……。
gtk。
実際の窓の生成やウィジェットの配置や所々の描画は
gtk->run(); してから行われる。
Glib::signal_timeout() は、
実際の窓の生成やウィジェットの配置や所々の描画の際に、
もろに遅延を起こす。
なので、
gtk->run(); したあと暫くしてから Glib::signal_timeout() するか、
gtk->run(); する前後で
Glib::signal_timeout() の被呼を捨てるかしないと、
実行周期がメタメタになる。
実地で試した範囲だと、
gtk->run(); 後 1500〜2000ms くらいを捨てないと駄目だった。
alt-cannadic。
「こう〜」で変換したら、アレ？っと思う様な候補が出て来た。
「こう #CN 府中」
実在の駅名らしい（ja.wikipedia.org より引用）
> 府中駅（こうえき）は、徳島県徳島市国府町府中にある四国旅客鉄道（JR四国）徳島線の駅である。駅番号はB04。
「こう #CN 国府」
実在の地名らしい（ja.wikipedia.org より）
奈良時代〜平安時代の呼称の名残りらしい。
「こふ」とも読むらしい。
実在の地名だったらしい。
wikipedia由来なので、どこまで正しいのかは不明。
Anthy の用例辞書とコーパス。
文節Ｎグラム・単語Ｎグラムと言った統計的手法を用いずとも、
用例辞書だけでも、
利用した時にどの様な挙動になるのかをきちんと考えて実装すれば、
それなりに使える物になる様な気がします。
ただし、本気で本格的に充実した用例辞書を作ろうとすると、
きちんと基礎研修をした人を×百人が×ヶ月、
とか必要になるとも思いますが。
と言う訳で、anthy の用例辞書の改造に着手。
ただし、
本格的に大規模な用例辞書の整備をしようとすると、
上記の様にとんでもない労力が必要となってしまうので、
辞書整備は、しない。
Kingston microSD 2GB ￥780-、 BUFFALO microSD 2GB ￥850-。
Anthy の用例辞書の改造。
手を付けてみたが……。
原作版 Anthy 由来の、データベース処理関連の基礎関数群に、
メモリ確保やデータセット初期化はあるのに、
メモリ解放やデータセット後始末の系統が全く無いと言う……。
と言う訳で、メモリリークしまくりの警報が出るのは、
原作版 Anthy 由来の仕様です。
メモリ確保やデータセット初期化の系統でも、
確保失敗や初期化失敗した時にグダグダになるのも、
原作版 Anthy 由来の仕様です。
メモリ確保失敗のチェックや初期化失敗のチェックが全く無いのだもの。
辞書ファイル読み込みの読み込み失敗チェックすら無い。
Anthy の用例辞書 udict を廃止して、
新しい仕様で用例辞書 ucdict を実装してみた。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
の
anthy-9100h.patch13B-23-iconv-ucdict.2009X18.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
コンパイルが通るのを確認して、
anthy-agent の試験でそれっぽい挙動になるのを確認した所で力尽きて、
実地試験はまだ行っていない。
あと、用例辞書 ucdict の中身も、テスト用の数件しかない。
現時点での仕様は以下の通り。
データ書式：-----------------------------------------------
#
# フラグ 優先度 注目文節の 注目文節の ペア文節の ペア文節の 注目文節の 注目文節の ペア文節の ペア文節の
# 自立語 付属語 自立語 付属語 自立語 付属語 自立語 付属語
# 読み仮名 読み仮名 読み仮名 読み仮名 変換結果 変換結果 変換結果 変換結果
#
- 9 さくら が さ * 桜 が 咲 *
- 9 はな が さ * 花 が 咲 *
- 9 はな を さ * 花 を 咲 *
- 9 さく _ しーずん * 昨 _ シーズン *
#
- 9 また を さ く 股 を 割 く
#
- 9 まんてん の ほし * 満天 の 星 *
- 9 まんてん の ほしぞら * 満天 の 星空 *
#
b 2 とびら * あけ * 扉 * 開け *
b 2 どあ * あけ * ドア * 開け *
b 2 ひきだし * あけ * 引き出し * 開け *
b 2 ばしょ * あけ * 場所 * 空け *
- 2 よ が あけ * 夜 が 明け *
#
# 優先度
# 0 スコアの加算をしない（存在意味が無い……）。
# 1〜15 1当たりコーパス10倍の単語の頻度値100相当（連文節学習の25分の１）。
#
# フラグ
# - 指定は何も無し（全て標準設定）。
# b 文節の順番が逆順の場合も適用。
#
-----------------------------------------------------------
・原作版 anthy の udict だと、付属語無しと付属語ワイルドカードの区別が付かないので、
元データの形式を変えないと駄目。
どのみち変えるのだったら、登録や調整が行いやすい様にしてしまえ。
・１行で１ペア。
原作版 anthy の udict の様な、連続指定は無し。
＃ １行１ペアと、連続指定できるのと、どちらが良いのだろう？
・データのメンテナンスの観点からすると品詞が有った方が良さそうだが、
データの作成の観点からすると品詞を書くのは凄く面倒臭い。
・読み仮名も指定しないと、誤変換が高まる可能性がある事に気付いた。
ので、読み仮名も必須。
・文節の順番は右方向限定。
左方向にも適用したい場合、フラグで指定する。
→ 適用時にフラグを見て両方向を検索するのは面倒なので、
バイナリ辞書に変換する際に両方向のデータを作る。
・現状では、連続した文節限定。
フラグにて間に他の内容が１文節入るケースも許容するか？
・付属語に _ と書くと、付属語無し。
・付属語に * と書くと、ワイルドカード。
・ペアが見つかれば、ペアの両文節とも加点する。
・複数の用例が重複した場合。
ペアのうち、重複していない方の文節は、全て加点する。
重複した方の文節では優先度が最も大きい加点のみ適用する。重複加算は行わない
（現状の Anthy の処理構造の都合で、重複加算は行えない。
重複加算を行える様に改造を始めると、
改造量が 50KB とか 100KB とか越えかねないので嫌）。
・ペア文節が動詞の場合、能動と受動で明確に分ける事ができる場合がある事に気付いた。
どうしよう。
と思ったが、どれも seg_class:Ve, dep_class:Se で、内部的には区別が無かった。
・ハッシュがコリジョンを起こした場合、後で記述した方が無視される。
mkworddic 実行時に、その旨表示が出る。
・「明け」（あけ）の様に、平仮名部分も含む自立語が有るので注意。
この場合、平仮名部分を書き忘れると、適用されなくなる。
Sun,25 Oct,2009 追記：
複数の用例が重複した場合。に関して。
同一文節の同一候補に対しては、１回しか加点を行いません。
同一文節の別候補に対しては、各候補毎に加点を行います。
例えば、
「部屋 → 暑」（優先度 3）と「暑 → 夏」（優先度 4）の２つの用例がある場合、
「|部屋の|暑い|夏|」という候補の「暑」への用例の加点は、
［優先度 4］（優先度の大きい方）の１回しか行いません。
「部屋 → 暑」（優先度 3）と「厚 → 本」（優先度 3）の２つの用例がある場合、
「|部屋の|[あつい]|本|」という候補の第２文節への用例の加点は、
「暑」が『頻度402 × コーパスの確率 × 文節構造の補正 ＋ 用例加点3 ＋ コーパス加点』、
「厚」が『頻度301 × コーパスの確率 × 文節構造の補正 ＋ 用例加点3 ＋ コーパス加点』、
になります。
品詞も付属語も文字数も同じなので、コーパスの確率や文節構造の補正は同じ値でしょう。
コーパス加点はどうなるか予想が付きません。
負けないで、ZARD、1993.1.27。
ゆずれない願い、田村直美、1994.11.9。
Anthy の用例辞書の新仕様の話、昨日の続き。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
の
anthy-9100h.patch13B-23-iconv-ucdict.2009X19.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
バグ修正とかバランス調整とか。
だいたいこんな所で、
そこそこ使える用例辞書機能になったと思うけれど。
あとは、
こだわりのある方や、チャレンジ精神旺盛な方など、
用例辞書の整備を行って頂くと、
そこそこ変換結果が良くなる可能性があるかもしれず。
でも、投入した労力ほどの成果は無いかもしれず。
Anthy の用例辞書の新仕様の話、昨日の続き。
取り敢えず、原作版 anthy の用例辞書 udict を
改造版用例辞書用に変換するスクリプトを作ってみた。
anthy_udict2ucdic.pl - 原作版 Anthy 用例辞書 udict 形式を、拙作改造版 用例辞書 ucdic 形式に変換する
試しに使ってみたら、
ハッシュ回りのバランスが悪い事に気付いた。
原作版 Anthy のハッシュ関数だと、ハッシュの継続計算ができない。
例えば、６つの文字列を結合したハッシュを求めたい時に、
一度、文字列を連結した文字列を作ってからでないと、
ハッシュの計算ができない。
実際の改造版用例辞書の処理だと、
条件によって、
６つの文字列のうち、
どれとどれを結合した状態のハッシュを求めるかが変化する上に、
複数の結合のパターンを同時に使用するので、
いちいち文字列を連結してこねくり回すのは面倒。
だからと言って、
継続計算の代わりに手抜きして、
各ブロックのハッシュの排他論理和とかにしてしまうと
ハッシュの質が下がる。
なので、ハッシュ関数を丸ごと作り直し。
CRC32C にしたら、
コリジョンが10.0％から9.9％に減った。
この程度は誤差だろうけれど。
コリジョン率の比較は、
以前に計測した所Thu,19 Feb,2009
に追記。
……ハッシュ関数を変えたら、コーパスの再計算が必須なのか。面倒だ……。
というわけで、
原作版用例辞書を編入して、コーパス再計算まで済んだ所で、
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
の試験版を更新。
anthy-9100h.patch13B-23-iconv-ucdict.2009X20.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
% env LD_LIBRARY_PATH=${HOME}/.anthy/test.patch13/lib/ ~/.anthy/test.patch13/bin/anthy-agent --anonymous
atui.natuhaatui.honnhaatui.
(2 ((UL) "あつい。なつはあつい。ほんはあつい。" -1 -1) cursor)
(space)
(3 ((UL RV) "暑い" 0 6) ((UL) "。" 0 3) ((UL) "夏は" 0 6) ((UL) "暑い" 0 6) ((UL) "。" 0 3) ((UL) "本は" 0 4) ((UL) "暑い" 0 6) ((UL) "。" 0 3))
なんじゃぁこりゃ、効いてない？
PRINT_CONTEXT |あつい|。|なつは|あつい|。|ほんは|あつい|。 あつい(暑い:(C,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)1,407,720 ,熱い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)909,973 ,厚い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)680,189 ,あつい:(N,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)677,937 ,篤い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)452,659 ,アツイ:(N,0,-)1 ,): 。(。:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)716 ,.:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)614 ,．:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)601 ,): なつは(夏は:(U,1000,Ny,65699,Sy,E:0,F:300,LF:0,D:1,L:1,S)1,232,231 ,なつは:(N,1000,Ny,65699,Sy,E:0,F:300,LF:0,D:1,L:1,S)515,176 ,奈津は:(,1000,Ny,65699,Sy,E:0,F:150,LF:0,D:1,L:1,S)207,212 ,奈都は:(,1000,Ny,65699,Sy,E:0,F:150,LF:0,D:1,L:1,S)104,557 ,ナツハ:(N,0,-)1 ,ナツは:(g,0,-)1 ,): あつい(暑い:(UC,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)1,522,120 ,厚い:(C,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)1,180,189 ,熱い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)909,973 ,あつい:(N,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)677,937 ,篤い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)452,659 ,アツイ:(N,0,-)1 ,): 。(。:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)716 ,.:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)614 ,．:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)601 ,): ほんは(本は:(U,1000,Ny,65699,Sy,E:0,F:301,LF:0,D:1,L:1,S)1,234,284 ,ほんは:(N,1000,Ny,65699,Sy,E:0,F:301,LF:0,D:1,L:1,S)617,831 ,ホンハ:(N,0,-)1 ,ホンは:(g,0,-)1 ,): あつい(暑い:(C,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)1,407,720 ,厚い:(UC,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)1,294,589 ,熱い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)909,973 ,あつい:(N,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)677,937 ,篤い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)452,659 ,アツイ:(N,0,-)1 ,): 。(。:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)716 ,.:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)614 ,．:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)601 ,):U が付いているので、用例辞書の適用は想定通りに行われている。
あつ #KY*403 熱 #KY*402 暑 #KY*301 厚 #KY*300 あつ #KY*200 篤 #CN*100 厚保なので、100点差。
あつい(熱い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)909,973 ,暑い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)907,720 ,厚い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)680,189 ,あつい:(N,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)677,937 ,篤い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)452,659 ,アツイ:(N,0,-)1 ,):となる。
(3 ((UL RV) "熱い" 0 6) ((UL) "。" 0 3) ((UL) "夏は" 0 6) ((UL) "暑い" 0 6) ((UL) "。" 0 3) ((UL) "本は" 0 4) ((UL) "厚い" 0 6) ((UL) "。" 0 3))ちゃんと用例辞書 ucdic が効いている。
あつい(熱い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)909,973 ,暑い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)907,720 ,厚い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)680,189 ,あつい:(N,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)677,937 ,篤い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)452,659 ,アツイ:(N,0,-)1 ,): 。(。:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)716 ,.:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)614 ,．:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)601 ,): なつは(夏は:(U,1000,Ny,65699,Sy,E:0,F:300,LF:0,D:1,L:1,S)1,232,231 ,なつは:(N,1000,Ny,65699,Sy,E:0,F:300,LF:0,D:1,L:1,S)515,176 ,奈津は:(,1000,Ny,65699,Sy,E:0,F:150,LF:0,D:1,L:1,S)207,212 ,奈都は:(,1000,Ny,65699,Sy,E:0,F:150,LF:0,D:1,L:1,S)104,557 ,ナツハ:(N,0,-)1 ,ナツは:(g,0,-)1 ,): あつい(暑い:(U,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)1,522,120 ,熱い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)909,973 ,厚い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)680,189 ,あつい:(N,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)677,937 ,篤い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)452,659 ,アツイ:(N,0,-)1 ,): 。(。:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)716 ,.:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)614 ,．:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)601 ,): ほんは(本は:(U,1000,Ny,65699,Sy,E:0,F:301,LF:0,D:1,L:1,S)1,234,284 ,ほんは:(N,1000,Ny,65699,Sy,E:0,F:301,LF:0,D:1,L:1,S)617,831 ,ホンハ:(N,0,-)1 ,ホンは:(g,0,-)1 ,): あつい(厚い:(U,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)1,294,589 ,熱い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)909,973 ,暑い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)907,720 ,あつい:(N,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)677,937 ,篤い:(,1000,A,72089,Se,E:0,F:403,LF:0,D:1,L:1,S)452,659 ,アツイ:(N,0,-)1 ,): 。(。:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)716 ,.:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)614 ,．:(1,100,KJ,3276,Se,E:0,F:6,LF:0,D:0,L:0,S)601 ,):点数も設計通りになっている。
Anthy の用例辞書の新仕様の話、昨日の続き。
どうやら、コーパスの
calctrans/corpus.3.txt:2799:|あついかもねえ|。| |暑いかもねえ|。|
から『「暑」←「。」』の用例が自動生成されて、
それが
『|あつい|。|なつは|あつい|。|ほんは|あつい|。』の
『|あつい|。|』の部分と
『|。|（別の内容）|あつい|』の部分に適用されて、
「暑」がやたら優先されているらしい。
オプション CANDIDATE_SCORE_UCDIC_RATIO と
CANDIDATE_SCORE_CORPUS_UDICT を追加して、
ucdic による用例辞書の加点レートと、
コーパスから自動生成した用例辞書の加点数を、
各々設定可能にした。
それから。
コーパスから自動生成した用例辞書の加点数を、
単語の辞書の頻度値の 100相当になるように大幅に下げた。
ucdic による用例辞書の加点レートは、
優先度１毎に単語の辞書の頻度値の 100相当になるように設定した。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
の試験版を更新。
anthy-9100h.patch13B-23-iconv-ucdict.2009X21.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
既知の問題として、
ケータイ売場。
イーモバイル同時契約のネットブック 100円を、
購入してすぐに em 解約すれば、
違約金と解約手数料を含めても、
普通にネットブックを買うより安く買える。
と呼び込み宣伝していた。
いいのかそれで？。
気になったので調べてみた。
契約月に解約した場合の違約金は約７万円。
単体購入だと約５万円（新モデル）〜約３万５千円（型落ち）。
あれ？。
どこをどう聞き間違えたのだろう。
広告のインターチェンジ。
とある広告で、インターチェンジの写真が大きく載っているのだが。
どこのインターチェンジなのか、気になる。
でも全然判らない。
「のすけ氏 - configureしてmakeをかけると再度configureが走る
(その前にautoconfか何かが走る?) のをエレガントに回避する方法」
source-tar-ball を展開した後のビルドする前に touch configure して、
それから
mkdir build ; ../configure ; make なり
./configure ; make なりする。
場合によっては、
touch aclocal.m4 ; sleep 1 ; find . -name Makefile.in -exec touch {} \; ; touch configure
touch aclocal.m4 ; sleep 1 ; touch config.h.in ; find . -name Makefile.in -exec touch {} \; ; touch configure
（FAT系の fs の場合は sleep が 2。
最近の ufs や ext2以降？の様にマイクロ秒のタイムスタンプを使える fs なら
sleep は不要）
でないと駄目な場合もあるかもしれません。
あとは autoreconf してしまう手もある。
その場合は、autoreconf にオプション指定が必須の場合もあるので注意。
RCS とか CVS とか SVN とか（たぶん git も）は
ファイルのタイムスタンプの復元方法にクセがある為、
source-tar-ball を作成した時に
configure の生成に使うファイルのタイムスタンプと、
configure のタイムスタンプにて、
時刻が同時刻なり逆順なりになる事があり、
make が「configure の再生成が必要」と判定して
autoreconf して再 configure してしまいます。
リビジョンの管理者側での確実な対処法となると、
svn の場合、環境設定で use-commit-times = yes すると共に、
configure が依存しているファイルを編集した際に、
それらのファイルをコミットした後、
１秒後以降（FAT系のファイルシステムでも利用する場合は２秒後以降）に
別リビジョンとして configure を強制的にコミット
（configureの中身が変化しなかった場合、
svn がコミットを拒否するが、それでも強制的に）すると、
解決できた筈
（svn から取り出した時に、必ずタイムスタンプの順番が正しくなる）。
で、現時点では、強制的にコミットする方法が不明です。
RCS や CVS は、
タイムスタンプのゴニョゴニョする方法が無かった様な気がする。
git は調べていません。
Sun,25 Oct,2009 追記：
nosuke氏の補足の通り。
touch aclocal.m4 後に touch config.h.in が抜けていると
autoheader が走ってしまいます。
忘れてた……。
Mon,21 Dec,2009に続く。
Atom 1.4〜1.6GHz クラスのネットブックなら、 一般的な家電量販店クラスでも、 型落ちなら３万円〜３万数千円で買えるらしい。 ただ、スペック的に、超高級電子手帳、な用途にしか使えないと思うけれど。
Core2 とか Athlon64 とかの 2GHz前後のノートＰＣだと、 廉価機でも６万数千円になるらしい。 同クラスのデスクトップ機だと３万数千円らしい。
1/24 K.I.T.T. ￥3,990- とか 1/48 エアーウルフ ￥3,990- とかの プラモデルが出た／出るらしい。 エアーウルフってブルーサンダーより大きかったんだ……。
Anthy 拙作パッチの
「vagus氏 - 丘の道を登り - 2009年10月24日 - 何か変…?」
の件。
一文で言うと。
uim には有るけれども scim には無い機能を使ってしまった為でした。
環境設定にて
「ENABLE_PROVISIONAL_COMMITTED false」
指定すると、発症しなくなります。
詳しく言うと。
すっかり忘れていましたが。
フロントエンド→エンジン間の API には、
仮確定としてどれが選択されたのかを通知する API は無かったりします。
その為、拙作パッチでは、uim の API 呼び出しのクセを使って、
仮確定の内容を取得しています。
その手法が scim では機能したり機能しなかったりしていました。
また、uim は、
注目文節の変換候補を変更した際に、
他の文節の候補の並び順の変更があったかどうかを
確認してくる様になっています。
scim は、
注目文節の変換候補を変更しても、
他の文節の候補の並び順の変更があったかどうかは確認しません
（変わらないと言う前提で処理している）。
拙作パッチでは、
注目文節の変換候補を変更した際に、
それに合わせて、複合語・連文節学習・用例の適用状況を調整し、
他の文節の候補の並び順の変更を行う場合があります。
uim では他の文節の候補の並び順の変更を正しく検出出来ますが、
scim では検出出来ません。
それとは別に、加点を間違えるエンバグ
（選択されている変換候補の変更により
複合語・連文節学習の加点を無効に変更した場合でも、
要加点フラグを消していなかった）
を見つけたので修正。
このエンバグは用例辞書の試験版では無い方にもバックポートしないと
いけないのだけれども、面倒だ……。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
の試験版を更新。
anthy-9100h.patch13B-23-iconv-ucdict.2009X25.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
uim および scim の API 呼び出しの流れの比較： ● uim の場合： anthy_create_context(); 変換開始 anthy_commit_segment(-1,-128); 初期化（拙作改造版 uim の anthy.scm のみ） anthy_set_string(); 変換したい文字列が uim→anthy に渡る 変換する。 anthy_get_stat(); 変換結果の文節数が anthy→uim に渡る anthy_get_segment(0,0,0x0,0); 第１文節の第１候補の文字数が anthy→uim に渡る anthy_get_segment(0,0,0x*******,5); 第１文節の第１候補の文字列が anthy→uim に渡る：ここで第１文節の第１候補を仮確定とみなす。 Anthy: TRACE: anthy_get_segment();rebuild=1 ここで anthy側が、第１文節の仮確定を受けて、自動で第２文節以降の再評価を行う。 anthy_get_segment(1,0,0x0,0); 第２文節の第１候補の文字数が anthy→uim に渡る anthy_get_segment(1,0,0x*******,7); 第２文節の第１候補の文字列が anthy→uim に渡る：ここで第２文節の第１候補を仮確定とみなす。 ここで anthy側が、第２文節の仮確定を受けて、自動で第３文節以降の再評価を行う……第３文節以降が無いので何もしない。 変換候補を表示される。 注目文節を第２文節に変更する。 anthy_get_segment(0,0,0x0,0); anthy_get_segment(0,0,0x*******,5); anthy_get_segment(1,0,0x0,0); anthy_get_segment(1,0,0x*******,7); anthy_get_stat(); 第２文節の候補一覧を表示する操作を行うと。 anthy_get_segment_stat(); anthy_get_segment(1,0,0x0,0); 第２文節の第１候補の文字数が anthy→uim に渡る anthy_get_segment(1,0,0x*******,7); 第２文節の第１候補の文字列が anthy→uim に渡る anthy_get_segment(1,1,0x0,0); 第２文節の第２候補の文字数が anthy→uim に渡る anthy_get_segment(1,1,0x*******,5); 第２文節の第２候補の文字列が anthy→uim に渡る：ここで第２文節の第２候補を仮確定とみなす。 anthy_get_segment(1,2,0x0,0); 第２文節の第３候補の文字数が anthy→uim に渡る anthy_get_segment(1,2,0x*******,7); 第２文節の第３候補の文字列が anthy→uim に渡る：ここで第２文節の第３候補を仮確定とみなす。 （略） 候補一覧の取得の最後に、uim は全文節の選択候補をもう一回取得する。 anthy_get_segment(0,0,0x0,0); 第１文節の第１候補の文字数が anthy→uim に渡る anthy_get_segment(0,0,0x*******,5); 第１文節の第１候補の文字列が anthy→uim に渡る：ここで第１文節の第１候補を仮確定とみなす。 anthy_get_segment(1,0,0x0,0); 第２文節の第１候補の文字数が anthy→uim に渡る anthy_get_segment(1,0,0x*******,7); 第２文節の第１候補の文字列が anthy→uim に渡る：ここで第２文節の第１候補を仮確定とみなす。 ● scim の場合： anthy_create_context(); 変換開始 anthy_context_set_encoding(); 初期化 anthy_reset_context(); 初期化 anthy_get_stat(); 変換結果の文節数が anthy→scim に渡る…… 0 だと思う。 anthy_set_string(); 変換したい文字列が scim→anthy に渡る 変換する。 anthy_get_stat(); 変換結果の文節数が anthy→scim に渡る anthy_get_segment_stat(); anthy_get_stat(); 変換結果の文節数が anthy→scim に渡る anthy_get_segment_stat(); anthy_get_segment(0,0,0x0,0); 第１文節の第１候補の文字数が anthy→scim に渡る anthy_get_segment(0,0,0x********,5); 第１文節の第１候補の文字列が anthy→scim に渡る：ここで第１文節の第１候補を仮確定とみなす。 Anthy: TRACE: anthy_get_segment();rebuild=1 ここで anthy側が、第１文節の仮確定を受けて、自動で第２文節以降の再評価を行う。 この時点では用例は効いている。 anthy_get_segment_stat(); anthy_get_stat(); anthy_get_segment_stat(); anthy_get_segment_stat(); anthy_get_segment(1,0,0x0,0); 第２文節の第１候補の文字数が anthy→scim に渡る anthy_get_segment(1,0,0x********,7); 第２文節の第１候補の文字列が anthy→scim に渡る：ここで第２文節の第１候補を仮確定とみなす。 anthy_get_stat(); anthy_get_segment_stat(); anthy_get_segment(0,0,0x0,0); scimは、変換した直後に注目文節の変換候補一覧を取得するらしい。 anthy_get_segment(0,0,0x********,5); anthy_get_segment(0,1,0x0,0); anthy_get_segment(0,1,0x********,9); 第１文節の第２候補の文字列が anthy→scim に渡る：ここで仮確定の内容が第１文節の第２候補に変化したとみなす。 Anthy: TRACE: anthy_get_segment();rebuild=1 ここで anthy側が、第１文節の仮確定の変更を受けて、自動で第２文節以降の再評価を行う。 anthy_get_segment(0,2,0x0,0); anthy_get_segment(0,2,0x********,9); Anthy: TRACE: anthy_get_segment();rebuild=1 （中略） anthy_get_segment(0,12,0x0,0); 変換候補一覧取得の最後。 anthy_get_segment(0,12,0x********,9); Anthy: TRACE: anthy_get_segment();rebuild=1 anthy_get_stat(); anthy_get_stat(); anthy_get_segment_stat(); anthy_get_stat(); anthy_get_segment_stat(); anthy_get_segment(0,0,0x0,0); 変換結果表示にて、注目文節の内容を再取得するらしい。 anthy_get_segment(0,0,0x********,5); ：ここで仮確定の内容が第１文節の第１候補に変化したとみなす。 Anthy: TRACE: anthy_get_segment();rebuild=1 ここで anthy側が、第１文節の仮確定の変更を受けて、自動で第２文節以降の再評価を行う。 ここで再度、用例適用の判定を行うのだが、第２文節の第１候補が仮確定とみなされているので、用例の判定範囲を第１候補のみに限定する。 → 「先に」が候補リストの１番に載ってしまう。 ここで、変換候補が表示される。 この後、第１文節の選択候補を変更しても、選択候補を変更した文節の内容しか取得しに来ない。 （anthy側が第１文節の選択の内容によって第２文節以降の候補の並び順を変更しても、scim が取得してくれない）
xterm でかな漢字変換を使う方法。
以前、vagus氏のブログ？にて、xterm で入力うんぬんの話が出た時に、
xterm から IM を呼び出す方法が判らなくて試す事ができないでいたのだが。
ようやくわかった。
X のリソースに
XTerm*inputMethod: xim
XTerm*openIm: true
するだけ。
inputMethod の xim は、適宜、uim なり scim なりに変える。
手元の .Xdefaults を見たら、故意に openIm false にしてあった。
なんで false にしたのだかもう覚えていないし……。
kinput2 がちょくちょくフリーズを起こして、
kterm がその巻き添え食ってフリーズするから、
巻き添え食わない様に openIm false にして、
必要な terminal だけ Open Input Method する様にしたのだっけ。
uim-xim に変えてから非常に安定して動作する様になったから、
標準で openIm true にしても問題無いかも。
scim-anthy の API 呼び出し状況のトレースをしようとしたら、
scim の anthy.so がコンソールを持っておらず、
コンソールに引っ付ける方法が判らなくて
ログが亜空間に消え去ってしまった。
ログをファイル出力する機能を追加しないと駄目か……。
Anthy、拙作パッチで変更・追加を行った量を見てみた。
行数ベースだと 65％、単語数ベースだと 93％、文字数ベースだと 69％、らしい。
誤差はそれなりに大きいとは思うけれど。
半年だか前に見てみた時は 30〜40％くらいだったと思ったけれど。
計算を間違えたのか。
私が kinput2 から uim, scim, im, iiimf のどれかに乗り換える時に、
何故 uim を選んだのか。
uim は xim対応と言うのが一番大きかったのだけれども。
scim には文節区切り位置を表示する機能が無い点が、
scim 却下の一因だった事を今更思い出した。
文節区切り位置の表示が無いと、誤学習しまくるだろうから……。
あとは、im や scim や iiimf はリソース消費量が多いとか。
雨音はショパンの調べ、小林麻美、1984.4.21。 「レイディネス」と聞こえたのは「Rainy days」だったらしい。
The Stardust Memory、小泉今日子、1984.12.21。 イントロで 0083と連想してしまう……、でも 0083 は 1991〜1992 らしい。
JST だと 28日 00:00（GMT だと 27日 15:00）に、
www.MekTek.net にて
MechWarrior の広報を出すと言う広報が出ていた。
……このカウントダウンページ、
MacromediaFlash で表示しているページなのだが、
JST でジャストなのは、
単にローカルマシンの時刻を MekTek の現地時刻と間違えているバグ
なんではないかという気が。
MW4無料版の件なのか、
幻だったMW5（新名称忘れた）の件なのか、
全然違うのか、は不明。
プロモーションムービーを見る限り、
うちのへっぽこマシンでは動きそうも無い。
時間も金も無い。
……あのプロモーションムービー、
１日ザク v.s. デストロイドトマホーク に見えてしかたがない。
あと、イジェクションシートが有っても、
あの位置関係だと爆風で死ねるんではないかと言う気が。
そう言えば、鉄騎のイジェクションシートは、 プロモーションムービーだと後ろに射出していた様な気がするけれど、 市街地で後ろに射出するとビルに激突しそうな気が……。
roguelike の前。
ひょんな事から、roguelike の前が有る事を知った。
「Classic 8-bit/16-bit Topics - 02.01.2004 - Rogue 1975年起源説の謎 - Beneath Apple Manor」
「SAND STORM - 2008年11月7日 - Rogue以前のRoguelike Beneath Apple Manor」
だそうで。
www.MekTek.net の件。
28日 00:00 過ぎたら残り時刻がマイナスになりおった。
やっぱりバグか。
JR東の新型試験車両。
電池で走る事ができるらしい。
未電化区間でも電気で走る事ができるらしい。
電池の大きさと乗客が乗れる広さとが、同じ位になってしまうらしい（爆。
電車内の半分くらいが電池で埋まってるし……。
いいなぁ、こう言うの好きだよ……。
その物自体も、そう言う事を真面目に仕事できる職場環境も。
自動車でのハイブリッドカーや電気自動車でも、
最初は人や荷物の容積より電池の容積の方が大きかったのだろうし、
そこからきちんと積み上げたからこそ、
今のハイブリッドカーや数年後の電気自動車があるわけだし。
人身事故の為、20〜30分の遅れ。 なんか久しぶりな気がする。
工画堂の PD1 の中古、週末特価￥4,980-。
先月は￥5,380-だったか￥5,480-だったかくらいだったと思う。
火星計画は売っていない。
原作版 udict の間違い探しをした結果、
見つけた alt-cannadic-090921 の間違いっぽい部分。
ふくそうじゅうし #JN*10 副操縦士 #T35*10 副操縦士
ふくそうじゅうし だけなぜか #JN で、そうじゅうし は #T。
しんふぉにえった #JN*10 シンフォニエッタ
楽曲の一般名詞らしい？
しんきょく #KK*150 神曲
叙事詩の名前。「その他固有名詞」は #KK になってしまう？
きおい #JN*10 紀尾井
御三家の総称の意味合いもないではないが、大抵は地名らしい？
Wed,04 Nov,2009 追記：
解説が来ていました。有り難うございます。
「vagus氏 - 丘の道を登り - 2009年11月04日 - 調べた」
#JN にすると「さん」が付くのは、知りませんでした。
妙な所で #JN をみかける事に合点がいきました。
HP の Athlon NEO な奴、たぶん dv2、店頭展示品？ ￥44,800-。
Celeron 1.2GHz なやつも、Celeron 2.2GHz なやつも、
両方共 ￥49,800- だった。
1.2GHz の方はデュアルコア(SU2300, 10W)で、
2.2GHz の方はシングルコア(900, 35W)らしい。
だた、メーカーによっては
1.2GHZ シングルコア(723, 10W)とか
1.8GHz デュアルコア(T3000, 35W)とか、
混じっているらしい。
恋しさと せつなさと 心強さと、篠原涼子、1994.7.21。
翼の折れたエンジェル、中村あゆみ、1985.4.21。
海を見ていた午後、荒井由実、1974？。 正直、四畳半の頃の曲は、 忘れられないし嫌いではないのだけれども、好みではない。 良いとは思うけれど聞きたくない。 いや、それは、やっぱり嫌いなのか？。 いわゆる「嫌いな曲」とは違うけれど。 暗い世の中だから、曲まで暗い感じなのは嫌、という単純な話かも。
Anthy 用例辞書改造の試験版を更新。
用例のスコア加算の際に、文節構造の評価を加味する様にした。
それに伴い、
CANDIDATE_SCORE_UCDIC_RATIO, CANDIDATE_SCORE_CORPUS_UDICT
の仕様を変更。
用例辞書 ucdict に
品詞小分類・品詞大分類・活用形・付属語型の条件を追加。
用例辞書 ucdict にて、
逆順フラグの仕様を変更。
用例辞書 ucdict にて、
間に１文節挟まった状態でも適用する様にした。その場合、加算スコアは半減。
用例辞書 ucdict にて、
間に他の文節が挟まった状態での適用を禁止するフラグ追加。
用例辞書 ucdict にて、
品詞の並び順によって優先度を変える予定。
方式としては、中間データ生成スクリプトが、
優先度を変えたデータを生成する様にする。
まだ未着手。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
anthy-9100h.patch13B-23-iconv-ucdict.2009Y01.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
原作版の udict の総数約二千件のうち、
alt-cannadic での？品詞変更の影響により
品詞情報が違っているデータが約五百件、
名詞の小分類が違っているデータが約百〜二百件、
読み仮名や送り仮名や字の間違いが十件〜数十件くらい、
有った。
ソース本体の改造の手間より、
そちらの修正の手間の方がずっと大きかったと言う……。
あと、 用例辞書の元データからハッシュペアに変換する際には 既に全ての単語辞書情報を持っているのだから、 その時点で品詞ワイルドカードを全て展開してしまえば、 かな漢字変換時の用例辞書ハッシュ検索を 簡素化／省力化／高速化できる事は判ってはいるけれども、 そこまで入れ込む気にはならない。
anthy に関して、調べもの。
Anthy での統計的手法の実装の移り変わり。 2003年第４四半期頃から、統計的手法に興味が有るととれなくもない発言が、見受けられる。 2004/07頃に ML にて「統計処理的なことも試している」発言。 2004-11-27、単語対の頻度情報を用いる手法を、uim カンファレンスにて発表（柳田 氏）。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2005-March/001906.html > 2005年 3月 1日 （Yuichi Yoshida 氏） [Anthy-dev 1907] anthy-6300 > これからは、品詞だけではなくて個々の単語間の遷移確率も見るようにして、 > どの漢字に変換されるかの精度も上げていきたいと考えています。 統計的手法を使う方向である明示。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2005-August/002312.html > 2005年 8月 29日 （Yuichi Yoshida 氏） [Anthy-dev 2313] anthy-6829 > # 単語間の統計を取って候補選びの推測の足しにしようという野心的な案が進行中ですが、 > # どこまで実現するでしょうかねぇ。 なんかトーンダウン。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2005-September/002364.html > 2005年 9月 11日 （Yusuke TABATA 氏） [Anthy-dev 2365] anthyの実験的機能 形態素解析のツール（後の anthy-morphological-analyzer）の公開。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2005-September/002426.html > 2005年 9月 25日 （Yusuke TABATA 氏） [Anthy-dev 2427] anthyの開発TODO anthy-morphological-analyzer の命名。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2005-October/002524.html > 2005年 10月 13日 （Yusuke TABATA 氏） [Anthy-dev 2525] anthy-morphological-analyzer 形態素解析のツール anthy-morphological-analyzer の紹介。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2006-February/002820.html > 2006年 2月 18日 （Yusuke TABATA 氏） [Anthy-dev 2821] wikipediaからのデータ取得 > anthyの性能向上のためにwikipedia日本語版から統計情報を取ってくる > 実験をしているのですが、データを作るところまではできたので > 状況を書いておきます。 変換済みの内容だけを用いて（読み仮名・品詞・文節区切り位置の情報無しで）、統計情報を得る手法を試している事の明示。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2006-October/003168.html > 2006年 10月 4日 （Yusuke TABATA 氏） [Anthy-dev 3169] anthy-8133memm コーパスの例文の形式の明示。文節区切りの情報を用いている。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2007-February/003346.html > 2007年 2月 5日 （Yusuke TABATA 氏） [Anthy-dev 3347] anthy-8604 > anthy-8300まで使っていたHMMやanthy-8523まで使ってたMEMMのような確率的言語モデルの > 場合、文節のパターンが例文の中に出てくる確率を計算して、もっとも出現する確率の > 高いものを選択します。それに対し、今使用しているのは識別モデルというもので、 > あるパターンに対しそれが正しい変換であった確率を計算し、最も高いものを選択します。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2007-February/003387.html > 2007年 2月 28日 （Yusuke TABATA 氏） [Anthy-dev 3388] anthy-8700 > ちなみに、今のanthyで確率を推定する手法はMBR(Memory Based Reasoning) > と言うらしいです。 > http://sourceforge.jp/projects/anthy/lists/archive/dev/2007-March/003428.html > 2007年 3月 12日 （Yusuke TABATA 氏） [Anthy-dev 3429] Re: wikiのコーパス用例文収集 > 環境変数ANTHY_HISTORY_FILEにファイル名を指定すると変換の履歴が > 書き込まれるようになります。 > それを適当に編集すればコーパスとして使えるようになります。 変換結果からコーパスの例文を採取する手法の始まり。 蛇足： Anthy の文節区切りアルゴリズムは概して「ビタビアルゴリズム」と呼ばれているが、 本来？の名前は「MBR(Memory Based Reasoning)」らしい。 ＃ MBR が文節区切りの確率情報群を生成する一連のアルゴリズムの名前。 ＃ ビタビは文節区切りの確率情報群から最適解を探索するアルゴリズムの名前。 統計的手法のアルゴリズムは、過去に２回変更していて、今の中の人は３人目らしい。 HMM（5911〜8130、8131〜8132は欠番？）→ MEMM（8133memm〜8521、8522は欠番？）→ MBRビタビ（8523〜）。
Anthy 用例辞書改造の試験版を更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
anthy-9100h.patch13B-23-iconv-ucdict.2009Y03.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
用例にて、
「形容詞 ＋ 名詞」や「名詞 ＋ 動詞」のペアの時に、
品詞の並び順や付属語の形によって、
よく使われる文体になるか、全然使われないか、
偏りがありそうな気がするので、
その辺によって優先度を変えてみた。
詳細は後述。
その他。
説明の抜けの修正。
「ぁぃぅぇぉゃゅょっ」→「ぁぃぅぇぉゃゅょっゎー゛」。
「ゎー゛」が抜けていました。
Thanks to 「vagus氏 - 丘の道を登り - 2009年11月03日 - 「着ー」」
かおりん氏 や のすけ氏 によると、どうも学習量が多すぎるっぽいので、
連文節の学習量（OCHAIRE 学習量）を
３ヶ月ぶん程度から１ヶ月ぶん程度に減らしてみた。
用例にて、「形容詞 ＋ 名詞」や「名詞 ＋ 動詞」のペアの時に、 品詞の並び順や付属語の形によって、 よく使われる文体になるか、全然使われないか、偏りがありそうな気がする話。 本格的に追究した場合を考えてみると、 付属語グラフに主語・目的語などの情報を追加するか、 本気で係り受け解析をするか、 しないと駄目そうなので、本格的な追究は、しない。 厚い #KY HaC_Se 本 #T HnC_Se 厚い #KY HaC_Se 本だと #T HnC_Sk 本が #T HnC_Sk 厚い #KY HaC_Se 本が #T HnC_Sk 厚いと #KY HaC_Sk 部屋が #T HnC_Sk 暑いと #KY HaC_Sk 本に #T HnC_Sk 部屋と #T HnC_Sk 厚い #KY HaC_Se 本 #T HnC_Se 本が #T HnC_Sk 厚いと #KY HaC_Sk 夏に #T HnC_Sk 本と #T HnC_Sk 暑い #KY HaC_Se 夏 #T HnC_Se 本と #T HnC_Sk 暑い #KY HaC_Se 夏に #T HnC_Sk 夏は #T HnC_Sy 暑そうだ #KY HaCsSe （Wed,04 Nov,2009 追記） 品詞の並び順とそれに対する使われる頻度としては、以下の様な傾向になると思う。初版： - 3 あつ * ほん * 厚 * 本 * #KY HaC_Se #T35 HnC_S* - 1 ほん * あつ * 本 * 厚 * #T35 HnC_Sk #KY HaC_Se - 3 ほん * あつ * 本 * 厚 * #T35 HnC_Sk #KY HaC_SkWed,04 Nov,2009 改訂： - 3 あつ * ほん * 厚 * 本 * #KY HaC*Se #T35 HnC_S* - 3 ほん * あつ * 本 * 厚 * #T35 HnC_Sk #KY HaC*Sk - 3 ほん * あつ * 本 * 厚 * #T35 HnC_Sy #KY HaC*Se - 1 ほん * あつ * 本 * 厚 * #T35 HnC_Sk #KY HaC*Se 空いた #K5 HvCsSe 場所 #T HnC_Se 空いた #K5 HvCsSe 場所で #T HnC_Sk 場所が #T HnC_Sk 空いた #K5 HvCsSe 場所が #T HnC_Sk 空くと #K5 HvC_Sk 場所で #T HnC_Sk 相手と #T HnC_Sk 場所で #T HnC_Sk 空いてと #K5 HvC_Sk 扉が #T HnC_Sk 開くと #K5 HvC_Sk 場所が #T HnC_Sk 品詞の並び順とそれに対する使われる頻度としては、以下の様な傾向になると思う。 - 3 あ * ばしょ * 空 * 場所 * #K5 HvC*Se #T35 HnC_S* - 1 ばしょ * あ * 場所 * 空 * #T35 HnC_Sk #K5 HvC*Se - 3 ばしょ * あ * 場所 * 空 * #T35 HnC_Sk #K5 HvC*Sk この方法では、「|場所で|空いてと|」を区別できる様な情報が無い。ので諦めた。 ＃ 「場所〜」→「空〜」の順番の際に、 ＃ 「場所〜」が主語ならば「空〜」を適用して、 ＃ 「場所〜」が目的語？やらなんやらなら適用しない、 ＃ とすれば良さそうだが、その情報が無い。
Anthy 拙作パッチで何も考えずに alloca() を使っているのは、
原作版 Anthy で alloca() をさも当然の様に使っているのを見て、
何かが折れたからです。
よいこは真似してはいけません。
あと、
malloc() した後に確保できたかどうかチェックしていないとか、
malloc() で得たメモリがゼロクリアされている前提になっている部分とか、
そう言うのは全部原作版 Anthy 由来です。
よいこは真似してはいけません。
きっと、
原作版 Anthy の作者氏達のマシンは
GNU/Linux なマシンでメモリが潤沢に搭載されていて
デフォルトのスタックサイズもたっぷりと割り当ててあるのでしょう、
きっと。
limit を見てみると、stacksize が 512M とかなっていた。 余裕たっぷりと言うよりも、そんなに使う方がおかしい気がする……。
関係無いけれど、 C++ で new したメモリを realloc() したい時って、 どうしたら良いのだろう。 そういう設計になってしまった時点で敗北？ std::string や std::vector を使うべき？
Anthy 用例辞書改造の試験版を更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
anthy-9100h.patch13B-23-iconv-ucdict.2009Y04.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
文節区切りを決める際に、
用例や複合語に該当する区切り方の場合、
その区切り方の評価を高める様に変更してみた。
オプション LATTICE_BIASSCORE_BY_COMPOUND,
LATTICE_BIASSCORE_BY_UCDIC にて変更可能。
0 を指定すると、この機能を無効にする。
用例辞書の、品詞分類による優先度調整の内容を変更。
夏は #T HnC_Sy 暑そうだ #KY HaCsSe
に用例が効いていなかった。
修正後：
- 3 あつ * ほん * 厚 * 本 * #KY HaC*Se #T35 HnC_S*
- 3 ほん * あつ * 本 * 厚 * #T35 HnC_Sk #KY HaC*Sk
- 3 ほん * あつ * 本 * 厚 * #T35 HnC_Sy #KY HaC*Se ← これを追加
- 1 ほん * あつ * 本 * 厚 * #T35 HnC_Sk #KY HaC*Se
↑ 用例や複合語に該当する区切り方の評価を高めてみたものの、 どの程度機能しているかを確認できる様な変換例が思い付かない……。
Anthy 用例辞書改造の試験版をまたまた更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
anthy-9100h.patch13B-23-iconv-ucdict.2009Y06.alt-depgraph-090712.alt-cannadic-090921.tar.lzma。
「vagus氏 - 丘の道を登り - 2009年11月06日 - G-HAL 氏版 anthy 2009Y04」
の件のバグ修正。
御指摘有り難うございます。
→ src-splitter/Makefile.am
src-splitter/Makefile.am を、書き戻し忘れていました。
＃ src-splitter/Makefile.in は、ちゃんと書き戻していたという……。
→ update_params
文節区切り判定時の複合語・用例辞書辞書の検索の際に、
自立語が無い変換候補の除外を忘れていました。
＃ ４日までは覚えていたのに、
５日になってころっと忘れて web に上げてしまった辺り泣ける orz
＃＃ 自分で３日間使っていてもバグに遭遇しなかった辺り、
運が良いのだか悪いのだか……
（ただでさえ運が悪いのに残りの運を変な所で変な方向に使い果たすとも言う）。
文節区切りを決める際に、複合語や用例辞書まで検索する様にしたら、
update_params １回に 20分かかるようになってしまった。
文節区切り時の用例辞書対応前の約2.5倍の所要時間……。
「LATTICE_BIASSCORE_BY_UCDIC 0」指定すれば、
文節区切り時には用例辞書の検索をしないので、
遅くならないで済む筈。
いっそ、
候補の並び順を決める際にも用例辞書の検索をしないオプションを追加して、
update_params を速く終わる様にしてしまった方が良いだろうか。
コーパスデータベースに用例辞書が反映されなくなるから
コーパスデータベースの品質が多少は下がるけれども、
単語の有無や品詞（付属語の内容）は変わらず、
単語の評価だけが変わるので、
weak_words のバランスがずれる程度で済む筈。
……連文節での評価の変化を知らないデータベースになるぶん、
かえってバランスが良くなったりして。
weak_words データベースに関して、
連文節の例文が少ない（たかだか１万５千程度しかない）状態に於いては、
前後にどんな文節が来るのかの影響を受けないぶんだけ
単文節の評価の方が偏らずに済むから、
基準として適切そうな気もする。
と思ったけれども。
文節区切りを決める際に用例辞書を検索しない様にすると、
文節区切りの位置が変わってしまうから、
コーパスに影響が出るか……。
メモ：
『|「|さとう|」|』 → 用例辞書判定にて自立語無しに当たる。
『さ』の部分に、自立語の長さ 0、付属語の長さ 1、の候補があるらしい。
『|二週間だと|領収証は|』 → 複合誤判定にて自立語無しに当たる。
『二週間だと』が複合語「にしゅうかん #T35 #_1二_5週間」に該当して、
『に』の部分に、自立語の長さ 0、付属語の長さ 1、の候補があるらしい。
オーバーラン、15mくらい。なんか久しぶり。
Anthy 用例辞書改造の試験版。
用例に品詞情報を追加する際に、
用例のハッシュ計算にて項目毎にデリミタ入れなくちゃ、
と思っていたのだが、ころっと忘れていた。
さっきようやく思い出した。
用例に追加や変更をした時に、
内容によっては疑陽性（False Positive）の誤判定を
やらかすバグなのだけれども。
例えば。
「愛う」（あいう）と言う語が用例に有る時、
「う愛う」（あい）も用例に有ると誤判定するとか。
「愛 + が」（あい + が）と言う語が用例に有る時、
「愛が」（あい）も用例に有ると誤判定するとか。
「愛」（あい）（Hn 名詞、活用形問わず）と言う語が用例に有る時、
「愛」（あい）（品詞問わず、Cn 動詞連用形名詞化）も用例に有ると誤判定するとか。
問題の起きる例を考えていたら、
表面化しないと思えてきた。
取り敢えず更新。
用例辞書の生成／読み出し部分が変わるだけなので、
表面上は何も変わらない筈。
update_params も不要（2009Y06版と同じになる）。
boost::numeric_cast
型溢れで例外が出るキャスト、らしい。
遥か昔に、
C/C++ の組み込み用拡張でそう言う機能を標準化しよう、
だか、
独自拡張で採用してしまえ、
だか、
そんな感じの話があった様な気がする。
組込系のアセンブリ出身者は、型溢れで CY が立って当然、な
考え方をしてしまうのだけれども。
パソコン系？の高級言語出身者だと、型溢れで例外？ 何その面倒なの、と
言う方向の考え方になって。
話がかみ合わなくて色々と面倒臭い。
発端は、
単に gcc33 -WConversion がグダグダなウォーニング出してきおった、
と言うだけ。
extern uint32_t hoge( uint8_t data );
int main()
{
uint8_t d = 1;
const uint32_t ret = hoge( d );
return 0;
}
これで、hoge() 呼び出しにウォーニング出すかな……。
gcc4.3系以降ならマシになったらしいけれど。
ゴミ：
「第１７７」と言ったら「第177特務大隊」を連想するのだが。
最近の流行は「第177支部」らしい。
あとは護衛艦にそんな艦番があった気がする。
Anthy 用例辞書改造の試験版をまたまたまた更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「vagus氏 - 丘の道を登り - 2009年11月06日 - G-HAL 氏版 anthy 2009Y04」
の件のバグ修正。
御指摘有り難うございます。
> #read @top_srcdir@/alt-cannadic/extra/gt-tankanji_hikanji-34.t
> read @top_srcdir@/alt-cannadic/extra/gt-tankanji_kanji-34.t
これは、わざとやっています。
そのままインストールして、そのまま使った時に出てくる候補は、
JIS X 0208 までにしておきたかったので。
gt-tankanji_kanji-34.t は、
意図的に t を入力しないと JIS X 0213 にならないので問題無し。
> gt-tankanji_hikanji-34.t のエントリが全部「〓」
辞書のエンコーディングが JIS X 0212 EUC-JP になっていました。
用例の改造の時に、
「read_uc」の機能を、「complete_words」と「read_ucdic」に分離したのですが、
「set_dict_encoding」の位置を考慮に入れていませんでした。
それ以外の変更：
環境設定のデフォルトを調整。
ビタビモードの文節区切りにて、
実験的に辞書の頻度値を加味していたのをやめた。
＃ ビタビモードにおける文節区切りの評価を、
学習／複合語／用例の加味以外は
原作版MBRビタビモード通りの評価方法に戻した。
前方ｎ文節最長一致モードで使用する際は、
LATTICE_WITH_CAND_SCORE true
LATTICE_WITH_CANDSTRUCT_SCORE true
に変更した方が良いかも。
環境設定にて、
文節区切りに対する学習の加味の重み付けを変更可能にした。
これに伴い、一部のオプションが変更になっています。
LATTICE_WITH_LEARNEDFREQ_SCORE (t/f指定) → LATTICE_BIASSCORE_BY_LEARNEDFREQ (数値指定)
LATTICE_WITH_DEP_HISTORY (t/f指定) → LATTICE_BIASSCORE_BY_DEPHISTORY (数値指定)
キラキラ、小田和正、2002.2.27。 あれ、これ、2000年越えてるの？。
Wine、
他所様のサイトを見てみるとちゃんと動いているのに、
自分の所だと動かない件、
Fri,06 Mar,2009の続き。
以下の話は多分に憶測や根拠の無い部分が混じっているので注意。
どうも、原因は、
http://thread.gmane.org/gmane.comp.emulators.wine.devel/73671
らしい。
GNU/Linux には、ページ 0 マッピングを通してしまう、
セキュリティホールが有るらしい
（http://lwn.net/Articles/360312/）。
*BSD だと、そのセキュリティホールは修正済らしい？
wine には、ページ 0 マッピングを使わないと動作しない
問題が有るらしい（今年だか最近だかの wine にて修正したらしい？）。
なので一部の MS-Windows アプリケーションは、
GNU/Linux + wine だと動作するけれども
*BSD + wine だと動作しないらしい。
一部って、
DirectX だか Direct3D だか使っている物は全滅な気もするけれど。
あと、GNU/Linux は、wine が動く為に、
そのセキュリティホールを治さない方向らしい？。
以上の話は多分に憶測や根拠の無い部分が混じっているので注意。
「OS ＝ アプリケーションランチャー」のスタンスならば、
GNU/Linux の対応は「望まれている」対応なのだろうけれど。
「OS ＝ 計算機の管理機構」のスタンスならば、
GNU/Linux は OS たることを捨てているわけで。
Anthy 用例辞書改造の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
anthy-agent にて一部の複合語を変換して PRINT_CONTEXT した時と、
一部の複合語に用例が適用された時に、
SIGSEGV するバグ修正。
一部の複合語と言うのは
「複合語辞書には載っているけれども、
通常の単語辞書には載っていない単語」。
具体例を挙げると、「|工業高等|専門学校|」（|こう|せん|）とか。
用例改造の際に、
変換候補一覧にて品詞名を取得する様に改造したのだが。
「通常の単語」と「通常の単語辞書にも載っている複合語」は、
変換候補一覧での品詞名の取得方法が同じなのだが、
「通常の単語辞書には載っていない複合語」は、
変換候補一覧では品詞名が取得不能だった。
その除外処理を行っていなかった。
ちなみに文節区切り位置の選定の際は、
「通常の単語」も
「通常の単語辞書にも載っている複合語」も
「通常の単語辞書には載っていない複合語」も、
全て品詞の取得方法は同じ。
どれも単語の出自の辞書に載っている品詞が返ってきた。
例えば「|愛想を|尽かす|」（|あいそを|つかす|）だと、
通常の単語辞書由来の「愛想を」は名詞、
複合語辞書由来の「愛想を」は動詞、
を返してきた。
ニキシー管 と エルフィン管 と。
Mon,09 Jan,2006、 Sun,02 Aug,2009、 の続き。
「ニキシー管」は、商品名（固有名詞）らしい。
特許も取得されているので、同方式の表示素子を作るとマズいらしい。
知らなかった。
一般名詞としては、
「冷陰極放電管」、「冷陰極ネオン表示管」、
「ガス放電表示器」、「ネオンガス放電管」、「プラズマ表示器」、
「ネオン式数字表示放電管」、「表示放電管」、
（これ以上は探すのが面倒になってやめた）、
とか、色々見つかって、どれが一般的なのかよく判らない。
また、このタイプの表示管の中でも、文字の形成方式に違いがあり、
１枚の電極板に付き１文字を表示し、
表示する文字の種類だけ電極板を持っているタイプが、
アメリカのバローズ社の「ニキシー管」らしい。
それから、表示する文字をセグメント（部位）に分割して、
複数のセグメントに分割してある電極板１枚で表示するタイプが、
日本の岡谷電機産業の「エルフィン管」らしい。
オネアミスの翼 王立宇宙軍 に出てくる表示管は、 セグメント分割の切れ目が見つからず、 多極を重ねている影も見つからないので、 ニキシーなんだかエルフィンなんだか判らない。
alt-cannadic。
何故か「ニキシー管」は辞書に載っていた。
なぜこんな専門用語が……。それとも案外と一般的なのだろうか。
Anthy 用例辞書改造の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
コーパス処理関連の
辞書／例文のメンテナ側が操作する部分の仕様変更と、
用例辞書の記述方法追加なので、
一般利用に関する変更は全く無し。
コーパスの確率データベース計算時は、
学習の再生／記録を行わず、
複合語／用例を用いない仕様に変更。
→
仕様変更に踏み切ったとどめは
「vagus氏 - 丘の道を登り - 2009年11月09日 - 効いてるかどうかが分からない - 【追記】11/9,11/10」
付近の、
update_params に時間がかかってファンが、
の件や、
（学習のリフレッシュ間隔を短くしていると）
update_params が滅茶苦茶遅くなる、
の件辺り。
私だけでなく、みんなはまるんだ、と言う事で、ふみきり。
また、
品詞のつながりの確率計算の際に複合語を使わないようにして、
品詞のつながりの変な情報が混じらない様にしてみた。
→
約20分から 2分40〜３分に高速化……。
10〜15分の高速化分は用例を検索しないぶん、
2〜5分の高速化分は学習を検索・記録しないぶん、
数十秒〜1分の高速化分は複合語を検索しないぶん、
らしい。
原作版 Anthy だと、確率計算の際に、
それよりも前に処理した例文を学習した影響を受けている模様。
学習の影響を受けても確率計算に影響が無いのかどうなのかは不明。
コーパスの例文にて品詞指定が行えるようにした。
コーパスの例文が変換できなかった際に stderr にも表示するようにした。
→
こんな感じ。
|かねが|なる| |鐘が|鳴る| |Nk|Ve|
anthy-agent --anonymous --proccorpus すると、
コーパスの確率データベース計算と同じ状態で変換を行うようにした。
→
前述のコーパスの例文にて品詞指定を行う際の、
どんな品詞を使えるのかの確認用。
あと、コーパスの例文が変換できなかった際の状況再確認用。
用例辞書にて、３文節以上からなる内容を１行で記述できるマクロを追加。
→
こんな感じ。
\compound 3 |い+の|なか+の|かわず+_|たいかい+を|し+らず| |井+の|中+の|蛙+_|大海+を|知+らず| |#T35+*|#T35+*|#T35+*|#T35+*|#R5+*|
見ての通り、データを作るのがかなり面倒。
anthy の品詞クラス。
「金が」や「鐘が」は、名詞+格助詞なのだろうか、名詞+連用形なのだろうか？、
「無い」は、形容詞+終端なのだろうか、連体修飾なのだろうか？、
「鳴る」は、動詞+終端なのだろうか、動詞+連体なのだろうか？。
とりあえず、anthy は、名詞+格助詞、形容詞+終端、動詞+終端、が好きらしい。
OpenBSD にも mplayer/mencoder の ports があった。
インストールしようとした。
x264 のインストールでこけた。
x264 が log2f() を使っているのだが、
そんな関数は無い、とか言って蹴られた。
英語の web で検索してみた所、散々既出らしい。
日本語の web だと１件だけ見つかったけれど、
面倒になって投げ出していた。
log2, log2f, log2l は C99 POSIX.1-2001 だとかで、
GNU/Linux方面だと GNU libc 2.1系にて実装済みだが、
*BSD系では未実装らしい。
C99化それ自体に関しては、
GNU/Linux でも完了していないっぽい
（ISO/IEC 9899:1999/Cor.3:2007 まで含めると
Missing とか Broken とか言う項目が残っている）。
FreeBSD だと 8.X系にて一部は実装済みだが、完了まではまだまだらしい。
賽の河原？
C++0x 出ちゃう……。
そう言えば、FreeBSD の C99 対応に関して、
C99仕様の thread-safe な関数に仕様変更しようとして、
POSIX で非thread-safe と規定されている関数まで間違って
thread-safe にしてしまっていらんバグが増えた、
とか言うウワサも聞いたような……。
ports を古い版にして x264 の 2008年版にしたら、
log2f() を使っていなかったのでインストールが通った。
最新版を使いたいなら、
log2f(i+1) → (logf(i+1)/logf(2))
する。
mencoder で作成した動画を
mplayer で再生して早送り／巻き戻ししようとすると、
先頭に戻ったり再生終了したりしてしまう……。
keyframe が足りないのかと思って試行錯誤してみたが駄目。
man mplayer してみたら……。
<- and ->
Seek backward/forward 10 seconds.
up and down
Seek forward/backward 1 minute.
pgup and pgdown
Seek forward/backward 10 minutes.
……そりゃ、10秒ちょっとの動画で
早送りしたり巻き戻ししたりしたら、
先頭や最後尾に届いちゃうわな…… orz
１秒単位の早送りと巻き戻しを下さい……。
あと、硬派でシックなスキンも欲しい。
OpenBSD の ports の gmplayer は、
gmplayer のデフォルトスキンと違っていて、わりとシックな感じ。
と思ったら、単に古いバージョンのデフォルトスキンなだけなのね。
取り敢えず、
Corelian, Industrial, hwswskin, xmmplayer 辺りが無難そう。
mplayer には aalib を使った再生モードがあるけれど、
需要が有るのだろうか……、冗談で実装してある？。
mencoder/mplayer の件は Mon,16 Nov,2009に続く。
fvwm。
時々、
ウィンドウ（mplayer関連とかOpenOffice関連とか）や
ダイアログボックス（OpenOffice関連とかuimのステータスとか）が
行方不明になって困っていたのだが、
ようやく原因が判明。
fvwm のレイヤー指定のデフォルトは 2 4 6 なのだが、
手元ではこれを 3 5 7 に変更して使っていた。
ところが、時々、レイヤー 4 決め打ちで表示される場合が有るらしい。
デフォルトレイヤーを 2 4 6 に戻したら、あっさりなおった。
過去数年なおせないでいたのは一体……。
ちなみに uim のステータスが行方不明になる件は、
画面外や別のウィンドウの入力位置に表示されてしまって
行方不明になっている場合もある。
これがどうにも原因がつかめない。
fvwm2 を使っている時に
ウィンドウのフォーカス移動を特定の手順で行うと発症するっぽい
のだが……。
comparing floating point with == or != is unsafe
意図的にフラグで 0.0 を使って判定している場合、
ウォーニング出さない様にできないかな。
Anthy 用例辞書改造の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
変換候補の並び順の学習が文節区切りに過剰に反映されてしまう調整ミスを修正。
用例の機能を色々追加／強化。
keepalive 機能を有効にしている時に。
文節区切りにて用例辞書を検索する機能を追加
（ENABLE_KEEPALIVE_REFER_UCDIC_FOR_LATTICE）。
候補の並び順にて用例辞書を検索する機能を追加
（ENABLE_KEEPALIVE_REFER_UCDIC_FOR_CANDIDATE）。
→
例：「年末 → 商戦」の用例に関して。
まず、「ねんまつの」を「年末の」で変換確定。
次に、「しょうせん（以下、なんか適当な内容）」を変換すると。
第１文節にて「商戦」を含む文節の区切り方の評価を高めに調整する。
文節区切りにおいて「商戦」を含む文節の区切り方が選択されたならば、
候補の並び順において「商戦」の評価を高めに調整する。
用例辞書にてマイナス点に対応。
それに伴い、
フラグ無しの指定子を '-' から '_' に変更（まぎらわしいので）。
用例辞書にて接頭辞／接尾辞を連結した内容への判定対応。
→
「|ほぼ|千部|」（|ほぼ|ぜんぶ|）（自立語が「千」で接尾辞が「部」）を
マイナス点指定できる。
用例辞書にて、単文節の内容を指定可能にした。
→
「|ほぼ千部|」（|ほぼぜんぶ|）
（接頭辞が「ほぼ」で自立語が「千」で接尾辞が「部」）
「|千部|」（|ぜんぶ|）
（自立語が「千」で接尾辞が「部」）
「|千パターン|」（|ぜんぱたーん|）
（自立語が「千」で接尾辞が「パターン」）
などに対してマイナス点指定できるようになった。
→
但しこれだけだとうまく行かない。
MBR+ビタビの中の人にとっては、
「|全|パターン|」（|Ne+Se+２文字|+|Ne+Se+４文字|）よりも
「|全波|ターン|」（|Ne+Se+３文字|+|Ne+Se+３文字|）の方が
評価が高いらしい。
品詞接続と総文字数と総文節数が全て同じ場合、
各文節の文字数が拮抗するような実装が行われている。
web でも公開されている
Anthy に関する何だったかの対外発表の資料に有ったのだが、
例文の統計を取った結果、文節の文字数に偏りがあったので、
かな漢字変換での文節区切りの際にもその文字数に近付く様に、
確率的手法で用いている確率値を偏らせたそうな。
その確率を偏らせる部分の実装が、
各文節の文字数が拮抗するようになっていた。
→
用例にて、
「|千パターン|」をマイナス点、
「|全|パターン|」をプラス点、
とすると、取り敢えずそれっぽくなった。
原作版のビタビの文節区切りアルゴリズムの実装だと、
右端の文節（中途枝切りを実施した場合は枝切り時点の右端の文節）
に対する評価補正は文節区切りの全体評価に影響するけれども、
それ以外の文節の評価補正は全体評価に影響しない設計になっている。
例：
用例機能にて「|千パターン|」（ぜんぱたーん）の文節区切り評価を下げた場合、
「|千パターンを|」の評価よりも
「|全|パターンを|」の評価の方が高くなる。
しかし、
「|取り|得る|千パターンを|試した|」と
「|取り|得る|全|パターンを|試した|」の
評価には影響せず、
相変わらず「|取り|得る|千パターンを|試した|」が選択される。
→
オプション VITERBI_MODE_METAWORD_EFFECTS_SENTENCE（デフォルト true）にて、
中途の文節の評価を文全体の評価に加味する様にした。
用例にて文節の評価に補正が入った場合、文節区切りにも反映されます。
ｎ文節最長一致では、元々、てきとーに波及する様にしてあるから関係無し。
文節区切り時において、単文節学習の評価が高すぎる調整ミスを修正。
学習済みの単文節が大量に有ると、
バグというか調整ミスというか同士が相殺しあって
そこそこまともな状態になるので、
気付くのがかなり遅れた。
用例試験版では無い方の patch13B でも直撃だったのでバックポート。
Anthy 用例辞書改造の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
文節区切り学習の反映アルゴリズムを大幅に変更してみた。
原作版・拙作パッチ問わずこれまでの全ての Anthy では、
文節区切り時に、
入力内容と読み仮名が一致する連文節の学習が見つかると、
必ず学習した内容を用いて文節を切っていた。
でも、
読み仮名が一致したからと言って必ず文節を切っていると
文節が過剰に細切れになる傾向が有るのではないかと言う懸念と、
MBR+ビタビは確率を用いるアルゴリズムなのだから、
学習内容も確率的に反映させる事ができるのではないかと言う疑問と。
そんなわけで、
入力内容に学習と一致する物が見つかった場合、
確率を上げるだけにして必ず用いるとは限らないモードを追加。
従来の「必ず学習した位置で文節を区切る」だと強過ぎると思う場合、
オプション
LATTICE_WITH_OCHAIRE_STRONG false
LATTICE_WITH_OCHAIRE false
を記述して、
VITERBI_MODE_LATTICE_BIASPROB_BY_OCHAIRE
LATTICE_BIASSCORE_BY_COMPOUND
LATTICE_BIASSCORE_BY_UCDIC
LATTICE_BIASSCORE_BY_OCHAIRE
LATTICE_BIASSCORE_BY_LEARNEDFREQ
LATTICE_BIASSCORE_BY_DEPHISTORY
にて、
確率・得点のパラメータを適当に設定すると、
連文節学習の効きの強さを変更できます。
どのくらいの値が適当なのかまでは判りません。
標準設定だと
学習していない内容の２倍〜20倍くらいの確率に設定してあるので、
やっぱり必ず学習した内容を使ってしまうのではないかと思われます。
前方ｎ文節最長一致モードの場合、
VITERBI_MODE_LATTICE_BIASPROB_BY_OCHAIRE は 0.0〜1.0e-13 くらいにして、
LATTICE_BIASSCORE_BY_OCHAIRE の値を変えた方が調整しやすいかもしれません。
LATTICE_BIASSCORE_BY_OCHAIRE 0.0 にて
学習した内容と学習していない内容がほぼ等確率、
LATTICE_BIASSCORE_BY_OCHAIRE 500.0 にて
学習した内容は学習していない内容のほぼ1.5倍の確率、
LATTICE_BIASSCORE_BY_OCHAIRE 1000.0 にて
学習した内容は学習していない内容のほぼ２倍の確率、
LATTICE_BIASSCORE_BY_OCHAIRE 2000.0 にて
学習した内容は学習していない内容のほぼ３倍の確率、
になります。
って sample/conf に書き忘れた。
LATTICE_WITH_OCHAIRE_STRONG true
にしないと学習が反映されませんが、
これはそう言う仕様のアルゴリズムだから。
文節区切りのパラメータの件は
Wed,18 Nov,2009に続く。
Get Wild、TM NETWORK、1987.4.8、の編曲。
気分上々↑↑、mihimaru GT、2006.5.3。 あれ、これも、2000年どころか2005年も越えてるの？。
mplayer/mencoder、
Thu,12 Nov,2009の続き、
Thu,19 Nov,2009に続く。
キー操作だと 10秒／１分／10分 単位でしかシークできない件。
mencoder でエンコードする際に
入力 fps を実際の 1/10 にしてエンコードし、
mplayer にて再生する際に 10倍速再生にしたら、
1秒単位でシークできるようになった。
Thu,19 Nov,2009 追記：
キー操作のカスタマイズで、
「10秒早送り」「10秒巻き戻し」を
「2秒早送り」「2秒巻き戻し」に変更したら、
そう言う小細工をしないでも細かいシークができた。
シークのキー操作への反応は mencoder時の出力 fps で決まるらしく、
-ofps で少なくとも 2 以上くらいを指定して
強制的に duplicate frame(s) でエンコードしないと、
キー操作の反応が壊滅的に悪くなる事があった。
vcodec=mpeg4 よりも vcodec=libx264 の方が、
動画ファイルのサイズが 1/4 くらいに縮まった。
毎秒2.5コマで png で画面キャプチャした内容を動画に変換する場合、
mencoder "mf://*.[0-9]*.png" -mf fps=0.25:type=png -ovc x264 -x264encopts keyint=1:crf=20 -ofps 8 -o 0B.avi
mencoder "mf://*.[0-9]*.png" -mf fps=2.5:type=png -ovc x264 -x264encopts keyint=1:crf=30 -o output.avi
か
mencoder "mf://*.[0-9]*.png" -mf fps=0.25:type=png -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell:keyint=1 -ofps 8 -o output.avi
くらいが良さげな感じだった。
再生する時は、
mplayer -speed 10.0 output.avi
にて10倍速再生。
ファイルサイズが多少大きくなっても構わないなら、
crf は 25 か 20 くらいの方が良いかも。
10秒分で、
元の png データが 640KB くらいで、
出来上がった動画が 1.2MB くらい。
……増えていませんか？。
crf=30 くらいにすると動画が 640KB くらいに縮まるけれども、
だいぶ汚くなってくる。
あと、-ofps を減らすとかえって動画ファイルのサイズが増える謎。
MNG や APNG は対応環境が壊滅的に少ないので除外。
gif に変換すると 920KB くらい。
gif-animation の時間軸方向無圧縮に変換すると 1.7MB くらい
（だからなんで増えるのだよ……）、
ただしシーク不可なので使い物にならない。
gif-animation の時間軸方向最大圧縮に変換すると 370KB くらい、
ただし非対応の再生ソフトが結構有る上に
やっぱりシーク不可なので使い物にならない。
↑ gifview で再生すれば、コマ送りのシークは可能だった。
但し、
時間軸方向の圧縮への対応が不完全で
時間軸方向の圧縮をしたデータだと
一時停止後の再開やコマ送りモードでこけるのと、
通常の早送り／巻き戻し／シークが無いのと。
mplayer にて、
seek OSD を black band に表示させる方法が判らん……。
せめて seek 非表示で timer と total time だけ表示にしたいが、
これもできない……。
それから、一時停止状態で早送り／巻き戻し／シークをすると
一時停止が解除されてしまうのもまずい。
Anthy 用例辞書改造の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
文節区切りの際に複合語が反映されないバグ修正。
文節区切りの際の学習の反映にて、
学習の種類による重み付けを追加。
ポインタがらみの typo がまたあった。
例に依って例の如く、& が１つ過剰。
工画堂の PD1 の中古、ふつうに￥4,480-。
Anthy 用例辞書改造の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
昨日、追加した部分に static を付け忘れていたので修正。
点検してみたら、他にも static や const の付け忘れがあったので修正。
原作版由来の部分にも static 付け忘れが有る様だけれども
収拾が付かなくなって手に負えなくなると嫌なのでパス。
あと、原作版由来の部分は
全くと言っていいほど const を使っていないけれども、
これはそういうコーディングスタイルなのだろうか？、
K&R派だと const 使わないのだっけ？。
↑ 2009Y15版以降、
文節区切り学習のバランスがうまくとれていないので注意。
LATTICE_BIASSCORE_BY_OCHAIRE や
VITERBI_MODE_LATTICE_BIASPROB_BY_OCHAIRE 辺りが
もうちょっと大きめの方が良いかも。
「|旧|仕様|」（|きゅう|しよう|）を学習しても、
VITERBI_MODE_LATTICE_BIASPROB_BY_OCHAIRE 6.0e-7
もしくは
LATTICE_BIASSCORE_BY_OCHAIRE 3.0e+8
くらいにしないと学習した方の候補が出ない。
どうやら、統計的手法による
『「文頭」＋「動詞+終端」＋「文末」』と、
『「文頭」＋「名詞+終端」＋「名詞+終端」＋「文末」』の、確率の差は、
300,000〜6,000,000倍（計算間違えているかも）くらいあるらしい。
物によっては確率差が２倍程度の物もあるので、
なんというか、もう、どうしようもない……。
↑ 辞書を確認したら、「きゅう #PRE 旧」があった。
機能していない？
src-splitter/wordlist.c の make_pre_words()、
一般名詞接頭辞の機能が意図的にコメントアウトしてあった。
さて、どうするか……。
DIARY の 6/12（2002年？）に、そう書いてあった。
「名詞に接頭辞をつけないようにした。
次は(a)接頭辞だけで文節になるようにする、
(b)接頭辞を含むmetawordを作る」
だそうで。
Sun, 12 Oct 2003 の
「[Anthy-dev 248] anthy-4609」辺りが予告？になって、
Fri, 17 Oct 2003 の
「[Anthy-dev 254] anthy-4616 (Re: anthy-4609)」にて
接頭辞は数詞と人名限定にしたらしい。
その後、
Sun, 25 Sep 2005 の「[Anthy-dev 2427] anthyの開発TODO」辺りから、
どの名詞にどの接頭辞が付くか、の情報を持たせる案が出て、
これから統計情報（コーパス）を実装するからそれでなんとかなんるんでは、
と言う事ですぐ消えて、それっきり、かな？。
↑ 数詞に付く接頭辞に関しても、 「vagus氏 - 丘の道を登り - 2009年03月09日 - cannadic改 20090308 (depgraph改 も更新)」 にて、 「誤変換を多発させるので「数詞につく接頭辞(NNPRE)を外した(「第」のみ残した)」 とのアナウンスが。
alt-depgraph-090712 + alt-cannadic-090921。
「付け忘れや」（つけわすれや）が、
「|付け|忘れ|や|」（|つけ|わすれ|や|）になる。
「|付け|忘れる|」や、「|付け|忘れて|」や、「|付け|忘れが|」は、
直感的な区切りになる。
さて、何処から手を付けたらいいのだろう。
それとも、この区切り方になるのが正しいのかな。
……。
なにかとっても既視感が……。
「vagus氏 - 丘の道を登り - 2009年09月15日 - 応答色々」
の「動詞連用形名詞化」と同じだった。
mplayer で、何かエラーが出る件、
Thu,09 Oct,2008の続き。
ports/multimedia/ffmpeg を
sudo env USE_GCC="4.4" make install してみた。
やっぱり「ffmpeg を gcc 4.2 以上にしろ」が出る。
ports/multimedia/mplayer を
sudo env USE_GCC="4.4" make install してみた。
「ffmpeg を gcc 4.2 以上にしろ」のエラーメッセージが出なくなった。
そっちかい……。
source tar ball を確認してみたら、
mplayer の中に ffmpeg のライブラリが同梱してあった。
mplayer/mencoder、
Mon,16 Nov,2009の続き。
キー操作だと 10秒／１分／10分 単位でしかシークできない件。
input/input.c の seek がらみの行の数値を書き換えたら、
１秒単位のシークができる様になった。
それと当時に、１秒単位のシークが搭載されていない理由も判った。
１秒単位で巻き戻すと、キーフレームと位置決めの都合で、
何回巻き戻してもさっき戻した地点と同じキーフレームになってしまって、
結局戻っていない、と言う事態になった。
２秒単位なら問題無かった。
一時停止中にシークすると、一時停止が解除されてしまう方は、
単純に、一時停止中に１個だけコマンドを実行する、
と言う機能が実装されておらず、
一時停止中のコマンド実行 ＝ 一時停止解除、
になってしまっているだけだった。
コマ送りは単純に、
一時停止中のコマンド（コマ送り）実行で一時停止解除した直後に、
実行すべきコマンドがコマ送りだったので即座に一時停止、
結果として一時停止した直後に停止するから１コマしか進んでいない、
と言う実装になっていた。
色々調べていたら、
${HOME}/.mplayer/input.conf に書けば、
いちいちソース改変＆ビルドしなくても、
簡単にカスタマイズできたらしい事に気付く……。
↑ 一時停止関連の微妙な仕上がり加減は
totem（旧gst-player？）が良さげなのだが、
ショートカットキーが一切無いのが不便。
あと、OpenBSD の ports に来ていない。
OpenBSD の ports にも来ていた、ports/gnome/totem だった。
さらに、gstreamer や GNOME に依存しているので、
バイナリパッケージを使わずにインストールしようとすると
コンパイル作業を延々12時間以上（20時間くらい？）
ぶん回し続ける羽目になった。
↑ OpenBSD 4.4-RELEASE版で各種 ports をインストール済の所に、
セキュリティフィックスがらみで
一部の ports だけ CURRENT版に更新していて
（4.6-RELEASE版だと未修正だった）、
その状態で 4.4-RELEASE版の ports をインストール
（4.6-RELEASE版や CURRENT版だとビルドでこけたので）
とか言う事をやったら、
その結果、ports のライブラリの依存関係が狂って、
GNOME系アプリケーションが全滅、
一切動かなくなってしまった……。
依存関係の立て直しの為に、ライブラリ関連の ports を、
CURRENT版 ports に依存する 4.4-RELEASE版 ports、
として再構築しなおしして、ようやく復旧。
コンパイル作業 18時間＊３日を余計に費やして、
月曜にようやく終わった……。
各種動画再生ソフト。
mplayer : 汎用再生。win32-codecs 対応。
プレイヤーとして無難。
xine : 汎用再生。win32-codecs 対応。
プレイヤーとして無難。
totem : 汎用再生。GNOME系の gstreamer の GUIラッパ。
シンプル、統合環境として無難。
kaffein : 汎用再生。KDE系の xine の GUIラッパ。
シンプル、統合環境として無難。
vlc : 汎用再生。Qt4系／wx系の gstreamer の GUIラッパ。
GUI が Qt4系や wx系なので、環境によっては GUI がやたら重くなる。
ogle : DVDプレイヤー。GNOME系。DVDではない動画再生はできない。
補足：
mplayer と xine は、
一時停止中にシーク／早送り／巻き戻しすると一時停止が解除されてしまい、
再生開始時／再生終了後は splash画面になってしまう。
ショートカットキーが豊富で、キー操作だけで全て済む。
totem と kaffein は、
一時停止中にシーク／早送り／巻き戻ししても一時停止が解除されず、
再生開始時／再生終了後に先頭／最後のシーンを表示し続ける。
ショートカットキーが貧弱？。
総論：
単に再生するだけなら mplayer か xine のどちらかがあれば用が済む。
両者の明確な差は無い。
動画再生中にポーズやシークを頻繁に行ったり、
再生開始時に先頭シーンを止めてみせたり、
再生終了時に最終シーンを止めてみせたりする必要がある場合は、
totem か kaffein が無難。
GTK/GNOME系を使っているのか Qt/KDE系を使っているのかに合わせて
どちらか選べば良し。
↑ リモートで実行する時は、 mplayer が一番高速かつ一番安定で、一番使いやすかった。
↑ gstreamer/gst系をリモートで実行する場合、
** Message: Error: Could not initialise Xv output
/usr/ports/multimedia/gstreamer-0.10/plugins-base/w-gst-plugins-base-0.10.19/gst-plugins-base-0.10.19/sys/xvimage/xvimagesink.c(1333): gst_xvimagesink_get_xv_support (): /video-sink/bin0/xvimagesink0:
No port available
とかなってこける。
あるいは、
「マルチメディア・システム・セレクタ」を使って設定を変更しろ、
と表示されるけれども、
「マルチメディア・システム・セレクタ」が何処にも存在しない。
どうやら /usr/local/bin/gstreamer-properties が
「マルチメディア・システム・セレクタ」らしい。
OpenBSD なら ports/x11/gnome/media、
FreeBSD なら ports/audio/gnome-media、
を
インストールすると /usr/local/bin/gstreamer-properties が入るので、
これを使ってビデオ出力の設定を変えると、解消できる。
「マルチメディア・システム・セレクタ ＝ gstreamer-properties」
と言う所までは日本語で探しても英語で探しても割とすぐに見つかったが
（でも何故か見つかる情報は全部 Ubuntu系）、
じゃぁ gstreamer-properties はどのパッケージに入っているのか、
と言う話が、何処を探しても見つからなかった。
英語で探しても駄目。
何とか探し当てたものの、
GNOME/KDE非依存の筈の gstreamer が、
カテゴリ audio とか x11 とかの gnome な media って、
わかるかいそんなの……。
浪漫飛行、米米CLUB、1987.10.21初、1990.4.8シングル。
バトルテック グレイ・デス ３巻、４巻、各￥105-。
続刊物で全巻揃わないって悲しい……。
しかも確かこのシリーズは、邦訳が途中で打ち切りになっていた筈……。
原語版が前期３巻の後期２巻で全５巻、
原語版１巻を邦訳２巻にしていて、邦訳は６巻までしか出ていない。
原語版の後期の４巻と５巻が邦訳されていない……。
前期シリーズは全巻出ているから、
話の途中で打ち切りになっていない点は、まだマシだけれど。
オースン・スコット・カードの「エンダーのゲーム」の裏シリーズの、
ハヤカワ版邦訳の続刊はまだですか。
原語版が出てから２〜３年は経っているけれど……。
これはもろに話の途中で切れているんですが……。
『Shadow of the Giant』だけでなく、
『First Meetings:In Ender's Universe』と
『Ender in Exile』の、
更に２巻が出ていたらしい。
ポイントの現金相当額。
率が５％上がっていた。
しかも私がポイントを使った
数時間後だか10時間後くらいだかに、即日発表即実行だったらしい。
それの数日だか１週間だかくらい前に、
他社ポイントへの交換に対応する旨の広報は出ていたけれども、
率変更は全く言及していなかった。
確かに、自社内消費よりも、新規に開始する他社交換の方が、
現金換算額が５％良いのは気にはなっていたけれどさ……。
このグループ企業で、
この手の即日発表即実行の数時間〜数日前のサービス向上前にやってしまって、
向上の恩恵を受け損なうのを食らったの、これで３回目くらいな気がする……。
１回だけ、窓口処理の遅延の結果、向上後に当たった予定があるけれど……。
alt-cannadic-091122:
「再入」（さいにゅう）がない
（たぶん Reentry の計算機ソフトウェア方面での翻訳語）。
＃ 今まで気付かなかったのが意外。
品詞は……、わからない……。
「再入な」 ？
「再入さ」 ×
「再入する」 ○
「再入の」 ？
格助詞かどうかは……よくわからない。
その他のパターン：
「再入が」
「再入で」
「|再入|可能|」 （|さいにゅう|かのう|）
「|再入|可|」 （|さいにゅう|か|）
「|再入|不可|」 （|さいにゅう|ふか|）
「|再入|不可能|」 （|さいにゅう|ふかのう|）
「|再入|防止|」 （|さいにゅう|ぼうし|）
ううむ……。
WX3 の辞書によると、#SX らしい。「さ行変格活用動詞」？
canna の pubdic によると、#T30 らしい。
Anthy 用例辞書改造の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
自立語が無いような内容を変換した際に、
用例辞書検索でバッファアンダーランするバグを修正。
anthy はメモリ管理機構を自前で持っている為、
OS や基本ライブラリや検査用アプリケーション等で提供されている
メモリ管理／メモリアクセスを失敗／間違えているバグの検出機能が、
全く効かない箇所があるのだよね……。
今回はもろにそこに直撃。
気付くのが遅れた。
あと、
anthy が持っているメモリ管理機構は
用済み後のメモリ自動解放機能（ガーベージコレクト？）を持っている為、
内蔵のメモリ管理機構を使っている処理では
明示的なメモリ解放が無いのだよね……。
Anthy 複合品詞の文節分離の試験版、追加。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
anthy-9100h.patch13B-23-iconv-ucdict-combinedphrases.2009Y29.alt-depgraph-090712.alt-cannadic-091122.tar.lzma
「|千|パターン|」（|ぜん|ぱたーん|）とか
「|付け|忘れが|」（|つけ|わすれが|）とか
「|付け|やすい|」（|つけ|やすい|）とか
「|付け|始める|」（|つけ|はじめる|）
の様な複合品詞にて、
文節を区切った状態のまま、複合品詞のつながりを持つ様になります。
そもそも Anthy は、
『［「接頭辞（０〜１個）」＋「自立語（１個）」＋「接尾辞（０〜１個）」＋「付属語（０文字以上）」］で１セットとし、
通常は１セットで１文節を構成し（複合語のみ２セット以上で１文節）、
それら文節群で１文を構成する』、
という基本設計になっているのですが、
それをぶち壊す改造（自立語が０個で文節を作っている）なので、
何がどうなるか判りません。
踏み切った、とどめ、その１：
「のすけ氏 - 日記みたいな何か - 2009年11月10日 (火) - 今日も」
n氏> （要約）「ぜんぱたーん」で「千パターン」が出てしまう
v氏> （要約）「接頭辞＋数詞＋助数詞」という繋がりを持ちつつも
「|千|パターン|」と区切れば、多少マシになるのかな
＃ 「全」を数詞にすると「全パターン」が出る様になると共に、
「何全パターン」とかも出てしまう。
踏み切った、とどめ、その２：
Wed,18 Nov,2009
辞書に「きゅう #PRE 旧」が登録されているけれども
名詞接頭辞の機能が封印されているので、
「|旧|仕様|」（|きゅう|しよう|）と文節が別れて、
１文節の「|窮し様|」（|きゅうしよう|）より評価が低くなってしまう。
踏み切った、とどめ、その３：
正確には、踏み切った後の作業中の方針調整になりますが。
「vagus氏 - 丘の道を登り - 2009年11月23日 - いくつか応答」
複合動詞への対応方針が決まらないそうなので。
では、１文節型と文節分離型で実装してみて実地で試してしまえ、
と言う事で。
原作版 Anthy での、この辺りに関するこれまでの流れの憶測
（嘘や間違いがあるかも知れないので注意）：
一般名詞接頭辞（#PRE）の機能が削除されたのは、
「変換精度がいまいち」（Sun, 12 Oct 2003, Anthy-dev 248〜254付近）
だかららしい。
その際に数詞の接頭辞（#NNPRE）を残した理由は不明。
その後、統計的手法（コーパス）への移行をプロジェクトの中核にした為に
（Sun, 25 Sep 2005, Anthy-dev 2427辺り）
接頭辞／接尾辞がらみの改装は棚上げ、
そのまま放置されて現在に至るらしい。
……、詳細を書くととんでもなく長くなりそうだ。
「|千|パターン|」の話：
「|旧|仕様|」の話：
複合動詞の話：
複合名詞の辞書をどう作るか：
Mon,30 Nov,2009、
Fri,18 Dec,2009、
Sun,27 Dec,2009に続く。
中核となる自立語に対して、
接頭辞や接尾辞を連結して１文節として生成する部分があるので、
そこを探し出して、
連結せずに分離して文節を生成するようにしつつ、
文節のつながりが強いと言うフラグを追加。
あと、文節のつながりが強いと言うフラグの機能自体を追加。
こう書くと簡単だが、anthy の基本仕様をぶち壊す改造なので、
けっこう面倒。
結局、
フラグを多種類用意して if 文の連打、と言う事をやったため、
文節のつながり情報を持つ処理の一般化は無理
（単語Ｎグラムへの改造は無茶）。
オプション LATTICE_SEPARETE_PRE_INDEP_POST true にて、
分離した文節になる。
オプション
VITERBI_MODE_LATTICE_BIASPROB_BY_COMBINED_*,
CANDIDATE_SCORE_COMBINED_*,
にて、加算する確率と得点を変更可能。
前置き：
単純に、接頭辞〜自立語間もしくは自立語〜接尾辞間で文節を切っても、
例えば「|旧|市街地|」（|きゅう|しがいち|）
（※注意※ 誤変換対策で既に１文節の単語で登録されている）の場合、
「|急|市街地|」が出るか「|旧|市街地|」が出るかの問題がある。
ここで「|旧|市街地|」が優先される様に「#PRE 旧」の評価を高くすると、
今度は「|急|降下|」（|きゅう|こうか|）
（※注意※ 誤変換対策で既に１文節の単語で登録されている）の変換結果が、
「|旧|降下|」とかなってしまう。
「|急|市街地|」とか「|旧|降下|」とかはありえないから、とか考えると、
「|旧市街地|」や「|急降下|」の様に単語として登録、と言う考えになるけれども、
そうすると接頭辞／接尾辞が付く全パターンを単語登録するのか、と言う問題が。
じゃぁ文節を切る様にした状態で、
接続のパターンを登録する機構を追加して変な候補が出ないようにする、
とかやっても、やっぱり全パターンを登録する事には変わりない……、
……機構を追加するも何も、それは複合語形式を使えば用が済むし。
振り出しに戻って一般名詞接頭辞を復活させて
接頭辞〜自立語〜接尾辞から自動で１文節を作るようにして、
候補として使用しないパターンを登録して変な候補が出ないようにする、
とかやると、これもやっぱり反対方向の全パターンを登録する羽目になる……、
……アンチパターンの登録作業をしなければならないぶん、たちが悪い……、
使用するパターンを登録して、パターンが無いなら候補として使用しない、だと、
前述の２つと変わらない。
どのみち全パターンを登録するならば、
かつ数詞絡みの場合に接頭辞〜自立語〜接尾辞で文節を
区切るように変更するならば、
一般名詞接頭辞は複合語形式で文節を区切ってパターン登録すると、
整合性は良さそう。
数詞絡みで文節を切らないならば、現状の１単語で登録が、整合性は良さそう。
結局、決め手となる判断基準は、
・変な候補が出ないけれども、望んだ候補も（登録するまで）出ない。
・望んだ候補が出るけれども、変な候補も（優先度下げ登録するまで）出る。
の、どちらが良いか、とか、
・どの方法がメンテナンスの手間が少なくてすむか。
の辺りなのだろうか。
処理の実装に関して：
そもそも根本的な部分で、
Anthy は、
文節間のつながりの情報はコーパスの確率情報しか持たず且つ使わない設計
になっている。
例：
複合語に
「あかさたなはまやらわ #T35 #_5ＡＢＣ_5ＤＥＦ」
「あかさたなはまやらわ #KS #_5αβγ_5δεζ」
の２つがあった場合に、「あかさたなはまやらわ」を変換すると、
確率情報の結果如何では
「|ＡＢＣ|δεζ|」とか「|αβγ|ＤＥＦ|」と提示してくる。
あるいは複合語と単語に
「あかさたなはまやらわ #T35 #_5ＡＢＣ_5ＤＥＦ」
「あかさたな #KS ●▲■」
「はまやらわ #KS ○△□」
がある場合に、
確率情報の結果如何では
「|ＡＢＣ|○△□|」とか「|●▲■|ＤＥＦ|」と提示してくる。
複合語でそんな候補を出されても嫌なので、その辺は改造済。
接頭辞／接尾辞を分離した状態（#PRE とか #SUC とか）で辞書に登録しつつ
接頭辞／接尾辞で文節を区切る場合、
複合語関連で改造した部分を流用すれば対応可能。
接頭辞／接尾辞を付けた状態で辞書に登録しつつ
接頭辞／接尾辞で文節を区切る場合、
複合語形式で登録すれば良し。
文節を区切らない手段を採る場合は、
特に改造しなくても現状のままで対応済み。
と言う訳で、
「接頭辞／接尾辞を分離した状態で辞書に登録しつつ、
接頭辞／接尾辞で文節を区切る」に対応してみた。
オプション
VITERBI_MODE_LATTICE_BIASPROB_BY_COMBINED_D2KY,
VITERBI_MODE_LATTICE_BIASPROB_BY_COMBINED_D2T,
CANDIDATE_SCORE_COMBINED_D2KY,
CANDIDATE_SCORE_COMBINED_D2T,
にて、加算する確率と得点を変更可能。
これで取り敢えず、試してみる為の手駒は揃う。
あとはどう辞書の元データを作るかと言う問題。
複合名詞の辞書をどう作るか：
に続く。
根本的な問題として、
複合動詞用の品詞を追加すると、
canna や改造無しの anthy で使えなくなってしまう問題がありますが。
取り敢えず棚上げ。
複合動詞を１文節に連結した場合：
こんなかんじ。
% env LD_LIBRARY_PATH=${HOME}/.anthy/test.patch13/lib/ ${HOME}/.anthy/test.patch13/bin/anthy-agent --anonymous
tukenaosihazimemakuru
(2 ((UL) "つけなおしはじめまくる" -1 -1) cursor)
(space)
(3 ((UL RV) "つけ直し始めまくる" 0 113))
PRINT_CONTEXT
|つけなおしはじめまくる
つけなおしはじめまくる(つけ直し始めまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)1,054,454 ,付け直し始めまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)1,054,454 ,つけなおし始めまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)1,054,454 ,付けなおし始めまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)1,054,454 ,着け直し始めまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)994,498 ,つけ直しはじめまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)994,498 ,付け直しはじめまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)994,498 ,着けなおし始めまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)994,498 ,つけなおしはじめまくる:(N,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)994,498 ,付けなおしはじめまくる:(,1000,Ve,62394,Se,#KS,H*C*S*,E:-1,F:360,LF:0,D:1,L:1,Vv)994,254 ,（以下 100パターンくらい候補が出るので省略）
「つけ」で１５パターン、
「なおし」で２パターン、
「はじめ」で２パターン、
「まくる」で２パターン。
文節を切った場合は 15+2+2+2 = 21パターンの候補で済むのに、
１文節にすると 15*2*2*2 = 120 パターンもの候補が生成されてしまう。
さらに増やして複合動詞を１０語くらい連結すると、
１万パターンくらいになってしまって、
処理に数十分とか数時間とかかかる事態になってしまう。
＃ デバッグ中に実際にやらかした。
かと言って１語〜数語しか連結しない様にすると、
「|つけ直し|始めまくる|」の様に２語〜数語毎の切り方になるが、
文節間のつながりを持っていないので、
複合動詞であることのメリット（文節区切り位置への関与）が
つながっている数語の範囲でしか効かなくなってしまう。
と言う訳で、試して数十分でお蔵入り。
文節を分離したまま複合動詞のつながりの情報を追加する場合：
こんなかんじ。
% env LD_LIBRARY_PATH=${HOME}/.anthy/test.patch13/lib/ ${HOME}/.anthy/test.patch13/bin/anthy-agent --anonymous
tukenaosihazimemakuru
(2 ((UL) "つけなおしはじめまくる" -1 -1) cursor)
(space)
(3 ((UL RV) "つけ" 0 15) ((UL) "直し" 0 9) ((UL) "始め" 0 15) ((UL) "まくる" 0 3))
PRINT_CONTEXT
|つけ|なおし|はじめ|まくる
つけ(つけ:(1N=D2Dl,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)903,215 ,付け:(1=D2Dl,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)902,933 ,着け:(=D2Dl,1000,Vy,19660,Sy,#KS,HvCySy,E:0,F:400,LF:0,D:0,L:0,S)799,326 ,漬け:(=D2Dl,1000,Vy,19660,Sy,#KS,HvCySy,E:0,F:400,LF:0,D:0,L:0,S)737,889 ,点け:(=D2Dl,1000,Vy,19660,Sy,#KS,HvCySy,E:0,F:400,LF:0,D:0,L:0,S)737,812 ,附け:(=D2Dl,1000,Vy,19660,Sy,#KS,HvCySy,E:0,F:400,LF:0,D:0,L:0,S)707,170 ,突け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)680,189 ,就け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)677,937 ,衝け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)454,911 ,憑け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)452,659 ,尽け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)340,019 ,吐け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)339,738 ,撞け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)339,456 ,搗け:(,1000,Ve,72089,Se,#K5,HvCmSe,E:0,F:400,LF:0,D:1,L:1,S)338,893 ,ツケ:(1N,1000,Ne,19660,Se,#T,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)154,208 ,):
なおし(直し:(1=D2Tl=D2Dl=D2Dr,1000,Vy,9830,Sy,#S5,HvCySy,E:0,F:301,LF:0,D:1,L:1,S)1,321,420 ,なおし:(1N=D2Tl=D2Dl=D2Dr,1000,Vy,9830,Sy,#S5,HvCySy,E:0,F:301,LF:0,D:1,L:1,S)1,321,113 ,治し:(1=D2Tl=D2Dl=D2Dr,1000,Vy,9830,Sy,#S5,HvCySy,E:0,F:301,LF:0,D:1,L:1,S)1,321,075 ,尚志:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:250,LF:0,D:0,L:0,S)62,051 ,直:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:250,LF:0,D:0,L:0,S)31,333 ,直史:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:250,LF:0,D:0,L:0,S)31,256 ,直志:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:250,LF:0,D:0,L:0,S)31,179 ,直紙:(1,1000,Ne,19660,Se,#T,HnC_Se,E:0,F:250,LF:0,D:0,L:0,S)6,758 ,ナオシ:(N,0,-)1 ,):
はじめ(始め:(1=D2Tr=D2Dl=D2Dr,1000,Ve,19660,Se,#KS,HvC_Se,E:0,F:401,LF:0,D:0,L:0,S)861,378 ,はじめ:(1N=D2Tr=D2Dl=D2Dr,1000,Ve,19660,Se,#KS,HvC_Se,E:0,F:401,LF:0,D:0,L:0,S)860,764 ,初め:(1=POST,1000,Ne,19660,Se,#T,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)185,541 ,一:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)93,385 ,元:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)92,693 ,哉:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)92,617 ,大:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)92,540 ,肇:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)62,666 ,ハジメ:(1N,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)62,051 ,一生:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)61,975 ,啓:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)61,898 ,始:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)61,821 ,創:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)61,744 ,甫:(1,1000,Ne,19660,Se,#JN,HnC_Se,E:0,F:301,LF:0,D:0,L:0,S)61,667 ,土師め:(,1000,Ne,9830,Se,#JN,HnC_Se,E:0,F:50,LF:0,D:1,L:1,S)15,516 ,):
まくる(まくる:(N=D2Dr,1000,Ve,72089,Se,#R5,HvCsSe,E:0,F:300,LF:0,D:1,L:1,S)1,292,337 ,捲る:(=D2Dr,1000,Ve,72089,Se,#R5,HvCsSe,E:0,F:300,LF:0,D:1,L:1,S)1,067,059 ,マクル:(N,0,-)1 ,):
「=D2Dl」が複合動詞の左側文節を表すフラグ、
「=D2Dr」が複合動詞の右側文節を表すフラグ、
両方付いている場合は継続する複合動詞の中途。
複合動詞の追加辞書は mkworddic/combinedverb.t 。
品詞の追加は src-worddic/wtab.h の #D2KS を参考に付け足せば OK。
付属語を変更するのでなければ ptab.h の修正は不要。
オプション
VITERBI_MODE_LATTICE_BIASPROB_BY_COMBINED_D2D と
CANDIDATE_SCORE_COMBINED_D2D にて、
加算する確率と得点を変更可能。
前置き：
「vagus氏 - 丘の道を登り - 2009年11月23日 - いくつか応答」
> a. あり得るものだけ一つ一つ辞書に登録する(一般辞書/複合語辞書(/用例辞書))
> b. 品詞コードを細分化して、接続を細かく指定できるようにする
> c. コーパスとかで単語レベルの接続情報を持たせる
a. は、
「一番原始的だが一番確実」ゆえに、
改造が不要で今すぐ使える上に使い方が簡単。
逆に言えば、今すぐ使える方法が a. だけ、と言う事かも。
c. は、本来、Anthy が目指していた方向の様な気がします（根拠無し）。
コーパスの例文を見ると、数詞絡みの接頭辞／接尾辞を使った文も入っていますし。
実際やってみるとどうなるかは、わからないですね。
b. は、あちこち改造が必要で困難ですが、データ構成としては綺麗だと思います。
a. や c. だと、
「|旧|市街地|」、「|新|市街地|」、「|元|市街地|」……
「|旧|都心|」、「|新|都心|」、「|元|都心|」……
「|急|降下|」、「|緩|降下|」……
「|急|発進|」、「|緩|発進|」……
と、いちいち全部書かなければなりませんが、
b. なら、
「旧、新、元、……」や「急、緩、……」等と、グループ分けして一括指定すれば、
「新旧+市街地」、「新旧+都心」、
「緩急+降下」、「緩急+発進」、
で済みますし、
接頭辞の登録漏れが有っても
グループのテーブルに追加してやれば済みますし。
問題は、
・グループの使い回し回数がかなり少なくて、
わざわざ大改造しなくても a. の方法でなんとななる程度だったりしないか
・どうやってグループのテーブルの内容（「旧、新、元、……」）を持たせるか
＃ 「きゅう #TPRE01 旧」？
・単語に対して
どのグループが接続できるかの情報（新旧グループ+市街）を
どうやって持たせるか（語によっては複数のグループが接続できるかも）
＃ 「しがい #T35_TPRE01_TPRE02_TPRE03 市街」？
・同じグループの様に思えても
細部が違って別グループになってしまってグループ数が爆発しないか
＃ 「新旧古」だったり「新旧」だったり「新旧前」だったり？
・つながり方によって頻度値を変えた方が良かったりする場合は
どうする（用例を使えば解決？）
＃ 「緩降下」「急降下」「急発進」は同程度だろうけれど、
「緩発進」はたぶん少ない。
と言った辺りでしょうか。
b. に関して、具体的な実装方法について考えてみると：
名詞接頭辞の場合、読みと変換結果のパターン数は爆発しないで済みそうなので、
文節のつながりの情報を生成するのは Anthy 本体内である必要は無い。
＃ 数詞接頭辞／数詞接尾辞は、パターン数が無限に有る
（数字部分が無限に存在するから）ので無理。
なので、
扱いやすい形式の元データを作り、
そこからスクリプトなりプログラムなりで辞書の形式に変換すれば、
品詞の追加や Anthy の改造をしなくても、
実現できるはず。
例えばこんな感じ。
----------------------------------------
# 元データ：
\define_table[緩急]
\table_add_element[緩急] かん 緩 #T35
\table_add_element[緩急] きゅう 急 #T35
\table_connect_pre[緩急] はっしん 発進 #T30
\table_connect_pre[緩急] こうか 降下 #T30
----------------------------------------
これをスクリプトなりなんなりで、辞書の形式に変換。
----------------------------------------
# 通常単語
かんはっしん #T30 緩発進
きゅうはっしん #T30 急発進
かんこうか #T30 緩降下
きゅうこうか #T30 急降下
----------------------------------------
# 複合語
かんはっしん #T30 #_2緩_4発進
きゅうはっしん #T30 #_2急_4発進
かんこうか #T30 #_2緩_3降下
きゅうこうか #T30 #_2急_3降下
----------------------------------------
# 用例
n 3 かん * はっしん * 緩 * 発進 * #T35 * #T30 *
n 3 きゅう * はっしん * 急 * 発進 * #T35 * #T30 *
n 3 かん * こうか * 緩 * 降下 * #T35 * #T30 *
n 3 きゅう * こうか * 急 * 降下 * #T35 * #T30 *
----------------------------------------
あとは、適当な形式のデータを、
canna なり anthy なり好みなりなんなりに合わせて使えば、
実現可能。
b. の具体的な実装の別案：
上記の方法だと、
新旧グループは、やっぱりパターン数が爆発しそうな気がした。
そうなると、既存の辞書データをそのまま使いつつ、
変な候補が減るような、接頭辞／接尾辞の実装方法が欲しい。
例えば、新旧がどんな単語に付くかを考えてみると、
物品名に付き、
補助動詞「する」が付く様な名詞には付きそうも無いと思う。
また、新旧を物品名に接頭辞として付ける場合、
「そんな表記はまず使わない」と言う事はあっても
「そんな表記はありえない」と言う事は無いと思う。
品詞で言うと、物品名は #T35 にあたりそう。
しかし、#T35 でも物品名以外があるのではなかろうか。
「きゅうきゅう #T35 救急」は……、
「新+救急+なんとかこうとか」みたいな語は……、有る。
案外、いけるかもしれない。
次に、
例えば、緩急がどんな単語に付くかを考えてみると、
補助動詞「する」が付く語に付きそう。
物品名には付かないだろう。
品詞で言うと、#T30 にあたりそう。
では、#T30 でそれをやるとどうなるかを考えてみると。
「れんぞく #T30*300 連続」に対して、
「|急に|連続する|」は問題無いけれども
「|急+連続する|」はありえない……。
と言う訳で、
「きゅう #T35PRE 旧」のように、
接頭辞／接尾辞を品詞毎に分ける程度の改造で、
変な候補が気にならない程度に減りそうな物と、
「きゅう #T30PRE 急」のように、
接頭辞／接尾辞を品詞毎に分ける程度の改造では、
変な候補が減りそうにないものと。
Don't you see!、ZARD、1997.1.6。
IT'S ONLY LOVE、福山雅治、1994.3.24。
ルージュの伝言、荒井由実、1975.2.20。
原作版 Anthy のバグではなくて仕様です。
自立語の品詞が同じで、接頭辞か接尾辞に違いがある変換候補は、
破棄されて生成されない事に気付いた。
自立語が無い文節の場合、
自立語が無い文節同士は同じ内容とみなされて、
破棄されて生成されなかった。
Anthy 複合品詞の文節分離の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
上記の破棄されてしまう条件を変更して、
分解した複合品詞／数詞の場合に破棄されない様にした。
複合品詞のペア存在のチェックが大甘だったので修正。
一般名詞接頭辞にて、後続の一般名詞の品詞細目を要指定に変更してみた。
#PRE を削除して、かわりに #T35PRE と #T30PRE が追加してあります。
Sun,29 Nov,2009、
Fri,18 Dec,2009、
Sun,27 Dec,2009、に関連。
結果。
現在の alt-cannadic は、
複合名詞が１単語化して登録してあり、
しかも調整済の頻度値が付いていて諸バランスが取れている。
なので、
#T35PRE や #T30PRE だと接続する単語毎の頻度値の調整ができないので、
候補の並び順のバランスが元の alt-cannadic より悪くなる。
用例を使えば頻度調整できるが、そうするくらいなら、
１単語化するなり複合語形式にするなりした方が、応用が効くと思う
（複合名詞だから、複合語にしても品詞が狂う心配が無い。
複合語形式なら cannadic用形式への変換が用例よりも容易）。
Anthy の文節区切りアルゴリズムの、
実装に採用している処理アルゴリズム上の限界。
事の始まり：
用例改造版以降、
「へんかんがようい」が「|変|閑雅よ|うい|」になった。
それ以前だと、
「へんかんがようい」が「|変換が|容易|」になった。
用例改造版以降でも
make update_params だけだと「|変換が|容易|」になるけれども、
用例改造版以降で
make update_params2 まで行うと「|変|閑雅よ|うい|」になるらしい。
用例改造版のバグかと思って試行錯誤してみたところ。
例に依って例の如く、単に Anthy の不思議変換なだけで、
改造前と改造後で発現する変換内容が違うだけらしい。
先の vagus氏のサイトでも取り上げられている「|キャッ|観的|」の件もあり、
気になるので追究した結果、
どうやら、Anthy の文節区切りアルゴリズムの、
実装に採用している処理アルゴリズム上の限界らしい。
状況を引き起こす最低限の要因の確認結果：
改造版以降にて、
コーパスに最低限下記３組だけ有る状態にて
make update_params だけだと発現せず、
１回以上 make update_params2 すると発現する。
＃ 当然、元通り約17000行のコーパス全てが有る状態でも同様に発現する。
----------------------------------------
|いったら|いい| |行ったら|いい|
|こっちゃ|ない| |こっちゃ|ない|
|きにいる|はずよ| |気に入る|筈よ|
----------------------------------------
make update_params と make update_params2 にて、
改造版前と後で違いが出た部分の確認結果：
「こっちゃ」の部分の認識：
原作版：自立語「#R5 こ」付属語「っちゃ」
改造版：自立語「#T35 こっちゃ」付属語なし
「ない」の部分の認識：
原作版：自立語「#KY な」付属語「い」
改造版：make update_params の時は、自立語「#T35 ない」付属語なし
改造版：make update_params2 の時は、自立語「#KY な」付属語「い」
分析結果：
まず make update_params にて、
「|行ったら|いい|」から『|A Se 付属語「い」|』を、
「|気に入る|筈よ|」から『|Ve Se|Ne Se 付属語「よ」|』を、
覚える（コーパス例文から生成する確率データベースに記録する）らしい。
この時、
「|こっちゃ|ない|」は『|Ne Se|Ne Se 付属語なし|』と覚えていた。
次に make update_params2 にて、
さっき覚えた『|A Se 付属語「い」|』を活かして、
「|こっちゃ|ない|」を『|Ne Se|A Se 付属語「い」|』と覚えなおしていた。
その結果、
「へんかんがようい」の文節区切りの候補の１つである
「|経ん|閑雅よ|うい|」は、
コーパスから覚えた
『|Ve Se|Ne Se 付属語「よ」|』が「|経ん|閑雅よ|」に、
『|Ne Se|A Se 付属語「い」|』が「|閑雅よ|うい|」に一致するので、
文節区切り位置として優先されるらしい。
実際に変換候補を提示する際には「経ん」よりも「変」の方が評価が高いので、
提示する内容が変更されて「|変|閑雅よ|うい|」になるらしい。
原作版 Anthy や改造版以前にて、
「|こっちゃ|ない|」を『|Ne Se|A Se 付属語「い」|』として
覚えない事が多い理由は不明。
覚える内容の調整を試みた結果：
『（文頭）|Nk Sk 付属語「が」|』と
『|Nk Sk|Ne Se （付属語無し）|』の、
２つの構造の例文を追加すると発現しにくくなるにちがいない、
と言う事で、試してみる。
……。
駄目だった。
その構造となる文（たしか、全く同じ内容の文だと無視されたと思う）を
１０くらい足しても、まだ駄目。
例文が１万数千あっても発現し続けるくらいだから、
人力でどうこうしようとしても駄目なんでしょう、きっと。
効果が有った対処法：
コーパスの例文に
----------------------------------------
|へん|かんがよ|うい| |~変|~閑雅よ|~うい|
----------------------------------------
を追加して、該当する構文を強制的に忘れさせたところ、
出なくなった。
だがしかし、
『|Ve Se|Ne Se 付属語「よ」|』と
『|Ne Se|A Se 付属語「い」|』の２つを、
データベースから削除する事になるので、
「|（動詞）（てきとうに付属語が有ったり無かったり）|（名詞）よ|」や
「|（名詞）（てきとうに付属語が有ったり無かったり）|（形容詞）い|」といった
構文の事を忘れている筈。
結果：
あちらの構文を覚えさせるとこちらの構文で望まない変換結果を返し、
こちらの構文で望んだ変換結果になる様にするとあちらの構文を忘れてしまい。
Anthy の文節区切りの基本アルゴリズムである
「品詞＆付属語ベース 文節２グラム(?) MBR ビタビ アルゴリズム」が
根本的に持っている不可分で構造的な要因なのでしょう、きっと……。
Tue,08 Dec,2009 追記：
（文頭）|へんかんが|ようい|（文末）
| SEG_HEAD | SEG_MEISHI_RENYOU,DEP_RENYOU | SEG_MEISHI_SHUTAN,DEP_END | SEG_TAIL |
| 2.748e-12,2.748e-09 | 7.552e-24,? | 7.552e-24 |
（文頭）|へん|かんがよ|うい|（文末）
| SEG_HEAD | SEG_DOUSHI_SHUTAN,DEP_END | SEG_MEISHI_SHUTAN,DEP_END | SEG_KEIYOUSHI,DEP_END | SEG_TAIL |
| 2.748e-12,2.748e-09 | 7.552e-18,7.552e-12 | 2.075e-23,? | 2.075e-20 |
確率が、
『|Nk Sk|Ne Se （付属語無し）|』で１桁、
『|Ne Se|（文末）』で３桁、
合計で４桁、
低いのが要因らしい。
コーパスに
『|Nk Sk|Ne Se （付属語無し）|』や
『|Ne Se|（文末）』と
なる構文を追加しても、確率が変わってくれなくてよく判らん。
Anthy の誤変換、昨日の続き。
昨日の件がきっかけで、
vagus氏のサイトでも取り上げられている「|キャッ|観的|」の件を
追跡してみようと思ったまま、ずっと忘れていた事を思い出した。
予備知識の確認：
Anthy の文節区切り位置の決定（MBR ビタビモード）は、
コーパスの例文を元に生成した確率データベースのみを用いて行われる。
単語辞書の頻度値情報は一切用いない。
なので、単語辞書の調整を行っても、
文節区切り位置をどうこうする事はできません。
単語を削除すれば、
その単語を使った文節区切りは行われなくなりますが……。
確率データベースからの情報取得の結果の確認：
% env LD_LIBRARY_PATH=${HOME}/.anthy/test.anthy.org/lib/ ANTHY_ENABLE_DEBUG_PRINT="yes" ANTHY_SPLITTER_PRINT="l" ${HOME}/.anthy/test.anthy.org/bin/anthy-agent --anonymous
（前略）
**lattice_node probability=0.00000000003679018535625566497202698834185715954375739400461498007643967866897583007812500000000000000000000000000000000000000000
*meta word type=compound_head(3-4):score=1000:seg_class=名詞:can_use=1*
*meta word type=compound_leaf(3-2):score=1000:seg_class=名詞:can_use=1*
(観)
*meta word type=compound(5-2):score=1000:seg_class=名詞:can_use=0*
*meta word type=compound_leaf(5-2):score=1000:seg_class=名詞:can_use=1*
(的)
**lattice_node probability=0.00000267739762012952767152333330424873736319568706676363945007324218750000000000000000000000000000000000000000000000000000000000
*meta word type=single(0-3):score=100:seg_class=連用修飾:hf:can_use=1*
.きゃっ.-(POS=7,COS=0,SCOS=0,CC=0,CT=0,flags=4)
連用修飾
(3 ((UL RV) "キャッ" 0 142) ((UL) "観" 0 156) ((UL) "的" 0 24))
要点の抜粋：
第１文節 : きゃっ : POS_AV : 連用修飾、付属語無し
第２文節 : かんてき : 複合語 : 名詞、付属語無し
どうやら、
「|文頭|名詞終端+付属語無し|」よりも、
「|文頭|連用修飾|名詞+付属語無し|」の方が、
評価が高いので文節区切りとして優先したようです。
第１文節の出自は、
alt-cannadic/gcanna.ctd:きゃっ #F06*301 キャッ #F06*300 きゃっ
第２文節の出自は、
mkworddic/compound.t:かんてき #T35 #_2観_2的
の模様。
Thu,03 Dec,2009 追記：
確率値を確認してみると、
どう見ても「|きゃっ|かん|てき|」よりも「|きゃっかんてき|」の方が高い為、
デバッガでトレースしたところ、全然違う様相が発覚。
候補その１：「|きゃっかんてき|」: 通常単語 : SEG_MEISHI, DEP_RAW : 確率 1.6105071315111313e-07
候補その２：「|きゃっかんてき|」: 複合語を１単語化 : SEG_MEISHI, DEP_NONE : 確率 3.1005387824716775e-07
候補その３：「|きゃっ|かん_てき|」: 最終文節は複合語を分解した要素 : 確率 3.6790185356255661e-14
以下の候補は省略
まず「候補その１」と「候補その２」を比較して、
確率の高い「候補その２」を「ここまでの最高評価の候補」とする。
次に「ここまでの最高評価の候補：候補その２」と「候補その３」を比較する。
ここで、
両候補とも最終文節が複合語なので特例が追加される。
特例により
「複合語を１単語化」した候補よりも
「複合語を分解した候補」が優先されるので、
「候補その３」が「ここまでの最高評価の候補」になる。
これ以降の候補には「候補その３」の確率を越える候補が無いため、
「候補その３」が最終候補として選択される。
結果、「候補その１」よりも確率の低い「候補その３」が採用される。
バグですかね？
拙作パッチの場合、
別件の「改造した時に増やしてしまったバグ」を治す際に、
上記の問題が起きない様に修正済だったので、該当しない
（その時は、原作版 Anthy にも同じ問題がある事に気付かなかった）。
↑ Fri,04 Dec,2009 追記： 本家 ML に送付完了。
うっかり、パッケージのセキュリティ更新を実行してしまったら、 Python とか x11-toolkit系とか 基本系の部分の更新もついでに実行されてしまって、 更新が完了するまで身動きが取れなくなってしまった罠。
と言う訳で、待ち時間に、
普段無視している様な所を気にしてみた。
plib を使って gl/glut から OpenGL を使うアプリケーションが、
FATAL: SSG: OpenGL will not accept a downsized version ?!?
とエラーを出してこける件。
さて、この件は何年ほっといたのだろう……。
ずばり、
「Games4Mac Community > Games4Mac . United Pc Kiallas . Spiel-Projekte > SuperTuxKart」
にある、
「SuperTuxKart がエラーを出してこける」件と全く同じらしい。
しかし、このページは一体何語なのだろう。
文の内容が全く読めない……。
要約すると、
plib の src/ssg/ssgLoadTexture.cxx の、
「ulSetError ( UL_FATAL, "SSG: OpenGL will not accept a downsized version ?!?" );」
の直前に有る
「if ( xsize < 64 && ysize < 64 )」を
「if ( xsize < 4 && ysize < 4 )」に
書き直す。
この修正をして plib の再インストールで治ると思いきや。
これだけでは駄目で。
plib は静的リンクなライブラリなので、
plib 本体を更新後に、
plib を使うアプリケーションを丸ごと再ビルドしないと駄目だった。
xshisen が junk pointer がらみで Abort する問題。
……なんか、xshisen の開発元ページが消滅してしまった模様ですが。
この件は、５年くらい放置していた気がする……。
xshisen in free(): error: junk pointer, too high to make sense
Abort (core dumped)
こんなん出て、動きません。
海外のサイトで検索をかけると、
「xshisen が Linux だと動くのに FreeBSD だと動かないのは
FreeBSD のバグだ！」（超意訳）
「バカ言ってんじゃねぇ、
FreeBSD のメモリ管理が厳格だから表面化しただけで、
xshisen のメモリ管理がトチってるバグだ。
治したきゃ作者に言って治して貰え。」（超意訳）
みたいな問答が見つかりました。
日本国内で検索すると、バグに関する情報が全然見つかりません。
せいぜい、Plamo GNU/Linux にて、
「ハイスコアが記録されないよん」（意訳）
と言うのが見つかる程度。
Debian GNU/Linux や Ubuntu GNU/Linux のパッケージをのぞいてみても、
このバグの修正は行われていません。
Plamo GNU/Linux は……パッケージのパッチの探し方が判らん……。
仕方が無いのでデバッガで追いかけてみたら。
見事に、
未初期化のポインタ hintArray にアクセスして delete かけていました。
使用中／未使用のフラグは有るので、単純ポカミスでしょうね。
そこまで判った所で、再度 web で検索してみたら……、
バグ修正パッチが見つかったし……。
「M.H Plamo Linux Home Page 0901 - 2009年その１」
でも、
検索エンジンのキャッシュに残っているだけで、
ページが消えていてアクセスできない……。
かな漢字変換の辞書に、開発者名やバージョン情報を入れる話。
「そう言う行為」に、何か固有の名称が付いているのですが、
３週間経っても未だに名称が思い出せません。
イースターエッグ？
ウォーターマーク？
ステガノグラフィ？
うーん？。
旧MS-Word だったか 旧MS-Excel だったかとか、
バンゲリングベイにも、
似た様な隠しコマンドが有ると聞いた事があるのを思い出して
ja.wikipedia を見てみたら。
チョップリフターとロードランナーとバンゲリングベイの３つって、
３部作だったんだ……、知らんかった……。
肝心の名称の方は見つからなかった。
Mon,29 Mar,2010 追記：
イースターエッグ。
Anthy にて、 「きゃっかんてき」が「|キャッ|観的|」になる件、 Wed,02 Dec,2009にて、 根本的な部分を覆す追記。
↑ anthy-5911 にてＴ氏により確率的手法（HMM）が採用、
anthy-6024 にてＹ氏により複合語が採用。
確率的手法の採用と複合語の採用が合わさる時に、
仕様のミスマッチをやってしまい、今回のバグ？が発生している。
なので、anthy-6024 以降の全てのバージョンに、このバグ？が有ると思われる。
その近辺で現在入手可能なバージョンは anthy-5900 と anthy-6300 なのだが、
確認してみたところ、
anthy-5900(2004-10-31)にはこのバグ？は無く、
anthy-6300(2005-03-08)には既にこのバグ？が有った。
……。
……。
……。
Anthy の後半生３分の１の、
確率的手法を採用後の全てのバージョンは、
根本的な部分のソゴの上に構築されていた事になる様な気が……。
FreeBSD-6系。
Fatal error 'Recurse on a private mutex.' at line 986 in file /usr2/src/lib/libpthread/thread/thr_mutex.c (errno = 35)
Abort trap (core dumped)
が出てコケたら。
freebsd-ports/2009-July : www/firefox35 coredumps every time at startup
それを出したアプリケーションに対して /etc/libmap.conf にて
[/usr/local/lib/firefox3/firefox-bin]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
する。
上記は www/firefox35 の場合。
Mon,14 Dec,2009に続く。
バトルテック グレイ・デス １〜６巻、各￥105-。
なんかいきなり邦訳版が全巻揃いましたよ……。
↑ 表紙カバー絵、１巻と２巻は２パターン存在していた。
３〜６巻は不明。
メックの立ち絵バージョンと、劇中シーン？のカラーイラストと。
３〜６巻はメックの立ち絵バージョンしか見た事が無い。
google.com の SSL の証明書の一部が、
Thawte から Equifax に変わっていた。
Thawte の方は 2009/03/2?頃〜2010/03/2?頃
（サービス種別毎に数日ずれている）で、
Equifax の方は 2009/11/13〜2010/11/13。
どうも、これまでは、
Thawte の中間局から
googleの各サービスに孫請けしていた所を、
今度からは、
Equifax から google内の中間局
（
SHA1: DD:7A:7F:13:1D:DB:A3:3D:3E:86:70:17:94:83:E6:FE:A6:98:7D:6A
MD5: 33:A0:EA:98:0E:3D:6E:26:1D:77:2D:82:DF:66:00:7D
; Google Internet Authority; ; Google Inc
）で請けて
そこから googleの各サービスに孫請けしているっぽい。
中間局の証明書は
http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crt
らしい。
全部が全部、異動したわけではなさそう。
接続したタイミングやサービスによっては、
Thawte の方の証明書や、
期間が更新された Thawte の証明書が出てくる事があった。
GNU screen。
FreeBSD だと問題無く使えるのに、
OpenBSD だと EUC-JP の G2 (SingleShift) がずっと文字化けしていた。
のだが、ようやく文字化けしない様にする方法が判った。
screen に入った後で
/usr/local/bin/screen -X encoding eucJP eucJP
にて、化けなくなった。
${HOME}/.screenrc に defencoding eucJP と書くのでは駄目だった。
新規起動時だけでなく -r した後も毎回やらないといけないので面倒。
……。
man 1 screen を読み直して、encoding enc [enc] の項目に、
何となく怪しい所を発見。
> The optional second parameter overwrites the encoding of the
> connected terminal. It should never be needed as screen uses the locale
> setting to detect the encoding.
はい、状況からすると、どうやら、
apr/subversion(svn) が文字化けしていた件と全く同じ現象らしいです、
たぶん。
標準の OpenBSD にはロケールが無いので、
ロケールから文字コードを取得する方法は必ず失敗します。
たすけて シトラスえもーん。
screen の話は、 Sun,26 Sep,2010、 Fri,15 Oct,2010、 に続く。 tscreen の話は、 Sat,16 Oct,2010、 Wed,20 Oct,2010、 Thu,21 Oct,2010、 Fri,22 Oct,2010、 Fri,17 Dec,2010、 に続く。
Sat,12 Dec,2009 追記：
screen.c の main() にて、
nl_langinfo(CODESET) で端末文字コードを取得していた。
apr(subversion - svn) と全く同じ。
OpenBSD の nl_langinfo(CODESET) は常に 646 を返します。
だからといって、libc に手を突っ込んで
nl_langinfo(CODESET) で eucJP とか UTF-8 とかの文字コードを返してやると、
mblen() とかその他のロケールがらみの関数が
文字コードに見合わない返値を返してしまう事になるので駄目。
また、
vim みたいに OS がロケールに対応しているか否かを判定して
相応の処理をしているプログラムも
出鱈目な動作をする様になってしまうので重ねて駄目。
diff -upr screen-4.0.3.org/screen.c screen-4.0.3.OpenBSD_locale_patch/screen.c --- screen-4.0.3.org/screen.c Mon Sep 8 23:26:41 2003 +++ screen-4.0.3.OpenBSD_locale_patch/screen.c Mon Dec 14 00:00:00 2009 @@ -30,6 +30,7 @@ **************************************************************** */ +#include/* Patched by G-HAL, Sun,13 Dec,2009 */ #include #include @@ -750,7 +751,17 @@ char **av; # ifndef USE_LOCALE setlocale(LC_CTYPE, ""); # endif + #if 0 /* Patched by G-HAL, Sun,13 Dec,2009 */ nwin_options.encoding = FindEncoding(nl_langinfo(CODESET)); + #else + { const char* s = getenv("SCREENLANG"); + if (s) { + nwin_options.encoding = FindEncoding( s ); + } else { + nwin_options.encoding = FindEncoding(nl_langinfo(CODESET)); + } + } + #endif debug1("locale says encoding = %d\n", nwin_options.encoding); # else # ifdef UTF8
インデックスファンド。
信託報酬 内訳 留保 逆日歩
委託 販売 受託 刻幅
----------------------------------------------------------------------------------------
野村 1306 0.1155〜0.2520 単元１万円前後 10口/単元 x.xx 0.50
三菱UFJ 1348 0.0819 単元１万円前後 10口/単元 x.xx 0.50
日興 1308 0.0924 単元10万円前後 100口/単元 x.xx 0.05
ダイワ 1305 0.1155〜0.2520 単元10万円前後 100口/単元 x.xx 0.05
eMAXIS TOPIX 0.42 0.18375 0.18375 0.0525 50億円未満 0.00
0.17325 0.19425 0.0525 50〜100億円
0.16275 0.20475 0.0525 100億円以上
STAM TOPIX 0.4830 0.2100 0.2205 0.0525 0.05
----------------------------------------------------------------------------------------
日興 1677 0.2625 単元50万円前後 10口/単元 x.xx 0.50 （Tue,05 Jan,2010 追記）
eMAXIS 先進国債券 0.63 0.2835 0.2835 0.0630 50億円未満 0.00
0.2730 0.2940 0.0630 50〜100億円
0.2625 0.3045 0.0630 100億円以上
三菱UFJ 世界国債(年１) 0.63 0.3255 0.2520 0.0525 0.00
STAM グロ債イ 0.672 0.315 0.315 0.042 0.05
----------------------------------------------------------------------------------------
日興 1680 0.2625 単元１万円前後 10口/単元 x.xx 0.50 （Tue,05 Jan,2010 追記）
SMAM 外国株式指数 0.525 0.30
eMAXIS 先進国株式 0.63 0.2835 0.2835 0.0630 50億円未満 0.00
0.2730 0.2940 0.0630 50〜100億円
0.2625 0.3045 0.0630 100億円以上
STAM グロ株イ 0.777 0.3465 0.3675 0.0630 0.05
----------------------------------------------------------------------------------------
これだけ見ると、
販社の立場で考えると、
eMAXIS 先進国株式 や eMAXIS TOPIX を
ポイント対象除外にしたいのがよく判る。
でも、
STAM グロ債イ と eMAXIS 先進国債券 を比べてみると、
ポイント対象にできるのではないかと言う気が。
あるいは、
eMAXIS 先進国債券 と eMAXIS TOPIX は、
ポイント対象除外までせずにポイント付与率を下げて付与はするとか。
さらに、
世界国債(年１) はポイント対象なのに
eMAXIS 先進国債券 がポイント対象除外になるのがよく判らん。
その辺りを考えると、
世界国債(年１) は 世界国債(月１) と合わせて
販売促進のキックバック？か何かあるのか？、とか、
STAM は販売促進絡みで何某かの援助が有るのか？、とか、
根拠も無く勘ぐってしまう。
ただ、顧客は販社の立場に合わせてくれるわけは無いので。
eMAXIS が全てポイント対象（しかも付与率が 0.05％高い）の
某販社に流出したり？。
ただ某販社は、コロコロとしかも唐突に
ポイント制度とか諸々とか変えてくる問題が有るけれど……。
Tue,05 Jan,2010 追記：
日興 1680 が１月22日設定の１月29日取引開始らしい。
取引価格のブレが許容範囲になりさえすれば
（1677 は、ただでさえ単元が大きくて庶民には手が出せないのに、
取引価格のブレが日々の価格変動並の有様で……）、
一気に STAM, eMAXIS, SMAM を抜いてダントツで最廉価に
（１万円単位で取引すると買付／売却の片道手数料が 0.21％だが）。
FreeBSD-6系。
Sat,05 Dec,2009の続き。
www/firefox35 が Bad system call を出して動かない問題の対処法。
具体的には、
Firefox の更新完了ページとか、
tab mix plus の更新時とか、
adblock plus の更新時に、
Bad system call を出して刺さった。
「freebsd-ports/2009-July : upgrade from Firefox 3.0 to Firefox 3.5 -- now that it's installed, it won't run」
% cd /usr/src/sys/modules/sem
% sudo make
% sudo make install clean
% sudo kldload sem
して、強引に sem.ko を突っ込んでみる。
問題無ければ /boot/loader.conf に sem_load="YES" を追加。
手元の環境では、
sem.ko 突っ込み ＋ libmap.conf 変更で、通った。
↑ GENERIC をみたら、 man 4 sem に書かれている options P1003_1B_SEMAPHORES が無かった。 でも、モジュールにすらなっていない理由は不明。
Firefox 3.5 で ５ボタンマウス／チルトホイールマウスの
進む／戻るが使えないと思ったら。
about:config で
user_pref("mousewheel.horizscroll.withnokey.action", 2);
user_pref("mousewheel.horizscroll.withnokey.numlines", -1);
user_pref("mousewheel.horizscroll.withnokey.sysnumlines", false);
する。
action 2 が「戻る／進む」モード。
numlines の符号が、「第６／７ボタン」で
「戻る／進む」（負）にするか「進む／戻る」（正）の選択。
sysnumlines false をし忘れると numlines が無視される。
フォント、その１。
IPA フォント の TrueType と
M+ の平仮名／カタカナの TrueType と
漣フォント の ビットマップフォント と
あと２０文字くらい自分で書いたものを連結して、
自分用フォントを作って使っているのだが。
等幅フォントの筈なのに、例えば // などで、等幅になっていない。
調べてみたら、フォントを連結する際に Auto Kern を実行してしまい、
等幅ではなくなっていたオチ。
フォント、その２。
1/2 とか 1/4 とか 3/4 とかが、
勝手に U+00BD とか U+00BC とか U+00BE とかで表示される。
U+00BC の Combining Character は
「U+0031 U+2044 U+0034」と設定されている。
でも、実際には「U+0031 U+002F U+0034」が U+00BC に変換される。
で、 ATT をみたら「one slash four」とか設定されていた。
ATT の frac 関連の項目を削除したら変換されなくなった。
Firefox 3.5。
いつのころからか、
おすすめアドオンがうるさくなった。
extensions.getAddons.showPane false で消えるらしい。
いつのころからか、
https から http に移動した時に警告が表示されなくなっていた。
以前は
デフォルト security.warn_leaving_secure true だったのが、
デフォルト security.warn_leaving_secure false に変わったらしい。
user.js に書かないと駄目か……。
↑ その近辺を確認してみたら、何時の間にやら
security.ssl3.rsa_seed_sha とか言うのが増えていた。
SEED と言うのは、どうも 128bit長ブロックの対称暗号らしい？。
韓国(KISA?) の政府標準(TIA? KICS?)で ISO/IEC18033-3 がどうとか？。
いつのころからか、
urlclassifier?.sqlite が更新されなくなっていた。
これが更新されないと、フィッシング等対策機能が効かなくなってしまう筈。
どうやら、
暫く前に *.google.com の SSL証明書が変更になった際に、
Thawte の google.com の SSL証明書を消して、
Thawte の認証局の信頼性を
Web サイトの識別に使用しないに変更していたのだが。
その為に https://sb-ssl.google.com:443 に接続できなくなり、
urlclassifier? のデータが取得できなくなっていたらしい。
Thawte を切ったのは、Thawte のサービスの中に、
メールさえ届けば
実在確認無しの数分で SSL証明書を発行するサービスがあり、
それを切りたかった為。
どのルート証明書がそれなのか確認せずにバシバシ切ったら、
やってしまった。
Thawte SSL 123 Certs が、
ドメイン認証のみ（実在証明無しのメールのみで数分で即発行）の
証明書サービスらしい。
SSL123 の上位局は Thawte Server CA らしい
（search.thawte.com の thawte CA Hierarchies and Trust Mappings より）。
Firefox 3.5 のアドオン。
更新しようとしたら、
「署名が検証されていません error -260」（日本語ロケール）とか
「signing could not be verified. error -260」（英語ロケール）とか
表示されて、更新できない。
散々試行錯誤した挙句。
そのアドオンの最近の版は StartSSL で署名されていたのだが、
StartCom はメールが届きドメインさえ保有していれば
無料且つ数分で発行できるので、無効にしてた。
その為、署名の検証ができなくて引っかかっていたらしい。
すっかり忘れていたのでメモ。
Verisign でも。
Class1 だとメールだけで発行。
Class2 だとオンラインの消費者データベース（具体的に何なのかは不明）とメールだけで発行。
Class3 だと担当者と会ったり登記事項証明書なりが必要。
Class4 は不明。
Thawte SSL123 はメールのみ即発行。
GeoTrust RapidSSL はメールのみ即発行。
GeoTrust QuickSSL はメールのみ即発行。
GeoTrust/RapidSSL FreeSSL はメールのみ即発行で無料。
StartCom StartSSL はメールのみ即発行で無料。
CACert.org はメールのみ即発行で無料、だけど、
普通はブラウザ標準のルート証明書には入っていない。
あとは、
EV SSL付きのレンタルサーバを無審査で借りる事ができたりするけれども、
フィッシングサイトでそれをやられると、
SSL の証明書を認めたり止めたりする方法では何の対策にもならない……。
RequestPolicy 使うしか。
シェルスクリプトで
文字列がワイルドカードを含む指定文字列に一致するか否かの判定。
case。
正規表現は使えない。シェルパターンのみ。
チルトホイールマウス（５ボタンホイールマウス）。
特定の５ボタンホイールマウスを、特定のアプリケーションで使用した時だけ、
第４／５ボタンが効かない。その２。
前回のその１の時（Sun,02 Aug,2009）は、
ボタンイベントがハットスイッチ？になっていて、
OS が対応していなかったオチだけれども
（結局、自分で USBマウスドライバを改造して対応）。
今回は、使えているアプリケーションも有る点が違う。
xev とカーネルソースを追跡してみたら。
問題になるマウスの場合、第４／５ボタンをクリックすると、
同時に第２ボタンもクリックした事になっていた。
複数ボタンの同時押しが起きた場合、
FreeBSD の ums.ko → usbd → moused → X だと、
ボタン番号の若番から順番にイベントを発生するらしく、
ボタン２クリック、ボタン４クリック、ボタン２リリース、ボタン４リリース、
の順番でイベントが発生していた。
第４／５ボタンが効かないアプリケーションの場合、
何かのボタンが押された状態で別のボタンが押されると、
後から押された方が無視されるらしい。
仕方が無いので、また USBマウスドライバを改造して、
ボタン１〜３とボタン４以降が同時にクリックされた時に、
先にボタン４以降のイベントを発生させて、
それからボタン１〜３のイベントを発生させる様に改造してみた。
どのアプリケーションでも第４／５ボタンが効く様になった。
↑ と言う訳で、FreeBSD のカーネルパッチ。
ホイールチルト操作をすると勝手に中ボタンクリックイベントが発生してしまうマウスにて、ホイールチルト操作を優先させる FreeBSD 6.4用パッチ
カーネルパッチなので、カーネル再構築が必要。
alt-cannadic-091122。
「わかばん #T35 若番」
「おいばん #T35 老番」
が無いっぽい。
でもどちらかと言うと技術専門用語らしい。
GLib-WARNING **: g_set_prgname() called multiple times。
Firefox のセキュリティアップデートをかけたら、
またもや GTK/GLib の更新が入ってしまった罠。
で。
GLib-2 が 2.20系から 2.22系に更新されたら、
GTK+-2 を使うアプリケーションが
「GLib-WARNING **: g_set_prgname() called multiple times」を
出す様になった。
ざっと検索してみたら、
Debian系とか Ubuntu系でバグだの何だの騒がれている様で。
日本語で検索してみると……、
……、
……それ、私は関係無いですから。
結論：「GNOME本家 - Bug 563627 - g_get_prgname() threadsafety」
↑ あと、GTK+-2.16系から 2.18系になったら、 ウィンドウ生成後に初めてフォーカスインした時に、 ウィンドウがチラつくようになった。
tcsh にて、複数端末間でコマンド履歴の保存ファイルを共有する方法。
ようやくみつけた。
足掛け何年だろう……。
man tcsh みたら、ちゃんと書いてあったし。
set savehist = (100 merge)
FreeBSD の場合、csh = tcsh なので、csh でも使える。
それ以外の *BSD の場合は csh ≠ tcsh なので csh では駄目。
欠点は、screen等で同時実行中の別のシェルとの即時共有はできない事。
history -S を実行するかシェルを終了した時点で履歴が統合保存され、
history -L を実行するかシェルを起動した時点で読み込みが行われるので、
同時実行中の全てのシェルにて
手動で history -S ; history -L すれば一応共有はできる。
↑ web で検索していたら、 「tcsh に履歴の共有機能は無いから zsh を使え」 と言う記事が見つかった。 記事のタイムスタンプと、 tcsh の更新日時（2001年版？の man に既に記述が有る）からすると、 記事が書かれた時期には既に tcsh に共有機能は有った筈だが……。
history の話は Wed,22 Sep,2010に続く。
Anthy 複合品詞の文節分離の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
Sun,29 Nov,2009、
Mon,30 Nov,2009、に関連。
前方ｎ文節最長一致モード時、
文節区切り位置を決める際に複合品詞の候補があると、
複合品詞を優先してしまい無茶な細切れになっていた問題の調整。
……うまく調整できていないっぽい。
「ていき」が「|てい|き|」に、
「じっさいには」が「|じっ|さいには|」に、
なる。
Sun,20 Dec,2009 追記：
うまく調整できていない様に感じたのは、
前方ｎ文節最長一致モード時の文節区切りアルゴリズムにて、
複合品詞の判定間違いがあったせいだった
（複合品詞の文節分離試験版開始時から 2009Z18版までずっと）。
2009Z19版にて修正。
2009Z19版の修正後でも
複合品詞の候補が有ると細切れになるのは変わらないので、
2009Z18版の調整はそのまま続行。
前方３文節以上の最長一致モードにて、
複合品詞が３つ以上続く場合
（「動詞連用形＋複合動詞＋複合動詞＋……」
および「接頭辞＋数詞／名詞＋接尾辞」）
のみ優先する程度に調整してみた。
副作用として、複合品詞が２つの場合、
（「動詞連用形＋複合動詞」とか
「接頭辞＋数詞／名詞」とか
「数詞／名詞＋接尾辞」とか）
候補が出にくい筈。
MBRビタビモードは、２週間試した結果、
（今までの文節の区切り方と区切り位置が変わるので）使い勝手が変わるとか、
元々のアルゴリズムの問題とか、
後述の学習とのバランスがうまくとれないとか、
その辺を除外すれば、問題無し。
前方ｎ文節最長一致アルゴリズムの根本的な話として、
文節区切り決定時の探索の評価値として、文節数と文字数が使われる。
ところが複合品詞の場合、
評価値としての文節数や文字数を整数値で計算すると、
適切なバランスにならなくて。
適切なバランスって何、と言う悩ましい問題も有るし、
小数値を指定可能にしても適切なバランスがうまくとれないのは変わらないし、
小数値にして更に微調整する方向に突っ走って行くと
接続コスト最小法とか係り受け最小コスト法
（参考文献：「阿部圭介 氏 - Top page : Computers&Internet : 日本語入力プログラムについて考える」）に
なってしまうし。
さらにそもそもの Anthy の根本構造が
文節分離型の複合品詞（あるいは単語Ｎグラム）を想定していない問題が。
文節区切り決定アルゴリズムが返すパラメータが
「文字数ベースの文節区切り位置」のみで、
「どこそこの位置で区切るけれども、
その区切り位置で使う変換候補はこれこれ」、
と言う指定ができない。
その為、例えば「やくさんさつ」を変換した際に、
文節区切り決定アルゴリズムにて
複合品詞を使って「|約|三|冊|」と言う候補を提示するつもりで
「|やく|さん|さつ|」と言う文節区切り位置を返すと、
変換候補決定アルゴリズムが
「|焼く|産|撮|」等と提示してくる問題があって……。
現状では CANDIDATE_SCORE_COMBINED_* で無理くり突っ込んでいるけれど。
学習が絡んで来ると、それでは処置しきれなくて。
例えば、
「ろくかんが」を「|６|巻が|」と提示するつもりで
「|ろく|かんが|」と言う区切りを決定したとする。
CANDIDATE_SCORE_COMBINED_* にて追加点を付けて
一時的に「|６|」と「|巻が|」の候補の評価を高くして、
変換候補決定アルゴリズムが「|６|巻が|」と提示する様に狙ってみても、
「ろく」を「録」と、「かん」を「|感|」と、学習していると、
「|録|感が|」になってしまう。
じゃぁ、数詞複合品詞を想定して文節を切った場合には
数詞関連ではない学習を無視する様にすると。
例えば
「ろっかんが」を「|肋間が|」と学習した場合にも
学習が無視されてしまう。
別の例として。
「そのごじっさいに」を
「|その後|実際に|」（|そのご|じっさいに|）と学習している場合に、
「|その|５０歳に|」（|その|ごじっさいに|）という
数詞複合品詞を使う候補が生成された時に
「|その後|実際に|」の学習が無視されてしまう。
文節区切り学習だけ使用して候補並び替え学習を使用しない様にすると。
意図的に「|六|感|」（|ろく|かん|）と学習していたりした場合、
どうする？。
しばしば忘れ去られ、注意が必要な点として、
「|肋間が|」（|ろっかんが|）も
「|その|５０歳に|」（|その|ごじっさいに|）も
「|六|感|」（|ろっ|かん|）も、
利用頻度の大小の違いこそあれ
どれも一応まともに文章になっているので、
候補として出ない様にするわけにはいかない。
複合品詞の話は Sun,27 Dec,2009に続く。
Anthy 複合品詞の文節分離の試験版、更新。
詳細は昨日の文を改訂して書いた。
超合金 マクロスクウォーター 完全変形 ￥18,680-。 ……、……、……。 箱の大きさだけで、抱えるほどの大きさだし……。 中身の全長 40cm ですか……。 10箱ちょっと積んであったけれど売れるのだろうか……。 ……１山で 20万円って……。
もしもピアノが弾けたなら、西田敏行、1981.4.1。 あれ？ 別の人かと思った。
ガンダーラ、ゴダイゴ、1978.10.1。
風の谷のナウシカ（イメージソング）、安田成美、1984.3.11。
天国にいちばん近い島、原田知世、1984.10.10。
風の谷のナウシカ（イメージソング）、安田成美、1984.3.11。 あれ？ ２回目？
ふられ気分でRock'n' Roll、TOM★CAT、1984.11.14。 2004年４月〜６月にアニメのエンディングテーマとして使われたらしい。
「のすけ氏 - configureしてmakeをかけると再度configureが走る
(その前にautoconfか何かが走る?) のをエレガントに回避する方法」、
Fri,23 Oct,2009の続き。
ようやく見つけた。
「「ぬ」氏 - 誰も褒めてくれないから自画自賛する日記 - 2001-05-16 - [本 autotool] autobook」、
「Junichi Uekawa氏 - 日本語での日記 2001年12月 - 2001年12月12日 - 18:55:26」、
「tmurakam氏 - X/Qt Server Project - 開発日記 - '04/2/20」、
「tet氏 - tet Diary - 2008 年 8 月 - 8/29 (Fri) - Automake」（2008）。
日本語で検索すると、この４件のみだった。
configure.ac に AM_MAINTAINER_MODE 付ける。終わり。
副作用として、元ファイルに更新があった場合でも
autoconf/autoheader/automake/autoreconf が走らなくなる。
従来通り、
自動で aclocal/autoconf/autoheader/automake が走る様にしたい時は、
./configure --enable-maintainer-mode
する。
↑ Anthy 拙作パッチの tar ball 配布物を、
AM_MAINTAINER_MODE 付きに更新。
本体部分は一切変更無いので、
かな漢字変換としてのみ使う人は更新する必要無し。
そうでない人はそれなりに。
学習と言えば。
Firefox の 2.x までは、
URLバーに何か入力した時に出てくる候補の出し方が、
前方完全一致（*:// とか www. とか、一部は判定から除外）だった。
例えば、「g」とタイプすると
「http://www.google.co.jp/」、
「http://gihyo.jp/ほげほげ」、
「http://www.google.com/」、
等と、アクセス回数順に出てくる。
Firefox の 3.0以降、
URLバーに何か入力した時に出てくる候補の出し方が、
学習による確率的手法？に変わったっぽい。
例えば、「g」とタイプすると
「http://gihyo.jp/ほげほげ」、
「URL に g は含まないけれど、ページのタイトルに g を含む所」、
「http://www.ring.gr.jp/ほげほげ」、
等と「g」を含む内容が、手動入力して確定した回数順に出てくる。
places.sqlite の moz_inputhistory を見てみると、
なんか重み付け値っぽい小数値がずらずら並んでいる。
FreeBSD で UDF 1.5。
Fri,07 Sep,2007、 の続き。
MS-Windows で書き込んだ DVD を、 FreeBSD から mount_udf して正しく書き込めたかどうかの確認を行ったら、 10KiB ブロック２個分が書き込み元データと一致しなかった。 慌てて udfclient で再確認したら書き込み元データと一致していた。 やだなぁ。 FreeBSD らしくないなぁ……、 いや、 サーバ用途としてコアでは無い部分で抜けているのだから FreeBSD らしいのかも。
Thu,09 Aug,2012、 Fri,18 Jan,2013、 Sun,20 Jan,2013、 Mon,21 Jan,2013、 Tue,22 Jan,2013、 Thu,31 Jan,2013、 Sun,03 Feb,2013、 に続く。
天神さんの子守唄、
作詞：井荻麟 作曲・編曲：菅野よう子 歌：勝沼恭子、
1998年。
「うちのカミさんおでぶ」？。
取り敢えず、毎年恒例のお約束ネタを。
「クリスマスはクルシミマス」
たぶんカタカナ表記だった様な気がするけれども全く自信無し。 元ネタの内容に自信が無いので web で検索したら見つからない。 タイトル一覧ですら、かすりもしない。
mlterm。
マウスで単語選択した時の挙動が、どうにも kterm と違う。
word_separators で設定しても、どうも違う。
色々試してみたら。
kterm の場合、ASCII 記号類全部だけでなく、
いわゆる全角の記号類でも単語区切りと判定されていた。
ただし、「仝々〆ー」は同一単語内と判定された。
さらに、アルファベットを選択した時は英数のみ、
ギリシャ文字を選択した時はギリシャ文字のみ、
と、単語選択を始める地点の文字の種別によって、
選択される内容が変わった。
区分が細分化されているっぽい。
芸が細かいなぁ。
mlterm の word_separators だと ASCII しか指定できないから、
どうしても同じ挙動にする事ができない。
mlterm のソースを見たら。
mlterm/ml_screen.c の is_word_separator() にて
US_ASCII 限定処理をかけて、
さらに char型にキャストしてから判定していた。
↑ 試しに mlterm を手動でビルドしてみたら。
autoconf/automake を使っているにも関わらず、
ソースディレクトリとビルドディレクトリの分離に対応していなかった。
↑*2 と言う訳で。
mlterm-2.9.4 で所謂全角記号を単語区切りとみなすパッチ。
Firefox 3.5.6 on FreeBSD/i386 6.4-RELEASE-p7。
Javascript を有効にした状態で特定のサイトにアクセスすると落ちる。
何度アクセスしても必ず落ちる。
拡張を全部切っても落ちる。
設定ファイルを何もかも空っぽにしても落ちる。
でも、FreeBSD/amd64 6.4-RELEASE-p7 だと落ちない。
どうも、4KiB だか 8KiB だか 16KiB だか、
その辺りのどれかより長い Javascript があると、落ちるっぽい。
で。日本語で連絡できるフィードバック先は何処？。
この手の解説を英語でできる程の英語力は無いのですが……。
↑ やけを起こして gdb で firefox-bin を追跡してみた。
結果。
mozilla-1.9.1/js/src/jsstr.cpp の js_ConcatStrings() にて、
長大な Javascript をブロック毎に読み込んでからバッファで連結する際に、
js_ConcatStrings (cx=0x********, left=0x********, right=0x0)
になって、right->label のアクセスで死んでいた。
mozilla-1.9.1/js/src/jstypes.h にて
#define JS_FASTCALL
#define JS_NO_FASTCALL
に変更したら、きちんと動く様になった。
Javascript の i386系専用高速化処理に問題があるっぽい。
i386 以外だと #define JS_NO_FASTCALL してあるし、
現に amd64 だと発症しなかったし。
↑ そこまで判った時点で web で検索しなおしてみたら。 「sakae氏 - Happy Hacking with ... - firefox35」 と同じ件だった。 英語で検索すると、 「freebsd-gecko -- Gecko Rendering Engine issues - Call for tester/reviewer: SeaMonkey 2.0」 にて、処置開始済になっていた。 Javascript の高速化処理の、 バグ、もしくは、gcc のオプティマイズとの悪相性、らしい。 なら、私から連絡しなくても大丈夫だね……。
Sat,09 Jan,2010 追記：
「のすけ氏 - Firefox」 によると、再ビルドせずとも、 javascript.options.jit.content を false でもいいらしい。
Firefox で Javascript が SIGSEGV する件は Mon,08 Feb,2010、 Wed,05 May,2010、 Fri,02 Jul,2010、 に続く。
Anthy 複合品詞の文節分離の試験の話。
Sun,29 Nov,2009、
Mon,30 Nov,2009、
Fri,18 Dec,2009、の続き。
複合品詞の文節を分離する様に変更して、品詞を追加して、
約１ヶ月、試してみましたが。
かな漢字変換を行う時の感覚が大きく変わる：
複合品詞の文節分離前の Anthy の場合、
「|約３０冊|」（|やく３０さつ|）や
「|書き忘れる|」（|かきわすれる|）の様に、
まとめて１文節で提示されます。
複合品詞の文節分離後の Anthy の場合、
「|約|３０|冊|」（|やく|３０|さつ|）や
「|書き|忘れる|」（|かき|わすれる|）の様に、
文節が切れて提示されると共に、
文節分離前の感覚で手動で切らずに１文節に変更すると
変換候補が出て来なくなります。
また、変換候補の提示にて、
分離前だと、
「|約３０冊|」「|約三十冊|」「|約30冊|」「|やく３０さつ|」や、
「|書き忘れる|」「|描き忘れる|」「|書きわすれる|」「|描きわすれる|」の様に、
複合品詞の候補のみが組み合わせの全パターン数だけ出て来ます。
分離後だと、
「|約|」「|訳|」「|焼く|」＋「|３０|」「|三十|」「|30|」＋「|冊|」「|撮|」や、
「|書き|」「|描き|」「|下記|」＋「|忘れる|」「|わすれる|」の様に、
複合品詞と関係無い候補まで出る様になりますが、
組み合わせパターン数は減ります。
これまでと文節の区切り方のルールや変換候補の出方が大幅に変わる為、
人によっては慣れる事ができないかもしれません。
先に大きな問題になるのは、
変な候補が出る出ないの話よりも、
この感覚の違いに慣れる事ができるかできないか、
になるかもしれません。
私の場合、
（これまで使っていた Anthy の挙動と違うと言う点で）
未だに若干の違和感がありますが、
改造版 Anthy に移行する前は Canna/FreeWnn を使っており、
文節区切りの学習ができない Canna/FreeWnn への対策として
文節を細切れにして変換していた為、
分離していた方が馴染みがあります。
複合品詞：数詞の接頭辞と接尾辞の分解に関して：
例えば「やく３０かい」を変換した場合、
文節分離前だと、
「|約３０回|」「|約三十回|」「|約30回|」
「|約３０階|」「|約三十階|」「|約30階|」
の様な変換候補の出方になっていた所が、
文節分離後だと
「|約|」「|訳|」「|焼く|」
＋
「|３０|」「|三十|」「|30|」
＋
「|回|」「|階|」「|下位|」
の様に変わります。
変換候補の組み合わせパターン数は減りますが、
接頭辞／接尾辞にて複合品詞ではない候補まで出てくる様になります。
個人的には、文節分離後の方が
今まで使っていたかな漢字変換の感触に近いので
馴染みやすくて使いやすいのですが、
人によっては、
とんでもなく使いにくくなるかも。
「|全|パターン|」v.s.「|千|パターン|」の様なケースには
遭遇していない（もしくは気付かずにスルーした）為、
その辺の使い勝手の変化はよく判りません。
複合品詞：複合動詞の多重連結もしくは全分解に関して：
複合動詞が連続する場合に多重に連結して
全てをひっつけて１文節にすると
（例：「|書き忘れ始め直し終わった|」）、
組み合わせ候補数が爆発的に増え、破綻しました。
変換の処理時間が数分とか数十分とか言う単位でかかってしまいます。
複合動詞を１つだけ連結して１文節にすると、
組み合わせパターン数が増えるので、
表記の違いの選択がちょっと行いにくい感じでした。
好みによる影響がかなり大きそうではありますが。
たとえば「つけわすれる」を変換した場合、
「付け忘れる」、「付けわすれる」、
「点け忘れる」、「点けわすれる」、
「着け忘れる」、「着けわすれる」……
の様な表記の違いを、多数並んでいる候補から選択しなければなりません。
全般的な文節区切りへの影響は……、正直、違いが判りませんでした。
また、連結する内容が違うと連文節の学習も単文節の学習も
どちらも適用できないので、
学習の効率がちょっとだけ下がります。
例えば、
「|説明を|書き忘れる|」（|せつめいを|かきわすれる|）を学習しても、
「|説明を|書き始める|」（|せつめいを|かきはじめる|）には効かない。
「|書き直し|始める|」（|かきなおし|はじめる|）を学習しても、
「|描き直し|始める|」（|かきなおし|はじめる|）には効かない。
動詞連用形と複合動詞の文節を分割しつつ
変換候補に「複合品詞フラグ」を追加し特別扱いした場合、
表記の違いの選択は「場所を選んで候補を選ぶ」となり、
操作感が大きく変わりました。
たとえば「つけわすれる」を変換した場合、
まず最初の文節で
「付け」、「点け」、「着け」……、
の選択を行い、次の文節で
「忘れる」、「わすれる」……
の選択を行う。
全般的な文節区切りへの影響は……、正直、違いが判りませんでした。
学習は、適用できるケースが増えます。
例えば、
「|説明を|書き|忘れる|」（|せつめいを|かき|わすれる|）を学習すると、
「|説明を|書き|始める|」（|せつめいを|かき|はじめる|）の
「|説明を|書き|」（|せつめいを|かき|）の部分に学習が適用できる。
「|書き|直し|始める|」（|かき|なおし|はじめる|）を学習すると、
「|描き|直し|始める|」（|かき|なおし|はじめる|）の
「|直し|始める|」（|なおし|はじめる|）の部分に学習が適用できる。
誤適用が増える事もありそうですが。
結局これも、変な候補が出る出ないよりも先に、好みの影響が有りそうです。
数詞における接頭辞／接尾辞の分離よりは感触の違いが格段に小さく、
わりと慣れやすいと思いますが。
個人的には、文節分離後の方が
今まで使っていたかな漢字変換の感触に近いので
馴染みやすくて使いやすいのですが。はてさて。
複合品詞：複合名詞の１文節化もしくは文節分離に関して：
現在の alt-cannadic では
十分な数の単語が連結した状態で登録済の上に調整済の為、
今更いじったところで何も変わりませんでした。
むしろ悪化する感が。
辞書が未整備の時点での応急処置としては、
手軽に実現できるのでしょうけれども。
複合品詞を分離した場合の副作用その１：
数詞の分離に関して。
「かん」を「|感|」と学習していると、
「６かんが」を変換した時に
「|６|かんが|」と文節を区切った上で
「|６|感が|」と言う候補が優先されてしまう。
数詞分割の候補の場合、数詞ではない学習を強制無効化すれば
良いかとも思ったけれども駄目。
「数詞＋数詞接尾辞」のつもりで変換したのか、
「数詞＋別の文節」のつもりで変換したのか、
判断の付けようが無いので、
接尾辞学習を優先するべきか、
自立語学習を優先すべきか、
単文節学習を優先すべきか、の、
判断を付ける事ができない。
あるいは『「数詞」＋「かんが」』の連文節学習を行えば、
２回目以降は何とかそれっぽくなるかも知れないが、
Anthy に品詞で連文節学習する機能／能力は無い。
現状では、
『「６」＋「かんが」』の連文節学習でしか対処できず、
数詞の内容が変わる毎に学習し直さなくてはならない。
複合品詞を分離した場合の副作用その２：
文節区切り位置決定アルゴリズムが
複合品詞を使って「|約|三|冊|」と言う候補を提示するつもりで
「|やく|さん|さつ|」と言う文節区切り位置を返すと、
変換候補決定アルゴリズムが
「|焼く|産|撮|」等と提示してくる場合がある問題があって……。
別の例として、「そのごじっさいに」を
「|その後|実際に|」（|そのご|じっさいに|）と提示するか
「|その|５０歳に|」（|その|ごじっさいに|）と提示するかの問題があって……。
詳細はFri,18 Dec,2009を参照。
複合品詞：総論：
結局、
まずはじめに、
操作感の違いに対する好みの影響が大きく出そうに思われます。
私の場合、文節区切り位置の修正や文節の選択をあまり気にしないので
（注目文節を移動しながら変換内容が合っているのか確認する癖が有る）、
文節分離して各文節の候補の組み合わせパターン数が減った方が、
操作しやすくなりました。
あと、根本的に Anthy の構造が
複合品詞の文節分離や単語Ｎグラム処理を想定していない問題。
文節分離すると
変換候補の並び順が（文節分離前と比べても）うまく行かないとか、
学習のバランスがうまくいかないとか。
昨今 名を馳せている／名が出て来ている 各種の「最新の研究／理論を利用したかな漢字変換」はどれも 各ユーザの入力内容や利用状況に合わせたチューニングや学習が ガン無視されている様な気がしてならない今日この頃。 そんな事をしていると「Anthy型車輪の再発明」に終始するのではないか と言う危惧。 あと、OS／アーキテクチャ非依存をうたっておきながら、 /usr/bin/make が GNU make である事を前提にするとか、 int 型が 32bit である事を前提にするとか、 構造体のビットフィールドがレジスタ１個程度にパッキングされる事を前提にするとか、 malloc() した領域がゼロクリアされている事を前提にするとか、 alloca() 使うとか、 ディスク読み書きは必ず成功する事を前提にするとか、 それ以外にも色々有ったけれど忘れた、 そう言うのはヤメテ。
浪漫飛行、米米CLUB、1987.10.21/1990.4.8。 ja.wikipedia.org の曲情報って、曲の発表年月日とは限らないのね……、 今頃気付いた。
リゾ・ラバ -Resort Lovers-、爆風スランプ、1989.7.19。
ら・ら・ら、大黒摩季、1995.2.20。
MajiでKoiする5秒前、広末涼子、1997.4.15。
かな漢字変換。
「そうさはしっている」
→
「|操作は|知っている|」（|そうさは|しっている|）、
「|操作|走っている|」（|そうさ|はしっている|）、
「|そうさ|走っている|」（|そうさ|はしっている|）。
……、上記の例だと、
「|操作|走っている|」は滅多に使わないだろうけれども、
「日本語としてありえない決定的に間違っている変換候補」は無いから、
候補を抹消してしまうのはマズい。
単語／文節の連接に依る影響が大きいから、
現状の単語辞書の各単語に単語評価値を持たせる方法では、
対処できない。
文節基準でも単語基準でもいいから、
読み仮名付きのＮグラムのデータを持たないと、
上記の様なパターンはどうにもならないかな……。
そうなると、
コーパスを使うか、
用例辞書を使うか、
コーパスの字句利用を実装し直すか。
あるいは現状の Anthy の品詞ベース文節２グラム(?)の
実装方法を見直して実装し直すか。
現状の Anthy だと、
「|（品詞）+（付属語は無視）|（品詞）+（付属語）|」
の方向で実装されているので、これを、
「|（品詞）+（付属語）|（品詞）+（付属語は無視）|」
の方向に変えるだけで、
大きく変わる可能性があるわけで……、
良い方向か悪い方向か、全く見当が付かないけれど。
この
「どの位置で文節を切っても、それなりに正しい日本語になる」
辺りの変換内容に対する対処は、
やっぱり SKK 最強なんだよなぁ……、
文節区切り位置の手動入力を強制しているだけあって。
などとかどうとか言いながら、
この辺をいじる気は全く無かったりする。
個人的には、
たまに起きるこの手の間違いが気になる「程度」よりも、
普段から文節区切り位置をわざわざ入力する面倒さの「程度」とか、
効果が有るか無いか判らない上に
試してみた結果が参考になるか否かさえ判らない
改造を試験する面倒さの「程度」とか、
その方が大きいので。
などと落書きしていたら別パターンに遭遇。
「けんとうがつかない」
→
「|検討が|付かない|」（|けんとうが|つかない|）、
「|見当が|付かない|」（|けんとうが|つかない|）。
この場合、「検討」に「付」は誤字と断言して良いかな……。
とすれば「|見当|付|」で用例辞書行き決定かな。
助詞は「が」だけでなく「は」とか「も」とか色々パターンがあるので、
単語辞書だろうが複合語辞書だろうが、登録するのは無理だし。
高校生プログラミングコンテスト。
本屋で雑誌をペラペラ眺めたら。
高校生のプログラミングコンテストがあったらしい。
ふと思ったのだが、この手のコンテストやコンペティションでは、
製作の早さ（例えば 一般的なプログラミングコンテスト）とか、
アルゴリズムやアイディアの斬新さ
（例えば CQ出版社のアイディアコンテストとか IPAの未踏 とか）とか、
そう言うのは評価されるけれども、
ユーザビリティとかセキュアとか移植性とかは
微塵も評価されないよね……
（CQ出版社のコンテストでは、
ユーザビリティは評価基準にちょびっと含まれていたかも）。
セキュリティのコンテストもあるけれど、
攻撃して陥落させる早さを競うコンテストだし
（海外での攻撃コンテストは、
防御の裏返しとして行われているらしいけれど）。
ユーザビリティとかセキュアとか移植性とかを
公平均一に評価する方法が無いから、
コンテストにできないのかな。
と思ったけれども。
公平均一に評価する方法が無いと言う点では、
アルゴリズムやアイディアの斬新さの評価も
非常に主観的かつ曖昧で不均一だし。
単純に、
評価しても見栄え／面白みが無い、
客入りが見込めない、
スポンサーが付かない、
辺りかな。
あるいは、
日本ではセキュリティやユーザビリティそれ自体が
社会的に評価されていないが為にか。
プログラムを城に例えると、コンテストやコンペティションでは、
城の美しさや芸術性あるいは建築の早さ／安さは評価しているけれども、
防衛性能や暮らしやすさや引越しのし易さは
評価していない事になる様な気がしてならない訳で。
芸術的かつ速攻で仕上げた超巨大なハリボテじゃぁ森本レオな鼻歌にしかならんし。
確かに、
シガラミに囚われずにアイディアを出せるのも重要だけれども
（既存のアルゴリズムや自分が知っているアルゴリズムやアイディアなどに
囚われずに、使いやすさや安全性を追究するのも重要だと思う）。
車で言うと、
アクセルとブレーキとハンドルの操作は知っているけれども、
サイドブレーキとかシフトレバーとか
ウィンカーとかワイパーとかハザードランプとかの
使い方を知らない様なものではないかと。
あと、
アイディアを出すだけの人（口だけの人とも言う）が高給取りで、
ユーザビリティとかセキュアとか移植性とかを満たす人が安月給、
と言う日本の現状は……。
電撃 HJ はオマケ付録付きにつき立ち読みお断り、が多いなぁ……。
ばら物語 が……。
先週辺りから、電車が定常的に３〜８分遅れな状態……。
今日は唐突に電車がすいていた。
某国道にて。 定例パトロールらしきパトカーが追越車線を法定速度で走っていた。 それを一般車が走行車線側から追い越していった。 いいのかそれで……。
今日は電車が、路線によって、 あり得ないくらいガラすきだったり、 いつもよりちょっと混んでいたり。
で、なんかいつもと違う場所に電車が留置されている。 と思ったら、今日は休日ダイヤだったのか。
ラジオ。
AM/FMラジオ内蔵ICレコーダー（ポケットサイズ）なんてあるのね。
と思ったら２万円近くするのか。
ゼネカバ買える値段だ……。
あれ、ワンセグTV FM/AMラジオ付き の最廉価品が１万５千円前後で、
それより高いんだ……。
中古 CD屋に、東方の音楽 CD が並んでいた。 うーむ。
サウンド デバイス。
入力をそのまま出力にスルーする機能の無い音源を使っている場合に、
Unix系 OS にて
マイク入力 や ライン入力 を、そのまま スピーカー出力 に出す方法。
% esdrec | esdcat
esd(daemon) を常駐させる必要は無し。
調べるのに１時間半もかかってしまった……。 ラジオのボリュームが故障気味で使い物にならないので、 PCをスピーカーの代用にしているだけなので、 ラジオを新調しろと言う話も有るけれど。 メーカー修理では異常無しで返ってきてしまったし。 コネクタを２個はさむ上に冷陰極管の駆動ラインに隣接しているラインに ボタン８個だか10個だかもアナログ化して重畳するから 滅茶苦茶になるのだよ……。
いつも読み方を忘れるのでメモ。 「重畳」（ちょうじょう）。
３ボタン チルトホイール DPI切り替え付き レーザーマウス ￥1,180-。 三菱？ 2GB SD ￥850-。
ルービックキューブ 限定特価￥1,450- で山積み。 ……クリスマス用で仕入れすぎたんか？。
負けないで、ZARD、1993.1.27。
夢をあきらめないで、岡村孝子、1987.2.4。