基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
気をつけろ！ 今日は満月だ -- more --
気をつけろ！ 今日未明は月食だ -- less --
戦闘妖精・雪風 アンブロークンアロー、神林長平。
えーと、これはまだ続刊が出ると言う事ですか。
SF と言うよりも、
SF的な世界を舞台にした哲学か禅問答なのではないかと思う。
純粋 SF を期待している人が読むと駄作だと感じる恐れが。
アシモフのロボット〜銀河帝国 シリーズも、その傾向があったけれど。
個人的には好きなのだけれども、読み手を選ぶと思う。
悲しいね、渡辺美里、1987.12.2。 作曲：小室哲哉 らしい。 半年だか１年だかくらい前から有線放送やラジオで耳にしていたが、 ずっと曲名が判らないまま歌い手も思い出せないままだった。 ようやく判明。
alt-depgraph-091231。
形容詞を細分化したとの事なので、どんな風に変えたのだろう、と見てみた。 要約すると、vagus氏のところの表に書いてある通りだった。 形容詞以外でも、alt-cannadic-091230 から単語が増えている事に気付いた。
日本語の場合、
どの様な付属語が付くかも含めて品詞が分類されている。
ところが原作版 Anthy の場合、
どの品詞にどの付属語群が付くかを余り区別せずにごちゃ混ぜになっており、
そのために滅茶苦茶な候補が出てくる事も多い。
もっともこれは、
この手の「人力調整が必要となる様な情報は使わない」と
言う方針かもしれないけれど。
※注意※ 未確認であり確証は無い。
なので、
品詞−付属語の接続情報を充実させれば、
それなりに（← 定量的な観測や検証を行っていないので曖昧表現）
改善される筈で、
その具体的なものが alt-depgraph であって。
でもそれを行うとなると、大変な労力が必要になる訳で。
と言う訳で、色々お疲れさまです。
コーパスに「|香る|風に|開けよ|」を追加すると、
「|（文頭）|VeSe + る|」
「|VeSe|NkSk + に|」
「|NkSk|VeSz + けよ|」
「|VeSz|（文末）|」
で処理される様な気がする。
なので、コーパスに「|香る|」「|風に|」「|開けよ|」を
各単語として追加すると、
「|（文頭）|VeSe + る|」
「|VeSe|（文末）|」
「|（文頭）|NkSk + に|」
「|NkSk|（文末）|」
「|（文頭）|VeSz + けよ|」
「|VeSz|（文末）|」
で処理される様な気がする。
場合によっては、余計な
「|（文頭）|クラス + 付属語|」
「|クラス|（文末）|」
を記録してしまって、文章を入力した時の
先頭や最後の語の品詞確率の元データが変になる場合があるかも知れない
様な気がしないでも無い。
気がするだけ。未確認。
かな漢字変換の文節区切り学習。
「の|文字」（の|もじ）を学習していると、
「だすのもじゅうようだと」を変換した時に、
「|出すの|文字|ュウヨウダト|」（|だすの|もじ|ゅうようだと|）と
区切ってしまう。
あるいは。
「|それを|見た|」（|それを|みた|）を学習していると、
「それをみたよ」を変換した時に、
「|それを|見た|世|」（|それを|みた|よ|）と区切ってしまう。
さらには。
「を|再|取得する|」（を|さい|しゅとくする|）を学習していると、
「がくしゅうをさいげんする」を変換した時に
学習の「を|再|」（を|さい|）の部分を適用して
「|学習を|再|言する|」（|がくしゅうを|さい|げんする|）
と区切ってしまう。
「|それを|見た|」 → 「|それを|見た|世|」 にかんしては、
「|それを|見た|」の学習を再現する際に
「|それを|見」以降の付属語違いのパターンも生成して、
多少は何とかしているけれども。
「|学習を|再|言する|」と
「|出すの|文字|ュウヨウダト|」では、
『学習を適用しない』事でしか対処できない。
のだけれども。
では、その学習を適用するかしないかの境目は何処にある？。
文字数が少ない物は学習しない？、
原作版 Anthy はそうなっているけれども、
それでは原作版 Anthy の全然覚えてくれない学習を繰り返すだけ。
自立語が無い物は学習しない？、
学習の変な適用が減るのと、学習を適用して欲しいのに適用してくれないのと、
どちらの影響が大きいだろうか。
標準設定では、これにしてあるけれど。
でも、
自立語がある物のみ学習した場合
（文節区切り位置を、自立語＋付属語＋文節区切り＋自立語、として学習した場合）
でも、
同様の問題が起きてしまう
（→ Wed,06 Jan,2010を参照）。
そうなると、
現状の「修正後の文節区切り候補が適用可能ならば必ず適用する」のをやめて、
「先に提示した文節区切り候補と、修正されて確定した文節区切り候補の、
比較情報も一緒に保持して判断する」しか無いだろうけれど。
さて、比較情報って何だろう。
最も単純に考えると、
先に提示した文節区切り候補丸ごとと
修正されて確定した文節区切り候補丸ごとを
保持して、
修正前と全く同じ候補を提示しようとした場合には
修正後に差し替える。
でもこれだと、学習を適用できる場面がもの凄く少なくなって、
殆ど学習が効かなくなってしまう
（原作版 Anthy の、
単文節における候補の並び順決定用の INDEPPAIR学習が、
「修正前と全く同じ候補を提示しようとした場合には修正後に差し替える」
方式だったが、滅多に該当する場面にならずに殆ど機能していなかった）。
順当に考えていくと。
MBR ビタビならば修正前後の確率差、
ｎ文節最長一致ならば修正前後の文節数／文字数ペア、
だろうか。
文節区切りを検索する際に、
修正後の候補に対して、学習時に得た確率差／文字数得点を加算し、
逆に、修正前の候補に対して確率差／文字数得点を減算する
（減算も行わないと、
学習した結果を提示したが修正された場合などに、
加速度的に大きくなってしまう）。
あと、もっと基本的な部分で、
Anthy の文節区切り位置を決める構造が、
「文節を指定して、その両端に文節区切りを入れる」
となっている問題がある。
「この単語とこの単語の間に文節区切りを入れる」
と言う指定ができないのだ。
ここの改造まで行うくらいなら、
既存のソースコードを捨てて新規に起こした方がマシ。
かな漢字変換の単語２グラム。
単語２グラムで処理すると、
「けんとうをつける」を変換する時に、
「（文頭）+ けんとう」＋「けんとう + を」
＋「を + つ」＋「つ + ける」＋「ける + （文末）」
になると思うので、
「検討 + を + 着 + ける」（けんとう + を + つ + ける）
という候補が出てくる場合があるのではないかと思う。
「（文頭）+ けんとう」＋「けんとう + を」にて「見当 + を」とかすると、
今度は「検討 + を + 行 + う」（けんとう + を + おこな + う）が駄目。
じゃぁ単語３グラム、とかしても、助詞が増えるとやっぱり駄目だと思う。
あと、Anthy で使っている程度のコーパスの量だと
スパースネス問題が顕著になる。
「いわゆる付属語（あるいは助詞）」を除外して
自立語２グラム（２グラムなのだろうか？）だとどうなるかなぁ。
……ってそれは Anthy における用例辞書だし。
文節区切り候補の生成に関しては、
読み仮名のみ単語２グラム（２グラムなのだろうか？）でも良いのかな……。
駄目だ、PC内蔵スピーカー、音悪すぎ。
悲しみよこんにちは、斉藤由貴、1986.3.21。
リンダリンダ、THE BLUE HEARTS、1987.5.1。
ポーラスター、八神純子、1979.7.25。
大都会、クリスタルキング、1979.11.21。
ANNIVERSARY、松任谷由実、1989.6.28。
Anthy 拙作パッチ、文節分離の実験版。
接頭辞／接尾辞で文節を分離すると、
かえって文節区切り位置修正が増える例。
「おくがわ」を変換した時の、
「|奥川|」（|おくがわ|）と
「|奥|側|」（|おく|がわ|）。
数詞の接頭辞／接尾辞ではなく、名詞の接尾辞なのでアレですが。
学習の誤適用が起きる例、
Sat,02 Jan,2010の続き。
「|区切り|位置し|」（|くぎり|いちし|）という文節区切り学習がある時に、
「くぎりいちしゅうせい」を変換すると、
「|区切り|位置し|ュウセイ|」（|くぎり|いちし|ゅうせい|）
と区切ってしまう。
「|区切り|位置|」（|くぎり|いち|）という文節区切り学習がある時に、
付属語を自動拡張して学習を拡張した場合にも、
同じ事が起きる。
Anthy の学習量集計用スクリプト anthy_split.pl 「各種スクリプト」 にて、 数値比較演算子にすべきところを 文字列比較演算子にしてしまっているバグが有ったので修正。
Firefox の Policy Manager。
パラノイアに走って網羅的にルールを作っていたら、
いつのまにか 600パターン 4.5MB くらいになっていて、
起動に 20秒少々かかるようになってしまった。
試しにルールを全部消してみたら６〜７秒で起動した。
ルールに記述されていたサイト数を数えてみたら 700サイトを越えていた。
網羅ルールベースで記述しても、
サイトベースで記述しても、
数がほとんど変わらない……。
どうしたもんだろうね。
あとはばっさり、「許可するサイト」なルール１つだけにしぼるとか。
元々、
何でもかんでも Javascript を許可したり、
スクリプトを外部に投げてアクセス解析をしていたり、
そう言ったのを排除したかっただけなので、
RequestPolicy があれば
Policy Manager で事細かに絞る必要も無くなってくるのだよなぁ……。
それに Policy Manager では
外部に投げそうな処理を禁止する事はできるけれど、
外部に投げている処理を禁止する事はできないし、
そもそものプラグインの目的が違うし。
Firefox 3 の capability.policy、その１。
Firefox 2 までは
capability.policy.default.Window.navigator
にて、いらん解析やら何やらを排除できていたのだが、
Firefox 3 になってからは、それだと排除できていない事に今更気付いた。
どうやら、
# Firefox にて実装済み
capability.policy.default.Navigator.appCodeName
capability.policy.default.Navigator.appName
capability.policy.default.Navigator.appVersion
capability.policy.default.Navigator.buildID
capability.policy.default.Navigator.cookieEnabled
capability.policy.default.Navigator.javaEnabled
capability.policy.default.Navigator.language
capability.policy.default.Navigator.mimeTypes
capability.policy.default.Navigator.oscpu
capability.policy.default.Navigator.platform
capability.policy.default.Navigator.plugins
capability.policy.default.Navigator.product
capability.policy.default.Navigator.productSub
capability.policy.default.Navigator.userAgent
capability.policy.default.Navigator.vendor
capability.policy.default.Navigator.vendorSub
# Firefox では未実装
capability.policy.default.Navigator.appMinorVersion
capability.policy.default.Navigator.cpuClass
capability.policy.default.Navigator.browserLanguage
capability.policy.default.Navigator.systemLanguage
capability.policy.default.Navigator.userLanguage
# いじるな危険
capability.policy.default.Navigator.mozIsLocallyAvailable
capability.policy.default.Navigator.preference
capability.policy.default.Navigator.registerContentHandler
capability.policy.default.Navigator.registerProtocolHandler
に分離したらしい。
capability.policy.default.Navigator とか * とかでは駄目だった。
全部書かないと効かないらしい。
Firefox 3 の capability.policy、その２。
Firefox 2 から 3 に移行後ずっと、
user_pref("capability.policy.default.Window.onunload", "noAccess");
も効いていない事に気付いた。
こちらは、新しい名称が見つからなかった。
廃止になったのか、新しい名称が何か有るのか、その辺は不明。
鉄道債。
３年 0.43％らしい。
2007年頃〜2009年初頭頃は 0.90〜1.4％をふらふらしていたが、
2009年初頭に 1.0％、2009年中頃 0.6％、そして今回 0.4％。
まぁ、100万円単位で売り出されても手が出るわけが無いのですが。
１万円単位ならコレクションしたくなるけれど……。
HDD の温度。
とある小型計算機の HDD 温度が、近くにある別の計算機の HDD より、
常に５℃くらい高いのが気になっていた（５年前からずっと）。
今日、ようやく原因に気付いた。
この小型計算機、
CPUのヒートシンクが筐体につながっていて、
筐体ファンとヒートシンクの冷却ファンが１個にまとめてある。
で、HDD も取り付け金具経由で筐体につながっているから、
当然、CPU のヒートシンクと同じ温度になる訳で。
その CPU の温度が、
近くの別の計算機の HDD より５℃高いところだった。
試しに HDD 取り付け金具を筐体から浮かせてみたら、
HDD 温度が５℃下がった。
サンヨーのエネループ。
なんかいっぱいあって何が何だか判らなくなってきたので調べてみた。
単3形 新eneloop（2本） HR-3UTGA-2BP yodo:780- bic:780- sof:780(10%) 単3形 新eneloop（4本） HR-3UTGA-4BP yodo:1,480- bic:1,480- sof:1,480(10%) seiyu:1,470- コンパクト急速充電器(2-230min) NC-TGR02 bic:1,281- sof:1,281(10%) スライドカバー付き充電器(2-210min,4-420min) NC-TGN01 yodo:1,780- bic:1,780- sof:1,780(10%) 急速充電器(1-75min,2-110min,4-220min) NC-TGR01 yodo:2,980- bic:2,980- sof:2,980(10%) 残容量チェック機能付急速充電器(2-100min,4-220min) NC-TGR03 yodo:3,980- bic:3,980- sof:3,980(10%) 急速充電器(2-120min,4-240min) BQ-391 yodo:3,480(15%) bic:3,480(15%) sof:3,480(15%) seiyu:3,770- コンパクト急速充電器セット(2-230min) N-TGR02AS yodo:1,980- bic:1,980- sof:1,980(10%) スライドカバー付充電器セット(2-210min,4-420min) N-TGN01AS yodo:2,980- bic:2,980- sof:2,980(10%) seiyu:2,970- 急速充電器セット(1-75min,2-110min,4-220min) N-TGR01AS yodo:3,980- bic:3,980- sof:3,980(10%) 残容量チェック機能付急速充電器セット(2-100min,4-220min) N-TGR03AS yodo:4,980- bic:4,980- sof:4,980(10%) 急速充電器セット(2-120min,4-240min) K-KJQ91M34R yodo:3,980(15%) bic:3,980(15%) sof:3,980(15%) 単三の主要系列は以上。但し、BQ-391 と K-KJQ91M34R は パナソニック エボルタ。 ヨドバシとビックは基本10％ポイント。 ソフマップは基本１％。 西友はセゾンカードの日のセゾンカード払いは５％引き。 TGR03 は、 残量チェック機能付き（同時に１本のみ測定可能）、 リフレッシュ機能付き、 NiMH, NiCd 両対応、 ２倍速充電まで対応、 単３は４本まで、単４は２本まで、 らしい。 TGR01 は、 残量チェック機能は無い、 NiMH のみ対応、 ３倍速充電まで対応、 単３、単４ともに４本まで、 らしい。 TGR01 にするか TGR03 にするか BQ-391 にするか、中途半端だ……。
R.I.P.、BUMP OF CHICKEN、2009.11.25。
アゲハ蝶、ポルノグラフィティ、2001.6.27。
Anthy……というよりも、かな漢字変換 全般。
「ほんしつてきにかわってしまう」を変換すると。
MBRビタビ：「本質的に|変わって|しまう」
前方ｎ文節最長一致：「本質的|膠って|しまう」
前方ｎ文節最長一致が提示してくる「本質的|膠って|しまう」は
日本語として見るとあり得ないわけだけれども、
そう言うのを出ない様にするにはどうするか、と言う所まで来ると、
もうパラメータ調整でどうこうできる範囲を越えているわけで。
対応策としては、
文節のつながり情報を何とかして用いる様にするしかないのだけれども、
そうなると、
「学習する」か、
「用例辞書に突っ込んで（無理して）出る様にする」か、
「連文節の情報のデータベース機能を追加して用いる」か、
その辺りしか手が無いけれども。
「文節のつながり情報を何とか」って、
原作版 Anthy が
HMM（5911〜8130、8131〜8132は欠番？）→ MEMM（8133memm〜8521、8522は欠番？）→ MBRビタビ（8523〜現在）と
（5911より前は未確認）、
色々とアルゴリズムを試していたのがまさにそれなわけで。
小型廉価のラジオ。
RAD-F182M 2,970 AM,FMステレオ でも内蔵スピーカーはモノラル RAD-S312N 1,770 AM,SF,FMモノラル RAD-F030M 1,480 AM,FMステレオ コンパクト、内蔵スピーカー無、感度悪いらしい
ジェスチャー機能／テンキー機能付きタッチパッド。
ELECOM TK-TCT005BK と
Princeton PTP-SP1W PTP-SP1B 辺りが、
￥3,000弱で買えるらしい。
半年内のつい最近の新発売らしい。
MS-Windows 以外でも使えるのだろうか。
それからジェスチャー機能は、
第３、４、５、６、７ボタンとして使い勝手はどうなのだろうか。
タッチパッド内蔵キーボードだと￥7,000弱するしなぁ……。
↑ テンキー／ジェスチャー機能無しのタッチパッドだと、
ダイヤテック FILCO ATP-400UB ￥5,000弱、
GP-410UB ￥7,500弱、
GP415UB ￥9,000弱、
と言うのも有るらしい。
こちらは2008年６月頃から発売らしい。
FTP500UB ￥5,000弱 と言うのも有って 2009年４月頃から発売らしい。
こちらはジェスチャー機能は付いているらしい。
VARIABLE FIGHTER MASTER FILE VF-1 VALKYRIE
とかいうのが出ていたらしい。
2009年７月14日発売だったらしい。
￥2,625-らしい。
次作は VF-19 EXCALIBUR らしい。
値段が2,730円に値上がりしていて、発売日は2010年３月下旬らしい。
何で今までチェックしていなかったのだろう、と思ったが。
出版社がソフトバンク系列なので脊椎反射で拒絶を起こしていたらしい。
Sun,27 Mar,2010 追記：2010年４月30日に延期らしい。
Tue,20 Apr,2010 追記：2010年６月２日に延期らしい。
Sun,30 May,2010 追記：もう発売されているらしい。
Anthy……というよりも、かな漢字変換 全般。
「|販|社|」（|はん|しゃ|）を学習していると、
「せきついはんしゃ」が「|脊椎|販|社|」（|せきつい|はん|しゃ|）になる……、
字が違うＯＲＺ。
ここ１ヶ月くらい同じ話をリピートしてしまっている気がするので省略。
省略も何も、前回、前々回と同じ話。
「脊髄反射」が 「せきづいはんしゃ」で出ないと思ったら「せきずいはんしゃ」だった。 辞書を引いても「ず」だった。 「せきつい」の変化で「づ」だとずっと思っていた……。
「
www.hi-matic.org - めもがき:2010年1月15日分
- [NetBSD] editline(3) - @ libeditの現状」
＞
「「 国際化はUTF-8にまかせろー(バリバリ)」ときたら
「 やめて！」と返すしかありませんやね。」
笑えると言うか泣けると言うか……。
何処の界隈に行ってもその話になってしまうのね……。
GearHead-1 の国際化計画
（l0ugh氏の日本語化版を基に UTF-8化する話が有ったとか無かったとか？。
誤解無い様に補足すると l0ugh氏版や 日本語SDL版 は日本語化対応日本語版。
迷宮版は国際化対応日本語版）
や
GearHead-2 の国際化計画（くわしい中身は調べていない）
の時も、全く同様の傾向が有ったらしいし、
原作版 Anthy もその傾向が有る様な感じだし……。
それは国際化対応ではなくて UTF-8 対応だ……、と言う突っ込み。
そう言えは
GearHead-1 の国際化版
（迷宮版の I18N版 ……と言うか何と言うか、
結局それ以外の呼称しようが無いような）
は本家に放置された状態だなぁ……、
下手くそな英語で誤解されて怒らせちゃったかなぁ……。
あと、あれは、
各国EUC/ShiftJIS/UTF-8 にもろに依存してコーディングしている上に
手抜きで ISO-2022 とか UCS-4/2, UTF-16/32 に対応していないし
結合文字の対応が不完全すぎるしなので、
まともな国際化対応とは言えないのではないかと言うアレがナニ……。
あと、
国際化と言っても I18N と L10N と M17N の違いとか言い出すと頭痛い。
Anthy 拙作パッチの aclocal のバージョンを 古いままにしている理由。
aclocal-1.10 辺りにバージョンを上げてパッケージを構築すると、
OpenBSD で libtool がこけるから。
どうも CC の解釈でこけているっぽい。
忘れていて aclocal のバージョンを上げてしまって、
またまたまた刺さった。
何回目だろう……。
と言う訳で書いておく。
点検だか何だかで、10〜20分に１本の運転。
反対方向はもろに20分待ちしているらしい。
まぁ、あれだ、そういう事態になる事が判っていても
安全確保の為の臨時点検を優先するのは、
安全に対して信頼できると言う話につながる訳だけれども。
日本の会社とか日本の世論とかの場合、
普段は削っちゃいけない所のコストまで削りまくるのにこう言う時だけ
「普段の整備をきちんとやらないからこんな事になるんだ」と、
変な方向にキレそうな人が
（主に経営陣とか団塊の世代とかに）いくらでも居そうな気がした。
ネットワークがまた死んだ。 誰かがまたまたまたまた何かやらかしたらしい。 fenix や svn サーバに接続できない……。
何か色々とお疲れさまです。
> UTF-8
なるほど、了解しました。
蛇足ですが。
私が使っているエディタ（vim）で、
EUC-JP なファイルをわざと UTF-8 で読み込ませて
そのまま保存してみた場合は、
いわゆる全角文字１文字 が
0x3F 0x3F（文字で表記すると「??」）に化けました。
エディタによって化け方が違うようです……。
銀行の普通預金金利。
なんか、先週末頃だか今週頭頃だかに、ネット専業系で下がったらしい。
普通預金より定期預金の方が預金金利が低いって……。
uim。
vi 連動モードにて、
ESC で IM off だけでなく、
IM on で入力モードに入る機能が欲しい。
実際の所は、i, I, a, A, o, O と入力モードは多数有るので無理だろうけれど。
入力モードに入るのを忘れたまま日本語入力してしまう事がしばしばあって泣ける。
そう考えると、vi 連動モードの ESC は、かなり助かっているのだよなぁ……。
uim。
ローマ字入力にて kinput2 のそっちのモード（名前忘れた）の様に、
未変換時の入力編集が、キータイプ毎になって欲しい。
子音や母音をタイプし忘れたり余計にタイプしたりした時に、
kinput2 を使っていた時の癖そのままに
画面表示を確認しないでミスタイプの修正作業をしている時があるのだが、
uim でそれをやってしまうと入力が滅茶苦茶になってしまう。
Anthy……というよりも、かな漢字変換 全般。
文体設定が欲しいかも。
書類もしくは webサイトによって、
例えば「事」「様」「為」「有る」「無い」「暫し」などを
平仮名にするか漢字にするかを
わざと変えているのだけれども、
学習だけだと第１候補を選べないから困る。
私以外に使う人がいるとは思えない機能だ……。
しかも、
どの字に関してモード切り替えするべきなのかを
どうやって知るのかが大変そうだ。
学習を確率モデルで行って、
確率が均衡している辺りで検出出来るか？。
ああ、正則送り限定／最優先モードも欲しい。
正式な書類でうっかり変則を使ってしまうと嬉しくないので……。
助動詞等の文節分離版の場合、 付属語グラフから助動詞等の平仮名表記を消した方が良かったかも。
「メモりの」 v.s. 「メモリの」
毎度毎度同じネタなので略。
今回は単文節変換での話である点だけが違う。
ハイバネーションが欲しい。
S4BIOS ハイバネーションではなくて、
作業中のデスクトップ環境を丸ごと一時中断して保存して、
別の保存してある作業中環境に切り替えられる様な機能。
一般的なデスクトップ環境のセーブだと、
エディタやら pdf ビューワーやらブラウザやらの
作業途中の状況が保存できないから……。
作業環境の切り替えで問題が出るか。
判りやすい所で webブラウザの履歴の競合とか。
Anthy 用例辞書の試験版、更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
alt-depgraph 更新に伴い、
今までの用例辞書の引用条件だとちょっと条件が厳しくなった気がしたので
（気がしただけ。詳細未確認）、
甘めに変えてみた。
あと用例を２件追加。
↑ 「|名詞活用形|動詞のなにか|」 の連文節判定にて名詞部分に格助詞の形が全く出なくなって、 全部 連用形になった様な気がする。 今までの用例辞書は格助詞で突っ込んでいたので、 用例に全くヒットしなくなっていた。 その割に、単文節候補では相変わらず格助詞で出てくる辺り Anthy はよく判らん。
年賀状：
975424
630838
446722
259668
0977
52
00
C-27520
TRUE LOVE、藤井フミヤ、1993.11.10。
ミラーブロックス（ゴールド）がまた売っていた。 限定だった気が？。
娘フロ。
中古￥500- で２枚、
新品￥3,045- から 10％引きで２枚、
売っていた。
しかも店の前の通りで 買い物券 50円 を配っていた。
GUNDAM SONGS 145 とか言うのが出るらしい。
CD 10枚組で￥30,000-らしい。
SHM-CD って…… Shared Memory ですか？。
レコードメーカーが違う、と言う理由で
GUNDAM Single History から故意に外されていた 0083 も、
今回は収録しているらしい。
ヒゲ以降も全部入っているらしい。
個人的には SEED 以降の SD も含めて 55曲は要らない……
そう言う層は結構厚いと思うのだけれどもなぁ……
金額換算で １万２千円ぶんにもなるし……、
逆に SEED以降だけあればよいと言う層もかなり厚そうだと思うし……。
銀河英雄伝説のサントラＢＯＸや攻殻機動隊サントラＢＯＸの時は、
知ったのは売り切れ入手不可の遥か後だったと言うオチがあるし……。
落ち着いて考えてみると。
CD 10枚と言う事は、まともに聞くと 10時間かかる事になる……。
しかも考えるまでもなく、
予約受付終了らしい。
Anthy 拙作パッチのバグ。
バグ検出用の機能（ENABLE_ERROR_RECORD）の
連文節学習用の部分にて、
バグでは無いものをバグと誤判定するバグを見つけた。
バグの存在自体は、
この機能を追加した割とすぐ後に気付いていたけれども、
何がどうバグになっているのか、ようやく判明。
入力された内容と学習内容とで、
自立語部分までは一致するけれども、
学習した内容に対して入力した内容通りの付属語を付加できない時に、
学習のバグと誤判定していた。
具体例を挙げると、
「|どう|効くか|」（|どう|きくか|）と言う変換確定内容から
『前の文節が「どう」（どう）、この文節の自立語が「効」（き）』
と学習してあった時に「いどうきょりが」を変換すると、
『「い」|「どう」|自立語「効」（き）+付属語「ょ／ょり／ょりが」』
と言う文節区切り候補を生成しようとするのだけれども、
「効」（き）に「ょ」で始まる付属語は付かないので、
そう言う文節区切り候補を生成する事ができない。
この最後の「文節区切り候補を生成する事ができない」に対して、
「学習が間違っている」とエラーを出しているのだけれども、
この例の場合は「候補を生成できない」方が正しくて、
候補が生成できちゃうとそっちの方がバグだね……。
かな漢字変換として使う時には実害が無いバグなので、治す気無し。
あと、 「そもそもこの入力内容にその学習の適用は無い」と言う点に関しても、 修正しようが無い。 人間だから判るのであって、機械判別する方法が無い （大量の例文情報を持つとか言う方法を除く）。
「１かいていど」
→ 「|１|改訂|度|」（|１+かいてい|ど|）
v.s. 「|１|回|程度|」（|１+かい|ていど|）
毎度お馴染み（略）
さくら、ケツメイシ、2005.2.16。 あれ、これ、2005年？、もっと前だと思っていた。
TeX で ハーチェク 。
TeX でチェコ語の人名を書く必要に迫られたのだが。
文字の上に v が付いているヤツを書く方法が判らなかった。
どうやらこれは ハーチェク と言うらしく、
「\v S」と書くと、「S」の上に v が付いた。
ディスプレイ。
超高解像度のディスプレイが欲しい。
A4サイズで 200dpi とか 300dpi とかくらいの。
書類をディスプレイで読んでいると、
解像度と広さのバランスが悪すぎてつらい……。
あと、CAD で図面を引いている時は、
解像度は現在の 64dpi だか 80dpi だかで構わないから
A3 サイズくらい欲しい。1600x1200 くらいのヤツ。
最近のディスプレイはワイドだか
ハイビジョンサイズ？だかに走ってばっかりで使いにくい。
Firefox weave。
Service.Main ERROR Could not load the Weave crypto component. Disabling Weave, since it will not work correctly.
はい終了……。
Darwin,
GNU/Linux_arm, GNU/Linux_x86, GNU/Linux_x86_64,
SunOS,
MS-Windows CE, MS-Windows NT
しか対応していないらしい。
↑ FreeBSD forums によると、
Mozilla のバイナリパッケージだとそうなるから駄目で、
/usr/ports/www/weave から入れるとＯＫらしい。
まぁ unzip -l weave_sync-1.0-fx+fn+sm.xpi した時点で、
Mozilla のバイナリパッケージ版だと動かないのは
すぐ判ったけれど……。
でだ。OpenBSD には www/weave の ports が来ていないのですが……。
入れた。 こけた。 Error While Syncing Weave encountered an error while syncing: Unknown error. Weave will automatically retry this action とかダイアログが出て、weave の client のログに Net.Resource DEBUG PUT fail 500 https://******************************************/storage/meta/global とか出ている。httpd のログを見たら、 [error] PHP Fatal error: Call to undefined function mb_strlen() in /var/firefox_weave_minimal/weave_basic_object.php on line 162 だと。パッケージが足りなかったらしい。 php5-core php5-mbstring php5-pdo_sqlite php5-sqlite これは不要かも？ まで入れて、ようやく同期が取れた。 でも、ローカルに 10MB前後のデータが有るのに、 サーバには 4MB前後しか送信していない……。 完全同期して欲しいのだが……。 あと、データの内容が暗号化されるのは各項目の内容だけで、 何の項目か（bookmark,history,tab,prefs,password）、 その行の管理番号？は幾つか、 などの情報は、平文だった。 暫く使ってみたら、今度は httpd のログに [error] ALERT - configured GET variable value length limit exceeded - dropped variable 'ids' (attacker '***************', file '/var/weave/index.php') とか出て、同期がコケていた。httpd の設定ディレクトリの php.ini にて php_admin_value suhosin.get.max_value_length の値を大きくすれば、エラー＆拒絶をしなくなるらしい。 手元で試した所では 6600台をちょっと越えた。 但し、アタックの可能性の有る接続も蹴りにくくなるらしい。 それから、毎回の同期に２分くらいかかる……。 さらに。 「履歴／ブックマークの削除」が出来ない事に気付いた。 ローカルから削除しても、同期を取った時に復活してしまう。 ……、同期、直後に削除、直後にまた同期、の手順でやれば、ちゃんと消えるらしい。
Anthy 拙作パッチ。
今更唐突に思い出しましたが。
iconv版は Unicode 5.0 まで対応で、
Unicode 5.1 の異字体セレクタ IVS には正式には対応していません。
もっとも、Unicode の構造の後方互換性に依り、
何となく出せてしまうと思いますが。
原作版 Anthy は、ソースコードを読む限りでは、
Unicode 2.1 かそれ以前までのみ対応でした
（Unicode 3.0 で追加になった漢字の処理コードが存在しない）。
こちらも、Unicode の構造の後方互換性に依り、
何となく出せてしまいますが。
Unicode 3.1 で対応になった JIS X 0213 とか。
とは言っても、高々、
Unicode の追補で追加になった漢字を漢字とみなさずに処理してしまう
程度の問題。
それよりも潜在的破壊力が有るのが。
原作版 Anthy でも拙作パッチでも、
Unicode の文字を 32bit として扱うか 16bit として扱うかは
処理系依存なので、
Unicode 3.1 追加漢字面とか
Unicode 5.1 異字体セレクタ IVS のように、
16bit に収まっていない奴は処理系によっては死にます。
これを治すくらいなら Anthy 捨てて全部作りなおした方が（略）
Firefox Weave で思い出したが、
Anthy の学習にも同様の機能が欲しいと前々から思っているけれども
やる気は無し。
作業環境が計算機３台くらいにバラけているので、
学習を統合してもらわんと効率が悪くて。
現状は、ファイルサーバに ssh でコネクション張りっぱなしにして、
rsync なり sshfs なりで同期を取っているけれど。
実装するとしたら、
まず学習の仕方を、
アトミックで個々の学習項目を単独に分離可能にする所から始めて、
データベース処理をデータ側において記憶しない系に改造しないと
いけないし。
それをやると、
原作版 Anthy のソースコードの残存部分が、
単語辞書の読み書きと、
コーパスからの確率解釈と確率データベースの読み書き適用だけ、
になるから、
Anthy 捨てて全部作りなおした方が（略）
Butterfly、木村カエラ、2009.6.1。
libxul。 ビルド時にテンポラリを 700MiB くらい消費。 ビルドは amd64 2.2GHz だと１時間前後、 Core 1.6GHz だと２時間ちょっと、 で終了。
Firefox で Javascript が SIGSEGV する件、
Thu,24 Dec,2009の続き。
Firefox 3.6 を試してみた。
やっぱり Javascript が落ちた。
しかも、
前回は i386 でのみ SIGSEGV して amd64 は問題無く動いていたのだが、
今回は amd64 でも落ちる。
JS_NO_FASTCALL の要改造箇所が
mozilla-1.9.2/js/src/jstypes.h だけでなく
mozilla-1.9.2/js/src/nanojit/avmplus.h にも
増えていた。
3.6 は、それでは治らず、落ちた。
amd64 の場合：ビルド中に落ちる。 #0 in _find_thread () from /usr/lib/libc_r.so.6 #1 in pthread_getschedparam () from /usr/lib/libc_r.so.6 #2 in PR_SetThreadPriority () from /usr/local/lib/libplds4.so.1 #3 in _PR_InitThreads () from /usr/local/lib/libplds4.so.1 #4 in _PR_ImplicitInitialization () from /usr/local/lib/libplds4.so.1 #5 in PR_NewThreadPrivateIndex () from /usr/local/lib/libplds4.so.1 #6 in main (argc=3, argv=0x7fffffffe2d0, envp=0x7fffffffe2f0) at js.cpp:4727 i386 の場合： ビルドは全部通った。 起動時に必ず落ちる。 印象としては C++ の例外を catch していない感じ。Wed,05 May,2010、 Fri,02 Jul,2010、 に続く。
Anthy の辞書更新。
用例を追加する毎に、
同一アーキテクチャの３台のマシンで丸ごとビルドし直すのが面倒なので、
リポジトリ直結で作業しているマシンのみでビルドして、
辞書データだけ残り２台に転送してみようとした。
その前に、３台でビルドした辞書データが一致するか否か確認してみた。
辞書ファイルの内容が一致しないのですが ＯＲＺ。
同一マシンでコンパイルオプションを変えただけでも一致しない。
全マシン、コンパイルオプションを変えたビルドディレクトリ、等全部で、
make distclean して ../configure からやりなおしてみたら、
ようやく一致した。
Anthy の Makefile.am が駄目駄目って事ですか。
前からそうだったけれども、
拙作パッチの修正でもまだ治り切らなかったか……。
辞書サイズから憶測するに、組み込みのコーパスデータベースが、
make update_params0 とか
make update_params とか
実行した時の、
古いままになって更新されていないっぽい。
FreeBSD 6 で NFS。
何年か前から、ごくまれに mountd が
bindresvport_sa: Address already in use
とか言って起動しない場合が有った。
で、今日、唐突に気付いた。
mountd は
使用するポートを Trusted Port からランダムに選んで決めるから、
それが既に起動済の他の daemon と衝突してこけただけなのではなかろうか。
mountd -p でポート決め打ちすれば問題起きないのでは。
↑ それだけでは駄目だった。
amd - Auto Mount Daemon も
適当に空いているポートを使って
udp4 でループバック？接続をしているのだが、
mountd が待ち受けポートを開けようとランダムに選んだポートが
amd がランダムに選んだポートとぶつかると、
前述の bindresvport_sa のエラーで
mountd が動かなくなってしまっていた。
/etc/rc.d/amd の REQUIRE の項目に mountd を追加すれば、
mountd が先にランダムにポートを決めて、
その後に amd がそれ以外の空きポートからランダムに選ぶ様になるので、
問題が出なくなった。
なのだけれども。
「amd は使うけれども mountd は使わない」と言う設定をした時に
まずいかもしれない。
音便。
私の場合、いつも
「の（だ／で）」が「ん（だ／で）」に
音便がかかっている事に気付いた。
shell script の case で空白にマッチさせる方法。
#!/bin/sh -- case "$1" in xax) echo "a" ;; " ") echo "b" ;; *) echo "z" ;; esac
非接触式 IC カードリーダ。Felica リーダーとも言う。
量販店価格で、
純正の「パソリ」だと￥2,980- するけれども
IO-DATA の「ぴタッチ」なら￥1,980- らしい。
「SD/miniSD/microSD カードリーダー内蔵テンキー」 と言う物があるらしい。 色々とよく考えるね……。
alt-depgraph-100120-patch100126.alt-cannadic-091230。
「一択の」（いったくの）が出ない。
「一択」（いったく）は出る。
さて、これは、出るのと出ないのと、どちらが適切だろう？。
#T35 が適切な気がする。
と思ったら、そもそも辞書に載っていないし。
何故、候補に出てきたのだろう。
出ないなら出ないで、その方が妥当だと思う。
↑ 拙作パッチの、 「辞書に無いけれども学習に有る場合は、変換候補として提示する」 機能のせいだった。
VF-1S マックス機カラーリングの完全変形？ 1/100？ ￥980-だったか ￥6??-だったか。 交換用 VF-1J頭つき。 マックス機で VF-1S頭の機体って劇中に登場したっけ？。
スーパーエアーコンバット２、通常版￥1,050-、廉価版￥525-。 懐かしいが、かなりの駄作らしい。 その値段では誰も買わない気がする。
POWER DoLLS ３ ￥1,029。 プレイしたい人なら買い一択の値段。 工画堂はもうアレな状態なので PD3+4 パックは出そうに無いし。
ブルーフロウ 値段忘れた。 BB TwinPack 出てるしなぁ。
D-SUB 15pin３段 本体側 → DVI-I ディスプレイ側、変換アダプタ ￥105- で１個と、￥315-で１個。 先々週、￥315-で買ったばかりなのにさらに安く見つかるとは……。
DVI-D (SingleLink) ケーブル ￥525〜￥840-。
EIZO の中古ディスプレイ ２万円台。
Fujitsu の USB接続 指紋認証装置らしきもの ジャンク ￥525-。 物としては非常に興味深いが買っても使い道が無い所が虚しい。
EIZO FlexScan S190 ￥10,500- Samsung PVA らしい。
P1700 値段忘れた Samsung TN らしい。
DVI-I ケーブル ￥525-、 DVI-D (SingleLink) ケーブル ￥525-。 D-SUB 15pin３段 ケーブル ￥315-、 D-SUB 15pin３段 延長 ￥315-。
スーパーエアーコンバット３、廉価版￥315-。 懐かしいが、かなりの駄作らしい。
車体の側面に 何かのアニメキャラっぽい絵と「リトルバスターズ」と書いてある 痛車がファミレスに入っていくのを見かけた。 何かのキャンペーンなのか、持ち主の趣味なのか……。
国民年金、平成２２年度。
14,980円／月＊12＝179,760。
89,860円／半年一括＊２＝179,720。
177,980円／年一括。
年一括もしくは半年一括のクレジットカード払いにする場合、
手続き締切は今月末まで。
口座引落の場合は、さらに追加割引有り。
↑ 追加値上げが有ったらしい。
15,100円／月＊12＝181,200。
89,860円／半年一括＊２＝179,720。
177,980円／年一括。
口座振替の割引を使った場合。
15,050円／月＊12＝180,600。
89,570円／半年一括＊２＝179,140。
177,400円／年一括。
Anthy の連文節学習の誤適用例。
「ひじょうにきょうみぶかいが」を変換すると、
「|非常に|機|ョウミブカイガ|」を出してきた。
以前からずっと、途中から後ろ丸ごとカタカナになってしまう、
連文節の学習適用が頻発していたのだが。
ふと気付いた。
拗音で始まる文節って、堅めの文語なら存在しないのではないかな……。
となると、この手の不適切な連文節学習の適用が減らせる筈。
残念ながら、今はそこまで手間のかかる作業を行う余裕が無い……。
かな漢字変換、毎度お馴染みネタ。
「すたーとして」を変換した時に、
「|スタートして|」とすべきか
「|スターとして|」とすべきか。
前後の文節に物理的な位置を示す単語が来た場合、
「スタート」の可能性が高そう。
前後の文節に立場的な位置を示す単語や形容詞が来た場合、
「スター」の可能性が高そう。
その２。
「のびたきょり」を変換したら。
「|のび太|距離|」（|のびた|きょり|）……。
文節区切りとしては『「名詞」＋「名詞、付属語無し」』が好きらしい。
気晴らしに、
MZ なバイナリダンプのテキストファイルをバイナリファイルに
変換するソフトを書いてみた。
フルスクラッチではなく、12年前に書いたプログラムの修正。
小１時間でできた。
「dumplist to binaly converter "dmp2bin"」
あーもう、昔書いたプログラムってのは小っ恥ずかしいね。
プログラムの書き方の根幹は 12年前からそんなに変わっていない事が
確認できてしまったと言うのは、
喜ばしい事なのか悲しい事なのか。
しかしまぁ、
昔の雑誌のバイナリダンプを OCR 読取している人が
私以外にもいるとは思っていたけれども、
レスポンスが有るとは思いもよりませんでした。
http://homepage3.nifty.com/mzakd/starthp/ocrtomzt.html
そんな訳で、ふと、MZ 対応にしてみました。
ちなみに、私自身では、
成田君シリーズ（
KNAP-88,
THE ROCKETMAN,
NO WAY OUT,
The GERORiN 午前０時のモンスターパニック！
）と
DARK ZONE
と
中国将棋
にて、
動作確認済。
ちなみに、
DARK ZONE のダンプリストには誤植が有る上に
誤植訂正にも修正漏れが有るので、
雑誌掲載そのままを取り込んだのでは、どうがんばっても動きません。
逆アセンブルして修正するか、DISK ASCII版を購入するか、
しか無いと思われます。
私は逆アセして修正しましたが。
「dumplist to binaly converter "dmp2bin"」
更新。
エラーの出た行番号の表示が、
LSI-C だと「zu」になってしまう不都合を修正。
size_t の printf の指定子が「%zu」になるのは
C99 以降？だと言う事を忘れていた。
例に依って例の如く？、手抜きでちゃんと調べずに、
MS-DOS上では「%u」に置換しただけなので、
long 型と等価だったりするとマズい。
……やっぱり long型かも。明日あたり直す予定。
↑ 以下の様なデータを読み込ませると……
2000 CD 09 00 11 76 31 DF CD : 3A
2008 09 00 3E 5D CD 12 00 AF : 32
2010 32 70 11 CD B3 09 CD CE : D7
2018 0B FE 57 28 6D FE 4E CA : 88
2020 7F 28 FE 47 CA 24 21 FE : F9
2028 58 CA 3D 24 FE 41 CA 1A : A6
2030 29 FE 44 CA FE 2B FE 4D : A9
2038 28 75 FE 3F CA 7C 2B FE : 49
2040 53 CA 68 23 FE 52 CA A9 : 68
2048 29 FE 42 CA 8E 26 FE 43 : 2B
2050 CA B7 23 FE 48 CA C2 23 : 99
2058 FE 50 CA D5 25 FE 4F CA : 29
2060 01 26 FE 45 CA 3B 25 FE : 92
2068 56 CA 81 24 FE 54 CA C5 : A6
2070 24 FE 49 CA 0B 25 FE 4C : AF
2078 CA CA 23 FE 51 CA 2B 21 : 1C
---------------------------------
SUM C4 63 A5 CB 10 14 FF 80 : 37
2080 CD 09 00 11 76 31 DF CD : 3A
2088 09 00 3E 5D CD 12 00 AF : 32
2090 32 70 11 CD B3 09 CD CE : D7
2098 0B FE 57 28 6D FE 4E CA : 0B
20A0 7F 28 FE 47 CA 24 21 FE : F9
20A8 58 CA 3D 24 FE 41 CA 1A : A6
20B0 29 FE 44 CA FE 2B FE 4D : A9
20B8 28 75 FE 3F CA 7C 2B FE : 49
20C0 53 CA 68 23 FE 52 CA A9 : 6B
20C8 29 FE 42 CA 8E 26 FE 43 : 28
20D0 CA B7 23 FE 48 CA C2 23 : 99
20D8 FE 50 CA D5 25 FE 4F CA : 29
20E0 01 26 FE 45 CA 3B 25 FE : 92
20E8 56 CA 81 24 FE 54 CA C5 : A6
20F0 24 FE 49 CA 0B 25 FE 4C : AF
20F8 CA CA 23 FE 51 CA 2B 21 : 1C
---------------------------------
SUM C4 63 A5 C8 10 14 FF 80 : 37
2100 CD 09 00 11 76 31 DF CD : 3A
2108 09 00 3E 5D CD 12 00 AF : 32
2110 32 70 11 CD B3 09 CD CE : D7
2118 0B FE 57 28 6D FE 4E CA : 88
2120 7F 28 FE 47 CA 24 21 FE : F9
2128 58 CA 3D 24 FE 41 CA 1A : A6
2130 29 FE 44 CA FE 2B FE 4D : A9
2138 28 75 FE 3F CA 7C 2B FE : 49
2140 53 CA 68 23 FE 52 CA A9 : 68
2148 29 FE 42 CA 8E 26 FE 43 : 2B
2150 CA B7 23 FE 48 CA C2 23 : 99
2158 FE 50 CA D5 25 FE 4F CA : 29
2160 01 26 FE 45 CA 3B 25 FE : 92
2168 56 CA 81 24 FE 54 CA C5 : A6
2170 24 FE 49 CA 0B 25 FE 4C : AF
2178 CA CA 23 FE 51 CA 2B 21 : 1C
---------------------------------
SUM C4 63 A5 CB 10 14 FF 80 : 37
読み込ませると、
C:\TMP<DMP2BIN.exe mz test2.dmp
dumplist to binary converter
Copyright (C) 1998-2010 G-HAL
Error test2.dmp 4: Checksum mismatch
Error test2.dmp 9: Checksum mismatch
Error test2.dmp 10: Checksum mismatch
Error test2.dmp 18: Vertical Checksum[3] mismatch
Error test2.dmp 18: Checksum mismatch
Error test2.dmp 42: Checksum mismatch
Error test2.dmp 47: Checksum mismatch
Error test2.dmp 48: Checksum mismatch
Error test2.dmp 56: Vertical Checksum[3] mismatch
Error test2.dmp 56: Checksum mismatch
File test2.dmp : start 2000, end 2180, size 0181
8 Error line(s)
とかなる筈。
上記のエラーが出る行は、わざと「8」と「0」と「B」を間違えて記述しています。
↑ と言うわけで、 「dumplist to binaly converter "dmp2bin"」 更新。
gimp の文字描画のフォント選択で落ちる。
調べてみたら、
SyrCOMEdessa.otf -misc-estrangelo edessa-medium-r-normal--0-0-0-0-p-0-iso10646-1
でこけていた。
原因とかは不明。
「dumplist to binaly converter "dmp2bin"」
に関して。
> 最後の行ではLine is too long が出る事が多い様です。
たぶんファイルの最後に、
EOF文字（0x1A）が付いているのではないかと思われます。
バグでもないし、ほうっておいても問題も起きないので、
修正しません。
Checksum mismatch は……、
私の所でやった時は、
0,3,6,8,9,B とか 0,C,D とか E,F とかの
読み間違いで出る事が多く有りました。
当然、直さないと駄目でした
（直しておかないと、データ本体が間違ってチェックサムが一致しないのか、
チェックサムの読み取りを間違っているのか、区別が付かない）。
また、
データ本体とチェックサムの両方を読み間違えた挙句に
Checksum mismatch が出ない、と言うのも、
少なくとも１ページに数ヶ所づつのペースで出ました。
なので、本気でやるなら垂直チェックサムも見た方が良いかと思われます。
alt-depgraph-100120-patch100126.alt-cannadic-091230。
「言問橋」（ことといばし）が無い……、
けれど、ローカル地名だしなぁ。
nosuke氏 - 日記みたいな何か - 2010年 3月18日 (木) - ■久しぶりにAnthy
「ありません」の部分を１文節で確定すると、
「|あり|ません|」の区切り方を忘れる設計になっていますし、
手元で試してみてもちゃんと忘れますが……。
たぶんどこかの環境設定の違いなんだろうなぁと思いつつ。
LATTICE_WITH_CANDHISTORY_STRONG が true とかなっていると、
そうなりやすいですが、
デフォルト false ですし。
取り敢えず、
ENABLE_RELEASELEARN は true にしておかないと、
忘れなくなってしまいます。
Sat,27 Mar,2010 追記：
なんかてきとうに何度も試していたら再現した。
なんだろう？
Sat,27 Mar,2010 追記：
アンチ学習？が不十分だった。
学習を忘れる学習を行った時に、忘れ切れていない。
Sat,27 Mar,2010に続く。
vagus氏 - 丘の道を登り - 2010年03月23日 - anthy で、「きょう?」で日付に変換する
ある程度学習がたまると、
学習内容が
${HOME}/.anthy/last-record1_default.utf8 とか
${HOME}/.anthy/last-record1_default.bin とか
に移行しますので、
${HOME}/.anthy/last-record2_default.utf8
だけから削除しても忘れない場合があります。
あと、
${HOME}/.anthy/last-record1_default.bin は
バイナリなので sed で削除は無理です。
${HOME}/.anthy/last-record1_default.utf8 を編集後に
${HOME}/.anthy/last-record1_default.bin のファイルを削除すれば、
編集後の
${HOME}/.anthy/last-record1_default.utf8 を使った
内容で再生成されます。
学習を eucJP で行っている場合は、ファイル名が違っていて、
${HOME}/.anthy/last-record2_default 、
${HOME}/.anthy/last-record1_default 、
${HOME}/.anthy/last-record1_default.bin 、
になります。
あと、anthy-agent を使っている場合（emacs/mule とか）、
設定によってはファイル名の default の部分が
別の任意の名称になったりします。
Xorg。
1.6.1 に更新したら、
マウスやキーボードを無視する様になった。
(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0こんな感じ。
Section "ServerFlags" Option "AllowEmptyInput" "off" EndSectionが必要らしい。
Anthy 拙作パッチ更新。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
「nosuke(のすけ)氏 - 日記みたいな何か - 2010年 3月18日 (木) - 久しぶりにAnthy」
> このところ「もうしわけありません」が，いくら学習させても「申し訳 + あり + 増せん」にしかなってくれず，
の件のバグ修正。
文の全長が以前の学習と同じで、
文節区切り位置や文節区切り回数を変えて学習した時に、
古い学習を忘れ切れていなかった。
Anthy 拙作パッチのバグかと思ったけれどもバグじゃなかった物。
「|学習した|時に|」（|がくしゅうした|ときに|）の
文節区切りを学習した時に、
「時に」の文節の付属語の文字数が 0 になっている。
バグかと思いきや。
gcanna.t に「時に」と言う単語が有った。
ので、付属語の文字数が 0 になって当然だった。
誤変換対策なんでしょうね、きっと。
……なんかまたデジャブ。
以前、vagus氏のサイトで、
誤変換対策でゴニョゴニョと言う話が有ったような。
Tue,30 Mar,2010 追記：
vagus氏 - 丘の道を登り - 2010年03月30日 - 「時に」が一語で登録されてる件
解説が来ていました。有り難うございます。
読みも表記も同じでは区別が付きませんね……。