E Tsemi2008

等価変換理論集中セミナー 2008 講師 : 若槻俊宏（北海道大学大学院情報科学研究科） 2008 年 8 月 31 日 ( 日 ) 10:00-17:00 サイボウズ・ラボ

Early history of ET theory
もともとは自然言語処理のための研究
北海道大学 (90 年代初頭 )
知識表現と推論 (AI) の理論
-> 汎用の計算モデルに一般化された
この点も Prolog と似ている
もともとは自然言語処理のため
colmerauer & kowalski (70 年代初頭 )
研究が進むにつれて Prolog の改良では不十分であることがわかってきた
「プログラミング」の基礎付けとなる理論を一から作る
証明 = 計算 (Logic Programming) から
証明も計算も，等価変換という原理で基礎付ける

自然言語処理
形態素解析（字句解析）が一意に定まらない
構文解析が一意に定まらない
⇒ 人工言語の処理系のように，フェイズごとの処理では非効率すぎる
意味解析が形態素解析と構文解析に依存
意味（を成す文）を，綺麗に少数のルールで公理化できない
⇒ 統計的で雑多な知識から大量の推論ルールを自動生成する必要がある
⇒ 形態素解析と構文解析の統合処理が必要
⇒ 知識表現系，制約解消系，並列処理
⇒ より強力なプログラム構築のための方法論が必要
AI は常に強力なプログラミングパラダイムを求め続けてきた

論理プログラミング（ Logic Programming, LP ）
計算 = 証明というパラダイム
論理的問題を推論によって解決する
非常に宣言的で抽象度が高いプログラミング
宣言的プログラミングの礎を築いた
プログラム合成，プログラム変換
AI 的プログラミング
自然言語処理
制約充足問題（パズル）
エキスパートシステム（演繹 DB ，知識ベース）
に大きな影響を与えた

History of LP 数理論理学のプログラミングへの応用 (MIT Al lab) 宣言的知識と手続き的知識の違いは ? (MIT AI lab) Lisp (50 年代 ) Plannner (60-70 年代 ) Prolog (70 年代) 第五世代コンピュータ計画 ( 並列述語論理推論マシンとその OS) GHC/KL1 (80-90 年代 ) Concurrent Prolog/Parlog (80 年代 ) 制約論理プログラミング Prolog III / CLP (R) / CHIP (80-90 年代 ) 制約プログラミング CHR (90 年代後半) 制約操作ルール型プログラム Matz が語らない方面 LMNtal (2002) Smalltalk-71 Simula ( アクターモデル，ペトリネット，知識表現 ) 並列計算，メッセージパッシング， OOP 宣言的プログラミング制御構造の議論（コルーチン，継続）関数プログラミング論理プログラミング Oz , Mercury, Erlang (90 年代中 - 後半 ) 関数型などとのマルチパラダイム Prolog/KR (80 年代中盤 )

計算可能性の理論との違い
チューリングマシン，原始帰納関数，ラムダ計算，ポストマシン = チューリング等価
扱う最大範囲 (枠) を決めるだけ
どうやって欲しいプログラムを見つければ良いの ?
計算可能性の広大な空間理想のプログラム ?

プログラム変換とプログラム合成
プログラム = 論理 + 制御 + データ構造
「プログラム変換」，古川康一･溝口文雄共編
プログラム変換
プログラムの正しさを変えないで
プログラムを効率化する方向に
論理･制御･データ構造を変換する
プログラム合成
プログラムが満たすべき性質の記述 ( 仕様 ) から（願わくば全自動で）仕様を満たすプログラムを導く
プログラム変換の初期プログラムとなる
( 現代の聖杯，錬金術と揶揄されることも )

コンパイルとの違い
コンパイル
基本的に一対一対応
高レベル -> 低レベル
プログラム変換
同レベルの変換
非決定性（どれが最適なのかを選択)
コンパイルという言葉はあいまい
複雑なコンパイル -> プログラム変換 ?
単純で決定的なプログラム変換 -> コンパイル ?

従来の問題点
プログラミング言語に固有の変換技法
プログラムドメインに固有の変換技法
それら最適化技法のコレクション
の研究が一般的だった
それらを統一的に扱える理論的枠組み
もっと広範囲のプログラムを扱える枠組み
仕様 - プログラム合成 - プログラム変換 - コンパイル
シームレスに上から下までを扱える理論
プログラミングの本質を明らかにできる理論
が欲しい

