http://w.atwiki.jp/hebolisper/ hebolisperのネタ帖 ja 2008-04-22T22:15:44+09:00 1208870144 https://w.atwiki.jp/hebolisper/pages/30.html 2008-04-22T22:15:44+09:00 1208870144 https://w.atwiki.jp/hebolisper/pages/29.html 子供を学校に屆けるだけではなく、お金をかせいだり、一日の残りをどのようにすごすかも考えてみてください。GPSは下のような構文でそういった問題を簡単に解決することができます。 > (gps '(son-at-home have-money car-works) '(have-money son-at-school) *school-ops*) (EXECUTING DRIVE-SON-TO-SCHOOL) SOLVED しかしながら、お金をバッテリーにつかうような次の例では正しくない成功が返ってきてしまいます。 > (gps '(son-at-home car-needs-battery have-money have-phone-book) '(have-money son-at-school) *school-ops*) (EXECUTING LOOK-UP-NUMBER) (EXECUTING TELEPHONE-SHOP) (EXECUTING TELL-SHOP-PROBLEM) (EXECUTING GIVE-SHOP-MONEY) (EXECUTING SHOP-INSTALLS-BATTERY) (EXECUTING DRIVE-SON-TO-SCHOOL) SOLVED この「バグ」はGPSはゴールのセットをするために(every #'achieve goals)という表現を使うせいです。この表現がtrueを返すなら、ひとつずつ順にゴールたどりつくことを意味しますが、それは最終的にtrueだったことは意味しません。言いかえると、(have-money son-at-school)というゴールは、have-moneyとson-at-schoolが最終的に両方存在している状態であればtrueなのですが、GPSにとっては「最初にhave-moneyを、それからson-at-schoolを」という意味にとります。一つのゴールにたどりつくまでは、別のゴールを達成しないといったこともあります。こういったことを「prerequisite clobbers sibling goal(厳密でひどい兄弟ゴール)」問題と呼んでいます。have-moneyとson-at-schoolは兄弟の問題であり、そのうちson-at-schoolのためにはcar-worksが必要で、その目的のためにhave-moneyが必要になります。 「prerequisite clobbers sibling goal」問題を認識したプログラムの更新を直接的に行ってみましょう。最初に(every #'achieve something)というのはプログラムの中で2回呼びだされているところを、(achieve-all something)におきかえましょう。achieve-allは下記のように定義できます。 (defun achieve-all (goals) "すべてのゴールを試し、その状態を確認する" (and (every #'achieve oals) (subsetp goals *state*))) Common Lispのsubsetpは第一引数がsubsetに2番目のものが含まれていたらtrueを返します。achieve-allでは、すべてのゴールを試したあとで現在の状態がそれぞれゴールのうちの一つがゴールだったらtrueを返します。これを確認しましょう。 achieve-allによって、GPSがひどいゴールのときにtrueを返さないようになりますが、ひどいゴールから回復しようとしたり再計画するようにはなっていません。可能性についてここでは言及しませんが、Sussmanの例をあとのセクションでとりあげます。 2008-01-25T05:29:49+09:00 1201206589 https://w.atwiki.jp/hebolisper/pages/28.html 「家から学校までのドライブ」のoperatorは前提条件、家にいるなどのdelete-list、学校にいるなどのadd-listといった簡単な内容でした。では、"runnning aroud the block"というのはどうでしょうか?居場所もかわりませんし、addやdeleteといったものを意味するlistもありません。そうなるとoperatorを適用する理由はないでしょう。もしかしたらadd-listは「エクササイズしたい!」とか「つかれた」とか、もっと一般的な「ブロックを走った経験」などを含むべきでしょう。こういった問題にはのちほど応えます。 2008-01-25T05:26:38+09:00 1201206398 https://w.atwiki.jp/hebolisper/pages/27.html 以下のセクションでは、このGPSの一般的な問題点についてあつかいます。次の4つのセクションでは、このversionのGPSの限界を指摘し、次のプログラムでこれらの制限をどのように訂正していくかをみていきます。 制限をバグという人もいます。しかし私たちはプログラムの「拡張」によって、「訂正」していきます。この点に明確な答がないのは、不明瞭な問題の記述や仕様のせいではありません。AI Programmingは巨大な探検なのです。対象には明確な仕様を定義する以上の問題が隠されているのです。コードが書かれてはじめて問題点がみえてくるというのは、よくある一般的な概念なのです。 2008-01-25T05:25:17+09:00 1201206317 https://w.atwiki.jp/hebolisper/pages/21.html * 4 [[GPS:The General Problem Solver]] ** 4.1 [[Stage 1: Description]] ** 4.2 [[Stage 2: Specification]] ** 4.3 [[Stage 3: Implementation]] ** 4.4 [[Stage 4: Test]] ** 4.5 [[Stage 5: Analysis, or "We Lied About the G"]] ** 4.6 [[The Running Around the Block Problem]] ** 4.7 [[The Clobbered Sibling Goal Problem]] ** 4.8 The Leaping before You Look Problem ** 4.9 The Recursive Subgoal Problem ** 4.10 The Lack of Intermediate Information Problem ** 4.11 GPS Version 2: A More General Problem Solver ** 4.12 The New Domain Problem: Monkey and Banana ** 4.13 The Maze Searching Domain ** 4.14 The Blocks World Domain ** 4.15 Stage 5 Repeated: Analysis of Version 2 ** 4.16 The Not Looking after You Don't Leap Problem ** 4.17 The Lack of Descriptive Power Problem ** 4.18 The Perfect Information Problem ** 4.19 The Interacting Goals Problem ** 4.20 The End of GPS ** 4.21 History and References ** 4.22 Exercises ** 4.23 Answers 2008-01-25T04:06:34+09:00 1201201594 https://w.atwiki.jp/hebolisper/pages/26.html このセクションでは"学校までドライブする"というドメインにつイて、list operatorを定義し、そのドメインにいける問題をどのように作成し、解決するのかをみていきます。最初に必要なのはドメインについてのlist operatorの構築です。defsstructは下記のとおり、opの型のmake-opを自動的に定義します。 (make-op :action 'drive-son-to-school :preconds '(son-at-home car-works) :add-list '(son-at-school) :del-list '(son-at-home)) この表現はactionがdrive-son-to-schoolというactionと、その前提条件であるadd-list,del-listという分割されたlistを返します。このoperatorの意図するところは、いつでも息子は自宅にいて、車は動作し、driving-to-schoolを適用すると息子が自宅にいる状態が削除され彼が学校にいるという状態に変更されるということです。 son-at-homeのように長いフレーズにハイフンをつけて表現する方法はシンプルで有効な手段です。よりよい表現はもしかしたら(at son home)かもしれませんが、これはatomではなくなってしまいます。atom-basedなアプローチの問題点の一つは組み合わせです。もし、10個の述語と10人とオブジェクトがあった場合は、利用可能なatomが10 * 10 * 10 = 1000になってしまいますが、componentなら20ですみます。明かに、componentを記述する方が簡単でしょう。この章では、世界記述の全部に必要ではないのでと単純さのために、ハイフンつきのatomを利用します。別の章ではもっとより深い知識表現をとります。 このoperatorを使ったモデルでは、109ページで引用したNewellとSimonの引用に対応する別のoepratorを定義できます。バッテリーの設置、店で問題を修理、店への電話などです。電話番号を調べたりとか店にお金を支払うなどの"and so on"もoperatorを追加することで実現できます。 (defparameter *school-ops* (list (make-op :aciotn 'drive-son-to-school :preconds '(son-at-home car-works) :add-list '(son-at-school) :del-list '(son-at-home)) (make-op :action 'shop-install-battery :preconds '(car-needs-battery shop-known-problem shop-has-money) :add-list '(car-works)) (make-op :action 'tell-shop-problem :preconds '(in-communication-with-shop) :add-list '(shop-knows-problem)) (make-op :action 'telephone-shop :preconds '(known-phone-number) :add-list '(in-communication-with-shop)) (make-op :action 'look-up-number :preconds '(have-phone-book) :add-list '(known-phone-number)) (make-op :action 'give-shop-money :preconds '(have-money) :add-list '(shop-has-money) :del-list '(have-money)))) 次のステップ定義した問題をGPSで解決するかを試すことです。3つの問題があります。それぞれの場合、goalは同じson-at-schoolという状態です。利用できるoperatorのlistには、それぞれの問題は同じですが、最初の状態が異なります。3つのGPSを読んだ場合、Lispシステムでどうなるかを試してみます。(gps...というのがuserの入力で、 (EXECUTE...というのがプログラムの出力で、結果はSOLVEDかNILになります。 > (gps '(son-at-home car-needs-battery have-money have-phone-book) '(son-at-school) *school-ops*) (EXECUTING LOOK-UP-NUMBER) (EXECUTING TELEPHONE-SHOP) (EXECUTING TELL-SHOP-PROBLEM) (EXECUTING GIVE-SHOP-MONEY) (EXECUTING SHOP-INSTALLS-BATTERY) (EXECUTING DRIVE-SON-TO-SCHOOL) SOLVED > (gps '(son-at-home car-needs-battery have-money) '(son-at-school) *school-ops*) NIL > (gps '(son-at-home car-works) '(son-at-school) *school-ops*) (EXECUTING DRIVE-SON-TO-SCHOOL) SOLVED すべての例のgoalはson at schoolです。son-at-schoolがadd-listに含まれるoperatorはdrive-son-to-schoolだけで、GPSは最初にそれを選択します。operatorが実行される前に、GPSは前提条件を解決します。最初の例では、shop-installs-battery, give-shop-money, tell-shop-problem, telephone-shopを通して前提条件のないlookup-numberをみつけます。その上で、lookup-numberが事項され、programは別のアクションに移ります。アリストテレスによれば「解析というのは、最初から順にやっていくことである」。 2番目の例は最初は同じなのですが、look-up-number operatorがhave-phone-bookを実行できないために失敗します。直接、間接を問わず、電話番号が前提条件ですが、そこに該当するアクションがないため、GPSはNILを返します。 最後に3番目の例ですが、より直接的で、車が動けばdriving operatorは直接実行できます。 2008-01-15T07:52:51+09:00 1200351171 https://w.atwiki.jp/hebolisper/pages/25.html 仕様が完全であるのならCommonLispに十分実装できます。図4.1にGPSをCommonLispを使って実装するための値、データ型、関数をまとめておきます。 |GPS|Top level関数。operatorのlistをつかって、状態をゴールまで解決する| |*state*|特殊変数：現在の状態| |*ops*|特殊変数：利用可能なoperatorのlist| |op|データタイプ：add-listとdel-listの前提条件つきoperation| |achieve|関数：単一のゴールを達成する| |appropriate-p|operatorがgoalに対して適切かを決定する| |apply-op|現在の状態にoperatorを適用する| |member|CommonLisp関数：listにmemberが含まれているかをテストする| |set-difference|setの中のそれ自身を含まないlistを返す| |union|2つのlistを連結する| |every|elementごとにlistからテストにパスしたを返す| |some|listからテストにパスしてlistを返す| |find-all|elementにマッチしたすべてのlistを返す(p101)| そして、これが完全なコードです (defvar *state* nil "現在の状態：条件のリスト") (defvar *ops* nil "利用可能なoperatorのリスト") (defstruct op "Operation" (action nil) (preconds nil) (add-list nil) (del-list nil)) (defun GPS (*state* goals *ops*) "General Problem Solver: *ops*をつかって、すべてのgoalを達成する" (if (every #'achieve goals) 'solved)) (defun achieve (goal) "もしすでに到達してるならgoalを達成する。そうでないなら適切なopがあれば、それを適用する" (or (member goal *state) (some #'apply-op (find-all goal *ops* :test #'appropriate-p)))) (defun appropriate-p (goal op) "もしadd-listにあるなら、opがgoalに適切であるかを判定する" (member goal (op-add-list op))) (defun apply-op (op) "opが適用されたときに、メッセージを表示し、更新を行う" (when (every #'achieve (op-preconds op)) (print (list 'executing (op-action op))) (setf *state* (set-difference *state* (op-del-list op))) (setf *state* (union *state* (op-add-list op))) t)) 見たところ、プログラムは7つの定義でできています。7つのアイテムの仕様は上のとおりです。一般的にいって、仕様と実装は対応になるものではありません。通常は、仕様と実装の間における対応は完全ではありません。二つのdefvar、1つのdefstruct、4つのdefunがあります。これらは変数、構造体、関数のCommon Lispによる定義です。これらは、ほとんどのLispにおいてはtop levelにありますが、それらは魔法ではなく、Lispの環境にたいして、新しい定義を追加するという副作用のspecial formなのです。 下に再掲した二つのdefvarでは、*state*と*ops*という名前の特殊変数を宣言していて、プログラム中からのどこからでもアクセス可能です。 (defvar *state* nil "現在の状態：条件のリスト") (defvar *ops* nil "利用可能なoperatorのリスト") defstructはaction, preconds, add-list, del-listといったslotのあるopという構造体を定義します。CommonLispにおける構造体はCやPASCALのものと同じです。defstructは自動的にmake-opというconstructor関数とop-action, op-preconds, op-add-list, op-del-listというアクセス関数を生成します。defstructはさらに、copy-opというcopy関数、op-pという述語とsetf定義によって各slotを変更できるようにします。GPSプログラムではそれらは使われていません。おおまかに言うと、defstructは (defstruct op "Operation" (action nil) (preconds nil) (add-list nil) (del-list nil)) であり、下記の定義はdefstructによって拡張されたものです。 (defun make-op (&key action preconds add-list del-list) (vector 'op action preconds add-list del-list)) (defun op-action (op) (elt op 1)) (defun op-preconds (op) (elt op 2)) (defun op-add-list (op) (elt op 3)) (defun op-del-list (op) (elt op 4)) (defun copy-op (op) (copy-seq op)) (defun op-p (op) (and (vectorp op) (eq (elt op 0) 'op))) (setf (documentation 'op 'structure) "An operation") 次に、GPSプログラムの4つの関数定義です。main関数はGPSで、3つの引数をとります。最初は世界の現在の状態、次がGoalの状態、3つめが使用できるOperatorです。関数の中身は簡単に言えば、もしGoalに到達可能であればそれを実行し、問題を解決します。そうでない場合には問題は解決できません。 achieve関数は引数にgoalをとります。関数は現在の状態がすでにgoal(実際にはなにもしない)か、適切なoperatorを適用したならば、関数は成功します。適切なoperatorのlistのうちのうち、何か適用できるまでこの操作は続きます。achieveが101pageで定義したfind-allを呼びだします。これを使って、find-allが現在のgoalにappropriate-p述語によってマッチしたoperatorのlistを返します。 appropriate-pはoperatorが適切なゴールになるかどうかをテストする関数です(Lispではこのような述語においては利便性のために末尾に-pをつけます) 最後にapply-opではすべての適切な前提条件をachieveし、operatorを適用できます。これにはメッセージを表示しdelete-listから削除し、add-listに追加するoperatorによって、作用させ、世界の状態を変更します。さらにapply-opは適用したoperatorを返します。 2008-01-15T06:37:14+09:00 1200346634 https://w.atwiki.jp/hebolisper/pages/24.html この点におけるアイデアは、あいまいさが許されるなら、GPSで解決する問題がなにを意味するかということだろう。Lispにそって気付いたことを表現していくと次のようになる。 - "なにを持っているか"という現在の状態と、目的の状態"何を欲っしているか"の条件のセットを表現することができる。CommonLispは setsのデータタイプは持ってないが、listはあり、listでsetを実装することができる。それぞれの状態はsymbolで表現することができる。そうすれば、典型的なゴールはlistの2つの条件(rich famous)になるし、典型的な現在の状態も表現できる(unknown poor)。 - 許される演算子のlistが必要になる。このlistは前提条件や問題にかぎらず一定であるが、新しい問題のドメインに対しては変更可能である。 - operatorはactionの構造や前提条件のlistや効果のlistとして表現される。現在の状態から条件を追加削除することができる効果を可能な限り設置することができる。そして、効果のlistを追加のlistと削除のlistに分割する。これはGPS実装のSTRIPSという方法によるもので、この章でそれについては扱う。オリジナルのGPSは仕様の作用に対して柔軟ではあるが、それゆえ効率的ではない。 - GPSによって記述される完全な問題は、最初の状態、ゴールの状態と、知られているoperatorのsetである。なので、GPSは3つの引数をとる関数となる。たとえばこのように呼びだす。 (GPS '(unknown poor) '(rich famous) list-of-ops) 別の言葉でいうと、poorでunknownな状態ではじまって、operatorを組み合わせて、richでfamousになる。GPSは問題が解決されたらtrueを返し、どのようなactionをしたかを表示する。もっとも単純な方法は、ゴールにたどりついたときに、それを実行することである。もし、すべて達成されれば、問題は解決されている。 - 単純なゴールの状態は2つの方法で達成される。現在の状態がそうであれば、ゴールですることはなにもない。そうでなければ適切operatorを探し、適用する。 - 作用のうちの一つのoperatorが現在の状態にgoalのquestionを足すなら、それは適切なoperatorである。 - すべての前提条件を達成できるなら、operatorを適用できる。前のパラグラフから、ゴールを達成したという概念を定義すればよいのだから、これは簡単。一度、前提条件が達成されたら、operatorの適用はactionの実行を意味し、add-listとdelete-listによって現在の状態が更新されるということになる。プログラムはシミュレーションなので-実際には車を運転したり、電話をかけたりするのだけど-単純にactionの内容を表示して、実際の行動は特になにもしない 2008-01-10T07:44:50+09:00 1199918690 https://w.atwiki.jp/hebolisper/pages/23.html MEMO:このページは少々ひどいので、あとで直す。 問題を記述するにあたって、はじめにNewellとSimonの1972年の論文「Human Problem Solving」をみてみましょう &italic(){GPSの主要な手法は人間の手段目的解析を具象化してむすびつけることです。手段目的解析の典型は下記のcommon-senseから引用でしょう。} 子供を保育園につれていきたい。持ってるものと必要なものはなにか?。一つは距離だ。 何が距離を変えるだろう。自動車。自動車は動かない。動かすには何が必要か? バッテリー。バッテリーは新しいか?車は店で修理する。車を店にもっていき、 修理しなければならない。店は私が何を必要としているかを知らない。何が難しいか? コミュニケーション。どうすればいいのか?電話...などなど &italic(){その種の分類解析の機能化というのは終端までのゆらぎの間で、要求を機能化し、すべき手段をならべ、GPSの選択基本システムで選択するということがある。} 解析は新しいことではない。手段目的解析は2300年まえにアリストテレスが「ニコマコス倫理学」の"自然の検討とその物質"にエレガントな記述をしている(Book III. 3,1112b) &italic(){最後まで検討せずとも意味はある。医者は彼が治るかを検討しない、演説者は彼を説得できるかを検討しない、法律家は法や秩序の作成を検討しない、誰も死を検討しない。終わりを過程し、それがどのようになるのか、なんの意味があるのかを考える。生みだされたことに何かの意味があるかのように。......} この問題解決のセオリーについての記述で、なにをプログラムすべきだろうか?最初に、引用されたプロシージャのアウトラインを理解しようとする。何かしたい状態が問題になったときに、手段目的解析とよばれるプロセスをつかって問題解決をはかるようにする。これが主な考え方である。NewellとSimonの例では、問題は子供を学校につれていくことであるが、一般的にはもっと広い問題の分類の解決についてプログラムしないといけない。"持っているものと欲しいものの差"をなくすことができれば、問題は解決できる。たとえば、子供が家にいて学校に行かせたいなら、ドライブすれば解決する。なぜならドライブは位置を変更するからである。手段目的解析の使用というのは、現在の位置から、ゴールにすすむ方法を検索するか、検索戦略の違いをまぜあわせてしてもってくる、ということに気づいただろうか。 いくつかのアクションは前提条件として副問題を解決することを要求する。車を運転する前に、車が動くかどうかという副問題を解決する必要がある。車が動くとしたら副問題がなくなる。適切なアクションをして直接問題を解決するか、最初の前提条件を解決してアクションすることになる。アクションするのに必要な記述を前提条件と効果に沿って明らかにし、適切な定義を開発する必要があるだろう。しかし、よりよい定義をしたら、それ以上の定義は必要なくなる。問題の記述が完了したとなれば、次の問題の仕様化にうつることになる。 2008-01-10T06:37:48+09:00 1199914668 https://w.atwiki.jp/hebolisper/pages/22.html General Problem Solverは1957年にAlan NewellとHerbert Simonによって開発され、確実に問題を記述するできれば、すべての問題を解決するたった一つのコンピュータプログラムという壮大なvisionを与えられました。GPSが紹介されたたときにひきおこした混乱によって、知性マシンの偉大な時代がやってきたとAIのことを考えた人々もいました。SimonはGPSについてこう述懐しています &italic(){ショックを与えたかったんじゃないんだ。...でも、一番簡単にまとめようとすると、マシンが考え、学び、創造するということだった。もっと言えばその能力はどんどんすごい勢いで増大していく...未来においては、それらの扱うことのできる問題が人類の知性の広がりと同じだけのもつようになる、ということだ。} けれども重要なプログラムの歴史的な問題のせいで、GPSはその誇張された期待には応えられませんでした。最初のプログラムは解決の戦略的と問題の知識が分割されておらず、それが問題解決のための調査に拍車をかけました。これらすべての理由が学習にからみあったのです。 オリジナルのGPSプログラムほかにもいくつか小さな問題がありました。さらに、それあIPLという低レベルの言語で記述されていて、それが余計に複雑にしていました。事実、GPSにおける理由のおおきなものに、IPLによって起きる混乱がありました。プログラムが複雑であれば、それはより重要になります。オリジナルのプログラムを無視してCommonLispにおきかえれば、IPLを使うより明快になるでしょう。その結果、GPSはかなりシンプルになり、AIのいくつかの重要な点が明らかにされました。 一つの1レベルとして、この章ではGPSを扱います。しかし、もう一つのレベルとしてAIコンピュータプログラミング開発のプロセスをとりあげます。プログラム開発は5つのステージにわかれています。最初に問題の記述、英語の散文の記述についてのラフなアイデア、なにをしたいのか。次にプログラムの仕様、問題をどのようにコンピュータプロシージャに近い形に書きなおすべきか。3つめはCommonLispによる実装。4つめはテスト。5つめはデバッグと解析です。その境界は流動的で、各ステージは完全なものではありません。問題はステージをすすむと前のステージとは変化しますが、プロジェクトを再デザインしたり放棄したりということはありません。プログラマーは部分的に記述、仕様、実装、テストと完璧にしていき、よりよい理解にもとづく完璧な仕様を得ます。 5つのステージでGPSを開発すれば、GPSのプログラムはより読みやすく、書きやすくなることでしょう。まとめると、AIプログラミングの5つのステージは以下のとおりになります。 1. 問題をはっきりした形で記述する 2. アルゴリズムの形で問題の仕様を決める 3. 問題をプログラミング言語で実装する 4. 例を使って問題をテストする 5. 結果をDebugと解析し、プロセスを繰り返す。 2008-01-10T04:58:07+09:00 1199908687