<   2006年 04月 ( 9 )   > この月の画像一覧

学習とは何か

学習とは何かというと、結局、非常に大量の用語とその意味を覚えることだ。まず、覚えなければならない用語の数多さに恐れを感じ、次に、その用語の意味、つまり、論理構造を理解する労力に挫け、なによりも、それだけの仕事を遂行するためにかかる時間の多さに圧倒される。

それを克服するためには、情報の圧縮を考えなければならない。十数個の用語を関連付けて、ひとつの用語に集約させてしまうのだ。この用語のクラスタリングは、トップダウンで行う場合もあるし、ボトムアップで行う場合もある。用語のクラスタを作る方法は、システム的にやるより、きままに思いついたところからやったほうが、興味を持続させることができる。

人間が一度に理解できる知識の範囲と量はたかが知れている。その許容量内に知識獲得の作業の範囲を絞るのがコツのようだ。

情報の圧縮と展開を自在にやれるようになると、新しい知識に挑戦するときの鬱陶しさが少しは軽減するかもしれない。
[PR]
by tnomura9 | 2006-04-26 22:06 | 考えるということ | Comments(0)

yacc

Racc の使い方が分かるようになってから、yacc が何をしていたのかが分かるようになってきた。また、Racc に興味を持つようになって分かったのは、パーサの機能を内包したプログラムが思っていたより多いことだ。C、Ruby、awk、yacc、lex、などの明らかなプログラム言語以外にも、正規表現、Vi などのエディタ等々、文字列を構文解析して動作するようになっているプログラムがいっぱいだ。

結局、プログラムで記述しているのは、本質的には、パターンとアクションの結びつきを作ることなのかもしれない。パターンとアクションという見方からプログラムのソースを眺めると、もっとソースを読むのが楽になるのだろうかなどと考えたりする。

パーサと関係の深いのが文脈自由文法だ。どんな言語のプログラムも、意味を持った単語と、意味のある単語の組み合わせである文節、意味のある文節の組み合わせである文、意味のある文の組み合わせであるプログラムからなっているが、その組み合わせ方をコントロールしている規則が文法なのだ。

単語の組み合わせすべてが意味があるわけではなく、語順や単語の種類などについて規則があり、その規則を再帰的に点検する方法が文脈自由法なのだ。そういうやり方で構文木を作っていくとき、必然的に文字情報は階層構造をとることになる。

文字列の情報が単に一列に配列しているだけなら話は簡単なのだが、実際には、階層構造の中に情報が存在するためにプログラムの製作が複雑になってしまうのだ。

パターンとアクション、情報の階層構造の三つのキーワードを頭に入れて、ソースを読んでみると面白いかもしれない。
[PR]
by tnomura9 | 2006-04-20 08:25 | Ruby | Comments(1)

YAML その2

YAMLにはRubyのユーザー定義クラスのオブジェクトを記述できる。詳しくは、YAML で遊ぶ

YAMLでRubyのオブジェクトのデータを操作できるので、設定ファイルをYAMLで書くと、Rubyのプログラムのカスタマイズが非常に簡単になる。YAMLがRubyのアプリケーションプログラムを操作する一種のプログラム言語のような役割も果たす可能性がある。しかも、YAMLはPerlやPythonやPHPなど、他のプログラムからも読み込むことができる。

RubyがUnixやWindowsで使用可能なマルチOSプログラムなのと同様に、YAMLはマルチプログラム言語のデータ記述規格なのだ。

YAMLがRubyに実装されているとはいえ、データ保存の手段やデータベースとしても速度が遅い。しかし、YAMLの意義は、構造化したハッシュやリストを可読なテキスト文書として残すことが出来るということだ。複雑なマークアップ言語は、結局のところパーサがないと読むのに苦労する。しかし、YAMLはパーサが無くても、その意味を直感的に知ることができる。

専用のプログラムが保守されなくなったら読むことが出来なくなる情報はいずれは消滅してしまう。プレイン・テキストやYAMLは専用プログラムの心配なしにデータを保存することが出来るので、いつまでたっても情報が読めなくなる危険がないのだ。つまり、プログラムとデータの独立性が高いのである。
[PR]
by tnomura9 | 2006-04-18 06:51 | Ruby | Comments(0)

YAML