探索のための羅針盤が欲しい
良いプログラムにたどり着くための理論
新しい視点，方向性，深い洞察の基礎
計算可能性の空間非決定的なアルゴリズム決定的なアルゴリズム形式的仕様記述実行可能なプログラム効率的なアルゴリズム

等価変換に基づくプログラム合成ハードウェア (FPGA) 低水準命令型プログラム確定節による仕様記述 Deterministic Rule Non-Deterministic Rule アルゴリズム探索の空間 N ルールでハードウェアの仕様を記述並列プログラム実行環境に最適な実装の探索望ましい仕様の探索の空間 What How Code

他のパラダイムの戦略
ざっくり分けると
命令型パラダイム (how の記述 )
命令の高級化
プログラムの部品化（オブジェクト指向，テンプレート）
一度に見渡せる範囲を大きく，一度に見る必要がある範囲を狭くすることにより，見通しを得ようとする
宣言型パラダイム (what の記述 )
問題を人間の推論に近いレベルの宣言的記述で整理する
数学的な検証や推論の力により見通しを得ようとする
プログラムから命令的な要素（副作用，実行順序）を排除し，抽象化とモジュール化を進める
（実際は，こんなに綺麗に分かれないけど）

他のプログラミングパラダイムとの違い
命令型 : 計算の理論
豊富なアルゴリズム
データ構造の自由度
宣言型 : 表現の理論
数学的な検証（関数型，論理型，制約プログラミング）
人間に近いレベルの表現
処理効率表現効率処理効率表現効率

宣言的言語の理論
どのように表現できるか，が主な関心事
表現可能性の理論
効率的に計算できるか ? は理論の外
例 : ペアノ算術やラムダ計算の理論
データは全て項で表現される
1 = S(0), 2 = S(S(0))
表現可能性の点では申し分無い理論
統一的な表現
様々な性質が証明できて有用
しかし，計算効率的には最悪

命令型言語の理論 (?)
そもそも理論が無い
あるけど，後付け（現場の要請ドリブン）
現実の機械の非本質的制約
コスト（部品の調達可能性などもろもろ）
既存の生産ラインとの親和性
会社の資本力，従業員の能力，人材の供給性
いかに効率よく機械を動かせるか，の理論
計算効率の理論
豊富なデータ構造やアルゴリズムを駆使
統一性も理論も無いが，計算効率を追求できる

表現と計算の理論
表現効率と計算効率を最大化する理論
ET が目指すところ
自動化できるところは自動化する
自動生成と推論を重視する
人間が，よりインテリジェントで本質的な部分に集中できるように
処理効率表現効率

表現と計算の両立の難しさ
表現力，移植性 ⇔ 高性能のトレードオフ
プログラミング言語の処理系に限らない
OS とか， VM とか， GUI とか，なんでもそう
上のレイヤーのために高級な機能 (how) を提供するソフトウェア全てのジレンマ
上のレイヤー ? 何が本当に重要なの ?
本来は中間のレイヤーは不要
上のレイヤーに必要な機能だけあれば良い
必要な機能に応じて，実装がチョイスされれば良い
トップレベルとは何か ? -> アプリケーションの仕様
それ以外は全て不純物（郭海皇）

高級な言語の問題点
命令 -> 宣言型のスペクトルのどこか
高級な機能 (how) を提供
言語仕様 = 提供する how のリスト
ライブラリでより高級な機能を提供
処理系の実装で効率が決まる
それぞれの処理系ごとに，実装戦略のトレードオフを取っている
全ての処理系で効率の良いライブラリを書くのは不可能
how ありきで進むことの限界を示している
how は what に依存し，推論によって決定されるべき

DSL じゃ駄目なの ?
Domain Specific Language : 領域特定言語
DS Embedded Language とも（汎用言語に埋め込む言語）
内部 DSL : プログラムを宣言的に書けるようにいろいろ工夫したもの（マクロなどの言語機能を使う）
外部 DSL ( 仕様からのプログラム生成も含む広い概念 )
プログラミング言語は how を表現する枠組み
表現の対象が違うならば，分けましょう（自然な発想）
what の枠組み（仕様記述言語）の中で， what のような how を書く Prolog -> 無理筋（失敗）
how の枠組み ( プログラミング言語 ) 中で what のような how を書こうとするの -> （おそらく）筋が悪い

Paul Graham もこう言っているメソッド
「埋め込み言語によって抽象化を最高に活用できるが，それは魔法ではない．非常に抽象的な表現から高速なマシン語に至る道のりを歩き通したいならば，やはり誰かがコンピュータにその方法を教えなければならない．この章では道のりのかなりの部分を驚くほど少ないコードで進んで来たが，それは本物の Prolog コンパイラを書くこととは違うのだ．」
(On Lisp ( 野田開訳 ) ， p.354)
DSL の限界
ET の枠組みが目指すもの

