基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
cache hit (direct) 30053 cache hit (preprocessed) 34018 cache miss 89667 called for link 24445 multiple source files 35489 compile failed 11425 preprocessor error 10341 bad compiler arguments 1637 unsupported source language 1476 autoconf compile/link 78152 unsupported compiler option 36045 no input file 12469
こんなもんだった。
autoconf/automake/libtool 更新。 開発環境を OpenBSD/amd64 から FreeBSD/amd64 に戻した。
autoconf-2.64 automake-1.10.3 libtool-2.2.6b から autoconf-2.69 automake-1.12.1 libtool-2.4.2 に更新。
当方のサーバ更新に伴う変更。
今までの自前 OpenBSD サーバ(kana.fenix.ne.jp)なら
問題無く開発が行なえていたけれども、
さくら VPS での OpenBSD なサーバ(akari.fenix.ne.jp)に変わったら
重過ぎて駄目だった。
MBRモードにて、
品詞ベースのコーパスデータベースに該当が無い場合、
読み仮名文字 変則２グラムに back off する様にしてみた。
アルゴリズムどおりの純粋な back off ではなく、
原作の MBRビタビモードに書かれている
確率値を小さくする処理に追加（乗算）している。
なので、理論通りの結果が出るものではない。
処理の内容からすると、
コーパスデータベースに該当が無い場合の処理が、
原作通りだと文節数最小になる所を、
読み仮名文字 変則２グラムになるように変更した、
状態。
MBR_MODE_LATTICE_BACKOFF_TO_YOMICHAR2GRAM
にて、
読み仮名文字 変則２グラムにするか
文節数最小にするか選択可能。
back off と言ってみたいだけと違うのか、 と言われると、言ってみたいだけなのかも。
back off って業界によって意味が違うのだよね。
通信系だと「コリジョンが起きた時の再処理」なのだけど。
英語の意味だとまた違うし。
オーディオ系だと「出力最大振幅と出力飽和電力の差」らしい。
言語処理系だとまた違う意味なのだろうか。
Sun,02 Sep,2012 追記：
そもそも、
原作の
MBRアルゴリズムにて品詞ベースのコーパスデータベースに該当が無い場合の
処理が、バックオフではなかった。
原作の Anthy に関してはどこにもバックオフとは書かれていない。
単に私が読み違えて思い込んでいただけ。
コーパスに該当が有る場合の MBRから求めた確率と、
コーパスに該当が無い場合の １文節当たり 1.0e-6（コメントには
「例文中に存在しないパターンなので0に近いスコア」と書いてあるので
値に根拠は無いらしい）の数値を、
単純比較しているので、バックオフではない。
make update_params0 してコーパスを無効にした場合のみ
文節数最小になるのであって、
通常時は文節数最小にもならない
（確率と数値の比較なので理論的な意味も無い）。
Sun,26 Aug,2012、
Sun,02 Sep,2012、
に関連。
文節区切り時のコーパス由来の共起辞書の検索を抜本改訂。
拙作パッチで追加した、 文節区切り時のコーパス由来の共起辞書の検索ですが、 これまでの漢字表記＆読み仮名での該当検査だと処理が遅すぎるので、 読み仮名のみでの該当検査に変更。 文節区切り速度が２〜３倍くらい速くなります。
いままでずっと、遅い遅いと気にはしていたのですが、 ずっと先送りしていました。
例文追加。
前回更新後に溜まった分。
IO-DATA の microSD 2GiB が￥340- だった。 無印SD規格 の最大容量だから、 出荷し続けないといけないのかな？
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
autoconf/automake/libtool 更新。
MBRモードにて、
品詞ベースのコーパスデータベースに該当が無い場合、
読み仮名文字 変則２グラムに back off するようにしてみた。
MBR_MODE_LATTICE_BACKOFF_TO_YOMICHAR2GRAM にて、
従来通りの文節数最小法に戻せる。
文節区切り時のコーパス由来の共起辞書の検索を抜本改訂。
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC にて変更可能。
例文追加。
詳細は昨日の記事の通り。
qemu-img convert -O vmdk hdd.raw hdd.vmdk したら、
hdd.vmdk を VirtualBox から認識できたが、
VBoxManage modifyhd hdd.vmdk --compact は出来なかった。
qemu-img convert -O vpc hdd.raw hdd.vhd したら、
hdd.vhd を VirtualBox から認識できたが、
VBoxManage modifyhd hdd.vhd --compact は出来なかった。
qemu-img convert -O vdi hdd.raw hdd.vdi したら、
hdd.vdi を VirtualBox から認識できなかった。
VBoxManage convertfromraw --format vdi hdd.raw hdd.vdi したら、
hdd.vdi を VirtualBox から認識できたし、
VBoxManage modifyhd hdd.vdi --compact を実行できた。
はて？
VirtualBox の ROM のマッピングが判らんので 手の打ち様が無い……。
有志？が製作したオリジナルドライバを突っ込まないと
駄目らしい。
etwas.wolfish.org/blog/p2009060701/
このへん。
VT-x は有効にしても大丈夫だった。
無事、800x600 とか 1024x768 とか 1280x1024 とかで映る様になったが、
ホストが 1366x768 なので縦がスクロールしてしまうオチ。
さらにスナップショットの結果を統合しようとして、 間違って復元してしまい、作業結果が全部パァになる２段オチ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 試験版」
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 安定版」
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 旧安定版」
バグ修正。
update_params 関連の処理（proccorpus）にて
変数の初期化を忘れていました。
しかも Nov,2009 からずっと……。
コンパイラのウォーニングに注意を払うのって大切ですね（棒読み）。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
コーパスから抽出した文節区切り／区切らない位置情報のパターンを 全９パターンに拡張。
変換結果が望む方向に変化する事も有れば
望まない方向に変化する事も有ったので、
効き目は、全く効いていないくらいに弱くしてあります。
LATTICE_BIASSCORE_BY_CORPUS_WB_DIC
を大きくすれば効きが強くなります。
以下の９パターン 2-gram |ID| 2-gram |I*|I*| |I*|*D| |*D|I*| |*D|*D| 3-gram |I*|ID| |*D|ID| 3-gram |ID|I*| |ID|*D| I が自立語（１単語のみ） D が付属語（助詞の複数単語可） * が判定なし | が文節区切り位置情報
コーパスに「|ソフト+の|新し+い|」がある時に。
「あいすのなつかしい」を変換すると、
文節区切り候補「|あいす+の|なつかし+い|」に対して、
パターン「|*D|*D|」が一致と判定します。
「そふとがふるい」を変換すると、
文節区切り候補「|そふと+が|ふる+い|」に対して、
パターン「|I*|*D|」が一致と判定します。
Tue,14 Feb,2012、 Tue,28 Feb,2012、 の続き。
冷却ファンがまたストールした。 こわいな。 今回はサーマルシャットダウンがかかった。 CPU速度不明（リミッタは 2133MHz）で 105℃らしい。
安いハンコを探していたら、
手仕上げで ￥380- メール便送料無料、
と言うのを見つけた。
FAQ を見てみたら、
「同じ書体同じ文字の印鑑を複数オーダーした場合、印影は同じになります」
と言う意味の事が書いてあった。
それって完全機械彫りって白状している様なものなのでは。
ミトメだから機械彫りでも構わないけれど、
機械彫りなら正直に機械彫りだって言っている所じゃないと嫌だなぁ。
float_t って使っていいんだっけ？
C99 で使っていいっぽい。
うーむ、今まで書いたソースコードの浮動小数部分、
たぶん全部 float_t で構わないところを
double で書いてしまっている……。
いや、まてよ、
CORBA がらみはどうだっけ……
プロジェクトの誰かが間違えそうで危なっかしいから
浮動小数を使わない様にしたのだっけ？
anthy の浮動小数演算部分も、 多分全部 float_t で構わない筈だけれども、 POSIX 限定だから C99 な float_t は使っちゃ駄目かな……。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
コーパスから抽出した文節区切り／区切らない位置情報のパターンの スコアへの反映方法を調整。
コーパスから抽出した文節区切り／区切らない位置情報の
スコアへの反映方法を、
読み仮名変則単語 変則２グラム／３グラムっぽい実装の
確率計算にしてみた。
コーパス中の出現回数をスコアに反映します。
単なる思いつき。
理論もバランス調整も何も考えていない。
「変則単語」と言っているのは、
付属語１単語につき助詞の複数単語を許容しているから。
さて。 コーパスの頻度情報(?)を確認してみる。
% ./build/calctrans/proccorpus ../../corpus/corpus.[012345xg].txt > parsed_data.HID_IDI_IwDT.org して % ./build/calctrans/calctrans parsed_data.HID_IDI_IwDT.org -o /tmp/ttt する。 Bucket size is 16384, Total 53991 data, 4698 dup, 49293 active, 3962 collisions, 636 collision and lost, in corpus bucket corpus wordborder I dic : Bucket size is 32768, Total 53991 data, 43889 dup, 10102 active, 1595 collisions, 0 collision and lost. corpus wordborder D dic : Bucket size is 16384, Total 53991 data, 49530 dup, 4461 active, 590 collisions, 0 collision and lost. corpus wordborder ID dic : Bucket size is 65536, Total 53991 data, 26572 dup, 27419 active, 5685 collisions, 0 collision and lost. corpus wordborder I*+I* dic : Bucket size is 65536, Total 36317 data, 7801 dup, 28516 active, 5997 collisions, 0 collision and lost. corpus wordborder I*+*D dic : Bucket size is 65536, Total 36317 data, 10213 dup, 26104 active, 5141 collisions, 0 collision and lost. corpus wordborder *D+I* dic : Bucket size is 65536, Total 36317 data, 19247 dup, 17070 active, 2159 collisions, 0 collision and lost. corpus wordborder *D+*D dic : Bucket size is 32768, Total 36317 data, 25923 dup, 10394 active, 1567 collisions, 0 collision and lost. corpus wordborder I*+ID dic : Bucket size is 65536, Total 36317 data, 2692 dup, 33625 active, 8596 collisions, 0 collision and lost. corpus wordborder *D+ID dic : Bucket size is 65536, Total 36317 data, 9360 dup, 26957 active, 5497 collisions, 0 collision and lost. corpus wordborder ID+I* dic : Bucket size is 65536, Total 36317 data, 4952 dup, 31365 active, 7505 collisions, 0 collision and lost. corpus wordborder ID+*D dic : Bucket size is 65536, Total 36317 data, 6369 dup, 29948 active, 6730 collisions, 0 collision and lost. corpus yomichar2gram-left : Bucket size is 128, Total 231535 data, Empty 45 data. corpus yomichar2gram : Bucket size is 16384, Total 231535 data, Empty 12113 data, Empty(Connect) 12680 data, Empty(Separate) 13813 data. corpus yomiword2gram-left : Bucket size is 32768, Total 95196 data, 80792 dup, 14404 active, 3142 collisions, 0 collision and lost. corpus yomiword2gram : Bucket size is 131072, Total 112882 data, 55529 dup, 57353 active, 12461 collisions, 0 collision and lost. max_collision=0 17686 sentences 68798 connections 51112 segments
付属語のパターンって案外少ないのね。
元のコーパスが約18000文。
コーパスに出現した文節の数が 53991 で
付属語のパターンが 4461。
だいたい１パターンにつき 12回くらい出現しているのかな。
コーパスに出現した、２文節の組み合わせ数が 36317 で
付属語のパターンが 10394。
だいたい１パターンにつき 3.5回くらい出現しているのかな。
逆に、付属語以外が絡む組み合わせパターンだと
だいたい１パターンにつき 1回くらいの出現で、
スパースネス(?)でスッカスカ。
読み仮名ベースでこれじゃぁ、
N-gram モデルを採用するとゼロ頻度ばかりで使い物にならないと思われます。
mozc が使い物になっているのは、
コーパス数の桁数が段違いな為と思われます。
しかしあれだ。 拙作パッチのコーパス由来のデータベースのサイズを見ると、 （まともに運用していない読み仮名ベースの変則 N-gram モデル用のサイズが 無駄に巨大で）原作版の何十倍なんだ？というバカげた状態だな。
http://www.wdic.org/w/TECH/予約済み識別子
インクルードガードでやらかした。 やっちまった……。 今まで書いたソースコード全てが該当する……。
int_fast*_t で構わない所を int*_t 使っている、 と言うのもあったっけ。 こちらはバグではないけれど。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
読み仮名文字 変則２グラムの使用感が 「もうちょっと」な感じだったので、 試しに読み仮名文字 変則３グラムを実装してみた。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
読み仮名文字 変則３グラムの実装を間違えていた バグ修正。
「ながおか」が「|なが|おか|」に分割される。
どうやら読み仮名文字 変則３グラムにて、
「みんなが|おもう」と「よみがなが|おなじ」が合わせて２件と、
「××が|おかしい|」と「××が|おかしすぎ|」が合わせて２件有り、
これから「なが|お」と「が|おか」を抽出し
適用されて確率が上がっているらしい。
「|ながおか|」を１件追加しただけでは
上記の４件に負けるらしい。
それともバグかな？
なが 0.031051253273475497 ながお 0.0016891891891891893 がおか 0.018315018315018316 おか 1.0 ← バグ？ 合計 0.00000096064910879726 なが 0.031051253273475497 なが|お 0.0067567567567567571 が|おか 0.018315018315018316 おか 1.0 ← バグ？ 合計 0.00000384259643518903
最終文節の最後２文字の確率計算を忘れているバグ 発見……。
なが 0.031051253273475497 ながお 0.0016891891891891893 がおか 0.018315018315018316 おか 0.029254642584584076 合計 0.00000002810344632706 なが 0.031051253273475497 なが|お 0.0067567567567567571 がおか 0.018315018315018316 おか 0.029254642584584076 合計 0.00000011241378530825
うーん、読み仮名文字 変則３グラムの限界かな。 読み仮名文字 変則４グラムとか考えるときりがないし ゼロ頻度問題が顕著化するし。
類似例で「|きょうと|ふ|」。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
読み仮名文字 変則３グラムにて、 最終文節の最後２文字の確率計算を忘れている バグ修正。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 試験版」
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 安定版」
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 旧安定版」
バグ修正。
配列の要素数を間違えていたバグ修正。
未初期化の変数にアクセスしていたバグ修正。
返値を忘れていたバグ修正。
LLVM Clang でコンパイルが通らないバグ修正。
GNU/Linux で configure が通らないバグ修正。
valgrind で出るエラーを全て修正。
LLVM Clang で出るエラーを全て修正。
LLVM Clang でビルドしたものが動作する事を確認。
Fri,07 Sep,2007、 Tue,22 Dec,2009、 の続き。
UDF 1.50 な DVD-RAM が２枚ほど論理クラッシュした。
１枚目は、
FreeBSD ports/sysutil/udfclient 0.7.5_1 で書き込みしたものを
MS-Windows 7 から chkdsk したら壊れた。
２枚目は、
MS-Windows7 で書き込み中に
残容量を確認しようとディスクのプロパティを実行したら壊れた。
udfclient はしょうがないとしても、 MS-WIN7 で書き込み中に壊れたのは納得できないなぁ。
Fri,18 Jan,2013、 Sun,20 Jan,2013、 Mon,21 Jan,2013、 Tue,22 Jan,2013、 Thu,31 Jan,2013、 Sun,03 Feb,2013、 に続く。
「I18N(Internationalization) GearHead」、 「UTF-8 GearHead-2」。
「たけのこ 氏 - ネコキス - 2012/06/06 - Anubisが遠い」
の
バグ修正予定。
情報ありがとうございます。
問題の箇所の処理は、
ギアの価格計算(GearValue)
- ギアの基本の価格計算(BaseGearValue)
- ギアの部位の価格計算(TrackValue)
- ギアのパーツの価格計算(ComponentValue)
- データ上の価格(NAttValue)
とネストしていて、
NAttValue だけオーバーフローのバグが
修正済（LongInt に納まらなければ丸める）だったけれど、
ComponentValue 〜 GearValue までは
修正していなかった（LongInt のまま）。
ComponentValue 〜 GearValue まで全部
修正（LongInt に納まらなければ丸める）しなきゃ……。
GearValue の呼出側も危ないかも……。
「I18N(Internationalization) GearHead」
「たけのこ 氏 - ネコキス - 2012/06/06 - Anubisが遠い」
の
バグ修正。
メックの PV が大きすぎると Range check error になるバグ修正。
GearHead2 にも同じ問題が有る。
「たけのこ 氏 - ネコキス - 2012/06/06 - Anubisが遠い」
の
バグ修正。
メックの PV が大きすぎると Range check error になるバグ修正。
それから、 メックを売る時のメッセージが「 を売る Mecha-Name」になっていたのを メッセージ分離かつ「Mecha-Name を売る」に修正。
今回は sage を行う事自体は忘れていなかったけれど、 間違えて名前を sage にして sage 損なった。 何かもうダメ……。
GearHead for スマホ が実現可能か否か調べてみた。
web で検索した限りでは、
FreePascal や SDL を iPhone で動かしているツワモノは実在するらしい。
と言う事は、
GearHead-1 SDL および GearHead-2 cute や、
GH1 cui / GH2 cui は
iPhone で動くかも知れない
と言う事かな。
さらに調べてみたら。
iOS 用アプリの開発には Intel Mac が必要らしい。
私の所には Mac はありませんので開発できません。
どなたか Mac をお持ちの方に頼んで下さい。
ただ、移植できたとしても、GH はやたら重いから
スマートフォンだと遅くてゲームにならないかも。
Android は情報が見つからなかった。
Windows CE では、FreePascal や SDL を動かしているツワモノは いるらしい。
sudo pkg upgrade したら vim が更新されていた。
そこまでは問題無い。
vim を起動したら、
カーソル行の行番号のカラーリングが変更になっていた。
こういう変更、地味に苦手。
pkgng で、sudo pkg install gimp とか gnuplot とかしたら、
リモートレポジトリにパッケージとか依存パッケージとかが無いと
言ってきた。
gihyo.jp の fdt - FreeBSD Daily Topics を確認したら、
今日の日付で、まだ開発中でそういう事もあるから注意、だって。
sudo portupgrade するとオーバーヒートおこして
サーマルシャットダウン起こす様なマシン使っているから、
バイナリパッケージはありがたいのだが。
キーボードの掃除をしていたら、キートップがはずれた。
押し込みゃ付くだろ、と思って押し込んだが全然付かない。
試行錯誤しても全然付きそうにないので、隣のキーを外して観察してみた。
プラの部品２つ使ってパンタグラフ構造になっていた。
左右から見ると×になる方向。
そして足元にパンタグラフの部品が１つ落ちていた。
危うく踏んづけるところだった……。
で、パンタグラフ構造を組み立てながら付けようと試行錯誤するが、
全然付かない。
外した隣のキーも付かない orz
上側左右端を押し込んで片側のアームを付けてから、
下側左右端を押し込んでもう片側のアームを付けようとするが、
付かない。
どうやって組み立てたのだろう……。
結局、30分くらい試行錯誤して、付いた。
先に土台にアームの部品２つをはめてから、
キートップを重ね、
キートップの上側左右端を押し込んで片側のアームを付けてから、
キートップの下側左右端を押し込んでもう片側のアームの片端が付いた所で、
キートップの下側を上にひねるようにして
後から付けた方のアームを持ち上げつつ、
下側左右端のまだ付いていない方のキートップを押し込む感じでねじると、
付いた。
工場では一体どうしているのだろう？
精神的にくたびれた。
「I18N(Internationalization) GearHead」
スレ13号機 259氏 指摘の件、
「CUI が文字化けする」。
デバッガで追跡しても原因がさっぱり分からなかったので
試しにコンパイラのバージョンを色々変えて試してみた。
fpc-2.2.2 にすると文字化けせず、
win32版 2.2.4, win32版 2.4.4, win32版 2.6.0 にすると
文字化け（CP932 を１バイトずつ表示している感じ）した。
FreeBSD版や GNU/Linux版だと
2.6.0 の ShiftJIS でも文字化けしなかった。
あと、
FreeBSD版や GNU/Linux版の 2.2.0 時代にもあった
UTF-8 の表示位置ずれは未だに健在だった。
FreePascal のバグだろうか orz
「コンパイラのバグもしくは相性問題」で片付けていいよね……。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 試験版」
試験版のデフォルトパラメータだと、 「あいしょうもんだい」を変換すると 「相性も|んだい」（あいしょうも|んだい）になる。
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WB_ADIA_DIC を
8.7e-6 まで下げると
「相性|問題」（あいしょう|もんだい）になった。
その他の変換結果と合わせて考えると、
付属語「も」＋自立語「んだい」
を適用して評価が高くなっているらしいのだが
自立語「んだい」
はコーパスに無い。
となると、ハッシュコリジョンか……。
ハッシュコリジョンによる誤適用を避けるとなると……。
再設計が必要だろうなぁ。頭痛い……。
あと、Anthy のハッシュを扱うルーチンで、 わざと３ビット削っている理由が分からない。 これだけでもハッシュコリジョンが減る筈なのだけれども。
LEDのマグライトが点灯できなくなった。
アルミ製の電源スイッチを押そうとしても固くて動かない。
カナヅチで叩くとアルミの粉末がパラパラこぼれてきて、
ようやく動く様になった。
どうやらサビて？固まってしまったらしい。
「I18N(Internationalization) GearHead」
スレ13号機 401氏 指摘の件、
「農場を守ってほしい→メック戦→画面外へ逃亡→依頼失敗→依頼主に話しかける→エラーメッセージ」。
TS_XRAN_aU-U_Interference.txt にて失敗した時のスクリプトが、
誤:「N= 3 S= 105 -1 E3」
→
正:「N= 3 E3 S= 105 -1」
、
らしい。
でだ。 本家に英語で説明できる英語力が無いと言う問題ががが。
acer ASPIRE AS3820T N52B 第１世代 Core i5-450M。
今日もまた爆熱熱風排気で
サーマルシャットダウンしそうになったのでクロックを下げた。
1.866GHz まで来てしまった。
3W 下げたら 10℃下がった。
3.3℃/W。
まぁそんなもんか。
1.733GHz で make -j4 buildworld に２時間半。 2.133GHz で make -j1 buildworld に４時間だから、 -j4 で２倍くらいの速度にはなっているのか。
Wed,10 Apr,2013 追記：
1.999GHz で 9.1p2-RELEASE の amd64 k8 make -j2 buildworld に１時間47分。(107min)
Wed,12 Jun,2013 追記：
1.999GHz で 9.1p3-RELEASE の i386 pentium-mmx make -j4 buildworld に１時間10分(70min)。
Mon,24 Jun,2013 追記：
1.999GHz で 9.1p4-RELEASE の amd64 core2 make -j4 buildworld に１時間21分(81min)。
Sat,29 Jun,2013 追記：
1.999GHz で 9.1p4-RELEASE の i386 c3-2 make -j1 buildworld に２時間21分(141min)。
time sudo make -j1 buildworld TARGET=i386 CPUTYPE=c3-2 DESTDIR=/compat/i386
Sun,07 Jul,2013 追記：
1.999GHz で 9-STABLE の i386 c3-2 make -j2 buildworld に１時間39分(99min)。
Sat,02 Jul,2011の続き。
FreeBSD 10-CURRENT を csup してみたら、
FreeBSD 10-CURRENT 2012/08/?? にて
DOS 拡張スライス内のパーティションからの起動に対応していた。
これで、csup する度に、
「[FreeBSD-users-jp 91326] （桂島@横浜 氏、Tue, 1 Jan 2008）」
のパッチを当てる必要が無くなった。
今までどうも有難う ＞ パッチ。
ただまあ、前回の
Sat,02 Jul,2011の
多段チェインが必要な事は変わりなく。
MS-Windows の BCD が FreeBSD 対応するとは考えられないので、
MBR の MBM か、GRUB4DOS が、
DOS 拡張スライス内のパーティションの FreeBSD の UFS2 に
対応して欲しいけれど、無理だろうなぁ。
自分で改造する気力も無いし……。
正当な対処法としては、基本スライスに FreeBSD を入れる、なのだが、
このマシン、
「リカバリ領域」，「システム予約」，「MS-Windows 領域」，で、
基本領域を３つ消費しているので、
拡張スライス内に入れるしか選択肢がないんだよなぁ……。
GPT？
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 試験版」
試験版のデフォルトパラメータだと、
「きほんりょういきを」を変換すると
「|きほんりょう|いきを|」になる。
原作版だと「|きほん|りょういきを|」。
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WB_ADIA_DIC がまだ大きいらしい。
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WB_ADIA_DIC を
3.2e-9 まで下げた。
「|きほん|りょういきを|」になった。
コーパスを検索してみた感触だと、
付属語「」（無し）＋自立語「いき」（「|行き」など）
を適用して
自立語「きほんりょう」＋付属語「」＋自立語「いき」＋付属語「を」
の
評価が高くなっているらしい。
付属語「」（無し）＋自立語「りょういき」（「|領域」など）
もあるが、負けているっぽい。
この 読み仮名ベース変則単語変則２グラムだと、 付属語無し＋自立語の形が課題なのかも。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 試験版」
試験版のデフォルトパラメータだと、 「むりだろうな」を変換すると 「|む|りだろうな|」になる。 原作版だと「|むりだろうな|」。 LATTICE_BIASSCORE_BY_CORPUS_WB_DIC を 0.0 にして MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WB_*_DIC を全て無効にしても 変わらず。
さて、どこだ？
MBR_MODE_LATTICE_BACKOFF_TO_YOMICHAR_N_GRAM だった。
他にも、 「とれていないらしい」が 「|とれ|ていないらしい|」になるのも見つかったが、 これも MBR_MODE_LATTICE_BACKOFF_TO_YOMICHAR_N_GRAM だった。
コーパスに該当が無い事と、
該当が有る部分（「|む|」，「|とれ|」）の
評価（評価が高めになる）と
該当が無い部分（「|むりだろうな|」，「|とれていないらしい|」
および「|りだろうな|」，「|ていないらしい|」）の
読み仮名文字変則２グラムとの評価（評価が低くめにずれる）の
バランスが取れていない事と、
の２つが原因らしい。
行き当たりばったりの思い付きで実装した物とは言え、
バランスが取れていないとは、ほんのちょっとショック。
結構シビアなのね。
↑ コーパスに例文を追加してデータベースを更新したら、
「|むりだろうな|」，
「|とれていないらしい|」
になった。
コーパスに該当が無かった部分
（「|むりだろうな|」，「|とれていないらしい|」）
が、
コーパスに該当が有る様になった為に、
評価のバランスがとれる様になったらしい。
コーパスがまだ足りない？
自転車がパンクした。
１年11ヶ月持ったのかな。
Thu,05 Jul,2012、 の関連。
原作の
MBRアルゴリズムにて品詞ベースのコーパスデータベースに該当が無い場合の
処理が、バックオフではなかった。
原作の Anthy に関してはどこにもバックオフとは書かれていない。
単に私が読み違えて思い込んでいただけ。
コーパスに該当が有る場合の MBRから求めた確率と、
コーパスに該当が無い場合の １文節当たり 1.0e-6（コメントには
「例文中に存在しないパターンなので0に近いスコア」と書いてあるので
値に理論的な根拠は無いらしい）の数値を、
単純比較しているので、バックオフではない。
make update_params0 してコーパスを無効にした場合のみ
文節数最小になるのであって、
通常時は文節数最小にもならない
（確率と数値の比較なので理論的な意味も無い）。
なので、
真っ当に back off かましたらどうなるかなぁと思ったのだが。
setjmp() とか longjmp() とかが必要になるかなと思ったりしたが
それだとメモリリークが酷い事になりそうだ。
深い所からメモリを開放解放しつつ
return hoge; していくのが妥当かな。
で。
真っ当な back off を実装してみた。
文節区切り位置が同じだけれども品詞クラスが違う、
というパターンが多いらしく、バックオフしまくりで駄目だった。
コーパス該当無しの場合でも、
文節区切り位置が同じで feature が違う物で該当が有れば、
該当有りを利用する処理を書かないと駄目か。
駄目だった。
探索しているとどこかで該当無しに突き当たる。
例えば「いんかん」を変換しようとすると。
「|いんかん|」と「|いんか|ん|」の比較が入るのだが、
「|ん|」が該当無しになってしまい駄目。
Mon,03 Sep,2012 追記：
具体例を挙げて考えてみよう。
変換内容が「Ａ」の時
候補１「|Ａ|」：「|Ａ|」はコーパス該当無し
候補２「|Ａ|」：「|Ａ|」は確率 0.1
この場合、候補２「|Ａ|」（確率 0.1）を選択。
→ 文節区切り位置が同じで品詞クラスが違い、コーパスの該当有無が変わるならば、
コーパス該当無しの確率は該当有りの確率よりも低いだろう、
と言う、思いつきのヒューリスティック。
※ 学術的根拠無し。
変換内容が「ＡＢ」の時
候補１「|Ａ|Ｂ|」：「|Ａ|」は確率 0.1、「|Ｂ|」はコーパス該当無し
候補２「|ＡＢ|」：「|ＡＢ|」は確率 0.5
この場合、候補２「|ＡＢ|」（確率 0.5）を選択。
→ 「|ＡＢ|」で確率 0.5 なら、
「|Ａ|」の時点で確率 0.1 の「|Ａ|ＢＣ|」の確率は確実に 0.5 より小さい。
変換内容が「ＡＢ」の時
候補１「|Ａ|Ｂ|」：「|Ａ|」は確率 0.5、「|Ｂ|」はコーパス該当無し
候補２「|ＡＢ|」：「|ＡＢ|」は確率 0.1
この場合、選択できない。
→ 「|ＡＢ|」で確率 0.1、
「|Ｂ|」が確率 0.2 より小さければ候補２、大きければ候補１。
だが「|Ｂ|」の確率を正しく求める事ができない。
※ back off すべきか。
変換内容が「ＡＢ」の時
候補１「|Ａ|Ｂ|」：「|Ａ|」は確率 0.5、「|Ｂ|」は確率 0.5
候補２「|ＡＢ|」：「|ＡＢ|」はコーパス該当無し
この場合、選択できない。
→ 「|Ａ|Ｂ|」で確率 0.025、
「|ＡＢ|」が確率 0.025 より小さければ候補１、大きければ候補２。
だが「|ＡＢ|」の確率を正しく求める事ができない。
※ back off すべきか。
変換内容が「ＡＢＣ」の時
候補１「|Ａ|ＢＣ|」：「|Ａ|」は確率 0.01、「|ＢＣ|」はコーパス該当無し
候補２「|ＡＢ|Ｃ|」：「|ＡＢ|」は確率 0.5、「|Ｃ|」は確率 0.5
この場合、候補２「|ＡＢ|Ｃ|」（確率 0.025）を選択。
→ 「|ＡＢ|Ｃ|」で確率 0.025 なら、
「|Ａ|」の時点で確率 0.01 の「|Ａ|ＢＣ|」の確率は確実に 0.025 より小さい。
変換内容が「ＡＢＣ」の時
候補１「|Ａ|ＢＣ|」：「|Ａ|」は確率 0.1、「|ＢＣ|」はコーパス該当無し
候補２「|ＡＢ|Ｃ|」：「|ＡＢ|」は確率 0.5、「|Ｃ|」は確率 0.5
この場合、選択できない。
→ 「|ＡＢ|Ｃ|」で確率 0.025、
「|ＢＣ|」が確率 0.25 より小さければ候補２、大きければ候補１。
だが「|ＢＣ|」の確率を正しく求める事ができない。
※ back off すべきか。
例外を使う事になるのかな？
それとも返値で処理すべきなのかな？
例外はあくまで「例外」に使うべきで、 想定内のループ処理中断は返値で処理すべきか？
冷却ファンがまたストールした。 今回は 69℃だった。cx C3 が効いているらしい。 掃除機で無理やりファンを始動してやると 59℃になった。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ 試験版」
想定よりバックオフが多いと思ったら、
読み仮名ベース変則Ｎグラムを実装した時（2012716版）に
コーパスの文末の解析でバグっていた。
ので修正。
ついでに wb_dic パラメータも調整。
ループバックのみ許可したい時は
block in on ! lo0
でいいのか orz
今までずっと
$if = "em0 em1 em2"
block in on $if
とかやっていた……。
予約受付開始から２日で予約完売って……。
「xosview-1.8.3 on FreeBSD でメモリを 4GiB以上積んでいると容量計算を間違えるバグ修正パッチ」
タイトル通り。
単なる型あふれでした。
「vtwm 5.4.7 フォーカスの有無によってタイトルの色を変える改造パッチ」
twm 系の軽量で仮想スクリーン対応の
vtwm
。
ウィンドウにフォーカスが有るかどうかは、
ウィンドウのボーダーの色の変化で分かる様になっていますが、
加えてタイトルの色も変える様にするパッチです。
ただまぁ、今の御時世、
ここまでの軽量高速にこだわる人ってそうそういないらしく、
パッチを作った所で使う人がいないのではないかと思われ。
と、言う訳で、本パッチのメンテナンスはしません。
GNU/Linux系で opt.junk を使う時は、
環境変数 MALLOC_CONF か
シンボリックリンクファイル /etc/malloc.conf か
グローバル変数 je_malloc_conf を、
使えばいいらしい。
BSD系の jemalloc と
環境変数名／グローバル変数名が
異なるので注意。
って、日本語で書かれているサイトが無いって……。 GNU/Linux系では誰もこの機能を使っていないのかな……。 それともわざわざ web に書くほどの機能ではない？
端株：はかぶ
xpdf で空白部分が□に×になっていたのだけれども、 ようやく解決。
問題が起こる pdfファイルでは
空白部分が U+2003 EM SPACE になっていたが、
フォントの該当部分はデータ無しになっていた。
フォントの U+2003 にテキトーに空白を突っ込んでやって解決。
そういえば試していなかったなぁ、と。
ホスト : Core i5-450M 2C4T 1733MHz 1366x768 FreeBSD-10-CURRENT
ゲスト : wine-1.5.12_1,1 MS-Windows7
ホスト : Core i5-450M 2C4T 2400MHz-TB2666MHz 1366x768 MS-Windows7SP1
Int Float Read Write R W Rect Text Fllipse BitBlt DirectD Read Write RRead RWrite
wine-1.5.12_1,1 74736 63544 266237 274093 515736 3965 2166 2619 62 4 * * * *
MS-Windows7SP1 618555 593134 400959 219083 616240 11600 11982 6855 284 16 48599 46209 16699 18696
VT-x は効果が有るらしい。
第１世代 Core i5 だと
ネステットページは遅くなるらしい。
実機だと、クロックが違う分を差っ引いて考えても、
演算とメモリアクセスは速いが
グラフィック関連とディスクが何故か遅いらしい。
自転車がパンクした。
３週間前に治した所のパッチが裂けていた。
タイヤも中のワイヤーが見え始めていたので交換。
「パナレーサー スーパーハード耐摩耗タイヤ」￥1,580- を使っていたのだが、
２年持ったのか……。
「デミング ロングライフ、チューブセット」￥1,580- が
半年しか持たなかったので、４倍持った勘定。
コストパフォーマンスはパナブランドの方が約2.7倍良かった事になる。
で、今度は共和のノーマルタイヤ￥798-にしてみた。 最低１年はもって欲しいな。
こんどは後輪のブレーキワイヤーが
引っかかって動かなくなった。
だいぶ錆び付いてきていたので交換。
新車の時から一度も交換していなかったので１０年もったのかな。
何軒か本屋を回ってみたが、 ヴァリアブルファイター マスターファイル VF-0 が店頭に無かった。 売れないから数を絞っているのか、 売れ行きが良くて切らしているのか。 どちらだろう。