using ai planning to implement algorithm composition context sensitive domain-independent algorithm...
TRANSCRIPT
Using AI Planning to Implement Algorithm Composition
Context Sensitive Domain-Independent Algorithm Composition and Selection.Troy A. Johnson and Rudolf EigenmannPurdue University
1
Motivation
Increasing programmer productivity Typical language approach: increase
abstraction abstract away from machine; get closer to problem do more using less code reduce software development & maintenance costs
Domain-specific languages / libraries (DSLs) provide high level of abstraction e.g., domains are biology, chemistry, physics, etc.
2
Query a remote database and save the result to local storage:Query q = bio_db_query_genbank_new(“nucleotide”, “Arabidopsis[ORGN] AND topoisomerase[TITL] AND
0:3000[SLEN]”);
DB db = bio_db_genbank_new();
Stream stream = get_stream_by_query(db, q);
SeqIO seqio = bio_seqio_new(“>sequence.fasta”,
“fasta”);
Seq seq = next_seq(stream);
write_seq(seqio, seq); 5 data types 6 procedure calls
A Common BioPerl Call Sequence
3
A Library Designer’s Problem
“Everything should be made as simple as possible, but not simpler” Create useful fundamental building
blocks Don’t include redundant ones, even
though they might be convenient
Library user is expected to compose sequences of “fundamental” calls
4
A Library User’s Problem
Novice users don’t know these call sequences procedures documented independently tutorials provide some example code
fragments not an exhaustive list may need adjusted for calling context (no copy paste)
User knows what they want to do, but not how to do it
5
Bridging the Gap
Build (semi) automatic tools to help users specify what they want and get what they need.
6
Agenda
A brief introduction to Automated Planning Algorithm Composition Using Planning
Mapping composition to planning DIPACS
Language, compiler and planner Limitations
Where do we go from here?
7
PlannerInitial State
Goal State
Plan Actions
Plan User World
World is composed of objects Actions modify objects' properties and
relationships Planner deals with a symbolic model
A Domain-Dependent Planner
Simplified View of Planning
Operators
A Domain-Independent Planner
8
Planners are not normally applied to software; they traditionally solve problems like this:
Traditional Planning Example
Initial state
on(B, table)on(C, table)on(A, C)
CB
A
Goal state
on(C, table)on(B, C)on(A, B)
C
B
A
These are properties.)Planner’s Input(
These are actions.)Planner’s Output(
These are properties.)Planner’s Input(
Planmove(A, table)move(B, C)move(A, B)
Actions in the planmodify a “world”of blocks
9
Classical Representation
The world is represented as states States are represented as a set of logical
atoms Operators define a state-transition system
precondition – when an operator can be used effects – what an operator does
Planner finds a path through the system from the initial state to the goal state
10
Why Planning Is Difficult
Too many states to enumerate Search intelligently using reasonable time &
space Danger that planner may not terminate
11
Simple Planning Algorithms
Forward Search Start at the initial state and advance using the
operators until you reach the goal Backward Search
Start at the goal state and apply the inverse of the operators
STRIPS
12
To Solve Composition Using Planning Initial state – Calling context
compiler analysis Goal state – “Abstract Algorithm”
user Operators – Procedure specifications
library author Actions – Procedure calls World – Program state
13
Is Planning Necessary For Composition Many possible actions
libraries contain 10s – 100s procedures (operators) each procedure has several parameters many live variables (objects) at a call site
many ways to bind variables to parameters
Ex: 128 procs, 2 params each, 8 objs, 4 calls assume all objects & params have the same type (128 * 82)4 = 252 potential plans
14
The Planning Solution
Add an “abstract algorithm” (AA) construct to the programming language An AA is named and defined by the programmer
definition is the programmer's goal An AA is called like a procedure
compiler replaces the call with a sequence of library calls
How does the compiler compose the sequence? it uses a domain-independent planner
15
Query a remote database and save the result to local storage:
Query q = bio_db_query_genbank_new(“nucleotide”, “Arabidopsis[ORGN] AND topoisomerase[TITL] AND
0:3000[SLEN]”);
DB db = bio_db_genbank_new();
Stream stream = get_stream_by_query(db, q);
SeqIO seqio = bio_seqio_new(“>sequence.fasta”,
“fasta”);
Seq seq = next_seq(stream);
write_seq(seqio, seq);
BioPerl Call Sequence Revisited
16
Defining and Calling an AA
AA (goal) defined using the glossary...
algorithmsave_query_result_locally(db_name, query_string, filename, format) => { query_result(result, db_name, query_string), contains(filename, result), in_format(filename, format) }
17
Defining and Calling an AA
...and called like a procedure
Seq seq = save_query_result_locally( “nucleotide”, “Arabidopsis[ORGN] AND opoisomerase[TITL]
AND 0:3000[SLEN]”, “>sequence.fasta”, “fasta”);
1 data type, 1 AA call
18
DIPACS
Domain Independent Planned Algorithm Composition and Selection
Operators
Application Code
DIPACSPlanner
Domain-SpecificLibrary
ProcedureSpecifications
Initial State
Goal State
Plan
gcc
C or C++ Code
Binary (Actions)
0010101001000010
Run-TimeProgram State
(World)
DIPACSCompiler
19
Challenges
Ontological engineering Choosing a vocabulary for the domain
Determine initial and goal states Object creation
most planners assume a fixed set of objects Merging of plan and program
20
Ontological Engineering
Glossary of abstractions for describing the preconditions and effect of library routines e.g. sorted(x), permutation(x, y), contains(a, b) not precise semantics
Library author and user understand the properties via prior familiarity with the domain via the glossary
21
Ontological Engineering
The compiler propagates terms during analysis meaning of properties does not matter
The planner matches properties to goals meaning of properties does not matter
22
Determining Initial and Goal States Determine variables at AA’s call point
int a, b, c;...a = b;c = AA(...);
(:objects a b c – int(:init (equals a b))
int a, b, c;...a = b;c = AA(...);
(:objects a b c – int(:init (equals a b))
23
Discover properties at the AA’s call point
Determining Initial and Goal States
(:objects x y z – int_array(:init (sorted y))
sorted(y)sorted(y)
sorted(y)sorted(y)
(:objects x y z – int_array(:init (sorted y))
sorted(y)sorted(y)
sorted(y)
y = sort(x)y = sort(x)
z = AA(y)z = AA(y)
...... ......
y = sort(x)y = sort(x)
z = AA(y)z = AA(y)
...... y[0] = 1y[0] = 1
24
Object Creation
Classical planning The world consists of a static set of objects Operators never create new objects
Extension to the programming world is needed1. Start with a “large enough” number of extra
objects
2. Create new objects on demand
25
Merging of Plan and Program Destructive vs. non-destructive call sequence The compiler choose based on live variables
analysis
int[] a, b, c;...a = sort(a);c = sort(b);...... = a;... = b;
sort is an AAdestructive
non-destructive
1. destructive_sort(a);2. a = nondestructive_sort(a);
int t[] = b;destructive_sort(t);c = t;
26
The Planning Language (Librarian) Library procedures and their specifications
Provided by the library programmer
procedure int[]nondestructive_sort( int[] array ) => { sorted (result) ,permutation(result, array) } time pow(array.length , 2) space 2 * array.length{ /* implementation */ }
27
The Planning Language (User) Defining Abstract Algorithms
algorithm sort( x ) => { sorted( result ), permutaion( result, x ) }
algorithm stable_sort( y ) => { sort(y), stable( result, y ) }
28
The Planning Language (Compiler) Generates extended PDDL
Lisp-like syntax
( define (problem sort) (: objects input_array − int_array) (: goal ( exists (?result − int_array) ( and (sorted ?result) (permutation ?result input_array)))))
29
The Planning Language (Compiler) Generates extended PDDL
Object creation – non standard “create”
(:action next_seq :parameters (?stream − Stream) :creates (?result - Seq) :effect (forall (?q – Query) (when ( stream_for_query ?stream ?q ) (query_result ?result ?q.db ?q.query))))
(:action insertion_sort :parameters (?array − int_array) :creates (?array@ - int_array) :effect (and (sorted ?array@) (permutaion ?array@ ?array)))
30
Generates extended PDDL Non deterministic effects – non standard “either”
(:action isalpha :parameters (?ch − char) :creates (?result - bool) :effect (either (and (?ch alpha) (equal ?result #t)) (and (not (?ch alpha)) (equal ?result #f))))
The Planning Language (Compiler)
31
The Planner
Call sequences are (relatively) short High Branching factor Exhaustive search is infeasible
Could not find good heuristic for forward search Use a modified version of STRIPS
allow for backtracking (multiple plans)
32
STRIPS
π the empty plan do a modified backward search from g
instead of -1(s, a), each new set of subgoals is just precond(a)
whenever you find an action that’s executable in the current state, then go forward on the current search path as far as possible, executing actions and appending them to π
33
Evaluation
# Abstract Algorithm create solutions time (ms)
1 dummy Seq 32 300
2 save_query_result_locally Seq 1 3270
3 sort int[] 2 800
4 sort float[] 0 30
Multiple plans require “interactive compilation” cache to store previous decisions
34
algorithm dummy();
Seq s = dummy();
algorithm dummy();
Seq s = dummy();
Where Do We Go From Here? DIPACS is a proof of concept. Can we take
the concept to the next level? language features: loops, exceptions, OO scalability using existing libraries
automatic inference of effects
Different planning algorithm plans with branches forward search
35
Questions?
36