ET 計算モデル
状態 (state) : 確定節で表現
状態遷移関数 : ET ルールで表現
優先度付き確定節集合の書き換えルール
ET ルール : 仕様 < D , Q > の意味を保存する
A  a 1 , a 2 , …, a n . B  b 1 , b 2 , …, b m . A’  ‘a 1 , … B’  ‘b 1 , … C  c 1 , c 2 , …, c l . 等価変換 M ( D ∪ st) = M ( D ∪ st’) st st’

宣言的記述の意味
空集合から始めて任意有限回の変換で得ることができる全てのグラウンドアトムの集合
ground atom : 変数を含まないアトム
アトム : p(t 1 , t 2 , …, t n )
項 t i ∈ {cal T} の定義はプログラムごとに変わる
論理プログラムの場合
エルブラン基底項上の意味
任意有限回の推論で得られる基底項の集合（最小モデル）
ET の場合，プログラムの扱うデータ構造は特殊化システムによって決定される（より一般的）
Γ + P ( 特殊化システム Γ 上のプログラム P)
プログラムが扱う項の集合を決定する

宣言的記述の意味の具体例
節集合 D (定数は [] のみ)
A([]) 
A([X])  A(X).
D の意味 M(D) = ∪ n=1 ∞ T D n (0)
T D 1 (0) = T D (0) = {A([])}
T D 2 = T D (T D 1 (0)) = T D 1 (0) ∪ {A([[]])}
{A([]), A([[]])}
T D 3 = T D (T D 2 (0)) = T D 2 ∪ {A([[[]]])}
{A([]), A([[]]), A([[[]]])}
…

仕様 (specification)
問題の背景知識の集合 (定義) : D
与えられる質問の集合 (入出力) : Q
定義域は D に依存して決定する
仕様 : D と Q の組 <D, Q>
D Q 確定節の集合クエリアトムの集合

仕様空間 Σ
Σ = <SPEC, PROB, ANS, cover , answer >
SPEC : 仕様 <D,Q> の集合
PROB : 問題 prb の集合
ANS : 任意のグラウンドアトムの冪集合
cover (<D,Q>) = Q
answer (<D,Q>, prb) = T prb (M(D))
全ての仕様のテンプレート
ET の理論は
ET の理論に依存しない一般的な枠組みを用意（仕様空間 Σ など )
その中で ET の理論を具体化 (ET 仕様空間 Σ ET など )
他の仕様記述やプログラムの理論をその中で具体化することにより，厳密に比較や本質を研究することが可能になる
この枠組みにより ET ルールと CHR の関連などが明らかにできた

仕様空間 Σ ET の具体例
D rv = {rv([], [])  ,
rv([A|X], Y)  rv(X,R),ap(R,[A],Y),
ap([], X, Z)  ,
ap([A|X], Y, [A|Z])  ap(X, Y, Z) }
Q fwd = { {ans(v)  rv(gl,v)} |
(gl is finite ground list) & (v ∈ V)}
Q bwd = { {ans(v)  rv(v, gl)} |
(gl is finite ground list) & (v ∈ V)}
S 1 = <D rv , Q fwd >
S 2 = <D rv , Q bwd >
S 3 = <D rv , Q fwd ∪ Q bwd >
prb 1 = {ans(X)  rv([1, 2], X)}
prb 2 = {ans(X)  rv(X, [1, 2])}

定義Ｄに対して正当な計算を行うためにはどうすれば良いか ?
Prolog (Logic Programmin) の回答 : 仕様をプログラムとして使えば良い
SLD 導出 (letf-to-right execution) でできるよ
そうすれば，仕様 (what) に関して正しい手続き (how) を必ず実行できる（自明だけど）
ただし，アルゴリズムやデータ構造は固定
それ以上の発展はできない (D を変えない限り )
仕様 = 解くべき問題の定義
効率のために問題自体を変えちゃうの ???

Prolog の無理筋の代表例 : cut
手続きを表現できない言語の苦し紛れ
宣言に手続き的意味を付けるという蛮勇
ルールの概念が無い言語で無理やりルールを表現している
cut （の一部）はガードとして素直に解釈･表現できる
Prolog の cut
A  a 1 , a 2 , …, a n , ! , b 1 , b 2 , …, b m .
GHC/KL1 のガード
A  a 1 , a 2 , …, a n | b 1 , b 2 , …, b m .
ET の条件部 (applicable condition)
A, {a 1 , a 2 , …, a n }  b 1 , b 2 , …, b m .