夕べと今日2日使ってYAMLの勉強をした。YAMLとは要するに、オブジェクトをテキストファイルに落とすための規格だった。要点は次のようになる。

  • YAMLを使うために require 'yaml' する。
  • オブジェクト a を YAML にするのは、a.to_yaml
  • YAML str をオブジェクトにするのは、a = YAML.load(str)
  • 複数のオブジェクトからなるリスト lst = [obj1, obj2, ...] を YAML にするのは、str = YAML.dump_stream(*lst)
  • 複数のデータが記入された YAML を複数のオブジェクトにするのは、stream = YAML.load_stream(str); lst = stream.documents

Racc にしても、YAML にしても、面白いものはみんなパーサだ。コンピュータで扱うデータというものは、本質的にはどれもこれも構造を持った文字列なのかもしれない。だから、コンピュータに何かさせようとすると、どうしてもパーサのようなパターン認識プログラムを作らないといけなくなってしまうのだ。

逆に言うと Racc や YAML のような、汎用のパターン認識プログラムを使い慣れていれば、コンピュータを使いこなすのにかなり楽ができるかもしれない。
[PR]
by tnomura9 | 2006-04-15 21:59 | Ruby | Comments(0)

慣性と陥穽

業績が好調な企業の経営者の話は面白くない。会社の組織としての慣性力が業績の好調を保っているために、経営者の判断の影響が隠蔽されてしまうからだ。業績の好調な起業の経営者の手腕が優れていたか否かは、何年も後にならないと現れてこないのだ。したがって、会議の席で無意味な演説をしても、それは賞賛され実質以上に評価される。そうして、自分自身が真に必要なことを決断しているのかどうかのフィードバックを見失ってしまう。

むしろ傾いた企業を立て直す経営者の判断にこそ学ばなければならないのかもしれない。しかし、それすら危うい場合があるのだ。見かけの数値上の改善は、その企業が持続的に立ち直ったことを意味するものではないからだ。リストラによって一時的に業績が改善したとしても、そのことによって士気が低下し、大事な人材の経験の継承という財産を減らし、やがて、立ち直るべくも無く業績が下降する場合もあるのである。

ひょっとしたら、経営者の資質を計るのは業績ではないのかもしれない。それは先見性でもない。ひとえに、現実の問題点を把握し、その意味を正確に測る能力ではないだろうか。好調なときには、そのなかに潜む具体的な危険の萌芽に気づき、業績が思わしくないときもその会社の社会における役割の可能性を発見できる現実性のような気がする。

しかし、どのようにすればそのような透徹した現実性を身につけることが出来るだろうか。それは、飽くなき好奇心を持つことと、物事を徹底的に多面的に考える習慣から得られるもののような気がする。地位や名誉などといった正確に測ることすら難しい幻影に惑わされず、今、自分の目に映っているものの本質とは何かということに考えを集中することの出来る能力を磨くことだ。

いや、徹底的に考えるとか、本質を見抜くという言葉自体が現実的でない。現実的とは、考えうるあらゆる事態に対して対策を考えるということだ。孫子の「算多きは勝ち、算少なきは負ける」ということだが、この算の中には負ける事も含まれているのだ。だから、あらゆる事態に対して備えるためには、決して一人で考えてはならない。他の人の意見に飲み込まれてはならないが、他の人の意見を聞くことで、起こりえる事態の選択肢を少しでも増やす気持ちを常に持っていなければならないのだ。

さらに、幸運不運の影響も過小評価してはならない。マイクロソフトの成功は、幸運のおかげでもある。しかし、幸運不運をあらかじめ予測することは全く不可能であるのは事実だ。

論理の本質は起こりえるすべての場合を考えつくすということだから、すべての可能性について検討していない考えは決して論理的ではないのである。

... と、ブログでこんなことをくどくどと書いているのが一番非現実的なわけで、要するに、アクセス数が伸びない鬱憤を晴らしているだけなのだったりする。
[PR]
by tnomura9 | 2006-04-14 01:02 | 考えるということ | Comments(1)

パターンマッチ

Racc を使ってみて分かったのが、パーサーはひたすらパターンマッチをおこなうプログラムだということだ。入力された文字列はまずスキャナでトークンの列に変換されるが、パーサの仕事はそのトークン列をひたすらパターンマッチし続けることなのだ。

