META-INTERPRETERS AND META
Download
Report
Transcript META-INTERPRETERS AND META
META-INTERPRETERS AND
META-PROGRAMMING
Ivan Bratko
Faculty of Computer and Info. Sc.
Univ. of Ljubljana
BASIC META-INTERPRETER
% The basic Prolog meta-interpreter
prove( true).
prove( ( Goal1, Goal2)) :prove( Goal1),
prove( Goal2).
prove( Goal) :clause( Goal, Body),
prove( Body).
SIMPLE TRACING META-INTERPRETER
prove( true) :- !.
prove( ( Goal1, Goal2)) :- !,
prove( Goal1),
prove( Goal2).
prove( Goal) :write( 'Call: '), write( Goal), nl,
clause( Goal, Body),
prove( Body),
write( 'Exit: '), write( Goal), nl.
TRACING META-INTERPRETER WITH RETRY
% trace( Goal): execute Prolog goal Goal displaying trace information
trace( Goal) :trace( Goal, 0).
trace( true, Depth) :- !.
trace( ( Goal1, Goal2), Depth) :- !,
trace( Goal1, Depth),
trace( Goal2, Depth).
% Red cut; Dept = depth of call
% Red cut
trace( Goal, Depth) :display( 'Call: ', Goal, Depth),
clause( Goal, Body),
Depth1 is Depth + 1,
trace( Body, Depth1),
display( 'Exit: ', Goal, Depth),
display_redo( Goal, Depth).
trace( Goal, Depth) :display( 'Fail: ', Goal, Depth),
fail.
% All alternatives exhausted
display( Message, Goal, Depth) :tab( Depth), write( Message),
write( Goal), nl.
display_redo( Goal, Depth) :true
% First succeed simply
;
display( 'Redo: ', Goal, Depth), % Then announce backtracking
fail.
% Force backtracking
METAINTERPRETER FOR
PROLOG WITH CONSTRAINTS
solve( Goal) :solve( Goal, [ ], Constr).
% Start with empty constr.
% solve( Goal, InputConstraints, OutputConstraints)
solve( true, Constr0, Constr0).
solve( (G1, G2), Constr0, Constr) :solve( G1, Constr0, Constr1),
solve( G2, Constr1, Constr).
METAINTERPRETER CTD.
solve( G, Constr0, Constr) :prolog_goal( G),
% G a Prolog goal
clause( G, Body),
% A clause about G
solve( Body, Constr0, Constr).
solve( G, Constr0, Constr) :constraint_goal( G),
% G a constraint
merge_constraints( Constr0, G, Constr).
MERGE CONSTRAINTS
Predicate merge_constraints:
constraint-specific problem solver,
merges old and new constraints,
tries to satisfy or simplify them
For example, two constraints X 3 and X 2 are simplified into
constraint X 2.
GENERATING PROOF TREES
% Prolog meta-interpreter that generates a proof tree
:- op( 500, xfy, <== ).
% prove( Goal, ProofTree)
prove( true, true) :- !.
prove( ( Goal1, Goal2), (Proof1, Proof2)) :- !,
prove( Goal1, Proof1),
prove( Goal2, Proof2).
prove( Goal, Goal <== Proof) :clause( Goal, Body),
prove( Body, Proof).
EXPLANATION-BASED GENERALISATION
EBG = Machine learning from one example only!
Lack of examples compensated by domain theory
Given:
Domain theory (can answer any question)
Operationality criteria
Training example
Find:
Generalisation of training example +
Operational definition of target concept (in terms of operational
predicates)
Note: EBG can be viewed as a program compilation technique
Inefficient program (domain theory) Efficient specialised program
A DOMAIN THEORY ABOUT GIFTS
% Figure 23.3 Two problem definitions for explanation-based
generalization.
% For compatibility with some Prologs the following predicates
% are defined as dynamic:
:- dynamic gives/3, would_please/2, would_comfort/2,
feels_sorry_for/2, likes/2, needs/2, sad/1,
go/3, move/2, move_list/2.
% A domain theory: about gifts
gives( Person1, Person2, Gift) :likes( Person1, Person2),
would_please( Gift, Person2).
gives( Person1, Person2, Gift) :feels_sorry_for( Person1, Person2),
would_comfort( Gift, Person2).
would_please( Gift, Person) :needs( Person, Gift).
would_comfort( Gift, Person) :likes( Person, Gift).
feels_sorry_for( Person1, Person2) :likes( Person1, Person2),
sad( Person2).
feels_sorry_for( Person, Person) :sad( Person).
% Operational predicates
operational( likes( _, _)).
operational( needs( _, _)).
operational( sad( _)).
% An example situation
likes( john, annie).
likes( annie, john).
likes( john, chocolate).
needs( annie, tennis_racket).
sad( john).
THEORY ABOUT LIFTS
% Another domain theory: about lift movement
% go( Level, GoalLevel, Moves) if
% list of moves Moves brings lift from Level to GoalLevel
go( Level, GoalLevel, Moves) :move_list( Moves, Distance),
Distance =:= GoalLevel - Level.
% A move list and distance travelled
move_list( [], 0).
move_list( [Move1 | Moves], Distance + Distance1) :move_list( Moves, Distance),
move( Move1, Distance1).
move( up, 1).
move( down, -1).
operational( A =:= B).
LIFTS
% Another domain theory: about lift movement
% go( Level, GoalLevel, Moves) if
% list of moves Moves brings lift from Level to GoalLevel
go( Level, GoalLevel, Moves) :move_list( Moves, Distance),
Distance =:= GoalLevel - Level.
% A move list and distance travelled
move_list( [], 0).
move_list( [Move1 | Moves], Distance + Distance1) :move_list( Moves, Distance),
move( Move1, Distance1).
move( up, 1).
move( down, -1).
operational( A =:= B).
GIFTS THEORY
gives( P1, P2, G)
likes(P1,P2)
would_please(G,P2)
feels_sorry_for(P1,P2)
would_comfort(G,P2)
P1=P2
needs( P2, G)
likes(P1,P2)
sad(P2)
sad(P1)
likes(P,G)
Training example
gives(john,john,chocolate)
gives( P1, P2, G)
likes(P1,P2)
would_please(G,P2)
feels_sorry_for(P1,P2)
would_comfort(G,P2)
P1=P2
needs( P2, G)
likes(P1,P2)
sad(P2)
sad(P1)
likes(P,G)
EBG AS PROLOG META-INTERPRETER
% ebg( Goal, GeneralizedGoal, SufficientCondition) if
% SufficientCondition in terms of operational predicates
% guarantees that generalization of Goal, GeneralizedGoal, is true.
% GeneralizedGoal must not be a variable
EBG, CTD.
ebg( true, true, true) :- !.
ebg( Goal, GenGoal, GenGoal) :operational( GenGoal),
call( Goal).
ebg( (Goal1,Goal2), (Gen1,Gen2), Cond) :- !,
ebg( Goal1, Gen1, Cond1),
ebg( Goal2, Gen2, Cond2),
and( Cond1, Cond2, Cond).
% Cond = (Cond1,Cond2) simplified
ebg( Goal, GenGoal, Cond) :not operational( Goal),
clause( GenGoal, GenBody),
copy_term( (GenGoal,GenBody), (Goal,Body)),
ebg( Body, GenBody, Cond).
% Fresh copy of
% (GenGoal,GenBody)
EBG, CTD.
% and( Cond1, Cond2, Cond) if
% Cond is (possibly simplified) conjunction of Cond1 and Cond2
and( true, Cond, Cond) :- !.
% (true and Cond) <==> Cond
and( Cond, true, Cond) :- !.
% (Cond and true) <==> Cond
and( Cond1, Cond2, ( Cond1, Cond2)).
WHY:
copy_term( (GenGoal,GenBody), (Goal,Body))
Proofs of Goal and GenGoal follow the same structure
They both must use the same program clause:
GenGoal :- GenBody.
This is checked by matching:
(Goal :- Body) = (GenGoal :- GenBody)
But, this check must be done without changing GenBody
Therefore: copy_term( (GG,GB), ...) produces a copy (GG’,GB’), and
this is matched: (GG’,GB’) = (Goal,Body)
EXPLANATION-BASED GENERALISATION
What is the logical relation between generalised goal GENGOAL
and derived operational condition COND?
What is the role of the example in EBG?
What is the difference between EBG and goal unfolding?
ABDUCTIVE REASONING
Types of logical reasoning:
deduction
induction
abduction
Abduction useful for explanation, construction, planning, e.g.:
patient’s symptoms
systems failures
Disease D causes symptom S; patient P has symptom S;
So, infer that P has D
Abduction considered as unsound rule of inference
FORMALLY
Given a Theory and an Observation
Find an Explanation, such that
Theory & Explanation |== Observation
Compare with definition of ILP: given BK and Examples, find
Hypothesis such that:
BK & Hypothesis |-- Examples
Discuss differences between abductive and inductive reasoning
% An example from Missiaen, Bruynooghe, Denecker 92
:- dynamic faulty/1, lamp/1, current_break/1. % Needed in SICStus by clause/2
faulty( L) :lamp( L),
broken( L).
% Device L faulty - doesn't work
% Device is a lamp
% Lamp broken
faulty( L) :lamp( L),
current_break( L).
% No electric current in lamp
current_break( L) :fuse( L, F),
% Fuse F connected to lamp L
melted( F).
% Fuse F is melted
current_break( L) :general_power_failure.
lamp( a).
lamp( b).
abducible( broken( Device)).
abducible( melted( Fuse)).
abducible( fuse( Device, Fuse)).
abducible( general_power_failure).
ABDUCING METAINTERPRETER
% abduce( Goal, Delta): Delta is a list of abduced literals
abduce( Goal, Delta) :abduce( Goal, [ ], Delta).
% abduce( Goal, Delta0, Delta):
% Delta 0 is "accumulator" variable with Delta as its final value
abduce( true, Delta, Delta) :- !.
abduce( ( Goal1, Goal2), Delta0, Delta) :- !,
abduce( Goal1, Delta0, Delta1),
abduce( Goal2, Delta1, Delta).
abduce( Goal, Delta0, Delta) :clause( Goal, Body),
abduce( Body, Delta0, Delta).
ABDUCING METAINTERPRETER, CTD.
% Now abduction reasoning steps:
abduce( Goal, Delta, Delta) :member( Goal, Delta).
% Already abduced
abduce( Goal, Delta, [Goal | Delta]) :abducible( Goal),
retract( index( I)), !,
% Lowest free index for new constants
numbervars( Goal, I, J), % Replace variables by Skolem constants
asserta( index( J)).
% Next free index
ABDUCTION, AUX. PREDICATES
:- dynamic index/1.
index( 1).
member( X, [X | L]).
member( X, [Y | L]) :member( X, L).
ABDUCTION, AUX. PREDICATES
USUALLY PROLOG BUILT-IN
numbervars( Term, N0, N) :var( Term), !,
Term = var/N0,
N is N0 + 1
;
atomic( Term), !,
N = N0
;
Term =.. [Fun | Args],
numberargs( Args, N0, N).
numberargs( [], N, N).
numberargs( [ Arg | Args], N0, N) :numbervars( Arg, N0, N1),
numberargs( Args, N1, N).
PATTERN-DIRECTED SYSTEMS
Set of program modules executed in parallel
Module’s execution triggered by patterns in their data environment
Data environment
Similar to Blackboard Systems
EXAMPLE
Greatest common divisor D of A and B:
while A and B not equal, do
if A > B replace A := A - B else replace B := B - A
D = A (or B)
Pattern directed modules
ConditionPart ---> ActionPart
[ Cond1, Cond2, ...] ---> [ Action1, Action2, ...]
PATTERN-DIRECTED PROGRAM FOR GCD
:- op( 800, xfx, --->).
:- op( 300, fx, num).
[ num X, num Y, X > Y ] --->
[ NewX is X - Y, replace( num X, num NewX) ].
[ num X] ---> [ write( X), stop ].
% An initial database
num 25.
num 10.
num 15.
num 30.
TRACE OF THIS PROGRAM
Data environment initially contains:
25
10
15
30
Trace execution here
Program works for any number of numbers!
% A small interpreter for pattern-directed programs
% The system's database is manipulated through assert/retract
:- op( 800, xfx, --->).
% run: execute production rules of the form
%
Condition ---> Action until action `stop' is triggered
run :Condition ---> Action,
test( Condition),
execute( Action).
% A production rule
% Precondition satisfied?
% test( [ Condition1, Condition2, ...]) if all conditions true
test( []).
% Empty condition
test( [First|Rest]) :call( First),
test( Rest).
% Test conjunctive condition
% execute( [ Action1, Action2, ...]): execute list of actions
execute( [ stop]) :- !.
execute( []) :run.
% Stop execution
% Empty action (execution cycle completed)
% Continue with next execution cycle
execute( [First | Rest]) :call( First),
execute( Rest).
replace( A, B) :retract( A), !,
assert( B).
% Replace A with B in database
% Retract once only