not の定義例
Prolog による定義
not( X ) :- X, !, fail.
not( _ ).
ET D ルールによる定義
(not *X), {(call *X)}  (false).
(not ?)  .
そもそも Prolog は真の Logic Program ですらない
SLD 導出アルゴリズムの手続き的性質に依存しなければ not も表現できない
上から下に，左から右に実行されるという性質に依存
宣言的意味は完全に等価なプログラムでも，アトムを書く順番によって効率が著しく変動する
場合によっては無限ループに入り，解けない

構成的プログラミング
形式的仕様の構成的証明からプログラムを得る
構成的証明 : ある性質を満たすオブジェクトを作って示す
論理式 = 型，証明 = プログラム
Curry-Howard 同型対応
アプリケーション
The Coq proof assistant
http:// coq.inria.fr /
Calculus Of Inductive Constructions の証明から OCaml コードを自動生成できる
70 ~ 90 年代に一時流行って ( 廃れた )
仕様に対して正しいプログラムは出せるけど
( 構成 ) 論理式で仕様を書くのが大変だった ?
プログラムを最適化するための枠組みが無いから ?

ET Solution
仕様とプログラムの空間を分ける
わかってしまえばコロンブスの卵
問題記述から，それを解くルールを生成する
初期ルール集合は Prolog と大差ない how
本当は，Prolog よりももっと良い how （ＥＴルール）をいきなり出すための研究も盛ん．論理等価式とか．
ここらへんは論文がまだパブリッシュされてない最新の成果が多いのであまり大っぴらに語ってはいけない部分が多い…
初期ルール集合から探索（メタ計算など）して，さらに多くの ET ルールを生成する
LP の理論では正当性が証明できないような how も生成できる
構成的プログラミングよりも発展性がある（出力して終わりじゃない）

プログラム空間 Π
状態遷移プログラム空間 : <PROG, PROB, COMP, ANS, compute , obtain >
全てのプログラム空間のテンプレート
Π ET = 状態遷移プログラム空間のテンプレートを
STATE = 宣言的記述 ( 確定節 )
PROG = <Rule, ≦>
ET ルールの集合とその上の半順序 (quasi-order)
のように具体化したもの

正当性関係 Corr
「プログラムが仕様に対して正しいとはどういうことか ? 」の形式的定義（テンプレート）
<Σ,Π> が与えられた時以下を満たしている
compute(prg, prb) が定義されている
compute(prg, prb) ≠ 0 ( 空集合 )
foreach com ∈ computer(prg, prb)
obtain(prg, com) が定義されている
answer(S, prb) が定義されているならば
obtain(prg, com) = answer(S, prb)
<Σ,Π> における正当なプログラムの空間は， <S, prg> ∈ SPEC × PROG における， S に対して正当な prg の全てのペアの集合

Prolog の場合
What から一つの自明な How しか出ない
How を変えるためには What を変えないといけない（D に対する正当性が議論できない）
単に，ハイレベルで書けるから，バグが少なくて正しそうでしょ ? 以上のことは何も言えない
D SLD-resolution などの実行アルゴリズムで直接実行

ET の場合
正当な How を What から自動生成
D から独立して How を膨らませていくことができる
常に D に対する正当性を議論できる
拡張された How の空間を探索できる
< D,Q > < D,Q > より良い How を仕様の空間プログラムの空間絞り出し法メタ計算メタ計算 + 帰納法と探索方向のモチベーションの理論 ( まだ秘密 ?)

ET 正当性関係 Corr ET
<Σ ET , Π ET > が与えられた時
Rule が D に対する ET ルールのみで構成
プログラムが停止性を満たす
foreach prb ∈ cover(S) if com ∈ compute(prg, prb) then com is finite.
プログラムが適用可能性を満たす
最終状態以外で変換が止まらない
(reach(prg, S) – FIN) ⊆ dom(τ(prg)).

