2008年2月アーカイブ

今日はYLUGのカーネル読書会に参加した。

ここ数回、こまめに参加しているのであるが、毎回非常に高度な話を
してくれるので頭がウニになって帰ってくる。

ただ、身の程を考えずに遥かににハイレベルな空間に身を投じることによって
触発されることも多いので、場違いな感じがしなくも無いと思わなくも無いが
頑張って参加してみるつもりである。

という事で今日のまとめを理解したなりにまとめておく。

今日のお題はバイナリパッチャ。

動的にバイナリにパッチ当てをする仕組みである。

基本的には実行されている(メモリに乗っている)プログラムに対し動的に
パッチ当てを行いバグフィックスや新機能の追加を行う仕組みである。

方法論としては関数を差し替える場合(※1)、新しい関数を置く場所をアロケートし
従来の関数の先頭をJMP命令で書き換えて新しい関数の場所まで飛ばしリターン時に
元の関数の元に戻ってくるように戻り番地を整えるとの事。

※1差し替えは関数ごととの事。

端的にはこうだよな。たぶん。

ポイントというか理解に必要な単語としてはコールスタックとかユーザランドとかptraceとかかと。

JMP命令とかINT3命令とかはもうアッセンブラの世界だとか思わなくも無く。

インテルのパイプラインをフラッシュしておかないと安全ではないとか
そんな質問というか意見というか出てましたが追いつけてない。

一つ一つ噛み砕いていこう。

danさんのブログで見つけたが、なんとも言いがたい。

コーパスの母体がwebサイトである事を考えるとアダルトサイトが多くを占めること、
「ちんこ」も「チョコ」も品詞では同じ扱いであることを考えると
出現頻度が高いほうがより上位に来るのだろうなと。

因みにmecabとipadicで解析すると以下の通り。

でかいチョコ
でかい 形容詞,自立,*,*,形容詞・アウオ段,基本形,でかい,デカイ,デカイ
チョコ 名詞,一般,*,*,*,*,チョコ,チョコ,チョコ
EOS
でかいチンコ
でかい 形容詞,自立,*,*,形容詞・アウオ段,基本形,でかい,デカイ,デカイ
チンコ 名詞,一般,*,*,*,*,*
EOS

同じ、一般名詞扱い。

やはり、単語のメタ情報が少ないなと。

mecabの処理内容がいまいち理解できていないので(※1)
この手のメタ情報を付加することにより、より言語情報が充実すれば
「検索エンジン空気嫁」が実現するのではないかなと夢想してみる。

まずはmecabのソースの解析かな。

※1マルコフ連鎖がまるでさっぱり。

編集ミスの為修正中(修正した。)

文字コードを理解する為の手段としてテキストを色々いじって遊んでみた。

用意するもの

  • UNIXマシン(家ではFreeBSD 6.2)
  • iconv(GNU libiconv 1.11)
  • 適当なテキスト(コードは何でも良いがUTF-8で用意した。)
  • hd(大概UNIX機に入っている)

用意したテキストは以下の通り

% cat utf8text.txt




ようよう赤くなり行く山際。

枕草子の第一節であるが、最初の部分に改行をわざと入れ変化を分かり易くしてみた。

hdはmanの「-C]を参照。
アスキー部分は見にくい為削除。

UTF-8

% cat utf8text.txt| hexdump -C
00000000 e6 98 a5 0a e3 81 af 0a e6 9b 99 0a e3 80 82 0a
00000010 e3 82 88 e3 81 86 e3 82 88 e3 81 86 e8 b5 a4 e3
00000020 81 8f e3 81 aa e3 82 8a e8 a1 8c e3 81 8f e5 b1
00000030 b1 e9 9a 9b e3 80 82 0a
00000038

規則性により「0a」が改行コードであることがわかる。(LF)
一行目を見やすく並べなおしてみる。

