2003年03月の記事
全23件 (23件中 1-23件目)
1
-
聖徳太子
この数日間、日記を書くのを忘れていた。というか、ちょっとあれこれ気力をなくしていたので、ネタを収拾する気も起こらず、書く気が起こらず・・・というのが正解なのだが、まあ、気分を改めて書き始めることにしようっと。ということで猛烈な勢いで、数日分の日記を書き込もうとしたが、やっぱりめんどくさくなったので途中で止める(笑)。『梅原猛著作集 ２ 聖徳太子』小学館刊 \5，300が出ているようだ。梅原猛著作集は、いつか買いたい。聖徳太子自体すごく惹かれるものがあるのだが、梅原猛氏の書き物には、それ以上に惹かれるものがある。この人の書き物は、歴史的な信憑性がどのくらいあるのか知らないけれど、情熱があっておもしろい。勢いがあって、ストーリーがあって、ロマンを感じさせる。実際のところ、勢い余って、歴史的事実に反することも勢いで書いていることもかなりあるんじゃないかと思うが、まあ、別に事実に反することがあってもたいした問題ではない。個々の事実よりも全体の流れを読み解く姿勢の方が歴史はおもしろいと感じさせてくれる。もちろん、アプローチによっては、一つの事実の信憑性のみに焦点を当てて追求するものもあるだろうし、やり方によっては、おもしろいものもあるだろう。まあ、とにかく梅原猛氏の書き物はおもしろい。で、ちょっと検索してみたら、聖徳太子は、実在しなかったなんていう説があるようだ。『聖徳太子はいなかった 古代日本史の謎を解く』三一新書、石渡 信一郎著 \800。なかなか商業主義的な題名の付け方とアプローチだな。実際のところはどうか。『聖徳太子と東アジア世界』川勝 守著、\2，500 では、これがしっかり否定されているらしい(実在した根拠が書かれているみたい)。でも、実在したかどうかって、たいした問題ではないと思う。少なくとも、これに代表あるいはモデル化される人物がいたであろうから、別にそれはそれでいいのだ。聖徳太子って、なんでこんなに魅力的なんだろう。原因はいろいろあるだろうが、『聖徳太子はなぜ天皇になれなかったのか』角川ソフィア文庫、遠山 美都男著 \819、『「日出づる処の天子」は謀略か 東アジアと聖徳太子』集英社新書、著者 黒岩 重吾著 \640。こうした謀略に関するロマンかも、人を惹きつける大きな要因かもしれない。「謀略と悲劇」というのは、絵になるのだ。謀略、悲劇、怨念、やっぱりこういう文脈はおもしろいのだ。音楽の調子にはメジャーとマイナーがあるが、こうした書き物はマイナーモードの書き物だと言えるだろう。艶やかさよりも、むしろ陰鬱ささえも時にともなうけれどロマンと郷愁の観を誘うマイナーモード。その陰鬱さの中に心を躍らせるものがあるのかもしれない。Tchaikovsky のピアノ協奏曲みたいなものなのだ。陰鬱さから解放される部分でカタルシスを感じる。さてさて、何はともあれ、こういうところに惹かれると、やっぱり梅原猛に洗脳された私としては、藤原不比等を調べたくなってくるのだよな。ちょっと、歴史物にはまってみようかな・・・。んと、人工無能のキャラクターを考えるときに、人格に対してどういうパラメータを考えることができるか、というのが一つの焦点であったりもする。これは、人工無能自体のパラメータというだけでなくて、あるユーザのオブジェクトを作ったときに、履歴をどういう形で記録していくかということにもつながったりする。歴史にイベントがつきものであるように、人工無能との会話でも、なんらかの記録すべきイベントを設けた方がいいんじゃないかという発想なのだな。具体的には、おいおい書くとして、まあ、人工無能では非常に単純化されたインタラクションの履歴が蓄積されていくのだ。これをして人工無能へのフィードバックともいう。フィードバックをどうやって単純だけども広がりのある方法でかけていくか・・・。
2003.03.31
コメント(0)
-
三顧の礼 (なんだか人工無能)
『銀河英雄伝説』の DVD がやっとすべて届いて喜んでいるんだけれど、PS2 が具合悪いまま放置されているので、DVD 見られないのだ。ゲームはできる状態なので、三国志のゲームでも買ってきてふとやってみようかと思ったのだけど、とりあえずやめておく。まあ、それはどうでもいい。「三顧の礼」 といえば、劉備玄徳と諸葛孔明の三国志のお話だが、こんなフィギュアを作っている人がいるのだな。すごい。キャラクターを視覚化すると、頭の中の想像の世界とはまた違った楽しい世界があるのだな。で、考えてみたら、ここでは Python は直接使わないことにしたので(コードはここでは出さないことにしたから）、シリーズも、Python をはずしてみる。考えてみたけどいい案が浮かばないので、なんだか人工無能というシリーズにしてみた。で、いつものように「三顧の礼」を形態素解析をしてみると、次のように解析された。三顧の礼三顧 名詞，一般，*，*，*，*，三顧，サンコ，サンコの 助詞，連体化，*，*，*，*，の，ノ，ノ礼 名詞，一般，*，*，*，*，礼，レイ，レイで、何を思うかというと、三 名詞，数，*，*，*，*，三，サン，サン台 名詞，接尾，助数詞，*，*，*，台，ダイ，ダイの 助詞，連体化，*，*，*，*，の，ノ，ノ車 名詞，一般，*，*，*，*，車，クルマ，クルマ「三台の車」だと次のように解析されるんだけど、「三顧の礼」の場合は、「三顧」が一語になるのだよな。不純じゃないか。数とその数え方という解析をするのなら「三」「顧」となぜなぜならないのだろう。「一顧」や「二顧」が存在しないのが、用例として明確であり、それ以外は現実的に意味を持たないから「三顧」だけを登録したとしよう。そうすると、「一顧の礼」「二顧の礼」が同様に存在しないことも明らかであるから、むしろこれは、「三顧の礼」と一語で登録した方がいいのじゃないか。いや、形態素解析はあくまで形態素解析であって、正しく形態素を解析することが目的なのだから、「三顧の礼」と一語にしてしまうと、ちょっとまずいでしょ、と思うなら、さて、最初に戻って、それじゃあ、「三」「顧」「の」「礼」と解析するのが正しいでしょうという気がするんだが・・・・。やっぱり、辞書というのはある意味、ご都合主義にならざるをえないとするなら、目的に応じて、カスタマイズをどうやっていくか、というのは非常に重要な問題なんじゃないかと思うのだ。
2003.03.27
コメント(0)
-
餡こものを食べる (なんだか人工無能)
ときどき、無性に餡こ（アンコ）が食べたくなる。そうすると、コンビニで安っぽいあんこが入ったものを買ってきて食べる。でも、これだってものがないのだよな。おいしいアンコが食べたい。あんまりおいしくないものを食べると、満足感がなくて、もっと食べたくなるのだ。やっぱ、デパ地下でも行って買ってこようかな・・・。ちなみに「あんころ餅」は、日本語形態素解析器の MeCab や ChaSen の辞書にちゃんと載っているのだな。でも「あんころもち」だと、ぜんぜんだめだめの結果になる。トーくんの辞書を作ろうかと思ってちょっと、いろいろ調べながら、やっぱり、たとえば「食べ物」という属性を形態素解析の結果にも入れてやりたい気がしてきた。辞書を改良するときに、属性ベースで、たとえば、「食べ物」に焦点を当てて、がーっと、これに対してまず属性をつけてしまうとかやりたいと思い始める。そうすると、属性のファイルを作って、ここにどんどんと食べ物の名前を書き込んで、そのファイルを今度は、形態素解析器の辞書の方にがーっとまとめて反映させるという方向性がメンテナンスしやすいんじゃないかなと。それにしても、「あんころもち」とひらがなにすると、辞書に載っていないから、解析がこけてしまうのはしょうがないとして、ここまでグチャグチャになるのか・・・。これはいくらなんでもなんだなぁ。「あ」「ん」「ころ」がそれぞれ非自立になっているところは、立派といえば立派なんだろうけど、ひらがな文字列の非自立語が連続している場合は、もしかして解析がこけている確率が高いのかな。大量にやってみると何かおもしろいことが分かるかもしれない。こけている確率が高いのであれば、一定の条件でつないでしまって未知語にしてもいいだろうし。あんころもちを食べる。あ 動詞，非自立，*，*，五段・ラ行，体言接続特殊２，ある，ア，アん 名詞，非自立，一般，*，*，*，ん，ン，ンころ 名詞，非自立，副詞可能，*，*，*，ころ，コロ，コロもち 名詞，一般，*，*，*，*，もち，モチ，モチを 助詞，格助詞，一般，*，*，*，を，ヲ，ヲ食べる 動詞，自立，*，*，一段，基本形，食べる，タベル，タベル。 記号，句点，*，*，*，*，。，。，。「ころ」の名詞，非自立，副詞可能っていうのは、何なのだろう。「４月ころ」とかの「頃」なのかな。「いちころ」とかの「ころ」ではないだろうな。やっぱり、ひらがなには弱い。あー、でも人工無能とかで会話していたら、けっこうひらがなにはつよくないとつらいときもあるんだよな。「アルジャーノンに花束」をプロジェクトとして、ひらがな文字列に強い形態素解析器も欲しいかもしれない。いちころい 動詞，非自立，*，*，一段，連用形，いる，イ，イち 動詞，自立，*，*，五段・ラ行，体言接続特殊２，ちる，チ，チころ 名詞，非自立，副詞可能，*，*，*，ころ，コロ，コロまあ、何にせよ、一応、「餅を食べる」ということ自体は、この解析結果からでも分からんことはないな。どうでもいいが、うまいアンコが入ったものが食べたい。
2003.03.26
コメント(0)
-
温故知新
温故知新。故きを温ねて新しきを知るのだ。24日の日記が「うこん」黒砂糖で、今日は「おんこ」。「ｘんこ」シリーズにしようかな、というのは、冗談。コンピュータの世界は、ものすごく早い進歩で10年前のものなど、古くさく感じるものかもしれないが、実際のところ10年以上前から存在するものをよく知ることは、やぱり意義があるなぁと感じる。というより、この十数年、根本的なところでは、それほど大きな進歩はないというのが本当かもしれない。というか、ほんとの最先端のところには、なかなか手出しできないから、ちょっと古いところから始めようという感じかな。歴史を振り返ってみて、たとえば、もし、あのとき「xxx だったら」という風に考えることがないだろうか。過去の一コマをちょっと変えるだけで、今が大きく変わるようなことだって想像できるだろうし。もしあのとき、xxx だったらと自分の人生を変えるのは難しいけれど、もし、あれが流行らずに、これが流行っていたら、というのは、コンピュータの世界であれば実現できるわけだし。で、どこに戻ってみたかというと、茶筅などが下敷きにしている計算機用日本語辞書ＩＰＡＬにまで戻ってみた。まあ、これはかなり前にダウンロードしてあったのだけど、単語数が少ないし・・・と思ってちゃんと見てなかったのだ。で辞書をよく眺めてみると、人工無能用に使えそうな情報がここから引き出せそうだなという気がしてきた。せっかく使えるものは使わんともったいないものね。「その２冊の本は間が辞書だ。」とか、けっこう壊れた日本語も入っていて楽しい。え、褒めてない？ 実際に使われている日本語は、けっこう壊れているものが多いから、そういう壊れた文を見るのも役立つこともあるんじゃないかな。変な日本語もたくさん入っているだろうけど、例文や属性が入っているから、やっぱりよい。これはやっぱり使わないともったいない。でも、かなり加工してやらないと使いにくいな・・・。
2003.03.25
コメント(2)
-
うこん黒糖
コンビニで「うこん黒糖」という妙なものを売っていたので食べてみた。沖縄産の「うこん」(ターメリックだな）と、黒糖を配合したもので、ちょっと不思議な味がする。ウコンってショウガ科の植物だったのね、知らなかった。ときどき米を炊くときに、ターメリックをパラパラと釜の中にいれて炊いてやると、ちょっと香りのある黄色いご飯がたけて、これにレトルト(笑)のカレーをかけて食べたりしてるので、ターメリック＝うこんという存在は知っていたのだけど（これけっこういけるのだ）。で、うこん黒糖は、あまりに奇妙な味なので、また買ってみよう。鉄分(1.7mg)、カルシウム(42.0mg)、カリウム(273mg)、リン(11.9mg) が含まれていて、267kcal。まあ、たいした量じゃないのだけど(70g)、これ全部いっぺんに食べたら気持ち悪くなるので、チョコレートとかポテトチップスとか食べるよりカロリーは低いな。ん、いや半分一気に食べたら気持ち悪くなった(^^;;そういえば、やっとのことで 5000アクセス突破。
2003.03.24
コメント(0)
-
トンネルを
さえないときは、ひたすらさえない、ダメなときは、ほんとにダメなものだ。あー、早く暗くて長いトンネルを抜けたいものだ。なんて書くと、「早い」がどこにかかっているのか曖昧になるから、あー、暗くて長いトンネルを早く抜けたいものだ、とでも書かないといけないかな。日本語を分かりやすく書くためには、修飾語と係り先をなるべく近づけてあげた方がいいわけだけど、気分をつづるためには、そうではない方がよかったりもするのなだ。「あー、早く暗くて長いトンネルを抜けたいものだ」「あー、早く、暗くて長いトンネルを抜けたいものだ」「あー、暗くて長いトンネルを早く抜けたいものだ」曖昧性はだんだんと下の方に行くにつれて減るかもしれないが、気分が違うのだよな。だいたい、「早い」が「トンネル」に掛かるなら「早くて暗いトンネル」って書くはずだから、あんまり違和感がないといえばないのだな。「あー、早く抜けたい。この暗くて長いトンネルを」こんな風に倒置してやった方が気分は近い。でも、こんな風に書いた方がいいのかもしれない。「あー、早いところ、この暗くて長いトンネルを抜けたいものだ」言葉と言葉の心理的な距離を考えると、これが一番近いのかもしれない。こういう書き方であれば、係り受けの曖昧性は減る。ただし、「あー、早いところ」というのは、文法的にはいったいどういう扱いになるんだろう。「早いところ」っていったい何なんだ？「通報を受けた警官がそこに駆けつけたところ、すでに犯人は逃げたあとだった」「その商品は通常は15000円のところ、割引で 10000円で販売されていた」「彼の書いた文書を解析したところ、非常に語彙が豊富であることが分かった」「私がよく行ったところは、すでに廃墟と化していた」さて、「トンネルを抜けると」を Google で検索すると、約17，600件もあった。『「雪国」あそび』が目についた。この フィクションにおける Voice（声）のページはおもしろいかもしれない。マイケル・オーロフスキー氏の引用の一部“controlling consciousness” behind your work" の "controlling consciousness" というのは、なんだか惹かれる言葉だ。ん、ふと考えてみると「トンネルを抜けたい」って変な響き。これは、壊れた日本語に限りなく近いかもしれない。
2003.03.23
コメント(0)
-
ZODB のパフォーマンス
新しい炊飯器をもらった。今まで使っていた炊飯器は10年ぐらい前から使っていたのだ。で、早速、新しい炊飯器を使ってみる。最近の炊飯器ってほんとに、うまく炊けるのだな。ご飯がよりおいしく感じる。ビックリしたのは、内釜の厚みと重さ。チタンコートの遠赤厚釜とか書いてあるな。ふーん、これがおいしさの一つの理由なのね。ってコマーシャルとかで見ては知っていたんだけど、いざ内釜を持ち上げてみると、やっぱりズッシリという感じでビックリしてしまった。時代は変わるものだ。まるで浦島太郎みたい(笑)。○ ZODB のパフォーマンス先日、ZODB (Z Object Database) が意外に高速でびっくりしたということ書いたが、もうちょっと、どれくらい使いものになるのかを確かめてみることにした。基本的には、キーとその値という構造を考え、どれだけ高速にデータを登録でき、また引き出すことができるかということを確認してみたいと思う。というわけで、その結果を、傀儡師の実験室に記録しておいた。要するに、MySQL の書き込みと、ZODB の書き込みとで比較をしてみたわけ。ZODB の能力をもう一度確認してみようと思ったのだ。結果だけここで書いておくと、十分満足できるものだということ。遅い遅いと言われる割には、そんなに遅くない。なんで遅いって印象を持つかっていえば、これは、Zope がいけないんじゃないかなぁ。Zope がなければ、そもそも ZODB はなかったわけだけど、実は、ZODB をデータベースとして単体としてみたときには、Zope が ZODB の足を今ひっぱっているような気がしないでもない。複数のユーザがデータベースに同時にアクセスしてコンフリクトが発生するような場面がなければ、キーと値の登録においては、MySQL と張り合える程度の書き込みパフォーマンスがあるということ。やっぱりやってみるもんだな。
2003.03.22
コメント(0)
-
バリエーション
オープンソースがこれほど普及しているにも関わらず、同じようなことに対して、同じようなソフトウェアが次々に作られる。通常、「車輪の再発明」とこれを呼び、好ましいことであるとはとらえられない。その一方で、「車輪の再発明だけど」というスタンスをとりながらも、さまざまなバリエーションが登場する。まったく同じ要求であれば、すでにあるものを使った方が遙かに効率的である。にも関わらず、さまざまなバリエーションが登場する。たとえば、主として HTTP プロトコルを扱うサーバ、つまりウェブサーバであれば Apache がほぼ標準的な地位を占めているのだから、新たに似たようなものを作るより、これをみんなで使った方がいいじゃないかと考えられる。これには、みんなで使い込んで、改良していくことによって、人の労力や知識が集約されるというメリットがある。なのになぜバリエーションが生まれるのか。こうした背景には非常におもしろいものがある。たとえば、Microsoft が Internet Information Server といった独自のウェブサーバを作り、これを広めようとすることについては、商用の製品を扱っているのだからバリエーションとして自社の商品を開発し、それを広めたいと考えるのは、道理にかなっており、さまざまな商用製品のバリエションが生じることに関しては、当然といえば当然である。オープンソースの場合、「売る」という行為が直接には伴わないのだから、直接に売れないものをなぜバリエーションを作ってしまうことになるのか。これを解読する一つの視点は、オープンソースの場合も商業と完全に切り離すことはできない、ということである。ソースを公開し、自由に改良できるように配布している一方で、それを自社の主力製品として何らかの商売を行っている場合が多々あるからだ。たとえば、メールサーバの Sendmail、データベースの MySQL や、ウェブアプリケーションサーバの Zope などをはじめとして、どこでどういう形で収益を得るかは別として、オープンソースだけれど、ちゃんと商品として扱うことができるという文脈がある。Apache にしても、やっぱりそういう文脈はあって、IBM などは Apache を利用しながら WebSphere のようなプロプライエタリな製品を作って販売しているし、他にも何らかの形で付加価値をつけるなどして、商品として販売している例はあるだろう。つまり、商業的な側面からみたとき、オープンソースは、自分の製品を広げて広く使われ価値を上げるためのひとつのゲームなのだといえる。だって、収益にならなかったら、会社がそれに取り組むことができないのは当然といえば当然の話なのだ。会社がそこに資金や人を投じているということは、それが最終的にモノとして売ることが可能であるか、サービスとして売ることができるかを別にして、なんらかの収入源につながることが前提とされるのは当然の話。だから、やっぱり、自分の収益が最大になると考えられるものに対して投資をするのは、これまた当然の話なのだ。で、どういうものが収益性が高くなるかといえば、自分の技術力を発揮しやすいところになるだろう。つまり、自社が作ったものが、通常、一番自社が理解しているわけだし、さまざまなルールを自社がコントロールすることも容易になる。Java なんてまさにそういうものだ。いろいろな会社がバリエーションを出しているけれど、やっぱり、一番影響力が強いのが Sun Microsystem ということになる。で、まあ、そういうところからも、バリエーションを作り出し、自分に有利なルールを作り、ゲームをしていくというのは、自然な成り行きなのだ。だからバリエーションはどんどんとできてくる。バリエーションを作らないとしたら、それは、de facto化(標準化)しているもの対抗する力がない場合に限られるといってもいいかもしれない。そうでなければ、バリエーションを作り出せ、というのが、実は真実なのかもしれない。Linux のディストリビューションなんかもそういうところがあるだろう。で、これとは別の文脈に GNU がある。GNU は、基本的に車輪の再発明をできるだけ避け、ほんとうの意味でリソースを共有していくものだと思う。だから、こそ知的所有権を行使して、それによって他者を縛ったりすることは排他されるし、フリーであることが徹底的に追求される。ソフトウェアの理想的原始的共産主義といえるものかもしれない。政治形態としての共産主義というものは、完全に資本主義に敗北してしまったけれど、ソフトウェアに関しては、その原初的理想が生き残っているともいえる。これは非常におもしろいことだといえる。リチャードストールマンはある意味でソフトウェアの世界におけるレーニンみたいな存在なのかもしれない。ストールマン亡き後に、GNU が同発展していくかというのが非常に興味深いものがある。一代目のカリスマを失ったときに初めて、その組織が本当に生き残っていくかが試されるからだ。まあ、まだすぐに亡くなってしまうことなどないだろうが、いずれはそのときが来る。GNU Public License というのは、非常に過激なライセンス形態ともいえるが、GNU の根幹をなすのがライセンス形態だといえる。けっきょく、この GPL というライセンス形態のおかげで、リチャードストールマンの死後も GNU は生き残っていくことにはなるのだが、実にすごいことをしたと思う。ただし、あと100年すると、GNU は敗北し、新規のソフトウェアのライセンスとしたはメジャーな位置を占めなくなっていると思う。縁起でもないという話ではあるが、純粋な GPL にしたがうソフトの占める割合より、より劣った形のデュアルライセンスが主流になる。つまり、フリーを強制するライセンス形態だけでなく、クローズドにすることも可能にしてしまう形態のいずれかも選択できるというのが主流になるわけだ。GNU の文脈からすると、これはあまり好ましいことではないしけれど、それが歴史というものだろう。ストールマンの存命中にどれだけの基盤を作ることができるかということが、GNU の将来のソフトウェアに対する影響力の生存期間を決める一つの要因になるかもしれない。GNU のソフトウェアの延長線上にあるのが知的財産権の行使の否定ということにあるわけで、ここがもっとも重要なところでもある。今、先進国は知的財産権をいかに行使して、途上国に対しての優位性を確保しようかとやっきになっているところだし、日本もその中の一員なわけだ。生きていくためには財産を必要とするという根本が解決されない限りは、その所有する財産をいかに有効に使うかということを追求するのもまた人間の姿であるかもしれない。理想と現実の狭間で、どのような形態を作り出したとしても、やはり、富める者は益々富み、そうでないものは・・・という構図は基本的に変わらない。それでもやはり貧富の差を少しでも縮めるためには、GNU のような仕組みは特にソフトウェアや知的財産に関する分野で必要になるというのもまた真実だろう。物質主義がその頂点を極めていく過程で、共産主義が生じたように、知的財産主義が頂点を極めていく過程の中で GNU は生まれた。政治形態が社会民主主義といった中間的な形態を求めたように、ソフトウェアの世界ではいわゆるオープンソース(フリーソフトではない)が生まれた。結局のところ、一番強いのはお金をたくさんもっているやつなわけだが、それでも、この一種の抵抗運動はバリエーションを作り出しながら続いていくことにはなるだろう。バリエーションというのは、非効率的な側面がある一方で、世界を広げ、自分のほんとうのニーズにあったものを作りたいという欲求の具現化したものでもある。非効率性を持っていたり、純粋性に欠けるとしても、それは少しでも、自分に有利なゲームを進めるための必死の試みであり、バリエーションなしにこの世が動くことはあり得ないのだ。そのバリエーションの中から、次世代の主流が登場するのもまた確かなことだし。結局のところ、人間の作り出すものに完全はあり得ず、いくら今は他に比べて優位性を保っていても、それが将来に渡る完全な優位性を主張できるようなものなどどこにもない。バリエーションをいかに包含していくかが、人が気持ちの上で豊かに生きていくために必要なことだったりするのかもしれない。人間の世の中というのは、複雑で難しい。
2003.03.21
コメント(0)
-
分散処理をしてみる
トーくん の 辞書作成の際のヒント、Ｔｉｐｓ を読んでちょっと辞書を作って 「くぐつくん」 を賢くしてあげようと思ったのだが、面倒になった。「おみくじ辞書」「血液型辞書」を公開しているサイトがあったのでとりあえずダウンロードしてみる。あと、リンク集にあるサイトも眺めてみる。辞書の作り方のイメージは分かった。うーむ、とりあえずは、@Nifty のページから一個一個追加しよう。面倒だからやっぱり一括登録も覚えようとも思うが、辞書作りが面倒ね。でも、それをやらなきゃ意味ないしな。おもいっっきりマニア目指そうかな。で、あと、傀儡氏の実験室の方で、ちょっと遊んだ。何を遊んだかというと、XREA のサーバには日本語形態素解析器 MeCab など、当然のようにインストールされていないだろうし、import MeCab として Python から MeCab を使える可能性などほとんどないに等しい。でも、それだとやっぱり寂しいので、別の自分のマシンにリクエストを送って、そちら側で形態素解析をさせて結果を戻すということをしてみた。まあ、裏側でいったり来たりするわけで高速なレスポンスは期待できないものの、どんなに重い処理でも自分のマシンなら人に迷惑をかけることもなく処理させてしまうことができるし、自分のマシン自体は公開する必要がないので、これいけるなーということをやってみたわけ。これで、人工無能用に小さいデータをやりとりするだけであれば、事実上何でもできるようになった (さすがにでかいデータをあまりやりとりしてたら警告をくらうだろうけど、会話のデータだけならたいしたことないし)。これでおもしろいことができる可能性が高くなった。が、肝心のプログラムはぜんぜん進んでいないではないかという話がある(^^;;
2003.03.19
コメント(0)
-
バニラをくだけ！
バニラをくだけ！ WAVE ウェーブ という雪印のアイスを食べた。208kcal なり。やっぱりアイスは冬だよね。バニラアイスの中にソーダ氷が入っているもので、なかなかおいしい。でも「もうほんのちょっとだけ」ソーダ氷の量が多い方がいいかな。雪印の関係者の方がいらしたら、お願いそうして（笑）そういえば、人工無能おしゃべりキャラ「トーくん」登場！ をあっちに入れたんだけど、ぜんぜんお話してあげてないので、誰かお話にいってください。変な絵のところをクリックするとお話できます。有料サービスになったら、さすがに少し有効活用しようかと思っていたのだけど、「無料期間延長！2003年６月末まで無料でご利用できます。」 だって。もう少しほっとこ(笑)。こういうマーケティングって難しいものなのだろうな。あんまり流行るとサーバ重くて大変だし、あまり使われないのもなだろうし、バランス難しいだろうな。デフォルトトーくんの辞書グループ一覧とか、辞書作成の際のヒント、Ｔｉｐｓとかのページちゃんとあったのね。トーくん情報交換ＢＢＳとかあるのね。少しのぞいてみよう。ランキングとかもできてるのね。ランキングってどの程度使われると載るんだろう。私のはぜんぜん使われてないから、絶対載らないのは分かるんだけど。まあ、とりあえず @nifty の方、このページご覧になったら、こういう情報を多少くどくていいからトーくんのメールとかに書いて欲しいなー。一週間誰も話さなかったら、「誰も話しに来てくれない、さみしいよー」とかいう形でオーナーを召還するぐらいのこともしたらいいし。今、使われているキャラクター数 885 あるのね。月200円だと、177，000円か。今のところ大赤字だろうなー。ただ、これって別の意味もあって、@Nifty の課金制度を使ってもらおうという意図もあるだろうから、仮に課金制度の１ユーザ獲得コストを 3，000円とすると、3000 * 885 = 2，655，000円の効果ってことになる。ただ、全員が新規ユーザのはずはないので、そこまでも経済効果はないだろし、焼け石に水って感じもする。そうすると、次に何をするかといえば、無料でいいやって割り切っちゃうと、会話の中に出てきたキーワードとかをマイニングして、マーケティング資料にしたりとか、辞書構築の際の参考にしたりとか、あるいは、会話の中に広告を含ませたりして、そちらから収入を得るとか、そっちの方向があり得るところ。でもどっちかっていうと、最終的には、これをもう少し高度にして、企業のページで使ってもらったりしてもう少し高い料金でサービスできるようにとか、そういうのも視野に入っているのかな。まあ、短期的には儲からないだろうけど、長期的に見ると、こういうのは大企業がやる分には、ノウハウたまっていいだろうな。実際に何をユーザが入力するかを知るのはすごく有効。作っている人は何より、実践的な経験値が上がるし。大規模でやると、小規模だと見えないものが見えてくるのね。あと、だんだんと、入力される内容が変化していくのもサービスが１年以上続けば分かるはずなので、チェックすべきだろうし、って私が見られるわけじゃないから、どうしようもないんだけど。見せろっていったって見せてくれないだろうし(笑)
2003.03.17
コメント(0)
-
ZODB が意外に速く (Python で人工無能)
「ことばの散歩道」というページを見つけた。なぜ「いっぽん、にほん、さんぼん」なのか？とか、 「立直」はなぜ「リーチ」と読むか？とか、読み物として楽しく書いてある。動詞の活用は、どのように変わったか？nのあたりもおもしろい。この方、高校の国語の50才台の先生みたい。最近 50 才とか聞いても、あんまりトシ～って感じがしない。そのぐらいの歳には、自分もあっという間になっちゃうのかなとか思えるようになった。だいたい人生80年ぐらいだとすると、40才になってもまだ半分だものね。そうやって考えると、まだまだ生きなきゃいけないのか、フーって感じ。先は長いのだよな。○ ZODB が意外に速く (Python で人工無能)ZODB (Zope Object Database) が思ったより速くて驚いた。結論から言うと、MySQL で MeCab で使っている形態素解析用の辞書を全部、見出しをキーにして、その他のフィールドをこれに対する値として登録したところ、5分程度で終わってしまった。MySQL だと 10分程度だったので、それより速かったことになる。うーん意外。ただ、条件は同じじゃないので、MySQL の方も同じようなことをすれば、さらに速くなりそうな気はする。とにかく一概に比較はできないけど、十分な速さを持つということが分かって満足。これは下手に MySQL を使うより、作り方によっては ZODB を使った方が遙かに効率的なこともあり得るというショッキングなテスト結果でもある。とはいえ、自分でやっておいて信じられない。もう一度、プログラム自体両方見直して、やり直してみよう。何かの間違いかもしれない (^^;;とにかく、ちょっと積極的に ZODB を使ってみることにした。いったん作られたデータにを検索するときは、インデックスをメモリ上に持っているから速いし (その分メモリを食うのは言うまでもない)。ただし、起動は時間がかかるという難点はある。数MBのインデックスを最初に読み込むことになるからだ。まあ、今想定している人工無能の場合、いったん起動したらそのまま使い続けるという使い方なので、これは問題ない。ZODB のデータの粒度は、オブジェクト指向だけあって大きく、元データの倍の大きさになってデータベースサイズが約 80 MB に膨れあがってしまったが、まあいいとしよう。で、とにかく人工無能のイメージとしては、がんがんと、対話や処理途中のデータを ZODB 上に保存していき、時々、睡眠時間をとってバッチ的に頭の整理をするというような感じ。ゆえに、文脈とかもある程度考慮する。文脈をどういう形で表現して持たせるか、というのは難しいところかもしれない。
2003.03.16
コメント(0)
-
鬼武者3
「鬼武者3」の制作が始まっているのか。mpeg movieが見られる。うーむ、それにしてもジャン・レノまで登場とは。発売は来年３月だからまだまだ先。まあ、楽しみに待つことにしようっと。そういえば、「鬼武者2」は複数のシナリオが用意されていて、何回もやらないとシナリオを全部クリアできないのだけど、まだ、そのシナリオ達成率がまだ100%にならないままなのだ・・・。来年までにクリアしよう(^^;;って、ことで今日は、ちょっと「鬼武者2」でもしようっと。
2003.03.15
コメント(0)
-
白いヨットの帆
IBM のサイトを見ているうちに(Notes の Web版が出たというので見に行ったら迷子になって(笑)、ついでにふらふらしていたら 言語的注釈付け のページを見つけた。「白いヨットの帆」は、「白い」が「ヨット」に係って「ヨットが白い」のか、「白い」が「帆」にかかって「帆が白い」なのか、どちらか判定するのは文書を書いた本人でなければ分からないことがあるから、これを白い<seg>ヨットの帆</seg> として、プログラムに教えてあげるためのタグとして、LAL (Linguistic Annotation Language) という仕様を作ってやってますよという話。「大きな黒い瞳の女の子」「美しい水車小屋の娘」とかよく例に出される、係り受けのあいまいさについて最初からタグをつけちゃうという反則ワザ。この発想自体は10年以上前から確実にあったものだし、たいした話ではないのだが、これをなんとか実用に結びつける技術にしようとがんばっている人がいるわけだなと。いわゆるセマンティックウェブとか関わりあう世界かな。それにしても、題名だけ見て来た人に殴られそうな内容だな（笑）で、とにかく、いちいち手でタグをつけたら大変だから専用エディタでとなって、XML エディタみたいなやつを使うのかな。まあ、それはよいとして、やっぱり現実的にはつらいだろう。曖昧性を持つ文だけをピックアップしてくれて、それにタグをつけていくというような形にでもしない限りは。でも、最近のウェブは自動的に DB から抽出したフィールドを使って構成する場合もあるから、そういうものを対象とすればあながち非現実的でもないけど。どの辺にターゲットをおいて今やってるんだろうな。「翻訳の王様」の機能強化のためなのかセマンティックウェブとかと関わるところでやってるのかどっちなんだろうかと、なんとなく興味を持ったので今日は取り上げてみた。で、もう一つの例として、山田は<lal:w sense="hum">長崎</lal:w>と<lal:seg>神戸へ行った</lal:seg>。 があげられているのだけど、「長崎」というのが人であればたしかに難しい。というかそういう悪文を書くなよなという世界でもあるが、実際そういう文章はたくさんある。で、いつもの MeCab で形態素解析をかけてみると次のように解析される。「と」は「並立助詞」で、「長崎」と「神戸」が地域名として解析されるので、たぶん、この結果を使って係り受け解析を行えば、長崎と神戸が並立であることを認識できるんだろう。確率的に見たら、たぶん、このようになっていた方が正しい確率が高いからいい。山田は長崎と神戸へ行った。山田 名詞，固有名詞，人名，姓，*，*，山田，ヤマダ，ヤマダは 助詞，係助詞，*，*，*，*，は，ハ，ワ長崎 名詞，固有名詞，地域，一般，*，*，長崎，ナガサキ，ナガサキと 助詞，並立助詞，*，*，*，*，と，ト，ト神戸 名詞，固有名詞，地域，一般，*，*，神戸，コウベ，コーベへ 助詞，格助詞，一般，*，*，*，へ，ヘ，エ行っ 動詞，自立，*，*，五段・ワ行促音便，連用タ接続，行う，オコナッ，オコナッた 助動詞，*，*，*，特殊・タ，基本形，た，タ，タ。 記号，句点，*，*，*，*，。，。，。でも、これを「山田はカールスモーキー石井と神戸へ行った。」とすればどうなるだろう。カールスモーキー石井は、人名しか入っていないから、山田とカールスモーキー石井は、神戸へ行った、となるのかな。形態素レベルで見ると、この場合もやっぱり「と」は「並列」になるのね。地域名か人名かの違いしかない。山田はカールスモーキー石井と神戸へ行った。山田 名詞，固有名詞，人名，姓，*，*，山田，ヤマダ，ヤマダは 助詞，係助詞，*，*，*，*，は，ハ，ワカールスモーキー石井 名詞，固有名詞，人名，一般，*，*，カールスモーキー石井，カール スモーキーイシイ，カールスモーキーイシイと 助詞，並立助詞，*，*，*，*，と，ト，ト神戸 名詞，固有名詞，地域，一般，*，*，神戸，コウベ，コーベへ 助詞，格助詞，一般，*，*，*，へ，ヘ，エ行っ 動詞，自立，*，*，五段・ワ行促音便，連用タ接続，行う，オコナッ，オコナッた 助動詞，*，*，*，特殊・タ，基本形，た，タ，タ。 記号，句点，*，*，*，*，。，。，。次のような例と比べてみると、これはこれで間違いではないということか。「と」はどうあがいても、並立の助詞ということか。英語に直したら、地名として並列になっていたら and 相当だし、人とであれば with になるわけで、同じ「と」でも違いがある「と」が一緒の品詞になるというわけだ。つまり「私と彼は××に行った」と解釈すればよいということなのかな、並列ってことは。私は彼と外へ行った。私 名詞，代名詞，一般，*，*，*，私，ワタシ，ワタシは 助詞，係助詞，*，*，*，*，は，ハ，ワ彼 名詞，代名詞，一般，*，*，*，彼，カレ，カレと 助詞，並立助詞，*，*，*，*，と，ト，ト外 名詞，一般，*，*，*，*，外，ソト，ソトへ 助詞，格助詞，一般，*，*，*，へ，ヘ，エ行っ 動詞，自立，*，*，五段・ワ行促音便，連用タ接続，行う，オコナッ，オコナッた 助動詞，*，*，*，特殊・タ，基本形，た，タ，タ。 記号，句点，*，*，*，*，。，。，。それじゃあ、これはどういうことなんだろう。「誰と」の「と」は「格助詞、一般」になる。あなたは誰と行きますか。あなた 名詞，代名詞，一般，*，*，*，あなた，アナタ，アナタは 助詞，係助詞，*，*，*，*，は，ハ，ワ誰 名詞，代名詞，一般，*，*，*，誰，ダレ，ダレと 助詞，格助詞，一般，*，*，*，と，ト，ト行き 動詞，自立，*，*，五段・カ行促音便，連用形，行く，イキ，イキます 助動詞，*，*，*，特殊・マス，基本形，ます，マス，マスか 助詞，副助詞／並立助詞／終助詞，*，*，*，*，か，カ，カ。 記号，句点，*，*，*，*，。，。，。なんだか、この品詞体系によって損をしている気がする。けっきょく、基本的には既存の文法に基づいた品詞体系を IPADIC はとってしまっているから、いけないんじゃないだろうか。MeCab 自体別に、他の品詞体系とコーパスを用意して接続コストを計算しさえすれば継続的に使えるようなものだろうから、もうちょっとコンピュータ処理が減る方向で品詞体系を作り直すような人がいて欲しいものだ。って大変だからやらないんだろうけど、助詞の再分類、細分類をするだけで、形態素解析の結果だけを利用した場合でも、もっと有効な言語処理を行えるようになるはずなんだけど・・・。そういえば、最初の話とずれたままなので、もとに戻して、形態素解析結果から、確信度/正解予想が0-100%の値で簡単に取り出せれば、はずす可能性が高い場合は、他の処理を行うということをすれば、やっぱり、いろいろおもしろいことができる。たとえばタグづけをする場合にも、曖昧性が高いものだけ自動的にピックアップするとか。
2003.03.14
コメント(4)
-
もうちょっと R 言語
まだパラパラと見ただけなのでよく分からないが、けっこう R 言語はなじみやすいように感じた。とりあえず 気長に勉強，R 言語 は一通り眺めてみたが、ここからだけでも、あぁ便利そうだなというのが感じられた。やっぱり、インタプリタ形式で使えるというのもいい感じ。ちょこちょこと試していけるのがいい。グラフのプロットもインタラクティブにできるし。あと何がいいかといえば、NA (Not Available、欠損値) がちゃんとあるところ。統計ソフトだから当然なのだけど安心する。自分でプログラム組むと、そういうところも書かなきゃいけなくて面倒だもの。行列や配列の計算ができるのは、当然といえば当然なのだけど、やっぱりいい。そうした話とは別に、すごいなと思ったのは、Packages - Update Packages from CRAN とか Install Package from CRAN なんてメニューがあって、パッケージのインストールがメニューから簡単にネット経由でできてしまうところ。これは正直驚いてしまった。こんな便利なものが無料で使えるなんていい時代になったものだ。このページがとりあえず、ぱっと使うには一番役に立ちそう。必要な統計処理の項目ものを見つけて、その通りにすればいいのだから(^^) R による統計処理。でもまあ、R 入門から地道にはじめてみようかな。統計処理というのは、社会的にみても非常に重要なものなんだから、中学高校で、ほんとはきっちり教えるべきもんだと思う。でないと、総務省「通信利用動向調査」発表、インターネット人口普及率が5割を超えるの記事をよく見ると分かるように、めちゃくちゃな話が何気なくとおっていくことになってしまう。こんなんめちゃくちゃな話を国がやっているということは、もっと批判されるべきこと。総務省の総務省統計局統計センターが出している「家計消費状況調査（IT関連項目）」では、「インターネットを利用できる機器を保有している世帯の割合が50.3％」なのに、情報通信政策局総合政策課情報通信経済室が出すと、「インターネットの世帯普及率は、前年の60.5％から大幅に増加し、81.4％」ってことになるの。誤算の範囲超えてると思うのだけど。要するに、世論操作のために数字を使っているということだよね。統計なんて言うのは建前にすぎなくて。でも、こういう数字が一人歩きして、どんどん訳の分からないことになっていく。それが狙いなんだろうけど。めちゃくちゃな数字が出てきたら、やっぱり叩かんとダメだと思う。世の中わけのわからない数字だらけで気がおかしくなりそう（笑）。大語彙連続音声認識デコーダ Julius ってどの程度ちゃんと認識してくれるんだろう。と試してみると、うーん、これは厳しい。やっぱり、このあたり商用のソフトとかなり差がある。5分もたたないうちにあっさり放棄 (^^;;
2003.03.12
コメント(0)
-
統計処理に R 言語使ってみるかな
なんとなく R 言語を使いたいと思い始める。R 言語というのは、S 言語というベル研で開発された統計処理言語の S 言語を、GNU project の一部としてオープンソースで新たに作っているもので、Microsoft の Office に対する OpenOffice みたいなものだと思えばいいだろう。開発は商品の S 言語とはまったく独立して行われているけれど、「S 言語用のプログラムの 95% はそのまま R で変更なしに動くそうです」。Perl に CPAN というライブラリがあるのと同様、R 言語には、CRAN というライブラリがあるようだ。会津大学にこのミラー(ftp://ftp.u-aizu.ac.jp/pub/lang/R/CRAN/)があるので、そちらを利用することもできるようだ。で、R 言語をダウンロード(ftp://ftp.u-aizu.ac.jp/pub/lang/R/CRAN/bin/windows/base/)する。ここにあるのは R-1.6.2 で Windows 版。インストールの方法はここにあるようにいたって簡単。インストールしたら、Rgui をダブルクリックして起動してみる。まあ、なんだかまだよく分からないが、とりあえず quit() を入力して終了。とりあえず、東工大 数理・計算科学専攻／情報科学科 間 瀬 茂氏のページを情報源とする。日本語訳のマニュアルもある。マニュアルは こっちがいいのかこういう風に大学の先生が情報を公開してくれるのは非常にありがたい。生涯学習なんのかんのという話にしたって、こうやって大学の関係者が情報の一部をウェブ上に公開すれば、それだけで十分という話がある。なんたら講座の受講料を国が負担しますというあのばかげた金のばらまきをするぐらいであれば、大学の研究室などに大量に情報公開用のサーバをばらまくとともに、書籍購入用の費用等のために金をばらまいた方が1000倍ましなのだが。これに加えて公共図書館にウェブアクセスのための施設を置く。かなりお金がかかるように見えて、今ばらまいている金額に比べたら非常に安上がりのはず。ほんとにあんなばらまき、一部の業者が得してるだけじゃん。あれいったいくらの予算使っているんだろう・・・。という話はおいておこう（笑）。r-help や R-jp に投稿された記事からまとめた R 使用上のヒント なんてページもあるな。あと、とりあえず、いくつかのページをピックアップ。気長に勉強，R 言語 1日～8日と１週間ちょっと毎日学習できる量があるな。Ｒによる多変量解析入門 ここに下平英寿氏（東工大 統計科学)のページに、講義用のスライドや資料があるな。Linux で科学しようのページにも R言語が取り上げられている。Notes on S adn R は Mac の人だな。でね、どうして R 言語なんて突然いうのかといえば、R/SPlus - Python Interface、RPy (R from Python)、The Omegahat RSPython package for R & SPlus のようなものがあって、Python からも使えるかなと思ったから。というか、もう少し数字に強くならなきゃなーというのがあって、統計の勉強をやっぱりちゃんとやり直そうというのもあるのだ。難しい数学はどうせわかんないし(^^;; 一応、人工無能とかの話とかとも全部つながってるんだけど、あまりにも構想が難しすぎて、自分でもよく見えない。というか、構想はなくて、直感しかないじゃんというだけの話。なんにせよ C や C++ でゴリゴリ書くことができないんで、こうやっていったん外側にデータを出して統計パッケージとかで処理して、その結果を使って・・・という感じなのだけど、何をどうするかはよくまだ分からない。作る前から、全部見えちゃってるとおもしろくないんで、試行錯誤してみるのだの世界なの。書籍を読みたければ、『渡辺利夫 著 使いながら学ぶS言語』オーム社 ２５００円とか、『S言語I、II 』ベッカー、チェンバース＆ウィルクス著 渋谷政昭/柴田里程 訳 共立出版 ５１５０円とか、S言語のものを読めばよいようだが、とりあえずオンラインマニュアルやネット上で読める資料を見るので買うのはやめておく。
2003.03.11
コメント(0)
-
うだうだ
なんとなく、タイトルさえつけるのがおっくうだったので、適当な題名にしてしまった(^^;; こういうタイトルのときは、中身は何もないのだ。Python の統合開発環境の WingIDE のデモ版をダウンロードする。Windows 版と Linux 版だと 30ドルも値段が違うのだな。デスクトップもいいかげん Linux にでもしようかな。KNOPPIX の CD-ROM でもとりあえず入手するか。ん、Debian で WingIDE 動くんだろうか。Eclipse は無料だから使いたいけど、しばらく前に Python 用の Plugin 使ったら落ちちゃうし、使えなかった。まあ、WingIDE は wxPython や Zope にも対応しているし。179ドルならまあ許せないことないか。ActiveState のComodo よりは安いし。しかし、日本語は通らないかな・・・。ん、Emacs 使え。いや、vi で十分だと、どこからか声がする(笑)。Windows 環境だとお金がかかってしょうがない。アンチウィルスのライセンスもそろそろ切れるし。あー、気分転換のつもりが暗い気分に(^^;; なんか、うだうだした気分。で、KNOPPIX については、KNOPPIXの解説スライドを見ると、どんなものか分かるが、要するに CD-ROM から起動できる Linux ということだ。ちょうど 日経 Linuxに CD-ROM がついてるので買おうかな。OpenOfficeはそれなりによくできているとは思うけど、やっぱりできばえから言うと、まだまだ Microsoft の PowerPoint にかなわないな・・・。
2003.03.10
コメント(0)
-
Blog って何？どうでもいいや(笑)
ちょっとの間、Blog について調べながら日記を書いてみることにした。Blog って言葉が最近流行っているようだけど、分かったようで分からない言葉だし。hohhoh さんの掲示板の書き込みに答えてコンパクトに書ければいいんだけれど、これはネタとしておもしろいので、扱ってみることにしたわけ。なお、XREA につくった傀儡氏の実験室 の方で、今後はプログラミングよりの話は扱うことに決めましたが、あっちで何かまとまったことをしたら、こっちにポインタを書き込みます。ということで、あいかわらず、ここが本拠地なのだ。○ Blog って何？どうでもいいや(笑)まず、安直に blog（Web Log）の一般的な定義 などを読んでみる。キーワードをピックアップすると、「比較的更新頻度が比較的高」、「行動ログ」、「日記」、「個人的な情報発信活動」のあたりかな。blog という言葉が流行るにしたがって、インターネットのあり方を変える？ 個人ニュースサイト“blog”を運営する人たち といった記事が出てくるようになる。「個人ニュースサイト」という色合いから、ニュースメディアとの対比の構図を一つの視点としてとることができるのかもしれない。blog は「単なる日記ではない」というのは、一つの主張であるかもしれない。そうしたところからも、ウェブログの倫理みたいな文章が出てくることがうなずける。日本では、昔から日記系のサイトが存在したけれど、日記とblog はいったい何が違うんだ。という話になる。ブロッグと日記、掲示板との違いは？ とかも見てみる。ほんとは、もっと濃いところも読んだが、結局、頭の悪い私には、よく分からんというか、別に違いなんてどうでもいいという気がしてくる。やっぱり、簡単なのはどういう blogツールを使っているかで切り分けてしまうことだ(爆笑)。非常にナンセンスといえばなセンスなのだが、結果としてだいたい妥当なところになってしまうことになるだろうな。つまり、論評としての独立性を持った記事を中心に考えてツールを選択していくとI can’t blog. などにも触れられている、コンテンツとデザインの分離、リンク駆動(RSS) などといったところに主眼がいって、けっきょく blog 系のサイトで使われているようなツールを使うのが効率的ってことになる。日記と blog を考えたとき、私事を綴ったもの、私の世界/社会/物事に対する関わりの中で事象を綴るもの、私がネットで見つけたページに対する意見・論評を綴るもの、私の意見・論評に対するコメントを掲示するもの、私の意見・論評に対するコメントを掲載したサイトのリンクを掲載するもの、私の世界/社会/物事に対する意見・論評を表明するもの・・・。などと考えてもみるが、日記も blog も明確な線引きをするのは、難しいと思う。blog ツール使ったって、単なる日記じゃんというのがたくさんあるわけだし、また、その逆もしかり。いや、矛盾したこと言うな（笑）。基本的には「私」の位置づけが西洋人と日本人では違うから、日本人が日記だ blog だと論じあってもあんまし意味ないというか、おもしろくないと思うのであった。ようするにさ、白人がブルースできるかぁ、という話と通じるところがあるの。日本人にロックはできるか。民謡の心を外国人は理解できるかでもいいや。西洋人と東洋人はどこが違うでもいいや。違うってい言えば違うけど、交差する領域があるし、個々の違いについても、下手に取り上げて論じれば、必ず反証事例が出てきて収拾がつかなくなるようなことに似ているのかもしれない。西洋的な考え方と東洋的な考え方は、ベースの部分では、大きく異なっているように思えるのだけど、ちゃんと論じるのは難しい。blog と日記もそんなところがあると思う。ベースの思考方法が違うと、論点がかみ合わないのね。東洋には昔からこういう思想がありまして・・・、いや、それなら西洋にも同じようようなものもありまし、いやいや、それとこれとは、ここが違ってまして・・・。で、まあ、こんな風にとりあえず考えておくのがいいのかな。日記サイトで有名な tDiary で使われているツールのサイトに tDiary.org blog的運用方法 というページがある。「日付は飾りにすぎない. むしろ更新時刻の明記が大事です」で、日記っていうことの純粋性を考えると「ある一日」ということが本当はポイントになるはずなのね。だから日付は重要。これに対して「ある一日」に書かれはするけれど、それを超えていこうとする意志が個々の記事にあるのが blog と。だから、今日ということを主張すれば主張するほど、純粋な日記的になるし、今日を超えれば超えるほど、blog 的になる。ところが、ネット上の巡回記録をつける意味でのウェブログという意味で、あるいはニュース性という点をとらえると、実は、日記よりももっと blog の方が日付が重要になってくるという面もある。また、生き生きとした日記は逆に時を超えるものでもある。紫式部日記、土佐日記・・・。でも、日記日記した日記ほど、本来人の目を気にしていないようで、気にしていて、気にしていない(笑)。blog は人の目を前提にしているようでいて、でも単なる自己主張であって、気にしていないようでいて、やっぱり気にしている。どっちもネット上にさらされている時点で他人とインタラクションが生じてしまうから。今日の結論。blog ？ 日記？ まあ、細かいことこだわらないでいいじゃないですか。東洋人の顔をした西洋人もいるし、西洋人の顔をした東洋人もいるわけだし。いつもながら、投げやりな終わり方であった。ほんとは、blog でも日記でも、そこで使われている言葉に着目するとおもしろいことができて、自然言語処理てきにも題材としておもしろいものがあるとかいう話まで書こうと思ったけど、めんどうになったのでここでおしまい。
2003.03.09
コメント(0)
-
またよけいなことに時間を使ってしまった
XREA に前にアカウントを作っておいたのを突然思い出す。つないでみると、ぜんぜん使っていなかったのにアカウントが削除されていなかった。使わないと消されちゃうと思っていたら、そんなこともなかったらしい。で、せっかくだから使ってみることにした。しかし、人間なぜ領土拡張に対して興味を感じてしまうのであろう・・・。最初は、人工無能に関する大半を Tripod の方に移そうと思っていたのだけれど、まだ、いま一つなじめない (あまりまだ使っていない)。なんだか便利なんだか不便なんだかよく分からないのだ。カウンタもちゃんと動いてくれないし。これが一番気に入らない。しょうがないから Perl のアクセスカウンタを落としてきてちょっといじってみたりもしたが、あそこはあそこでまたクセがあるのね。最初分からなくて、手間取ってしまった。人工無能関連の記述については整理して、あっちにまとめようと思ってるのだけど、しばらく放置かな。で突然 XREA を思い出して、うん、そういえばアカウント作ってたんだ。すっかり忘れていた、と。そして、今日一日かけて、新しく TinyBlog という Python で書かれた Blog プログラムを改造して動かしてみた。何を今更自分でそういうもの改造するかなという気もしたのだが、すごくシンプルで簡単にいじれたので、うれしくなっていじくってしまった。単純なものの方がすぐにいじれていい。で、オリジナルにはない記事の削除機能とか、一覧表示機能とかもひそかに作ってしまった(これは外部からじゃ分からないが)。RSS もそのうち対応させよう。TinyBlog はなにせ単純なものなので、欲しい機能がぜんぜんないという話もある。大きいもので、いいものがあるかもしれないけれど、それだと、今度は把握するのが大変だし、インストールも面倒だし、一日じゃとてもやれないし。というわけでいくつか Python の Blog 関連のプログラムをダウンロードして、一番簡単そうなのを選んだというところ。最近流行らしい MovableType とかいう Perl の Blog も惹かれたのだが、Python じゃないから止めた。というか、高機能だから使い方を覚えて日本語化してとやるのも面倒でというのが本音かもしれない。誰かやってるんだろうが探すのも面倒だし。でとにかく、こういうちまちまとしたプログラミングは、一回始めるとけっこうはまるというか、遊びまくってしまうのがよくない。あれをこうして、ここをこうしてとやり始めると、ほんとにきりがない。だからこそ、楽天のようなできあえの日記を使った方が、よけいなことに時間をとられなくてよいという話もある。Tripod の日記でもよかったのだけど、なんだか XREA に置くためのコンテンツを用意しようと思ったら、やっぱり Blog も欲しくなって、ついつい遊んでしまった。非常にシンプルなものをいじってみると、やっぱり楽天の日記帳ってよくできてるなーと思う。まあ、とにかくこれでプログラムのソースとかを日記に入れる場合は、XREA の方が使えるようになったので、あっち側でやることにする。ここはといえば、とりとめのない日記を綴る場所かな。なんだかんだで気に入ってたりするので、また、もう少しジェネラルなことを書く場所にしようかと思う。といわけで、プログラミングに関わるようなことは、ここで書くのはおしまい。あとは、傀儡師の実験室の方で進めることにする。なんにつけ Tripod の傀儡師の研究室 は、ご用済みのような気もするので、そのうち削除しちゃおうかな (^^;;あと、Blog を調べていて感じたのは、アチラでは、Blog のサーバはいくつか有名なものがあって、あとは、その周辺にいろいろツールが発達しているってところかな。クライアントソフトが充実しているのだ。Radio UserLand みたいなやつとか、いろいろある。TTW (Thorough The Web)でコンテンツを書いていくというより、クライアント側でコンテンツを作っておいて、それを Blog サーバに XML-RPC を使ったりしてアップデートするという感じのがけっこうある。このあたり、日本ではまだあまり発達していないような感じもする。というか、趣向にやっぱり違いがあるのかもしれない。
2003.03.08
コメント(4)
-
再び ZODB に挑戦 (Python で人工無能)
ジャガイモを電子レンジで調理して食べた(それだけってことは、さすがにない(笑))。サツマイモもそうだけど、一番弱くしておいて、時間をかけて調理するのがコツ。その方がおいしく仕上がるのだ。○ 再び ZODB に挑戦 (Python で人工無能)先日 ZODB でサンプルが古いから動かんと書いたけれども、何か勘違いして、やり損なっただけみたいなので、やり直し。で、ZODB に単語の「見出し」と「読み」を登録する簡単なプログラムを作ってみた。この程度だと、あんまり ZODB の良さが分からんかもしれないなーと思いつつ(笑)。データベースに接続したりとかするところは、RDBMS とか使っていても同じようなもので、いったん接続用のリソースを確保しておいて、それを使ってデータベースにアクセスするというところでは変わらないのといえば変わらないが、いったん接続してしまったあとは、通常の python のディクショナリ形式のデータにアクセスするのと同じようにデータにアクセスできるので、もうちょっと手の込んだものをやってみるとメリットが明確になるかな。でも、単語(word) オブジェクトをそのままデータベースにぶち込んでいるところに注意なのだ。これができるから便利なの。で、とりあえずソースはこんな感じ。ZODB for Python Programmer を参考に、これをもっと単純にした感じ。起動すると、「一覧表示(’L’)、単語追加(’A’)、終了(’Q’): 」こういうメニューが表示されて、それぞれの機能を実行できる。単語の追加は、見出しと読みを入力するだけ。# いろいろ読み込む(笑)from ZODB import DBfrom ZODB.FileStorage import FileStoragefrom ZODB.PersistentMapping import PersistentMapping# こいつは、ZODB をインストールすると一緒にインストールされているのだ。from Persistence import Persistent# Persintent クラスを継承した Word クラスを宣言class Word(Persistent): """A word""" def __init__(self， midashi， yomi): self.midashi = midashi self.yomi = yomi# データベースを設定# 最初に words.fs というファイル名の格納場所を用意する。# ファイル words.fs を使ったストレージ(格納場所)を使って# データベースとしてアクセスすることにする。# 通常のファイルじゃなくて、BSDDB とか使う場合は、ここが# 変わることになる。storage=FileStorage("words.fs")# このストレージを初期値として ZODB データベースオブジェクトを# 作成する。db=DB(storage)# DB を開いて、接続用の変数に代入する(接続オブジェクトを作る)connection=db.open()# ZODB の接続オブジェクトの root メソッドを使って、# データベースのルートを開く。ちょうど、Unix の / や# Windows の C:\ のディレクトリ/フォルダを開いた状態と# 考えてみることにしよう。root=connection.root()# root に words というキーがなかったら、words というキーで# root 上に 空のディクショナリを作ってやる。if not root.has_key("words"): root["words"] = {}# root から words をキーとして値を取り出す。# ２度目からは、ちゃんとこれで前に保存してあったものが# 読み込まれることになる。words=root["words"]# 一覧表示用の関数の定義def listWords(): """ 登録単語の一覧を表示する """ if len(words.values())==0: print "登録された単語がありません。" print return for word in words.values(): print "見出し: %s" % word.midashi print "読み: %s" % word.yomi printdef addWord(midashi， yomi): """ 単語を新規登録する """ # words ディクショナリ中に、この見出しがすでに登録 # されていたら、登録済みのメッセージを表示する。 if words.has_key(midashi): print "この単語は登録済みです。" return else: # 未登録であれば、この単語を見出しをキーにして # words ディクショナリに追加する。 words[midashi]=Word(midashi， yomi) # words に再登録して更新する。 root[’words’] = words # このトランザクションをコミットする。 get_transaction().commit() print "単語 %s が追加されました." % midashi printif ＿name＿=="＿main＿": while 1: choice=raw_input("一覧表示(’L’)、単語追加(’A’)、終了(’Q’): ") choice=choice.lower() if choice=="l": listWords() elif choice=="a": midashi=raw_input("見出し:") yomi=raw_input("読み:") addWord(midashi， yomi) elif choice=="q": break # データベースを閉じる connection.close()で、実行するとこんな感じ。一覧表示(’L’)、単語追加(’A’)、終了(’Q’): A見出し:人工無能読み:じんこうむのう単語 人工無能 が追加されました.一覧表示(’L’)、単語追加(’A’)、終了(’Q’): L見出し: 人工無能読み: じんこうむのう一覧表示(’L’)、単語追加(’A’)、終了(’Q’): A見出し:形態素解析読み:けいたいそかいせき単語 形態素解析 が追加されました.一覧表示(’L’)、単語追加(’A’)、終了(’Q’): L見出し: 形態素解析読み: けいたいそかいせき見出し: 人工無能読み: じんこうむのうこれで ZODB も使えるようになったので、また、ipadic をぶち込んでみるかな。これはかなり時間がかかるだろうな。インデックスも作ってあげないと見出しの検索しかできなくておもしろくないか。インデックスを作ったら、かなりデータサイズが大きくなるだろうし、さらに時間がかかりそう。うーん。まあ、これは遅くてかまわないので、どの程度、どんなことになるかとりあえずやってみるかな。
2003.03.05
コメント(0)
-
形態素解析器ベンチマーク (Python で人工無能)
久々に自分で肉を焼いて食べた。なんて生活だ(笑)。このところのお気に入りは、ノルウェー産の子持ちシシャモ。安くてうまいのでいい。体にもいいしね。で、たまには自分で肉を焼いて食べようと豚肉を買ってきた。やっぱりコンビニの弁当についている肉より自分で焼いた肉の方がうまい。鉄のフライパンにしっかり油をひいて焼いて食う。テフロン加工のフライパンは焦げ付かなくていいのだけど、やっぱり鉄のフライパンで焼いた方が肉はうまい。○ 形態素解析器ベンチマーク (Python で人工無能)しばらく前に形態素解析器のベンチマークをしようと思っていてすっかり忘れていた。ということで、簡単なベンチマークをやってみた。この機械翻訳用の試験文から日本語だけを切り出して５回繰り返すテキストファイルを作っやってみた。それとは別に、１文だけ入れたファイルを作って、500回繰り返すというアバウトなテストをやってみた。比較したのは、MeCab、Chasen、JUMAN、Breakfast、kakasi。結果として、改めてびっくりしたのは MeCab の優秀さだった。最初のテストでは、 MeCab ＜ kakasi ＜ Chasen ＜ Breakfast ＜ JUMAN だが、MeCab が圧倒的にかつ信じられないほど速く、kakasi なんか目じゃないという強さ。JUMAN はお役目ご苦労様でしたという感じ。２番目のテストでは、 kakasi ＜ MeCab ＜ Breakfast ＜ JUMAN ＜ Chasen という感じになった。MeCab は kakasi にかなりよい線で張り合っているが(それでもやっぱり kakasi は速い)、Breakfast、JUMAN、Chasen は、お話にならないぐらいに２つに比べて遅い。ここから、１文単位で動かす場合は、kakasi がサイズが小さいし、中身が単純なだけに有利に働くということが分かる。これに対して、Chasen はやたらと起動時間に時間がかかっているという感じ。いったん起動して解析を始めれば、量が多くなるほど kakasi のメリットは見えなくなっていく(つまり、純粋な解析速度そのものはそれほど速くない)。ただ、１文単位でそんなに形態素解析を行うようなことは、なんらかの自然言語処理のプログラムでも作らない限りはあり得ず、数十キロバイト単位のインデックス用のキーワードの切り出しに使うのであれば、Chasen が kakasi にそれほど劣った速度にはならないはず。ということで、全文検索用に kakasi か chasen のどちらがいいかということになれば、基本的に Chasen を使った方がいいんじゃないのと思える。また、MeCab はどういう条件でもばかに速いので、キーワードインデックスの切り出しなど一定度のテキスト容量がある場合には、kakasi よりも MeCab の方が速度的にも有利になるはず。で、kakasi はもうお役目ご苦労様になる。それに、kakasi はキーワードの切り出しにしても、分かち書きが適当でない場合もやはりやや多いし・・・。Breakfast は、Chasen より起動が速いせいか単文の場合やや速いものの、量がある場合は Chasen と順位が逆転した。また、MeCab とはまったく張り合えるような速度ではなかった。MeCab はこれで、安定度して使えるという評価を得られれば、kakasi や Chasen にとって代わるケースが増えるだろう。が、辞書登録がやや面倒とか、その他、若干、使用上の問題において chasen に劣る部分があるので、完全に置き換わることにはならないかもしれないが。まあ、個人的には、これから MeCab をもっと使い込んでいこうという確信を強める結果ではあった。形態素解析結果については、面倒なので見ない(笑)。結果は辞書によっていくらでも変わるし、kakasi はそもそも、分かち書きはしてくれても品詞がつかないし、分かち書きの結果もかなり適切でないことも多いので対象外。Mecab と Chasen はやや、違うところがあるものの、おおよそ同じ感じになるだろうと予測がつくし、JUMAN はちょっと癖があるけど、場合によっては便利なこともある。さらに、Breakfast はといえば、品詞体系がまた違うので一概に比較できない。分かち書きだけを比較するということをしてみると、特長が分かっておもしろいかもしれないが、やっぱり面倒なのでやらない。で、試してみた結果、MeCab はやっぱりかなり優秀だった。ほんとにびっくり。Chasen の新しいバージョンはどうだろう。機能が若干削られて、Dart を取り入れているだけに、速度向上は期待できる。そのうち試してみよう。なんにしても、ベンチマークをするときには、どういう単位(量)を扱うかということも、ちゃんと検討しなくてはいけないなというのも改めて感じた。
2003.03.04
コメント(0)
-
ipadic をちょっと眺める (Python で人工無能)
グリコのジャイアントソフト、ビター＆バニラを食べた。やっぱりアイスは冬に限るのだ。これはバニラの部分はあんまりうまくないが、ビターチョコの部分がうまい。ボリュームたくさん、カロリーたくさん、257kcal。でも、ポテトチップス一袋食べるより、よっぽどカロリーすくないのだよね。コンビニの商品って入れ替わりがけっこう激しいけど、それなりの期間たっても消えてなくならないということは、そこそこ売れているということなのかな。○ ipadic をちょっと眺める (Python で人工無能)ipadic のマニュアルを眺めてみる。このマニュアルは ipadic 2.5.1 用に書かれているな。新しい ChaSen 2.3.0 はまだ時間がないので入れていない。いや、日記書くのやめれば、その程度の時間はあるんだけど(笑)。よけいな処理もなくなって Darts (Double-ARray Trie System) も使われてということで、なんだか速くなるんじゃないかなーという期待はあるのだけど、面倒なのでいれてない。ipadic-2.5.0 と ipadic-2.5.1 の比較をするのは、とりあえずは ChaSen の方がいいかな。MeCab だとなぜか、Make してる最中に落ちちゃって ipadic 2.5.1 使えないし。原因は調べれば分かるのかもしれないが面倒なので放置。単純に diff だと ipadic 2.5.0 と ipadic 2.5.1 の違いがよく分からないが、いろいろツール作ってから調べることにしようっと。で、とりあえず、またちょっと ipadic について調べる。ipadic-2.5.1/doc あたりをまず眺める。品詞体系そのものは、2.5.0 と 2.5.1 の違いはなさそう。どちらも、情報処理振興事業協会(IPA) で設定されたIPA 品詞体系(THiMCO97) に修正を加えたというもの。まずは、1998年5月に公開したIPA品詞体系日本語辞書(ipadic1.0b2) があって、日本語ディクテーション基本ソフトウェアの開発」の成果を反映させて修正改良が行われたと。で、「 ipadic-2.5.0 の品詞体系は ipadic-2.4.X と同じものを利用しますが、今後、茶筌 project では品詞体系（活用型／活用形）の大幅な変更を行っていきます。」とドキュメントに書かれているが、このあたり、で、いまいったいどうなったのかよく分からんな。2.5.X というのは、なんにせよ、開発版ということなのかと改めて気づく(^^;; つまり、Linux などの偶数のバージョンと奇数のバージョンとかと同じ感覚でとらえればいいわけか。で、辞書ファイルは (Noun.dic など) の品詞ごとに分かれた辞書がまずあって、連接表ファイル (connect.cha)、 品詞定義ファイル(grammar.cha)、活用型定義ファイル (ctypes.cha)、活用形定義 ファイル(cforms.cha) がある。ということで、品詞自体は、まず、品詞定義ファイル(grammar.cha) を見ればいいということだな。品詞定義ファイル(grammaer.cha)の「(動詞%」みたいに % がついているやつは、活用する品詞。ついていないのは活用しない品詞と。人工無能も活用する品詞としない品詞の区別を明確に持たせた方がよいかもしれないな。(chasen のドキュメントより引用)BNF で書かれているな。で、BNF って何の略だっけ。Backus Naur Form でした。バッカスさんと、ノーアさんが作った書式(Form) だから、２人の名前からつけられたと。BNF記法入門（1） ─XML関連仕様を読むために─なんてものも見つかった。でも、どっちかっていうと yacc 入門みたいなところを見た方がいいのかな。でも、Javaコードの診断: 拡張可能アプリケーションの設計 第4回， S式がどのように軽量のブラック・ボックス拡張性を実現するかみたいなものの方が、S式を扱っているからいいのか。と話がそれる。とにかく grammer.cha とか connect.cha ctype.cha とかも RDBMS に入れてしまおうかな。うーん、この量なら pickle とかで持たせて毎回読み込んじゃってもいいかな。全部合わせて 1MB 強程度だし。と、話がどんどんとそれる。が、文の生成のときに役立てられそうな気もするし。なんだか、どんどん仕様ばかり妄想的に膨れあがっていくなー。まあ、いいや。ふと、おもしろいと思ったのが、フィラー。で、フィラーって何？といったら、要するに詰め物で、その語自体に特別な意味はなく、むしろ、会話の途中に間をとったりするために使われるような語のことを指すのだろう。「その、なんか、あのー、えーと、えー、あの、と、えーっと、うん、ま、えと、まあ、そのー、うんと、ええと、え、そうですね、あ、」というのがフィラーとして登録されているが、ここを増強すると口語に対してもっと強くなりそうな気もする。「えっとー」とか「んで」なんて入っていないものね。「まあそのー」とかすると、「まあ(感動詞)/そのー(フィラー)」に解析されるけれど、「まあ」と「そのー」は、それぞれ登録されているものの結果としては、両方ともフィラーという風には解析されない。意味的に言ったら、たぶん両方フィラーなんだろう。Noun.place.dic に地域名が入っているが、郵政省の郵便番号データから作り直したとすると、やはりこの程度の数になるのかな。ipadic のエントリ数は 67295。郵便番号データからとったらどうなるか。鄙俗 (ヒゾク) みたいな難しい言葉もたくさん入っているが、むしろ、このレベルの文字は当用漢字に入っていないだろうから、鄙俗より、ひ俗と書かれるか、それではわかりにくいからそもそも、別の言葉に言い換えられる言葉かもしれない。人工無能っぽくかわいくするためには、当用漢字だっけ、常用漢字だっけにある文字だけを固有名詞、地域名以外は残して後はバッサリけずってしまうとかいうのをやってもおもしろいかもしれない。でも、コストの付け方が問題だな・・・。
2003.03.03
コメント(0)
-
辞書をRDBMS に入れて遊ぶ ２ (Python で人工無能)
とりあえず、昨日は、いいかげんにデータベースに放り込んだので、もう少しちゃんと入れ直すことにしよう。とりあえず、正規化するにしても、どんなエントリが入っているか、ちょっと見てみるのに RDBMS に入れちゃった方が便利だから(笑)。ちゃんと正規化すれば、少しは Gadfly でもパフォーマンスがよくなるかもしれないが、やっぱり遅そうなので、Gadfly はあきらめて、MySQL でやることにする。MySQL がインストール済みなら、Sourceforge から、MySQL Pythonをダウンロードしてインストールすれば、すぐに Python からも MySQL が使えるようになる。ということで、昨日は MySQL の方もセットアップしてしまった。で、昨日のは、こんな感じでデータを登録した。#! /usr/bin/pythonimport sysimport MySQLdbCSVFile = "C:￥￥Program Files￥￥mecab￥￥dic￥￥ipadic￥￥dic.csv"# MySQL サーバに接続するtry: conn = MySQLdb.connect (host = "localhost"， db = "pytest")except MySQLdb.Error， e: print "Error %d: %s" % (e.args[0]， e.args[1]) sys.exit (1)# カーソルを作成cursor = conn.cursor ()# コマンドの前半だけ用意するcmd0 = """insert into dic ( mkey， cost， pos1， pos2， pos3， pos4， pos5， pos6， genkei， yomi， hatsuon) values """cmd0 = cmd0.replace(’￥n’， ’ ’)cmd0 = cmd0.replace(’ ’， ’ ’)# カウンタc = 0# CSV ファイルを開き、最初の行を読み込む# ちなみに行末の改行(￥n)が邪魔なので1文字捨てている。csvfile = open(CSVFile， ’r’)line = csvfile.readline()[:-1]while line: # カンマ区切りのデータをリストに分解 [’見出し’， ’品詞1’， ’品詞2’] line = line.split(’，’) # "(’見出し’， ’品詞1’， ’品詞2’， ...)" という文字列が欲しい。 # のだが面倒なので、タプル(a， b， c...) という形式にリストから # いったん変換して、その表示用の文字列を使ってしまう(^^;; line = tuple(line).__repr__() # コマンドの前半部と読み込んだ行を合体して、 # その行を挿入するための SQL 文を作る cmd = cmd0 + line # sql コマンド を実行し、データを挿入する cursor.execute(cmd) # どのくらいまで進んだか、画面に表示しておく # 1000 ごとに ’.’ を１つ表示しておく c = c + 1 if ((c % 1000) == 0 ): print ’.’， # 次の行を読み込む # ちなみに行末の改行(￥n)が邪魔なので1文字捨てている。 line = csvfile.readline()[:-1]# csv 形式の辞書を閉じるcsvfile.close()# テスト用に小さい csv ファイルを最初に作ってテスト# でかいのでそのままやると大変...# cursor.execute("select * from dic")## cursor が示しているポイントから、# データをすべて取り出して(fetchall)、# 変数 x に代入してすべての取り出した行に対して操作を行う。##for x in cursor.fetchall():# print x# とするとデータが多くて大変なので# 確認しないでとりあえず閉じて終わり。conn.close()sys.exit (0)とりあえず、データをぶち込んだら検索してみる。Gadfly と比べてやっぱり速くて気持ちいい。それにしても、こういう汎用の RDBMS と比べて、形態素解析の辞書引きって速いよなーと思う。まあ、RDBMS の方が遅いけれど、いろいろ遊べるのだよな。#! /usr/bin/pythonimport sysimport MySQLdbCSVFile = "C:￥￥Program Files￥￥mecab\\dic￥￥ipadic￥￥dic.csv"# connect to the MySQL servertry: conn = MySQLdb.connect (host = "localhost"， db = "pytest") cursor = conn.cursor ()except MySQLdb.Error， e: print "Error %d: %s" % (e.args[0]， e.args[1]) sys.exit (1)# 検索の例cursor.execute ("SELECT * FROM DIC where mkey=’北’")# 検索結果をいいかげんに表示rows = cursor.fetchall ()for row in rows: for r in xrange(len(row)): print "%s " % row[r] ， print "￥n"print "%d 行、マッチする行ががあります。" % cursor.rowcountてな具合でまず動けばいいって感じでやってみた。これでも、いろいろ検索できるので便利なのだ。名詞だけを抜き出したり、固有名詞だけを抜き出したり、あっという間にできてしまうから。で、正規化する前に、まずデータを眺めてみることにしよう。と、また、これもシリーズ的に長々と続くんだろうか。いつになったら、人工無能に組み込まれるのだー。でも、本質的に、たくさーんのデータをこれから扱っていこうと思うので、やっぱり、どこにどういう風に格納しておけば楽に扱えるかなというのも、やっぱりやっておかないとならないし、辞書も鍛えなきゃならないし。最初の予定では３月中に第２弾でもう少し賢いバージョンにしようと思っていたが、当分、ちまちま、辞書をいじったりとかの実験を続けるかも(^^;;ころころ気が変わるんだ。で、実はテーブルはむちゃくちゃなことしているので(大笑い)、これから正規化したりしながら、ちょっとまともに直していく。create table dic ( mkey VARCHAR(40)， cost VARCHAR(40)， pos1 VARCHAR(40)， pos2 VARCHAR(40)， pos3 VARCHAR(40)， pos4 VARCHAR(40)， pos5 VARCHAR(40)， pos6 VARCHAR(40)， genkei VARCHAR(40)， yomi VARCHAR(40)， hatsuon VARCHAR(40) );で、いちいちプログラムを書くのも面倒なので、mysql のコマンドラインで接続して、キーをたたいてしまうことにする。見出し語の長いのはどの程度だろうとちょっと眺めてみると、mysql> select mkey from dic where length(trim(mkey)) > 39;げげっ、40文字じゃ足りてなかった。途中で切れてるやつがある。ということで、元データから見直し。mysql> select max(length(trim(pos1))) from dic;のように、各フィールドの最大文字列帳をとりあえず見直し。で当然、見出しが40に収まっていないものは、読みや原形も収まりきらないので 40 文字を超えている。その他は、コスト、品詞１...6 は、 4， 8， 24， 12， 4， 20， 14 文字あれば足りる。コストは 4文字で数字なので、INT にしておけば足りるな。面倒なのでもう一度フィールドを長くして入れてカウントしてみよう。無精だがやり方(笑)。create table dic ( id INT(7) PRIMARY KEY NOT NULL AUTO_INCREMENT ， mkey TEXT， cost INT(4)， pos1 VARCHAR(8)， pos2 VARCHAR(24)， pos3 VARCHAR(12)， pos4 VARCHAR(4)， pos5 VARCHAR(20)， pos6 VARCHAR(14)， genkei TEXT， yomi TEXT， hatsuon TEXT);で、ざっくりと、もう一度テーブルを定義し直して入れ直す。で trim で空白をカットして length で長さをとって、max で最大値を求める。読みの類は７４文字とかなり長芋のも登録されているし、見出しキーや原形も５２文字とかなり長いものがある。ふーん。avg で平均を見てみると、読みの平均は 9.7875。こういうのが一瞬でできちゃうから MySQL は便利でいい。mysql> select max(length(trim(hatsuon)))， max(length(trim(yomi))) from dic;+----------------------------+-------------------------+｜ max(length(trim(hatsuon))) ｜ max(length(trim(yomi))) ｜+----------------------------+-------------------------+｜ 74 ｜ 74 ｜+----------------------------+-------------------------+1 row in set (1.31 sec)mysql> select max(length(trim(genkei)))， max(length(trim(mkey))) from dic;+---------------------------+-------------------------+｜ max(length(trim(genkei))) ｜ max(length(trim(mkey))) ｜+---------------------------+-------------------------+｜ 52 ｜ 52 ｜+---------------------------+-------------------------+1 row in set (1.24 sec)mysql> select avg(length(trim(yomi))) from dic;+-------------------------+｜ avg(length(trim(yomi))) ｜+-------------------------+｜ 9.7857 ｜+-------------------------+1 row in set (1.15 sec)固有名詞の数を数えてみると 142154 と、368198 の見出しのうち、38.6% の割合。名詞(214618) のうち、66.2% もの割合を占めていることが分かる。実際のところ活用形が展開されて登録されているので、かなりの割合を固有名詞が占めているということになるな。ただし、「きれい」などは、名詞-形容動詞語幹というように登録されているから、純粋な名詞が全部と言うことではない。また、サ変名詞などもあるし。mysql> select count(mkey) from dic;+-------------+｜ count(mkey) ｜+-------------+｜ 368198 ｜+-------------+1 row in set (1.27 sec)mysql> select count(mkey) from dic where pos1=’名詞’;+-------------+｜ count(mkey) ｜+-------------+｜ 214618 ｜+-------------+1 row in set (1.52 sec)mysql> select count(mkey) from dic where pos2=’固有名詞’;+-------------+｜ count(mkey) ｜+-------------+｜ 142154 ｜+-------------+動詞の数も確かに多いのだが、動詞の活用形とひらがなで登録されているものも併せて考える必要がある。1/10 程度に考えてみると、まあ、それでも 1万を超える数が登録されているので、主な動詞はだいたいカバーされているということなのかな。mysql> select count(mkey) from dic where pos1=’動詞’;+-------------+｜ count(mkey) ｜+-------------+｜ 125259 ｜+-------------+1 row in set (1.40 sec)mysql> select count(mkey) from dic where pos1=’形容詞’;+-------------+｜ count(mkey) ｜+-------------+｜ 24174 ｜+-------------+1 row in set (1.29 sec)品詞の一覧も簡単に作れちゃうから楽でいいのだ。これで品詞テーブルも楽に作れちゃう。別に正規化なんかしなくても、けっこう使えてしまうのが RDBMS のよいところ。って何の話だ。とうぜん、こういうのも Python のプログラム内から実行することができるわけね。だから、人工無能との会話で、何か地名が出てきたら、似たような地域名を引っ張ってくるとか、人名だったら、また別の名前を検索して引っ張ってくるなんてことも簡単にできるわけ。それが役に立つかは別にして(笑)。mysql> select distinct pos1 from dic;+----------+｜ pos1 ｜+----------+｜ 名詞 ｜｜ 副詞 ｜｜ 形容詞 ｜｜ 動詞 ｜｜ 接頭詞 ｜｜ 接続詞 ｜｜ 連体詞 ｜｜ 記号 ｜｜ 助詞 ｜｜ 助動詞 ｜｜ 感動詞 ｜｜ フィラー ｜｜ その他 ｜+----------+13 rows in set (1.77 sec)
2003.03.02
コメント(0)
-
辞書をRDBMS に入れて遊ぶ 1 (Python で人工無能) (1)
○ 辞書をRDBMS に入れて遊ぶ 1 (Python で人工無能)今日はのっけから本題のみ。とりあえず、Gadfly に MeCab で使っている ipadic を試しに登録してみることにした。まず、辞書を作成するディレクトリのチェックと作成から。Gadfly はデータベースごとにディレクトリを作っておいた方がよいので、C:\\GadflyDB にまとめてデータベースを置くディレクトリとしておいて、そこにさらに ipadic というディレクトリを用意して、そこにデータベースを置くことにする。import sysimport osimport gadfly# とりあえず、 DB を C:￥GadflyDB というディレクトリに# 保存することにする。もし、このディレクトリが存在しない# 場合には、ディレクトリを作成し、作成できない場合は# 終了することにする。DBDataDir = "C:￥￥GadflyDB￥￥ipadic"if not os.path.isdir(DBDataDir): try: os.mkdir(DBDataDir) except: print "ディレクトリが作成できません。"# データベース名DBName = "ipadic"# でもって、今度は、データベースを用意する。とりあえず、# まずテーブルを作成してやる。そうしたら、ちょっと、ここに# 実際にデータを登録できるかどうか、試してみよう。# これはデータをコミットして正式にデータベースに書き込むので# はなくて、最後に rollback してみる。# ここから本番# Gadfly への接続用にオブジェクトを作成し、# connection という変数に代入する。connection = gadfly.gadfly()# DBDIR (C:￥GadflyDB￥ipadic)にある# ipadic というデータベースの使用を開始する。# もし、存在しない場合は、勝手に新規に作成される。# 存在する場合は「初期化」される。connection.startup(DBName， DBDataDir)# カーソルオブジェクトを作成し、# cursor という変数に代入する。cursor = connection.cursor()# sql コマンドを用意する。cmd = """create table dic (key varchar， cost varchar， pos1 varchar， pos2 varchar， pos3 varchar， pos4 varchar， pos5 varchar， pos6 varchar， genkei varchar， yomi varchar， hatsuon varchar) """# sql コマンドを実行し、テーブルを作成するcursor.execute(cmd)# コミットして、データベースに反映させるconnection.commit()cmd = """insert into dic (key， cost， pos1， pos2， pos3， pos4， pos5， pos6， genkei， yomi， hatsuon) values (’若松山’，’3524’，’名詞’，’固有名詞’， ’一般’，’*’，’*’，’*’，’若松山’， ’ワカマツヤマ’， ’ワカマツヤマ’) """# sql コマンド を実行し、データを挿入するcursor.execute(cmd)# test テーブルにあるデータをすべて選択する(select)cursor.execute("select * from dic")# テーブルができたか確認するprint cursor.pp()# 明示的に前の命令(挿入)をロールバックして無効にする。cursor.rollback()# 接続を閉じるconnection.close()ここまででいったん終了。とりあえずテーブルは作成してコミットしたので、テーブルはちゃんと残っているはずなので、これを使う。よけいなテスト用のデータはロールバックしたので残っていないはず。さて、これから ipadic の MeCab 用の csv ファイルから、ガツンと読み込んでやることにする。import sysimport osimport gadfly# データベース名DBDataDir = "C:￥￥GadflyDB￥￥ipadic"DBName = "ipadic"# ipadic の csv ファイルの場所を指定するCSVFile = "C:￥￥Program Files￥￥mecab￥￥dic￥￥ipadic￥￥dic.csv"# データベースはすでに作成されているので、# これからは接続するだけでいいというか、初期化しちゃだめ。connection = gadfly.gadfly(DBName， DBDataDir)cursor = connection.cursor()csvfile = open(CSVFile， ’r’)# コマンドの前半だけ用意するcmd0 = """insert into dic (key， cost， pos1， pos2， pos3， pos4， pos5， pos6， genkei， yomi， hatsuon) values """# カウンタc = 0# 最初の行を読み込む# ちなみに行末の改行(\n)が邪魔なので1文字捨てている。line = csvfile.readline()[:-1]while line: # カンマ区切りのデータをリストに分解 [’見出し’， ’品詞1’， ’品詞2’] line = line.split(’，’) # "(’見出し’， ’品詞1’， ’品詞2’， ...)" という文字列が欲しい。 # のだが面倒なので、タプル(a， b， c...) という形式にリストから # いったん変換して、その表示用の文字列を使ってしまう(^^;; line = tuple(line).__repr__() # コマンドの前半部と読み込んだ行を合体して、 # その行を挿入するための SQL 文を作る cmd = cmd0 + line # sql コマンド を実行し、データを挿入する cursor.execute(cmd) # どのくらいまで進んだか、画面に表示しておく # 1000 ごとに ’.’ を１つ表示しておく c = c + 1 if ((c % 1000) == 0 ): print ’.’， # 次の行を読み込む # ちなみに行末の改行(\n)が邪魔なので1文字捨てている。 line = csvfile.readline()[:-1]# csv 形式の辞書を閉じるcsvfile.close()# テスト用に小さい csv ファイルを最初に作ってテスト# でかいのでそのままやると大変...# cursor.execute("select * from dic")## cursor が示しているポイントから、# データをすべて取り出して(fetchall)、# 変数 x に代入してすべての取り出した行に対して操作を行う。##for x in cursor.fetchall():# print x# とするとデータが多くて大変なので# 確認しないでとりあえず閉じて終わり。connection.commit()connection.close()だいたい、１秒間に100行程度しか処理できない。うーむやっぱり大量のデータを扱うのはつらいってことかもしれない。せいぜい、4桁程度のデータまでかな。MySQL を使って同じことを Python からやってみたが、あっという間に終わった。Gadfly だと２時間以上かかるものが、MySQL だと 10分程度。うーん。ちょっと考えちゃうな。１行ごとにコミットしてみたり、1000行ごとにコミットしてみたり、checkpoint の設定を自動ではなく、手動にしてみたりもしたが、どうあがいても遅い。検索はどうだろう。まあ、やらないでも分かるな・・・。できあがったデータ量も、Gadfly 45MB 程度、MySQL は 30MB 程度と、容量もやっぱり差が出る。ちなみに、元のデータは 26MB 程度なので、MySQL がやっぱり優秀なのだな。検索してもやっぱり、全然速さが違う。うーん、Gadfly はちょっと数十万行とかあつかう場合は、やっぱり厳しいな。インデックスをつけたとしても、そんなに速くならないだろうし(MySQL もインデックスなしで同じようなテーブルで作ったから条件同じだし）。ということで、この用途に対しては Gadfly をあえて使うこともないという、当たり前の結論に達して、MySQL でいいやということになる(笑)。この記事、カテゴリを変更して再登録しようとしたが、文字数制限がきつくなって再登録できないので、後半部を 別の日に入れておく。
2003.03.01
コメント(0)
全23件 (23件中 1-23件目)
1
-
-
- 楽天ラッキーくじ
- 楽天ラッキーくじ更新情報（2026/7/2…
- (2026-07-27 15:19:08)
-
-
-
- 新生活にむけてほしい家電は？
- 車内清掃に便利な 「サイクロン式ハ…
- (2026-06-28 23:19:07)
-
-
-
- 花、風景の写真を撮るカメラとレンズ
- 寒風にも負けず水仙の花(1/26)
- (2026-02-02 14:22:42)
-