参考文献
ETI (ET ルールインタプリタ ) やリファレンスマニュアル
http:// assam.cims.hokudai.ac.jp/et/indexj.html
論文はここからだいたい取れます
http://assam.cims.hokudai.ac.jp/akama/indexj.html
ET 計算モデル [1]
Kiyoshi Akama, and Ekawit Nantajeewarawat: Formalization of the Equivalent Transformation Computation Model, Journal of Advanced Computational Intelligence and Intelligent Informatics, vol.10, No.3, pp.245-259, 2006
メタ計算（自動で ET ルールを仕様から生成する研究）
いろいろありすぎて，どれがまとまってるのかちょっとよくわからない（駄目）
搾り出し法 ( 半自動で ET ルールを仕様から生成する手法 )
Kiyoshi Akama, Ekawit Nantajeewarawat, and Hidekatsu Koike: Program Generation in the Equivalent Transformation Computation Model Using the Squeeze Method, PSI 2006, LNCS 4378, Springer-Verlag Berlin Heidelberg, pp.41-54, 2007

ET ルール (2 種類ある)
Deterministic Rule (D ルール )
変換する（クエリ節中の）アトムと，適用するルールの選択が決定的
確定節の左から右にアトムを実行する
ルールは上から下に選択する
SLD resolution に対応
Non-Deterministic Rule (N ルール )
アトム ( の多重集合 ) とルールの選択が非決定的
多重集合 : 重複を許す集合
ルールがマルチヘッドなので，集合の中から，どのようにアトムを選択するかについて任意性がある
適用可能なルールのうち，どのルールを適応するかに任意性
全部適用するモードもある（コストが大きいので普通はやらない）

クエリ節 (入力された質問) の扱い
a 1 , a 2 , …, a n が成り立つならば A が成り立つ
A を成り立たせるためには a 1 , a 2 , …, a n を成り立たせれば良い（宣言的意味の手続き的解釈）
SLD resolution (D ルール ) の世界では，確定節のボディはアトムの列のような扱い
N ルールの世界ではアトムの多重集合
並列動作するオブジェクトの集合と見ても良い
A a 1 a 2 … … a n

N ルールの非決定的計算 ST i ST i+1 ルール r を適用ルール r’ を適用アトム選択の非決定性ルール適用の非決定性ルール r’’ を適用

ETI が扱うN ルールのクラス
N ルールを計算するのは非常にコストが高い
ETI では，効率化のため，上から下にルールを検索し，一番最初に適用可能な条件を満たした N ルールのみを適応するようにしている
(setExhaustiveMode *world true) で 1 ステップずつ全通り計算をすることは可能
プログラム変換で効率化することを前提にしている
言語仕様と実装は
違うクラスでも良い
（理論重要）
真の N ルールのクラス ETI が通常扱うN ルールのクラス

Prolog の理論的限界と N ルールによる解決の具体例
palpal 問題
pal (palindrome : 回文 )
回文か否かの判定述語
グラウンドな query ならば Prolog も解ける
pal([1, 2, 1]) => true
Pal([1, 2, 3]) => false
問題は変数を含む query ( 解が無限 )
ans(X)  pal([1 | X]), pal([2 | X]).
D の空間の知識だけでは解けない

なぜ解けないのか ?
Prolog でも X = [] までは解ける
ans(X)  pal([1 | X]), pal([2 | X]).
その後，他の解の可能性を探しにいって無限ループ
SLD resolution では， X の加算無限回の具体化の後，解が [] のみであることを決定できる
つまり，永遠に解けない
問題をメタレベルで眺め，解決するための手続きを生成する枠組みが存在しないことが本質的原因
Prolog の探索の本質が，具体例の代入に基づいていることに由来する理論的限界

問題の定義 D palindrome
palindrome(X)  reverse(X, X)
reverse([], []) 
reverse([A | X], Y)  reverse(X, R), append(R, [A], Y)
append([], X, X) 
append([A | X], Y, [A | Z])  append(X, Y, Z)
長くなるので，それぞれ pal/rv/ap と略記する

D pal に対して正当な ET ルール ( の，必要最小限の一部 )
pal(*x) ⇒ rv(*x, *x).
rv([], *x) ⇒ {=(*x, [])}.
rv([*a | *x], *y) ⇒ rv(*x, *v), ap(*v, [*a], *y).
rv(*x, [*a | *y]) ⇒ {=(*x, [*u | *v])}, rv(*v, *w), ap(*w, [*u], [*a | }y]).
rv(*x, *y), rv(*x, *z) ⇒ {=(*y, *z)}, rv(*x, *y).
ap(*x, [*a], [*b]) ⇒ {=(*x, []), =(*a, *b)}.
ap(*x, [*a], [*b, *c | *y]) ⇒ {=(*x, [*b | *v])}, ap(*v, [*a], [*c | *y]).
ap(*x, *y, [*a | *z]) ⇒ {=(*x, []), =(*y, [*a | *z])}; ⇒ {=(*x, [*a | *v])}, ap(*v, *y, *z).