パターンマッチという観点から見ると、構文解析プログラムとパーセプトロンとはよく似ているように見える。スキャナが文字列をトークンの列に変換するように、パーセプトロンの入力層の出力も中間層のセルの出力に変換される。また、トークン列をパーサがパターンマッチするように、中間層の出力もパターン分析されて出力層の出力になる。

構文解析では、スキャナは必須かというと、実はそうではない。パーサが入力されるあらゆる記号に対する文法を持っていれば、スキャナは必ずしも必要ではない。しかし、間にスキャナを介在させることによって、パーサの文法規則の数は、圧倒的に少なくなる。

ところで、スキャナもそのプログラムを見ると、パターンマッチ機械なのだ。したがって、スキャナとパーサを組み合わせた構文解析プログラムは、二階層のパターンマッチ機械なのだ。これは、入力層と中間層と出力層からなるパーセプトロンとその意味において同じものなのである。

ところで、出力層の出力に対して外部からのフィードバックをかける教師つきパーセプトロンは学習をすることができる。そうであれば、パーサに外部からの入力をフィードバックすることによって学習するパーサを作ることができるのではないだろうか。文法をあらかじめ提示しておかなくても、学習によって文法規則を学習していくパーサである。そんなパーサを十分に学習させた後、文字列を入力したときにどのような動作をするのかと考えると面白い。

パターンマッチが、学習や思考のセントラル・ドグマなのだろうか。
[PR]
by tnomura9 | 2006-04-13 21:11 | 考えるということ | Comments(0)

TOC(制約理論)の事例

TOC(制約理論)の日本における事例を見つけた。日本総研がコンサルタントをした、グンゼの子会社のタッチパネル製造のエルマ株式会社の事例だ。なんと製品製造のリードタイムが5分の1になってしまった。

小説「ザ・ゴール」が現実に
グンゼ株式会社電子部品事業部様/エルマ株式会社様 TOC適用による新生産システム構築プロジェクト

TOCの面白いところは、トヨタの看板方式のように現場のノウハウの集積や、理想を掲げてそれを追及していくという経験主義ではなく、現場の観察をもとに、生産ラインのシステムとしての振る舞いをモデル化して、そのモデルを最適化するためにはどうすればいいのかというトップダウンの考え方をしているところだ。

もちろん、そのモデルが現実のラインの振る舞いの本質を表していなければこの方法は机上の空論となるが、しかし、そのモデルがしっかりしていて、汎用性のあるものであるなら、同じような手法をいろいろな種類の生産ラインに当てはめることが出来る。汎用性において看板方式をはるかに凌ぐ可能性があるのである。

抽象的なモデルの振る舞いを、はっきりと制御できれば、様々な現場への応用が容易で、迅速になる。同じようなことは、論理学の形式的体系とモデルとの関係にも言える。形式的体系の定理はどのようなモデルに対しても定理であるので、いったん形式的体系とモデルとの対応関係が確立されれば、モデルのさまざまな振る舞いを予測することが出来るのだ。統語論が確立している形式的体系では、それに意味づけをするモデルの振る舞いを完全に予測できる。

プログラム開発の場合も、Racc の例でも分かるように、統語論的な構造が十分に研究されていれば、実用的なプログラムの開発もスピーディに行われるのだ。現実に起きるいろいろな現象を統語論的構造と意味論的現実主義にわけて考えてみることは大切なことのような気がする。
[PR]
by tnomura9 | 2006-04-10 19:39 | 話のネタ | Comments(0)

ブラックボックス読書法

システム分析でブラックボックスというのがある。中身の仕組みは分からないが、入力に対する出力の応答の特性だけを考えようというやり方だ。

これを読書にも応用してみよう。文書の段落をひとつのブラックボックスとみなし、その入力と出力だけを考えるというやり方だ。この際の入力とは段落の最初で提起される問題であり、出力とはその段落の結論だ。手元に『NHKまる得マガジン ここがポイント確定申告』 野口テル監修があるのでその5ページの文章を例にして実行してみよう。

納税は国民の義務です。税金を納めることによって、道路が整備されたり、社会保障が受けられたりと、生活が安全に保たれています。いい換えれば、税金は国民の共通会費といえるでしょう。
入力: 税金とは何か? 出力: 国民の共通会費


