基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
きたらしい。
ふと、セーブデータの解析をしてみたのだが。
単純なランレングスっぽい圧縮がかかっていた。
でも、レングスに当たる箇所に所々 00 が混じっている辺りが
ランレングスじゃないんだよなぁ……。
チェックデジットは無かった。
OpenAFS 1.6.0/1.6.1pre1/1.7.4 のカーネルモジュール libafs.o が、
: relocation truncated to fit: R_X86_64_32 namei_pool
で蹴られるのだが、何だろう？
-fpic とか -fpie とかでビルドすると、
エラーは出ないけれどカーネルパニック起こすし。
カーネルパニック起こすのは、改造失敗のバグだった。
コンパイルオプションをカーネルビルド用と同じにして、
-fPIC だか -fPIE だかで良いらしい。
まぁそもそも、 OpenAFS 1.6.0/1.6.1pre1/1.7.4 は、 OpenBSD 4.8-RELEASE/i386 までしか対応していないけれど。 4.9/5.0 や amd64 は非対応……。
OpenBSD 4.8-RELEASE から 4.9-RELEASE での変更点は、
大きな所で、
OpenBSD 4.8 直後の CURRENT（Dec,2010）にて、
vnode テーブルが
ポインタの片方向リストから構造体に変更になったらしく。
小さい所で relookup() が vfs_relookup() に変更になった？
続き。
コンパイルオプションを
/usr/src/sys/arch/amd64/compile/GENERIC.MP/Makefile
と同じにしたら、
relocation truncated は出なくなった。
だがしかし、
カーネルモジュールから
vnode を登録する方法が判らない……。
と言うわけで、OpenAFS の OpenBSD 4.9/5.0 移植改造は失敗。
終章、なんかぶった切り感が……。
「しんかを」を変換した時。
「真かを」なのか「真価を」なのか、変換エンジンでは判定できない。 前後の文脈を見るしかないのだけれども、 文法ベースや付属語ベースだと、たぶん判定できない。
「|（名詞）は|真価を|発揮する|」（|＊＊は|しんかを|はっきする|） 「|（名詞）は|真かを|判定する|」（|＊＊は|しんかを|はんていする|）
どちらも「（名詞）は|＊＊を|（動詞）する」になる。 あれ？ 動詞だっけ？ サ変だっけ？ 忘れた。 とにかく、区別が付かない。
解決するには、
自立語の連結のデータベース（自立語Ｎグラム？）を
持つしかないと思うけれど。
Anthy だと用例辞書や学習データベースが概ね当てはまるけれど。
用例辞書は人力メンテナンスなので網羅が貧弱、
人力なので豊かなデータベースを持つのは無理です。
学習データベースも元となる情報源は人力入力なので、
やっぱり豊かなデータベースを持つのは無理です。
あと、学習データベースの構造上、
データ量を増やすと目に見えてどんどん遅くなると言う問題が。
うーん、自立語２グラム？辞書を持たないと駄目なのかなぁ……。
自立語２グラム？辞書システムを実装したとしても、
辞書の元となるデータが無いぞ。
「:-O」と「:-P」と「:-D」を、頻繁に書き間違えていた事に気付いた。 恥ずかしい……。
Fri,22 Jul,2011、 Wed,03 Aug,2011、 Thu,04 Aug,2011、 Thu,11 Aug,2011、 Fri,18 Nov,2011、 の続き。
Thu,31 May,2012、 に続く。今まで FreeBSD/amd64 9-CURRENT にて、 Intel_GPU - FreeBSD Wiki を数回試しても毎回カーネルフリーズ起こしていたのだが。 「畑農 智実 氏 - FreeBSD | Panasonic CF-J10T に入れる」 と言う記事を見つけて、再度試してみた。
カーネルだけ FreeBSD/amd64 10-CURRENT に更新して ユーザーランドを FreeBSD/amd64 9-RC3 のまま更新し忘れて dhclient が「alc0 なんて無い」とか言って来るとか、 sudo を更新し忘れて「pam_unix.so が無い」とか言って来るとか、 ポカミスを連続したものの、 カーネルもユーザーランドも FreeBSD/amd64 10-CURRENT に Intel_GPU パッチ付きにして起動したら、 今回はカーネルフリーズせずにちゃんと立ち上がった。 ちゃんと agp0 も認識しているし。 今まであんなに不安定だったのは何だったのだろう……。
snip
acpi0: <ACRSYS ACRPRDCT> on motherboard
snip
acpi_ec0: <Embedded Controller: GPE 0x17> port 0x62,0x66 on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0x1800-0x1807 mem 0xf0000000-0xf03fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0
agp0: <Intel Ironlake (M) SVGA controller> on vgapci0
agp0: aperture size is 256M, detected 131068k stolen memory
snip
こんな感じ。
ports の dri2proto, glproto, libdrm, xf86-video-intel も更新して、 xorg.conf にてドライバを Intel に変更して、 X を起動した所、1366x768 で表示される様になった。 長かった……半年費やしたのか……。
だがしかし問題点も出てきた。うーん、 起動／終了は１分程度で済むし ５ボタンマウス対応で ネイティブで動作するけれども 上記問題が出る 1366x768 表示なネイティブ FreeBSD/amd64 と、 これら問題点が一切出ず 1366x768 表示できるが 起動／終了に数分かかるし ３ボタンマウスまでしか対応しておらず エミュレーションで動作する FreeBSD/amd64 on VMPlayer in Debian GNU/Linux と、 どちらがいいか、悩ましいなぁ……。
MS-Windows側からアクセスしている raw HDD には
VMPlayer側からアクセスできないのね。
GNU/Linux版 VMPlayer なら両方からアクセスできたのだが。
と言うわけで、
起動用パーティションだけ仮想ディスクにしていて
残りは生HDD のスライス／パーティションに入れている OS は、
MS-Windows からは使えない。
「ー」：音引き、長音符。
「ゃゅょ」が付く：拗音。
「っ」が付く：促音。
「たてんぽとりよせ」
Anthy MBR 「(3 ((UL RV) "立てん" 0 22) ((UL) "ポトリ" 0 2) ((UL) "寄せ" 0 5))」 文節数最小 「(3 ((UL RV) "立てん" 0 22) ((UL) "ポトリ" 0 2) ((UL) "寄せ" 0 9))」 前方２文節最長一致 「(3 ((UL RV) "立てん" 0 22) ((UL) "歩" 0 5) ((UL) "取り寄せ" 0 7))」 前方３文節最長一致 「(3 ((UL RV) "他" 0 23) ((UL) "店舗" 0 4) ((UL) "取り寄せ" 0 7))」 SJ3 「多テンポ取り寄せ」 Mozc 「|た|店舗|取り寄せ|」
SJ3 で文節区切り位置を見る方法忘れた……。
前方３文節最長一致は、なぜこうなったか不明。
Anthy (MBR) と文節数最小の結果を比較するに、 Anthy (MBR) では連文節情報に該当が無かったので 文節長が均等になる様に割り振ったと思われる。 面倒なので裏付けは取っていない。 さて、こんな変換内容の場合、 どう判定すればよいのだろう？
学習データが肥大化して起動や変換が遅くなっているので
思い切って学習データを全て削除して、
ブートストラップ学習データも無効にしてみた。
速度は戻ったのだが、変な文節区切りが出る様になった……。
学習が無いとこんなにポロポロ変な文節区切りが出る物だったのか……。
あれ、今日は節分だったか。
上記の件は偶然今日になったのだけれども。
ぎゃー。
src/sj3serv/Makefile.* と src/sj3proxy/Makefile.* にて、
誤：-I$(top_builddir)/lib/lua/src 正：-I$(top_srcdir)/lib/lua/src
dict/Makefile.* にて、
誤： visual.dic 誤：./visual.dic 正：$(top_srcdir)/dict/visual.dic
３〜４年くらい前に送付したパッチで修正漏れが有った。 orz 今更どうしよう。困った。 送付した方が良いのか、寝た子を起こさない方がいいのか……。
「ぶんせつくぎりいちを」
Anthy-9100h MBR 「(3 ((UL RV) "文節" 0 4) ((UL) "区切り" 0 6) ((UL) "一を" 0 10))」 Anthy MBR コーパス強化 「(3 ((UL RV) "分節" 0 4) ((UL) "釘" 0 4) ((UL) "利一を" 0 5))」 文節数最小 「(3 ((UL RV) "文節" 0 4) ((UL) "区切り" 0 6) ((UL) "位置を" 0 10))」 前方２文節最長一致 「(3 ((UL RV) "分節" 0 4) ((UL) "釘" 0 4) ((UL) "利一を" 0 5))」 前方３文節最長一致 「(3 ((UL RV) "分節" 0 4) ((UL) "釘" 0 4) ((UL) "利一を" 0 5))」 SJ3 「文節区切り市を」 Mozc 「|文節|区切り|位置を|」
こちらは、 コーパスを強化すると失敗する例。
「３ねんくらい」
Anthy-9100h MBR 接頭辞／接尾辞の連結モード 「(3 ((UL RV) "3年くらい" 0 5))」 Anthy MBR 接頭辞／接尾辞の分離モード 「(3 ((UL RV) "３" 0 3) ((UL) "寝んくらい" 0 6))」 SJ3 「３年くらい」 Mozc 「|３|年くらい|」
こちらは、 接頭辞／接尾辞の分離モードにすると失敗する例。
FreeBSD の ports の cfs が 暫く前に消えてしまったので、 今更仕方なく fusefs-encfs に移行。
fusermount が無いと思ったら、fuse の FAQ に書いてあった。 GNU/Linux 以外だか Mac OS X だかでは sudo umount〜 らしい。 FreeBSD でも sudo umount〜 だった。
FreeBSD 10 だと BROKEN が付いていた orz
Intel_GPU は FreeBSD 10-CURRENT しかないのに……、どちらか選べと。
Thu,01 Mar,2012 追記：
いつのまにやら 7.1 から 7.1a に更新されていて、
さらに FreeBSD 10-CURRENT での BROKEN が消えていた。
でも、カンマが余計に有ってビルドが通らない……、
むりやり通したら普通に動いたっぽい。
刺さった。
kernel: Fatal trap 12: page fault while in kernel mode kernel: cpuid = 3; apic id = 03 kernel: fault virtual address = 0x0 kernel: fault code = supervisor read instruction, page not present kernel: instruction pointer = 0x20:0x0 kernel: stack pointer = 0x28:0xffffff811b27bad0 kernel: frame pointer = 0x28:0xffffff811b27bb20 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 kernel: current process = 34259 (cp) kernel: trap number = 12 kernel: panic: page fault kernel: cpuid = 3
web で検索してみたら
http://lists.freebsd.org/pipermail/freebsd-fs/2011-December/013318.html fusefs broken on 8-stable? Thu Dec 29 22:14:00 UTC 2011 There is alternative fuse port at https://github.com/glk/fuse-freebsd-ports Could you try it and let us know if it works.
だって。……試してみたら
kldload: can't load /usr/local/modules/fuse.ko: Exec format error
で駄目だった。
仕方がないので他のファイル／ディレクトリベースの暗号化FSを探してみた。
FreeBSD 限定で pefs と言う物が有るらしい。ports からサクッと入った。
ざっと試した感じ、cfs より速い。encfs より２割速い。
今の所、刺さる事も無い。
http://wiki.freebsd.org/PEFS 抜粋：作る： % mkdir ~/private ~/private.enc % pefs addchain -f -Z ~/private.enc Enter parent key passphrase: Reenter parent key passphrase: 抜粋：使う： % pefs mount ~/private.enc ~/private % pefs addkey -c ~/private Enter passphrase: 抜粋：後片付け： % pefs umount ~/private
cfsと同程度に簡単。まぁ encfs も同程度に簡単だけど。
「こうか」の変換候補。
「×か」（付属語：か）が「××」（付属語なし）よりも
先に並んでいるけれど。
「××」（付属語なし）を優先する様に
順位をいじった方が良いのかなぁ？
類似として、文節区切り候補において、 複数文節に区切る候補よりも １文節になる候補を優先する様に 順位をいじった方が良いのかな？
例えば「こう」。
「項」などの付属語なしと
「乞う」（付属語なしにはできない）などの付属語「う」が
同列（付属語なしを優先すると、
付属語なしにできない候補が常に下位になってしまう）だから、
単純に付属語なしを優先するだけだと駄目っぽい。
やるとしたら、
付属語グラフにて
単語変換モードで優先したい付属語候補に優先マークを付けるしかないか……。
このページ（whatsnew）の RSS を探している人がいるみたいなので、 rss20.rss を作ってみた。
自前で作った perl script で抽出して RSS に変換しているので、 バグが有るかもしれません。悪しからず。
rss だと、 適当に書き散らかして後で加筆修正しているのが把握出来ませんね。 どうすれば良いのだろう？
１時間で４回もサーマルシャットダウンがかかった。 爆熱で排気が熱風。
sysctl を見てみたら、
dev.cpu.0.freq: 2400 dev.cpu.0.freq_levels: 2400/25000 2266/23316 2133/21689 1999/20116 1866/18531 1733/17021 1599/15517 1466/14068 1333/12640 1199/11250 1049/9843 899/8437 749/7031 599/5625 449/4218 299/2812 149/1406 hw.acpi.thermal.tz0.temperature: 99.0C hw.acpi.thermal.tz0._PSV: 99.0C hw.acpi.thermal.tz0._CRT: 103.0C hw.acpi.thermal.tz1.temperature: 50.0C hw.acpi.thermal.tz1._CRT: 92.0C
だと。冬場でそれって……。
それとも表示が 2.400GHz になると ターボの 2.66GHz になって TDP の 35W 近くになっているのかな？
powerd で最高周波数を 2.133GHz に下げたら、
温度が80℃まで下がった。
3.3W 下がって20℃下がるって熱抵抗が 6.1℃/W になるけれど、
いくらなんでもそんなに大きくはないだろう。
やっぱりターボで 35W 近くまで行っているのだろうか？
そう仮定すると 13.3W で20℃だから……
1.5℃/W ……やっぱりまだ大きい様な……。
と思ったけれど、フルパワー 35W 仮定で 100℃になるとすると、
周囲温度 15℃と仮定すると 2.4℃/W、
周囲温度 20℃と仮定すると 2.3℃/W、
周囲温度 25℃と仮定すると 2.1℃/W、
ノートPC だから案外そんなものかもしれない。
仮定の２階建てだけれど。
普段が 1GHz前後で 10W前後の 55℃前後。
周囲温度 15℃仮定で 4.0℃/W、
周囲温度 20℃仮定で 3.5℃/W、
周囲温度 25℃仮定で 3.0℃/W。
大きいなぁ。
でもファンがほとんど止まっているから、そんなものなのかなぁ。
しかし、私がノートPC を使うと、 ことごとくサーマルシャットダウンに当たるって……。
Tue,28 Feb,2012に続く。
「おおきくはないだろう」の変換候補。
「|大きく|花井だろう|」 v.s. 「|大きくは|ないだろう|」
他の変換内容でも、
「|××|花井だろう|」 v.s. 「|××は|ないだろう|」
は結構出てくる。
他にもしばしば見かけるのは、
「|××|出てくる|」 v.s. 「|××で|てくる|」 （「|結構|出てくる|」）
「|××するか|否か|」 v.s. 「|××するかい|中|」 v.s. 「|××する|腕か|」
「|××やるか|否か|」 v.s. 「|××やるかい|中|」 v.s. 「|××やる|腕か|」
など。
「|××|内容で|」 v.s. 「|××な|いようで|」 （「|変換|内容で|」）
も見た事がある。
機械的にそこだけ見ると確かに日本語にはなっている
（「てくる」はともかく）。
でも前後の文脈を合わせると日本語になっていない。
さぁ、どうやってこの判定を回避する？
とあるサイトにて、 Firefox が必ずフリーズする。フリーズすると負荷 100％になる。
Firefox を 3.6.24/3.6.26/10.0.1 と変えてみたけれども、 ３つとも発症する。 さて、困った……。
WITHOUT_DBUS=true WITHOUT_PGO=true WITHOUT_DEBUG=true WITHOUT_LOGGING=true WITHOUT_OPTIMIZED_CFLAGS=true でも発症した。
I , flags 10004083 , STATE uwait で 固まっているのか……。
Wed,15 Feb,2012 追記：
Add-on の RequestPolicy が原因だった。
状況から憶測するに、
RequestPolicy の表示がなにがしかの理由で行われないまま、
ユーザの応答待ちになっている気がする。
あーでも、それだと負荷 100％になるのは変か。
何だろう。
Fri,24 Feb,2012 追記：
自動設定のポップアップが出る前にフリーズしてしまうので、 手動で RequestPolicy に許可の設定を追加してみた。
フリーズせずにちゃんと遷移する様になった。
<DL> の表示が変わっていた。
3.6 までは、<DL> がネストすると ネストした回数だけインデントが増えていたのだが。
10.0.1 では、<DL> がネストしても
インデントが増えなくなっていた。
どうやら <DL> の後に <DD> が記述されていると、
ネストした回数だけインデントが増えるらしい。
<DL> の後に <DT> だけが記述されていて
<DD> が無いと
インデントが増えない。
うーん。 Bookmark の export した html が読みにくいぞ。
Tue,14 Feb,2012の 「おおきくはないだろう」、 「いくかいなか」、 の文節区切り候補の話の続き。
コーパスに 「|大きくは|ないだろう|」と 「|行くか|否か|」を追加して、 「|大きく|花井だろう|」や 「|行く|腕か|」＆「|行くかい|中|」が 出なくなるかどうか試してみたが、 変わらなかった。
そこで、 改造版用例辞書に追加した所、 両方とも出なくなった。
それならばと、 文節候補判定の際に用いられている コーパスシステム由来の用例辞書機能 （コーパス用例辞書……勝手に命名） を改造して、 文節区切り判定の際にも コーパス用例辞書を用いる様にしてみた所、 「|大きく|花井だろう|」は出なくなったが 「|行く|腕か|」は相変わらず出る。
仕方が無いのでデバッガでトレース。
section corpus_array値 フラグ＋ハッシュキー 自立語ハッシュ 自立語表記 896841640,-1 BOS+BORDER+91535272 1970583464 行 668951530,-1 BORDER+132080618 400516074 否 ※ コーパス用例辞書では読み仮名や品詞や付属語は無視される。
コーパス用例辞書を検索する際に、 上記の１ペア（ハッシュキーは上記２件）を引き当ててくれれば 「|行くか|否か|」が強くなる筈。 個人的には、 付属語＋自立語ペアを文節区切りに生かしたかったのだが、 データベース操作のコードを作る所から始めなくてはならないので断念。
試した結果、
コーパスの登録件数が今回の１ペアのみだと引いてくれず、
２ペアだと引き当てて適用されたのだが、
コーパス強化版＋今回の追加にすると
また引き当ててくれなくなった。
再度ソースコードを追跡……。
コーパスデータベースに登録された最後の１ペアが
コーパス用例辞書の検索対象から故意に外されているのですが、
これは仕様でしょうか orz
１ペアのみ登録した時に引き当ててくれず
２ペア以上登録した時には引き当ててくれる理由は
これだった。
あとついでに。
ここでもまた int型が 32bit以上有る前提で
コーディングされていた。
また、
同一の基準単語（今回は「行」）から
探索する隣接単語（今回は「否」）は
100件までしか検索しない様になっていた。
コーパス強化版＋今回の追加では、
「行」を基準にした対が237件有ったので、
「行」−「否」ペアは検索対象の100件から溢れているらしい。
単純にこの検索件数を３倍にすると、
コーパス用例の検索時間も３倍になってしまうので望ましくない。
基準単語（今回は「行」）と
隣接単語（今回は「否」）を
逆にした所で、
別のどこかで 100件を溢れるだろうし。
改造版用例辞書は コーパス用例辞書と違い １ペアでハッシュ値１つに変換しているのだが、 ハッシュコリジョンを起こすと登録しなくなる仕様なので、 コーパスを丸ごと登録すると溢れるかもしれない。
今回の話のオチは、手詰まり、でした。
find_border_of_this_word() にて変なループがあるけれど バグだろうか？ ループ内に書かれている処理では、 アンダーフロー検査を除き ループ条件が変わらず ループから抜け出る事が出来ないのだが……。
find_left_word_border() も、 ループの初回条件と２回目以降の条件が違っているのだが……。
文節区切り判定の際にも
コーパス用例辞書を用いる様にしてみた。
（試験版更新に付き削除）
今回の機能を有効にすると変な文節区切りが増えた為、
標準設定では無効にしてあります。
有効にしたい場合は
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSUDIC 0.0e-1 LATTICE_BIASSCORE_BY_CORPUSUDIC 300.0
を調整してみて下さい。
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSUDIC を 6.4e-1 以上にすると、 コーパス用例辞書に登録されている文節区切りが強く出る様になります。 が、間違った文節区切りの適用も強く出てしまいます。
例えば、
「じょうけん」が「|上|件|」（|じょう|けん|）になったりします。
これは、
コーパスに書かれている「|上の|件|」（|うえの|けん|）を
「|上*|件*|」
（読み仮名／品詞／付属語は
コーパス用例辞書登録時に削除される）
として記録しており、これを適用した結果によるものです。
コーパスの MBR アルゴリズムによる利用：
コーパスのコーパス用例辞書での利用：
MBR アルゴリズムでは、 自立語の読み仮名や変換結果の表記は破棄。
コーパス用例辞書では、 品詞／読み仮名／付属語は破棄。
文節区切り判定の際にもコーパス用例辞書を用いる様にした状態で 「いくかいなか」を変換すると、 「|いくか|い|中|」になる。
「行」−「否」ペアが検索対象から溢れているらしいのは
Sun,19 Feb,2012
に書いた通りだけれども、
今回の疑問は何故「|い|」で切るのか。
追跡した結果、どうやら、
例文中の「|行ったら|いい|」（|いったら|いい|）、
データベース中では「|行*|い*|」、
を
適用して、「|い|」で切っているらしい。
Anthy では、文節区切り候補を生成する前に 入力内容に適合する単語を全てディスクから読み出して列挙してから、 文節区切り位置を探索している。
文節区切り位置探索の際に 列挙した単語を全て検索しているか否か調べてみたら、 検索していない単語も有った。
検索する単語だけディスクから読み出す方が速いのか、 ディスクから全パターンを読み出す方が速いのか、 その辺まで突っ込んで調べる気にはならず。
Sun,19 Feb,2012 に挙げた 「|上の|件|」が「|上|件|」（|じょう|けん|）になるのを 防げないものかと、 自立語の表記だけでなく読み仮名も合わせて記録し、 試してみた。 自立語の表記と読み仮名を NUL文字を付けて連結しただけなので、 よそでハッシュコリジョンを起こす可能性は変わらないのだけれども。
anthy-9100h.patch13-testing-2012222.alt-depgraph-110208-angie.zipdic-201101.tar.lzma（試験版更新に付き削除）
実地テスト中。
Fri,02 Mar,2012 追記：
実地で使ってみたが結論だけ言うと良くない。
確かに、表記は同じで読み仮名が違う、と言う適用は無くなったが、
そこで文節を区切るのは変だ、と言う適用は相変わらず出る。
終章、またなんかぶった切り感が……。
著者のスタイルなのかな？
「星を継ぐもの」
「ガニメデの優しい巨人」
「巨人たちの星」
の続編と言う事になっているが、
同じ登場人物の別シリーズと見た方がよいと思う。
大分類では同じシリーズだけど小分類では別シリーズ、
と言ったらよいのかな。
これにもまた続編が有るらしいが未翻訳、 と ja.wikipedia.org で見かけた。 J.P.ホーガンの邦訳は創元だけれども、 ハヤカワのA.S.カードのエンダーシリーズも 途中から未翻訳だしなぁ……。 大御所の A.アシモフでも未翻訳が有るらしいし。 原文で読む気力も無いし。
Firefox 10.0.2 にて、 〜 （波ダッシュ）と − （マイナス）が、 ～ （チルダ）と － （ハイフン）に、 化けている事に気付いた。 いつからだろう？
Firefox 3.6.x を試してみたら化けなかった。 という事は 4.x から化け始めたのかな……？
試行錯誤してみたら、 EUC-JP と ISO-2022-JP と Shift-JIS なページの時は化けて、 UTF-8 なページは化けない事にも気付いた。 えー。
Firefox 10.0.2 のソースコードに grep かけてみたら該当部分を見つけた。
intl/uconv/ucvja/japanese.map の gJapaneseMap[]
/* index 8648 */
0x3000, 0x3001, 0x3002, 0xFF0C, 0xFF0E, 0x30FB, 0xFF1A,
0xFF1B, 0xFF1F, 0xFF01, 0x309B, 0x309C, 0x00B4, 0xFF40, 0x00A8,
0xFF3E, 0xFFE3, 0xFF3F, 0x30FD, 0x30FE, 0x309D, 0x309E, 0x3003,
0x4EDD, 0x3005, 0x3006, 0x3007, 0x30FC, 0x2015, 0x2010, 0xFF0F,
0xFF3C, 0xFF5E, 0x2225, 0xFF5C, 0x2026, 0x2025, 0x2018, 0x2019, ← 0xFF5E
0x201C, 0x201D, 0xFF08, 0xFF09, 0x3014, 0x3015, 0xFF3B, 0xFF3D,
0xFF5B, 0xFF5D, 0x3008, 0x3009, 0x300A, 0x300B, 0x300C, 0x300D,
0x300E, 0x300F, 0x3010, 0x3011, 0xFF0B, 0xFF0D, 0x00B1, 0x00D7, ← 0xFF0D
0x00F7, 0xFF1D, 0x2260, 0xFF1C, 0xFF1E, 0x2266, 0x2267, 0x221E,
0x2234, 0x2642, 0x2640, 0x00B0, 0x2032, 0x2033, 0x2103, 0xFFE5,
0xFF04, 0xFFE0, 0xFFE1, 0xFF05, 0xFF03, 0xFF06, 0xFF0A, 0xFF20,
0x00A7, 0x2606, 0x2605, 0x25CB, 0x25CF, 0x25CE, 0x25C7,
/* index 8742 */
eucJP/ISO-2022-JP/Shift-JIS から Unicode に変換するテーブルが、 もろに CP932/CP51932系だか eucJP-MS系だかになっている。 CP932/CP51932系なのか eucJP-MS系なのかは面倒だから確認していない。 ただ、テーブルの変数名は CP932 になっていた。
と思ったけれど、firefox-3.6.27.source.tar.bz2 の ソースコードでも同じだ……。はて？
試しに、firefox-10.0.2 にて、上記のテーブルを
eucJP(JIS X 0208) に書き換えてビルドしてみた。
文字化けしなくなった……。
ネタのおおもとは 「saiten 氏 - 簡易radiko録音ツール。要swftools」、 らしい。
「YAMA'S MEMORANDUM - June 6, 2011−3:04 pm - RTMPDUMPによるradikoの録音」、
さらにそのネタ元：
「saiten 氏 - 簡易radiko録音ツール。要swftools」。
や
「タツヤ 氏 - 個人的自由帳 - 2011 年 3 月 21 日 - とあるサイトの録音手段 (シェルスクリプト)」、
さらにそのネタ元：
「saiten 氏 - 簡易radiko録音ツール。要swftools」、
「machua 氏？ - 禿散らかしてごめんなさい - 2010-11-06 - 電話会議システムを導入 ＠OpenMeetings」、
「がーぶろぐ(G-Blog) - 2010/04/09 - debianでradikoをエアチェック、mp3出力してみる」。
に書いてある通りにしたらアッサリ録音できた。
RTMPDump は OpenBSD の ports にあるので楽に入る。
OpenBSD の ports には swftools が無いけれど、 「山賀正人のブログ - 2011年03月25日 - swftools-0.9.1 (OpenBSD 4.8 自作パッケージソース)」 から持ってきたらサクッと入った。
だがしかし。 聞く時の手間や聞く時の音質を考えると、 ステレオのタイマー録音の方が良さそうだ。 聞く時の音質と言っても、PC からステレオにつなげば 電波を経ないぶん radiko の方が良さそうだけれども。
「つなげば」の変換候補。
原作の Anthy だと「|つなげば|」。
コーパス強化版だと「|綱|下馬|」。
コーパス強化版は 「|(名詞)(付属語なし)|(名詞)(付属語なし)|」 が好きらしい。
Tue,14 Feb,2012の続き。 Sun,22 Jul,2012に続く。
冷却ファンがストールした。 599MHz 駆動 5.6W で、99℃に達していた。 こわいー。
熱抵抗を考えてみると、
周囲温度 15℃仮定で 15℃/W、
周囲温度 20℃仮定で 14℃/W、
周囲温度 25℃仮定で 13℃/W。
ずいぶん大きいなぁ……。
「かいていないからへんな」の変換候補。
原作の Anthy だと「|書いていないか|ラ変な|」。
コーパス強化版だと「|書いていないから|変な|」。
先日のコーパス用例辞書の文節区切り適用版では 「|書いていな|意から|変な|」。 「かいていないから」は「|書いていないから|」になるので、 「|意*|変*|」（|い*|へん*|）が適用された結果だと思う。
用例辞書／コーパス用例辞書は、 文節候補の判定にとどめた方が良さそうな気がする。 文節候補の判定だけなら同音異義語で効果を発揮して そこそこ有効だと思う。
「いれていなかったため」の変換候補。
原作の Anthy だと「|入れていなかったため|」。 付属語が２文字長すぎ。
コーパス強化版だと「|いれていなかった|貯め|」。
先日のコーパス用例辞書の文節区切り適用版では 「|いれて|い|なかったため|」。 「|い*|ため*|」らしい。
「じぶんでかいた」の変換候補。
原作の Anthy だと「|自分で|書いた|」。
コーパス強化版だと「|自分で|書いた|」。
先日のコーパス用例辞書の文節区切り適用版では 「|自分|デカ|いた|」。
マルチジェスチャーのスクロールが効かない。
試行錯誤した結果。
/boot/loader.conf で hw.psm.synaptics_support=1 して /etc/rc.conf で hald_enable="YES" と dbus_enable="YES" して x11-drivers/xf86-input-synaptics を入れて /etc/xorg.conf で synaptics の設定を書いたら、 エッジスクロールや２本指スクロールが使える様になった。
hald を入れていなかったので効かなかったらしい。
マルチジェスチャーが効く様になったものの、 どうにも慣れなくて使いにくい。
Firefox 3.x までの browser.history_expire_days での 保存日数指定は廃止になって、 places.history.expiration.transient_current_max_pages での 保存件数指定になったらしい。
anthy-9100h.patch13-testing-2012303.alt-depgraph-110208-angie.zipdic-201101.tar.lzma（試験版更新に付き削除）
後日、パラメータ調整後に、更新します。
現在、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSWBDIC 0.0e-1
を変えて実地試験中。
概ね 4.7e-7 が最低ラインで、6.6e-1 が上限の模様。
現在値は 3.3e-1 。
「(付属語) + (文節区切り) + (自立語)」の、
読み仮名ベース変則単語 変則２グラム
（読み仮名ベース文節 変則２グラムではないし、
付属語に２単語以上の語を許容しているので
読み仮名ベース単語 変則２グラムでも無いんだよね……。
そもそも確率(頻度)を 0 と 1 しか持っていないのに
２グラムと呼べるのかな？）の
データベースを持った方が良いのではないか、
でも面倒、と、前からこぼしていたけれど。
「(自立語) + (ワイルドカード) + (文節区切り) + (自立語)」
ベースのテストベッドや、
「(自立語品詞) + (付属語) + (文節区切り) + (自立語品詞)」
ベースの MBR にて、
どうにもたまに明らかに変な文節区切り候補が出るのが止まらない
（注意：
単語登録をしていない単語を使うと明らかに変な候補が出るのは、
かな漢字変換システムそれ自体の仕様です。
単語登録して下さい）
ので、
結局、
「(付属語) + (文節区切り) + (自立語)」を
実装してしまった。
既存のソースで これに使いまわせるデータベースが無かったので、 完全新造。 と言っても、単なるハッシュだけれど。
どんな仕様で実装されているかと言うと。
言葉にするとたった３行で済んじゃったよ……。
具体例：
「いくかいなか」→「|行くか|否か|」（|いくか|いなか|）
を登録した場合。
「(付属語：くか) + (文節区切り) +
(自立語読み仮名：いな，自立語表記：否)」
を抽出、ハッシュ化してテーブルに記録する。
この方法には欠点が有って。
コーパスに記述された固有の言い回しに対しては有効かも知れないけれど、
そうでないものはパターンが多すぎて、
例文に合致する確率が低すぎる問題が。
私のタイピングの学習量の OCHAIRE の項目が
ほぼ直線で右肩上がりになっているのがその証左。
さて、 「(付属語) + (文節区切り) + (自立語)」は どの程度有効なのかな。
Total 50201 data, 4418 dup, 3737 collisions, 543 collision and lost, in corpus bucket Total 25608 data, 10828 dup, 3411 collisions, 0 collision and lost, in corpus wordborder. max_collision=0 47412 sentences 235426 connections 188014 segments
１行目が、
「(自立語) + (付属語ワイルドカード) + (文節区切り) + (自立語)」
の情報。
２行目が、今回新造した
「(付属語) + (文節区切り) + (自立語)」
の情報。
コーパスから抽出できた 「(付属語) + (文節区切り) + (自立語)」情報の件数が 15000弱（25608-10828）。 思ったより少ない。
コーパスの情報量を確認してみた。
行数 単語数 字数
14 38 355 corpus/corpus.0.txt
1746 3499 126190 corpus/corpus.1.txt
83 180 4600 corpus/corpus.2.txt
9098 18237 549937 corpus/corpus.3.txt
17 34 357 corpus/corpus.4.txt
77 157 4472 corpus/corpus.5.txt
3223 6461 188565 corpus/corpus.g.txt
1768 3541 128498 corpus/corpus.x.txt
16026 32147 1002974 total
16026行から 15000弱抽出。 そんなものかなぁ？
「(付属語) + (文節区切り) + (自立語)」を 実装したせいで出てくる変な候補の話。
「|古く|手|」（|ふるく|て|）
コーパスの 「|置く|手も|」（|おく|ても|） から抽出した、 「|*く|手*|」（|*く|て*|） にヒットしたらしい。
学習が無い状態に於いては、 「文節を区切らない」システムが無いので対応できない。 未学習で対応するにはどうすればいいだろう。
「文節を区切らない」システムは、 改造版 OCHAIRE 学習には実装してあるのですが、 学習させないと反映されない問題が。 学習ブートストラップを使えば学習させなくても反映されるけれども、 起動が遅くなる （anthy.el だと変換毎に起動する事になるので、使い物にならなくなる） 問題が。
その他の遭遇例
|区切るの|破片だ| コーパスに該当が無かった為。 |明らかに|経んな| コーパスに該当が無かった為。 |一致するか|いな|可を|判定する| コーパスに該当が無かった為。 |学習させないと|反映されないもんだ|伊賀| コーパスに該当が無かった為。 |実装した|可と|言うと| コーパスに該当が無かった為。 |その一|での| 「文節を区切らない」システムが無いので対応できない。この例では人間でも判定できない。 |１行|メガ| 「文節を区切らない」システムが無いので対応できない。 |反|ご以上| 「文節を区切らない」システムが無いので対応できない。 |鋼鉄と|し| 「|値付けと|した|」と衝突。この例では単語登録するべきだが。
競合する情報が有った場合どうしたらよいだろう。 競合した場合は「文節長が長い方」とか「文節数が少ない方」とか ヒューリスティックを導入すると、 それって「ｎ文節最長一致」とか「文節数最小」とか になってしまうし。 ……。 いっそのこと、そこまで割り切った方が良いのだろうか？ 単語付きコーパスデータベースに一致した場合は文節数最小で処理して、 単語付きコーパスデータベースで見つからなかった場合は MBR で処理する、 と言うふうに。
駄目だ。
「|値付けと|した|」（|ねづけと|した|）→「|鋼鉄と|し|」（|こうてつと|し|）の場合と、
「|鋼鉄|都市|」（|こうてつ|とし|）→「|鋼鉄|都市|」（|こうてつ|とし|）の場合で、
合計の文節長も、文節数も、該当部分の文字数も、
どれも一致していて判定できない。
OCHAIRE学習では、
衝突した場合は該当文字列長が短い方を削除、
になっているが
（原作版では文字列長が短い場合は学習しない特例が付いているけれど）。
駄目だ。
「*と|し*」の２文字と「*|とし*」の２文字で、これも一致して判定できない。
こうなると、
「(付属語) + (文節区切り) + (自立語)」
だけでの処理を諦めて、
「(自立語) + (付属語) + (文節区切り) + (自立語)」
を追加するしかないか……。
OCHAIRE学習と全く同じになるなぁ……。
OCHAIRE学習と比較して良い点は、
変換時にハッシュで検索する為、
起動時に学習データを丸ごとメモリに読み込む OCHAIRE学習よりも、
起動が速い（その分変換が若干遅くなる）事かなぁ……。
「(付属語) + (文節区切り) + (自立語)」を
実装したせいで出てくる変な候補の話。
付属語が無い文節の場合
「(付属語無し) + (文節区切り) + (自立語)」
に、適用するか否かで変な候補が出たり出なかったりする。
「|変換|出|遅く|」（|へんかん|で|おそく|）
MBR_MODE_LATTICE_BIASPROB_BY_CORPUSWBDIC を
8.2e-4 まで下げれば、出なくはなる。
ただ、下げると下げたで、
出て欲しい候補が出なくなったりするから面倒くさい。
いくかいなか
「(付属語) + (文節区切り) + (自立語)」を適用するけれど
「(付属語無し) + (文節区切り) + (自立語)」
を適用しない場合に
「|行くか|否か|」が出るけれど、
「(付属語無し) + (文節区切り) + (自立語)」
も適用すると
「|いくかい|中|」
になる。
「|行くか|否か|」→「*か|否*」（*か|いな*）
と、
「|再び|中へ|」→「*|中」（*|なか*）
が衝突しているせいで、こんなんなる。
「(付属語無し) + (文節区切り) + (自立語)」
に適用しないべきか、
衝突した場合に何らかのヒューリスティックを導入するべきか。
この位の長さがダレないでちょうど良いと思う。 ネタも展開も、長さにちょうど合っているし。
anthy-9100h.patch13-testing-2012310.alt-depgraph-110208-angie.zipdic-201101.tar.lzma（更新につき削除）
後日、パラメータ調整後に、更新します。
調整の方針としては、
学習ブートストラップを無効にするか大幅に減らして起動時間を短縮し、
下記２つを有効（0.0以上）にして学習の代替をさせる予定。
現在、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-1
を変えて実地試験中。
現時点では
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 8.3e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 1.0e-1
にて試験中。
「(付属語無し) + (文節区切り) + (自立語)」 を無効にすると共に、 「(自立語) + (付属語) + (文節区切り) + (自立語)」 および 「(自立語) + (付属語無し) + (文節区切り) + (自立語)」 を、 コーパスから単語付きで抽出して利用する様に変更。
corpus wordborder D+I dic : Total 25863 data, 10975 dup, 3467 collisions, 0 collision and lost corpus wordborder ID+I dic : Total 34755 data, 3716 dup, 7323 collisions, 0 collision and lost D+I はハッシュテーブルのサイズが 32768。 ID+I はハッシュテーブルのサイズが 65536。
この方法にも
「(付属語) + (文節区切り) + (自立語)」
と同じ欠点が有って。
コーパスに記述された固有の言い回しに対しては有効かも知れないけれど、
そうでないものはパターンが多すぎて、
例文に合致する確率が低すぎる。
私のタイピングの学習量の OCHAIRE の項目が
ほぼ直線で右肩上がりになっているのがその証左。
「さがせと」
原作版だと「|探せと|」
コーパス強化版だと「|差が|背と|」
コーパス文節区切り辞書だと「|佐賀|背と|」
単文節 OCHAIRE 学習と同等の コーパス文節区切り辞書を実装しないと駄目か……。
anthy-9100h.patch13-testing-2012311.alt-depgraph-110208-angie.zipdic-201101.tar.lzma（更新につき削除）
後日、パラメータ調整後に、更新します。
調整の方針としては、
学習ブートストラップを無効にするか大幅に減らして起動時間を短縮し、
下記３つを有効（0.0以上）にして学習の代替をさせる予定。
現在、
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 0.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 0.0e-1
を変えて実地試験中。
現時点では
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 8.3e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 1.0e-1
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 6.7e-6
にて試験中。
でも、これだとちょっとバランスが悪いらしく変な候補が出てくる。
さらに追加で、 「(文節区切り) + (自立語) + (付属語) + (文節区切り)」 を、 コーパスから単語付きで抽出して利用する様に変更。
Total 51014 data, 4534 dup, 3766 collisions, 554 collision and lost, in corpus bucket corpus wordborder D+I dic : Total 25923 data, 11005 dup, 3472 collisions, 0 collision and lost corpus wordborder ID+I dic : Total 34858 data, 3744 dup, 7372 collisions, 0 collision and lost corpus wordborder ID dic : Total 51014 data, 22726 dup, 6061 collisions, 0 collision and lost D+I はハッシュテーブルのサイズが 32768。 ID+I はハッシュテーブルのサイズが 65536。 ID はハッシュテーブルのサイズが 65536。
ブランチを玉突きで１個ずつずらす予定。
現行：
変更後：
変更後の「旧 安定版」での辞書更新はしません
（vagus氏により提供されているので必要無いと思うので）。
変更後の「安定版」での辞書更新は暫く後になる見込み。
変更後の「試験版」での辞書更新は暫く後になる見込み。
「おおせか」
「読み仮名ベース文節 変則１グラム」
（確率(頻度)が 0 と 1 だからＮグラムとは言わない？）を
実装すると、変になる例。
「|お|衣装|」から「|お|」をデータベースに記録してしまい、
「おおせか」を変換すると「|お|小瀬か|」になってしまう。
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC を
1.1e-6 〜 1.0e-6 まで下げれば、出なくなった。
占いクッキー 100文を変換した時の所要時間。
今回一連のコーパス文節区切り辞書を無効にした場合： Anthy: Total time of splitter: 17.082057 Anthy: Total time of candidate: 0.355770 今回一連のコーパス文節区切り辞書を有効にした場合： Anthy: Total time of splitter: 122.920758 Anthy: Total time of candidate: 0.581485
ううむ。遅すぎ。
なので、漢字表記を入れ込む事を諦めて、 自立語や付属語の読み仮名だけを使って辞書化／検索する 事にしてみた。
Anthy: Total time of splitter: 20.401588 Anthy: Total time of candidate: 1.144207
まぁ許容範囲かな……。
anthy-9100h.patch13-testing-2012313.alt-depgraph-110208-angie.zipdic-201101.tar.lzma（更新につき削除）
後日、パラメータ調整後に、更新します。
調整の方針としては、
学習ブートストラップを無効にするか大幅に減らして起動時間を短縮し、
下記３つを有効（0.0以上）にして学習の代替をさせる予定。
現時点では
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBDI_DIC 8.3e-4
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBIDI_DIC 2.1e-2
MBR_MODE_LATTICE_BIASPROB_BY_CORPUS_WBID_DIC 1.0e-6
にて試験中。
2012311版までは、
「(付属語) + (文節区切り) + (自立語)」，
「(文節区切り) + (自立語) + (付属語) + (文節区切り) + (自立語)」，
「(文節区切り) + (自立語) + (付属語) + (文節区切り)」，
を
データベース（ハッシュ）に変換／検索する際に、
表記と読み仮名の両方を使っていたが、
これが前述の通り遅い。
ので、
変換後の表記の一致判定を諦めて、
読み仮名だけを
データベース（ハッシュ）に変換／検索する様にしてみた。
前述の通り、従来の１〜２割遅くなる程度で済む様になった。
まあこれでも、１文の変換に 0.2秒も かかっている勘定になりますが。
ネットブックとかタブレットＰＣとかだと
0.5秒以上かかりかねませんよ。
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
後日、辞書を更新します。
試験版更新：
anthy-9100h.patch13-testing-2012317.alt-depgraph-120315-angie.zipdic-201101.tar.lzma（更新につき削除）
とりえあず、試しに辞書を更新してみました。
「もうちょい続きます。」との事なので、
後日再度、辞書を更新します。
そして梱包後に
また間違って作業ディレクトリを壊してしまうオチ orz
やりなおしだ……。
終章また微妙にぶったぎった感じがなくもないけれど、 そうでもないか。
常々、楽天的なエンディング。
著者のクセがそうなのかな。
インフォネット，PDP64，ジェンカ，GRASER, BIAC。 過去の未来として遜色無い感じ。
「かな漢字変換 anthy で、個人用学習データを活用して、変換結果の改善を目指すパッチ」
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」
「かな漢字変換 anthy で、個人用学習データを活用して、なんかもう思い付く事を何でもかんでも試してみて、変換結果の改善を目指すパッチ」