計算パスの例
Initial 質問節集合 {ans(X)  pal([1 | X]), pal([2 | X]) }
pal(*x) ⇒ rv(*x, *x). を 2 回適用 {ans(X)  rv([1 | X], [1 | X]) , rv([2 | X], [2 | X]) }
rv([*a | *x], *y) ⇒ rv(*x, *v), ap(*v, [*a], *y). を 2 回適用 {ans(X)  rv(X, A1) , ap(A1, [1], [1 | X]),
rv(X, A2) , ap(A2, [2], [2 | X])}
rv(*x, *y), rv(*x, *z) ⇒ {=(*y, *z)}, rv(*x, *y).
適用

肝になるルール
rv(*x, *y), rv(*x, *z) ⇒ {=(*y, *z)}, rv(*x, *y).
計算の発散を収束させるルール
本来無限回の計算が必要なのを，有限回に押し込める
参考文献 [1] の時点では人間の閃きで作ってる
その時点では「人間が追加したルールは ET ルールである」ということを仮定していたらしい
実は本当に厳密に D に対して ET ルールであることが証明可能になったのは，つい最近だったり
現在は（まだ査読中の論文に載っている，論理等価式に関する研究成果により） D の定義から自動生成可能になっている

計算パス例･続き
rv(*x, *y), rv(*x, *z) ⇒ {=(*y, *z)}, rv(*x, *y).
{ans(X)  rv(X, A1), ap(A1, [1], [1|X]) , ap(A1, 2], [2|X])}
ap(*x, *y, [*a | *z]) ⇒ {=(*x, []), =(*y, [*a | *z])}; ⇒ {=(*x, [*a | *v])}, ap(*v, *y, *z).
 {ans([])  rv([], []), ap([], [2], [2]),
ans(X)  rv(A, [1|A3]) , ap(A3, [1], X), ap([1|A3], [2], [2|X])}
rv(*x, [*a | *y]) ⇒ {=(*x, [*u | *v])}, rv(*v, *w), ap(*w, [*u], [*a | }y]).
{ans([])  rv([], []), ap([], [2], [2]),
ans([A6|A4])  rv(A4, A5), ap(A5, [A6], [1|A3]),
ap(A3, [1], [A6|A4]), ap([1 | A3], [2], [1, A6 | A4]) }

計算パス例･続き
{ans([])  rv([], []), ap([], [2], [2]),
ans([A6|A4])  rv(A4, A5), ap(A5, [A6], [1|A3]),
ap(A3, [1], [A6|A4]), ap([ 1 | A3], [2], [ 2 , A6 | A4]) }
ap(*x, [*a], [*b, *c | *y]) ⇒ {=(*x, [*b | *v])}, ap(*v, [*a], [*c | *y]).
{ans([])  rv([], []), ap([], [2], [2]) }
ap(*x, [*a], [*b]) ⇒ {=(*x, []), =(*a, *b)}.
{ans([])  rv([], []) }
rv([], *x) ⇒ {=(*x, [])}.
{ans([])  }
Unification 不可能
False
矛盾した節は消える

拡張された手続きの世界の探索
LP と ET の違いの本質（ ET の力の本質）
Prolog は D の中での議論しかできない
D の内部でしか理論的に保障された探索ができない
ET は， D を拡張した世界の中の材料を使って議論できる
拡張された世界の力を利用できる
( Ｄから生成した ET ルールから ) 新しく生成した ET ルールの力を使って，無限ループのキャンセルなど，強力な演算ができる
（詳細は，まだ論文になっていない他人の成果なので微妙だったり）

ET solution により広がる可能性
ET ルール生成による仕様の検証
Prolog は how が暗黙的
仕様が不完全の場合
確定節の集合に何を追加すれば良いのか ?
何を追加すれば，どのような how が出るのか ?
が不明確
ET ルールの形で how を生成する
欲しい how を出すためには，どういう仕様が必要なのか，逆検証できる

アルゴリズム教育の側面（ not プログラミング教育）
アルゴリズムを作る理論の研究
-> アルゴリズムの教育の研究
ルールの積み上げによるプログラミング
分割統治の概念とルールは相性が良い
（大問題） -> (中問題), (中問題), (小問題)
意味の概念に基づくデバッグ
直感や経験だけではない，科学的なデバッグ
デバッグやプログラミングに科学的な根拠を導入して説明・教育できる（可能性がある）