年が改まると、”確定申告”という言葉を耳にしたり、目にするようになってきます。
「確定申告は、基本的に自営業者がするもので、給与所得者(サラリーマンなど)は会社が代行して行ってくれているから関係ない」「会社で年末調整を行ったから、自分たちには関係ない」
はたしてそうでしょうか。昨年一年間、給与所得以外から、20万円を超える所得を得たことはありませんか?持っていた不動産を売ったりしていませんでしたか?この場合は、払わなければならない税金が出ていることも考えられます。
入力: 確定申告はサラリーマンには関係ないか? 出力: 税金をさらに払う場合がある。


また、家族の中で、病院にかかった人はいませんか?マイホームを購入して引越しをすませていませんか?故郷に住んでいる年老いたご両親に生活費の仕送りはしていませんか?これらも控除の対象になるかもしれません。”医療費控除” ”住宅ローン減税” という言葉は聞いたことがあると思います。しかし、申告しないと、控除も還付もされないのです。
入力: 税金が戻ってくることはないか? 出力: 申告しないと還付されない。

こうしてみると、段落というのは、質問に対する答えが出力されるブラックボックスであることが分かる。また、システム分析のアナロジーで行けば、異なった質問には異なった出力が得られる。つまり、関数なのだ。関数であれば、入力となる質問の集合は限定される、定義域である。また、現れる答えの範囲も限定される、値域だ。さらに、前の段落の出力が、次の段落の入力になっているときは、話がカスケードでつながっていく。文章といえどもひとつのシステムなのである。

また、質問に対する答えが得られるブラックボックスという観点から見ると、段落は一種のデータベースとも考えられる。クエリーをデータベースに発行すると、答えが検索されるのだ。データベースであれば、その内容を機械的にシステム的に調べることも出来るかもしれない。ひとつの文書をあらゆる観点から機械によって検討することが出来れば、契約書のトリックなどすぐに見つけることが出来るようになるだろう。

こういう文書情報処理の機械化は Google などに見られるように実際はものすごく進んでいるのかもしれない。身近に利用できるまでにはしばらく時間がかかるかもしれないが、文書からのデータの抽出や作成に、より多くの機械化が関与してくるようになるかもしれない。
[PR]
by tnomura9 | 2006-04-09 02:26 | 考えるということ | Comments(0)

自動思考機械としてのプログラミング

管理人が最初にパソコンを使い始めたころは、パソコンはマイコンと呼ばれていた。そのころは、マイコンはプログラミングをして遊ぶものだった。みんながみんな BASIC という、あまりできの良くないプログラム言語で、せっせとプログラムしていたものだ。マウスもなく、できることはモニターにアルファベットを表示することと、解像度が160*100ドットの6色のグラフィックができるくらい、日本語はカタカナが表示できるだけという代物だったが、管理人は夢中になった。

なんといっても、プログラムできるということが刺激的だった。自分の書いたプログラムのとおりに自動的に実行してくれるコンピュータは、テレビやラジカセとは違った興奮を与えてくれた。

そのうちに、コンピュータは飛躍的に発展し、ワープロやリアルなゲームが次々と現れたが、それに伴ってプログラミングも難しくなり、専門化し、素人が手を出す代物ではなくなった。

なにが、あれほどマイコンのプログラミングに管理人を夢中にさせたのか考えてみたが、ひとつは、思考が自動実行できるということではなかったのだろうかと思う。頭の中で考えたアイディアが、プログラムによって実体化し、動き始めるというところに魅力を感じたのだろう。自分の考えを検証してくれるもうひとつの脳を手に入れたような気がした。

コンピュータは本質的には命題論理学実行機械だ。無限を扱うことはできないが、有限のものならありとあらゆる事を表現できる。昨今のシミュレーションやゲームを見ると、コンピュータの表現能力の高さが感じられる。しかし、まだ、普通の人間の意思決定や学習の補助をしてくれるほどにはインターフェースが進化していないように見える。

しかし、Ruby の出現で少々事情が変わってきているのではないだろうか。エクセルに物足りなさを感じていた管理人も Ruby に出会ってから以前の興奮を思い出しつつある。Ruby のプログラミングはそれ自身が楽しい。プログラミングを行うというより、考えを記述しているという感じがする。アイディアを検証してくれる第二の脳の役割をパソコンがまた取り戻していきつつあるような気がする。
[PR]
by tnomura9 | 2006-04-07 07:22 | Ruby | Comments(0)