「e6 98 a5」=「春」
「0a」 =「LF」
「e3 81 af」=「は」
「0a」 =「LF」
「e6 9b 99」=「曙」
「0a」 =「LF」
「e3 80 82」=「。」

3byteの文字と1byteの制御コードになっている事が見て取れる。

UCS-4

% iconv -f UTF-8 -t UCS-4 utf8text.txt| hexdump -C
00000000 00 00 66 25 00 00 00 0a 00 00 30 6f 00 00 00 0a
00000010 00 00 66 d9 00 00 00 0a 00 00 30 02 00 00 00 0a
00000020 00 00 30 88 00 00 30 46 00 00 30 88 00 00 30 46
00000030 00 00 8d 64 00 00 30 4f 00 00 30 6a 00 00 30 8a
00000040 00 00 88 4c 00 00 30 4f 00 00 5c 71 00 00 96 9b
00000050 00 00 30 02 00 00 00 0a
00000058

4byteの固定長であることがはっきり判る。
「00 00 66 25」=「春」
「00 00 00 0a」=「LF]
改行コードも4byteである。

UCS-4はUnihan Databaseで確認可能なので確認してみる。
結果を見ると「00 00 66 25」が「春」であることが分かる。
一緒にUTF-8も確認可能。

UTF-16

% iconv -f UTF-8 -t UTF-16 utf8text.txt | hd
00000000 fe ff 66 25 00 0a 30 6f 00 0a 66 d9 00 0a 30 02
00000010 00 0a 30 88 30 46 30 88 30 46 8d 64 30 4f 30 6a
00000020 30 8a 88 4c 30 4f 5c 71 96 9b 30 02 00 0a
0000002e

指定が無いのでBOM「fe ff」がついている。(feffなのでリトルエンディアン。Core 2 Duoだしね。)

eucJP

% iconv -f UTF-8 -t eucJP utf8text.txt | hd
00000000 bd d5 0a a4 cf 0a bd ec 0a a1 a3 0a a4 e8 a4 a6
00000010 a4 e8 a4 a6 c0 d6 a4 af a4 ca a4 ea b9 d4 a4 af
00000020 bb b3 ba dd a1 a3 0a
00000027

固定長(ただし、改行コードは1BYTE)

SJIS

% iconv -f UTF-8 -t SJIS utf8text.txt | hd
00000000 8f 74 0a 82 cd 0a 8f 8c 0a 81 42 0a 82 e6 82 a4
00000010 82 e6 82 a4 90 d4 82 ad 82 c8 82 e8 8d 73 82 ad
00000020 8e 52 8d db 81 42 0a
00000027

EUCと番地が違うだけという感じ。(SJISの方が元だし逆か。)

以上のように並べてみるだけでも結構面白いかも。

元々言語学日本語専攻だったという事もあり、
かなり以前から形態素解析に対する違和感を感じていた。
(※アンチ生成文法論者だったという事も有るが。)

特に形態素の指定の仕方と分類の仕方が特にである。


日経BP曰く、

自然言語で書かれた文を「形態素」に分割する技術のこと。
形態素とは言語として意味を持つ最小単位を指す。
形態素に分割して,品詞を見分ける。

象徴的に取り出してみたが、要点は以下の通りである。

指定の仕方としては、「言語として意味を持つ最小単位」という指定はいいのだが、
最小の意味合いが曖昧でどうとでも取れてしまう所に疑問があった。

いくつかの疑問はあるが、一例として「都道府県」、「大中小」などをあげてみる。
mecabで解析してみると以下の通りである。

都道府県 名詞,一般,*,*,*,*,都道府県,トドウフケン,トドーフケン
EOS
大中小
大 接頭詞,名詞接続,*,*,*,*,大,ダイ,ダイ
中小 名詞,一般,*,*,*,*,中小,チュウショウ,チューショー
EOS

同じような言葉の使い方であるが複数の取られ方をしている。