自分の研究
大目標
「コンパイル」という概念を体系化したい
中目標
D プログラムの実用的なコンパイル体系を確立したい　（実装依存まで踏み込む）
小目標
D プログラムと命令型プログラムの関係を理論化する　（理論化しやすい綺麗な部分から）

Paul Graham もこう言っているメソッド
「コンパイル」という言葉にはいくつかの意味がある (on Lisp (野田開訳) , pp353-4)
抽象的な記述 -> 低レベルのコード
プログラムをマシン語に変換すること
その言語のレベルでの最適化を行うこと
ET の世界では，さらに「仕様のコンパイル」と「アルゴリズムのコンパイル」的な要素が入ってくる ?
最適な仕様，最適なアルゴリズム，最適なプログラム
広限定

プログラムのコンパイルとは何か　 ?
「コンパイル」　には様々なレベルがある
展開後の命令の粒度
最適化のレベル（ほぼインタプリタ->最適化コンパイラ）
高級　 C コード　（抽象命令型プログラム）
インタプリタの評価関数呼び出しに対応するレベル
人間がライブラリを使って書いたレベルのコード
抽象機械語
VM の抽象命令　 ( これもいろいろなレベルがある )
ぎりぎり高級言語
Low-level の　 C コード
アセンブラ構文の代わりに　 C 構文で書いているレベル
アセンブリコードまで落とす
VM と同様にいろいろレベルがある　 (CISC/RISC)
いろいろな軸があってよくわからない世界

コンパイラとインタプリタ
原理的にはインタプリタからコンパイラが生成できる
二村理論 ( 写像 )
Futamura, Y. : “ partial computation of programs” , Lecture Notes in Computer Science 147, Springer-Verlag, 1983
プログラムの特殊化 ( 部分計算 ) がキー
特定のプログラム P を目的プログラム C(P) に変換するコンパイラ C と , インタプリタ I と特定のデータ D に対して
C(P)(D) = I(P,D)
I P (D) = I(P,D) とすると I P = C(P)
C = peval I (P, I p )
peval R (u, R u ) = peval(R, u, R u )
データ u に関して関係 R を特殊化したものが R u である

ET の世界での捉え方
D ルールの計算
N ルールの計算
．．． ST init ST fin ST init ST3 fin ST2 fin ST1 fin ST0 fin 正当な計算パスが複数存在する効率的なパスを一つだけ選択

ET の世界におけるコンパイル
計算パスの縮約
正当な計算パスのうちどれを選択するか　?
Nルール/Dルール，それぞれの空間で探索する
D ルールにもいろいろなクラスがあるはず（自分の研究）
データ構造の縮約
リッチな表現を，どのようにしてプアな構造で効率的に表現すればよいのか　?
特殊化システム　(Specialization System)　という ET の理論体系で統一的に扱えないか ? (自分の研究)

特殊化システムの動機
宣言型パラダイムの歴史と問題点
宣言型言語のプアなデータ構造
Prolog, Lisp : なんでも項とリスト
豊富なデータ構造を扱う理論が無い
解が正しいということまでしか考えない ( 良い解放であるかまでは議論しない理論 )
宣言型言語の歴史　 = データ構造をリッチにする歴史
効率的な表現と計算のため
Prolog -> 　制約プログラミングへの流れ　（固定された how-> 多様な how ）
項と unification 一本　->　豊富な制約 solver
制約　 solver が処理系に組み込み
Prolog II : 無限木データ構造
LOGIN : ψ 　項　 ( クラス階層 )
Uranus/TDProlog : 項記述
cu-prolog : 素性構造 ( 知識表現，自然言語処理 )
{log} : 有限集合データ構造
CHIP : finite domain とその上の　 domain-variable
CFT : レコード
DOT : DOT 式　 (IS-A 関係の知識表現 )
Quixote 　 : オブジェクト項　 ( 演繹　 OO データベース言語 )
LiLFes : 型付き素性構造
LMNtal : 多重集合

特殊化システムの歴史
論理オブジェクトに基づく知識表現言語　 UL/α 　　　　　 [ 繁田 et.al, 95]
特殊化システムと情報付き変数
データ構造のユーザ定義を許す言語
組み込み固定ではなく，パラメータ化して扱う理論
背景
論理プログラムの等価変換による問題解決の枠組み　　　　　　　 [ 赤間 et.al, 95]
正当性と高速性を両立するために　「推論による計算」　に代わる新しい枠組みが提案された
論理的問題の等価変換による解決　 (1) [ 赤間 et.al, 98]
それまでは論理的問題は推論によって解くのが常識
等価変換という一般的な概念で解きたい　（動機）
ET 言語の前身
( 私見では，まだ宣言型言語　 (Prolog) の影響が濃い )

