[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1406] Re: Object Oriented の問題点 + Prolog による解決





隆一です。


From: Hideaki Suzuki <h1suzuki@bridgew.edu>
Subject: [b-free: 1401] Object Oriented の問題点 + Prolog         による解決
Date: Sun, 19 Apr 1998 14:25:46 -0400


...[snip]...

> 
> 
> えっと、Night さんの指摘していた問題点というのは、Object Oriented という
> concept は対象がまず在ると言うことが背景となっている。そして、対象が特定
> できない場合に、問題だ。という話でしたでしょうか? ここまで、僕に誤解は
> ないですか?

ここへのコメントは、[b-free:1404] で書いたので省略。



> そうなると、対象が特定できない状況というのがどんなものかという話になるで
> しょうかねぇ。
> もしくは、時計の例のように、対象の情報を集めて必要な情報を「抽出する」と
> いう話です。
> 
> こいつはある意味、prolog とかの WHAT 型言語ですね。
> 知っての通り prolog では、今までの言語と違い、いかにして情報を抽出するか
> という「手続き」を書く代わりに、何を抽出するかという「目標 (goal と称さ
> れるもの)」を書きます。そして、目標を program に与えてやることで実行が
> 開始され、目標を program によって表現された知識を元により基礎的なものへ
> 置き換えていくことで最終的な操作対象を発見するわけです。

...[snip]...

> 
> Prolog の問題点は、大きく3種類在ります。
> 
>  1.無限 loop を引き起こしやすい。
>    さらに、program の文を入れ替えると「効率や処理結果」に影響する。
>  2.「閉世界仮定」をしている。知識のないものは「分からない」で
>    はなく「No」になる。「証明できないものは存在しない」とい 
>    う policy かな。
>  3.ある種の algorithm を非常に記述しにくい。たとえば、sort を行おう
>    とした場合、prolog での効率的な処理方法は見付かっていない。
>    「否定」を非常に記述しにくい。cut operator という美しくないも
>    のを導入して大部分解決しているが、それでも不完全。
> 
> 
> 2はOSという観点から見れば、ある主体にとって「存在しないものは、参照さ
> れたくない」わけで、問題ないと思われます。3はこの場合、prolog を object
> 発見手段にのみ使っていますので、大きな問題にはならないだろうと。1のみが
> 大きな問題ですねぇ。Non-deterministic TM 風に、検索の目標適合時に常に
> thread を生成し、すべての可能性を同時並列検索すれば、問題はないでしょう
> が、それに掛かる大変な数の thread を思うと、すこし、怖いです。prolog の
> 多少の言語仕様変更により、大分軽くなるかもしれませんが、とにかく、その手
> の変更をしないとだめでしょうね。
> 

うーん、2.が一番問題のように思いますが。
つまり、2.は、Prolog プログラムは、「全て知っている」という前提で動
いており、「知らないこと(もの)は、存在しない」ということですよね。
こういう前提だと、たとえば「時計」を新しく追加する場合、知識ベースを変
更しないと「時計」を認識できなくなってしまうわけです。

鈴木さんは、OS が自分の動いているマシンの資源についての情報を公開(どこ
に?)することによって、知識ベースを構築することを考えているように思い
ます。この場合、あらかじめ何に対する情報が聞かれるかというのが分からな
いという問題があります。すべての要求に対して、あらかじめ有効な情報を記
憶しておくというのは不可能でしょう。
(フレーム問題でしたっけ?)

# ところで、知識ベースはどこに記憶するんでしょうか?
# 知識ベースにアクセスするためにも、また検索が必要なような。。。


並列 Prolog (のようなもの)としては、あの第5世代プロジェクトで作られた
GHC というのがありましたね。もっとも、こちらにはバックトレースの機構が
ありませんでしたが(並列処理とバックトレースとは相性が悪いのかな?)。
GHC だと並列処理の単位が節なので、ひとつひとつの処理の負荷自体はそれほ
ど大きくないと思います。


p----------------------------------------------------------------------q
| FROM R.Night                                                         |
| E-mail:                                                              |
|         rnaitoh@st.rim.or.jp                                         |
| Key fingerprint = 89 EB 77 95 40 C0 3C CC  37 A1 A7 FA 1C 66 FF D0   |
b----------------------------------------------------------------------d