この場合、形態素は「都」、「道」、「府」、「県」であるのか、
「都道府県」であるのか曖昧である。

分類の仕方に関しては、最小単位に分けた後、無条件に品詞分類をしていることである。
特に、何をもってして品詞とするのかをあまり煮詰めずに「品詞」としているところに疑問を持つ。

橋本文法の位置づけには
昔から色々と異論が有るのだがその辺りがまったく考慮されていないところに違和感を感じる。

また、単語(形態素でも良いが)のメタ情報が品詞だけというのも貧弱すぎると思っていた。

これが今まで思っていた形態素解析の違和感である。

先日、言語解析の調べ物をしていて、KOTONOHA
面白い言語解析を用いていることを知った。

言語単位の指定方法である。

詳しくはKOTONOHAのサイトを参照してほしいが、
単語のメタ情報を格段に増やしたところにポイントがあると思う。

この、文献を見つけた時、長年の引っ掛かりがかなり解消されようやく
「形態素解析」(というのも怪しいが)が自分の中に落ちてきた。

解析辞書も公開されている。unidic

mecabに対応していないところが痛いところであるが、解析してみるのも面白いと思う。
とりあえずしばらくはこの辞書で遊んでみる。

特に重要なのはエンジニアとしてと言うこと。
エンジニアとしてサービスを創りたいという事である。

その意味することは、自分としては、どの様に作られているかが
サービスを成り立たせる上で重要であると考えている。

サービスという概念が色々なものを含んでいるのは事実で、
何を持ってしてサービスということかは人それぞれであるが、
昔からサービスとは表面に見えること、直接肌で感じられる事が
すべてではないと思っている。

通り一遍使用しただけで評価されてしまうものにはどうしても
違和感を覚える。使い込んで使い込んで、乗りこなすのが大変で、
でも手懐けると最高のパフォーマンスを発揮するもの、
使い手側にそれなりに能力を要求するものが最高のサービスだと
思っている。

近しい物として、Satoshi Nakajimaさんが盛んに
「おもてなし」という言葉を使って表現されているサービスが
それに当たるかなと思ったりもする。

提供されるサービスの何たるかを理解するだけの感覚の鋭さを
必要として初めてそのサービスの良さを実感できるというサービスが
自分の好みなのである。

ディズニー然り、アップル然りである。
リッツカールトンは未経験の為知らない。

このようなサービスを立ち上げたいと思うのだが、
作り込まれた世界を頭の中でふわふわと夢想しながら、
右往左往としているのが現状である。

そのうち何か思いつくかも。

でもその為にはアンテナを最大限に伸ばし、無駄を恐れずに感性を
磨いていこうと思う。そして今年の目標として感じたものを
自ずから発信していこうと思う。

技術ネタだけだとどうにも勉強が追いつかないので細々と戯言を綴ろうかなと。

で表題の件。

勝間さんの行っている事による生産性の向上については概ね同意なのだが、
根本的に考え方が違うので自分に対する適用は不可能だよなと。

要約して「ググレカス」とか、人と会おうとか、情報発信は必要とか、
健康維持に努めろとかそこいら辺は同じ。

でも、根本的に違うこと、勝間さんは物事に於いて1を100にする人だよなと。
自分は可能な限り0を1にする事を望んでいると言う事。

もちろん、1を10にする事も大変困難な中で100にしてしまうので
非凡なる才能を持っていることは確かなのだけど、
そのような才能にどうしても興味をもてない。

無を有にする事は膨大な無駄の中から知力、体力、時の運で辛うじて
発生しうるものなので無駄を極力排除する勝間メソッドにかかってしまうと
ほぼ全否定になってしまう。

そう言った意味で勝間メソッドの考え方のみ拝借。(拝借するまでも無いけど。)
手段は無駄を可能な限りし尽くすという所で愚直に片っ端からやり倒すしかないのかな。

繰り返して繰り返して。

ウェブページ