様々な計算のパラダイムを統合
情報付き変数の有用性　 ( 論理オブジェクトの実現 )
例　 : 関数型パラダイム
論理オブジェクトの最汎単一化　 = 遅延評価
与えられた式の，正規形を，最小回数の，簡約で求める
遅延評価　 = 正規形に限定された遅延実行
一般的な計算の枠組みとは言えない
関数論理型言語
論理プログラムに等号を導入
等式単一化　 ( ナローイング )
論理オブジェクトの特殊化　 = 関数の計算
言語を変更する必要が無い
特殊化システム上で単一化が拡張されるだけ

現在の具体的な研究テーマ
まだ話すほどまとまってない…
一応，学振に出したテーマ
「アルゴリズム探索に基づいて実行環境や実行例に適応するプログラムの理論と構築」
現状では， D プログラムを命令型に変換するためのアルゴリズムと，その正当性に関する論文をまとめている
そもそも D プログラムや命令型プログラムって何 ? ってところからまとめている

研究背景
実行環境が多様化してきている
手作業で移植するのは大変
実行環境の情報と，その環境でのプログラムの使われ方を基に，自動的に適応して欲しい
実行環境の情報にはさまざまなものがある
どのようにして表現するかも研究（知識表現）
とりあえず今は，決定的アルゴリズム（D ルール）から命令型のプログラムを生成する研究
まだ，探索とか，知識表現とかは未着手

D ルール
決定的アルゴリズムをテキスト表記したもの
学生の教育などの際には R 式で記述
h, {c 1 , …, c l }  {e 1 , …, e m }, b 1 , …, b n .
ヘッドアトム h にマッチし，条件アトム列 c 1 , …, c l を満たしたならば，特殊化アトム列 e 1 , …, e m を実行した後， h を b 1 , …, b n に置き換える
プログラム生成や変換の際の中間言語として使う場合は S 式で
( as h c 1 … c l : e 1 … e m b 1 … b n )

枠組みの全体像 CPU 命令の知識変換システム低水準 C プログラム ARM CPU アセンブリプログラム X86 CPU アセンブリプログラム D プログラムの知識プログラミング言語の知識実行環境の知識プログラム構造の知識等価変換型プログラム命令型プログラム知識から様々なシステムが生成異なるシステムからは異なるプログラムが出力 N プログラムの仕様を満たす D プログラム空間豊富なプログラムの可能性を探索可能 CPU 命令の知識低水準抽象命令型プログラム低水準抽象命令型プログラム変換システム低水準 C プログラム ARM CPU アセンブリプログラム X86 CPU アセンブリプログラム D プログラムの知識プログラミング言語の知識実行環境の知識プログラム構造の知識等価変換型プログラム命令型プログラム知識から様々なシステムが生成異なるシステムからは異なるプログラムが出力低水準決定的抽象プログラム低水準決定的抽象プログラム抽象命令型プログラム抽象命令型プログラム N プログラムの仕様を満たす D プログラム空間 D プログラム D プログラム豊富なプログラムの可能性を探索可能低水準抽象命令型プログラム低水準決定的抽象プログラム抽象命令型プログラム D プログラム

まとめ
等価変換に基づく問題解決の枠組み
宣言的表現から高速なマシン語に至る道のりをコンピュータに体系的に教えるための理論（を目指す）
プログラム合成の研究のための新しい枠組み
プログラミングの本質の理解･形式化
自分の研究
理論の世界と現実の世界を体系的につなぐための理論の構築を目指している
ET モデルの一番下のレベルの体系化を行っている
まぁ，長い目で見ていただければ… （亀の歩みである）

共同研究者募集中！
まだマイナーな分野だが将来性は十分にある
最近は知名度が高まり，論文も普通に通るように
研究のネタはいくらでもある（慢性的人手不足）
プログラム生成以外の理論研究もいろいろ
無限計算の理論，セマンティックウェブ (DL) の新しい基礎付け， LP の ET による新解釈，．．．
「組まないか ? 私と！！」 (by 寂海王 )
「必要なんだ．キミのような共同研究者が」
「そして… 悩める計算機科学を導く」

http://alohakun.blog7.fc2.com	188
http://www.slideshare.net	6
file://	1
http://72.14.235.132	1

E Tsemi2008

by alohakun on Sep 01, 2008

Accessibility

Upload Details

Usage Rights

4 Embeds 196

Statistics

E Tsemi2008 Presentation Transcript