Using AI Planning to Implement Algorithm Composition Context

Using AI Planning to Implement Algorithm Composition Context Sensitive Domain-Independent Algorithm Composition and Selection. Troy A. Johnson and Rudolf Eigenmann Purdue University 1

Motivation n n Increasing programmer productivity Typical language approach: increase abstraction q q q n 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 q e. g. , domains are biology, chemistry, physics, etc. 2

A Common Bio. Perl Call Sequence n 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); Seq. IO seqio = bio_seqio_new(“>sequence. fasta”, “fasta”); Seq seq = next_seq(stream); write_seq(seqio, seq); 5 data types 6 procedure calls 3

A Library Designer’s Problem n “Everything should be made as simple as possible, but not simpler” q q n 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 n Novice users don’t know these call sequences q q procedures documented independently tutorials provide some example code fragments n 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 n Build (semi) automatic tools to help users specify what they want and get what they need. 6

Agenda n n A brief introduction to Automated Planning Algorithm Composition Using Planning q n DIPACS q q n Mapping composition to planning Language, compiler and planner Limitations Where do we go from here? 7

Simplified View of Planning Operators Initial State Goal State Planner Plan Actions Plan User World AA Domain-Dependent Planner Domain-Independent n n n World is composed of objects Actions modify objects' properties and relationships Planner deals with a symbolic model 8

Traditional Planning Example n Planners are not normally applied to software; they traditionally solve problems like this: A B C Initial state on(B, table) on(C, table) on(A, C) These are properties. (Planner’s Input) Actions in the plan modify a “world” of blocks Plan move(A, table) move(B, C) move(A, B) These are actions. (Planner’s Output) A B C Goal state on(C, table) on(B, C) on(A, B) These are properties. (Planner’s Input) 9

Classical Representation n The world is represented as states States are represented as a set of logical atoms Operators define a state-transition system q q n 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 n n n Too many states to enumerate Search intelligently using reasonable time & space Danger that planner may not terminate 11

Simple Planning Algorithms n Forward Search q n Start at the initial state and advance using the operators until you reach the goal Backward Search q q Start at the goal state and apply the inverse of the operators STRIPS 12

To Solve Composition Using Planning n Initial state – Calling context q n Goal state – “Abstract Algorithm” q n n user Operators – Procedure specifications q n compiler analysis library author Actions – Procedure calls World – Program state 13

Is Planning Necessary For Composition n Many possible actions q q q libraries contain 10 s – 100 s procedures (operators) each procedure has several parameters many live variables (objects) at a call site n n many ways to bind variables to parameters Ex: 128 procs, 2 params each, 8 objs, 4 calls q q assume all objects & params have the same type (128 * 82)4 = 252 potential plans 14

The Planning Solution n Add an “abstract algorithm” (AA) construct to the programming language q An AA is named and defined by the programmer n definition q An AA is called like a procedure n compiler n is the programmer's goal replaces the call with a sequence of library calls How does the compiler compose the sequence? q it uses a domain-independent planner 15

Bio. Perl Call Sequence Revisited n 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); Seq. IO seqio = bio_seqio_new(“>sequence. fasta”, “fasta”); Seq seq = next_seq(stream); write_seq(seqio, seq); 16

Defining and Calling an AA (goal) defined using the glossary. . . algorithm save_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 n . . . 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 n Domain Independent Planned Algorithm Composition and Selection Plan Domain-Specific Library Procedure Specifications Application Code Operators DIPACS Compiler Goal State Initial State DIPACS Planner C or C++ Code gcc Run-Time Program State Binary (Actions) (World) 00101010 01000010 19

Challenges n Ontological engineering q n n Determine initial and goal states Object creation q n Choosing a vocabulary for the domain most planners assume a fixed set of objects Merging of plan and program 20

Ontological Engineering n Glossary of abstractions for describing the preconditions and effect of library routines q q n e. g. sorted(x), permutation(x, y), contains(a, b) not precise semantics Library author and user understand the properties q q via prior familiarity with the domain via the glossary 21

Ontological Engineering n The compiler propagates terms during analysis q n meaning of properties does not matter The planner matches properties to goals q meaning of properties does not matter 22

Determining Initial and Goal States n Determine variables at AA’s call point a, b, c; . . . a = b; c = AA(. . . ); (: objects a b c – int (: init (equals a b)) 23

Determining Initial and Goal States n Discover properties at the AA’s call point y = sort(x) sorted(y) . . . sorted(y) z = AA(y) (: objects x y z – int_array (: init (sorted y)) y = sort(x) sorted(y) . . . sorted(y) y[0] = 1 sorted(y) z = AA(y) (: objects x y z – int_array (: init (sorted y)) 24

Object Creation n Classical planning q q n The world consists of a static set of objects Operators never create new objects Extension to the programming world is needed 1. 2. Start with a “large enough” number of extra objects Create new objects on demand 25

Merging of Plan and Program n n Destructive vs. non-destructive call sequence The compiler choose based on live variables analysis destructive sort is an AA int[] a, b, c; . . . a = sort(a); c = sort(b); . . . = a; . . . = b; non-destructive 1. destructive_sort(a); 2. a = nondestructive_sort(a); int t[] = b; destructive_sort(t); c = t; 26

The Planning Language (Librarian( n Library procedures and their specifications q 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( n 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( n Generates extended PDDL q 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( n Generates extended PDDL q 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 ? q. db ? q. query)))) (: action insertion_sort : parameters (? array − int_array) : creates (? array@ - int_array) : effect (and (sorted ? array@) (permutaion ? array@ ? array))) 30

The Planning Language (Compiler( n Generates extended PDDL q 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)))) 31

The Planner n n n Call sequences are (relatively) short High Branching factor Exhaustive search is infeasible q n Could not find good heuristic forward search Use a modified version of STRIPS q allow for backtracking (multiple plans) 32

STRIPS n n π 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 π q n 33

Evaluation # 1 dummy Seq 32 300 2 save_query_result_locally Seq 1 3270 3 sort int[] 2 800 4 n Abstract Algorithm create solutions time (ms) sort float[] 0 30 Multiple plans require “interactive compilation” q cache to store previous decisions algorithm dummy(); Seq s = dummy(); 34

Where Do We Go From Here? n DIPACS is a proof of concept. Can we take the concept to the next level? q q q language features: loops, exceptions, OO scalability using existing libraries n n automatic inference of effects Different planning algorithm q q plans with branches forward search 35

Questions? 36