konstantine arkoudas selmer bringsjord cog sci; comp sci...

27
Automatic Programming Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci; RAIR Lab Rensselaer Polytechnic Institute (RPI) Troy NY 12180 USA [email protected] [email protected]

Upload: others

Post on 27-Feb-2021

8 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Automatic Programming

Konstantine Arkoudas

Selmer Bringsjord

Cog Sci; Comp Sci; RAIR LabRensselaer Polytechnic Institute (RPI)

Troy NY 12180 [email protected][email protected]

Page 2: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

What is the goal?

The answer has fluctuated widely over the decades.

Fortran programming was considered “automatic” in the 1950s.

The 60s were much more ambitious.

Blackbox view of automatic programming:

-What we want AP -Program that does it

2

Page 3: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

What is the goal? (continued)

How is “what we want” expressed?

Several possibilities:

• Natural language

• Formal specification

• Input/output examples

• Traces

But it makes no difference.

The blackbox vision is a pipe dream no matter what.

At least as hard as general AI problem...

3

Page 4: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Automatic Programming Difficult!

A Π2 formula in the Arithmetical Hierarchy:

∀u∀v[∃kH(n, k, u, v)↔ ∃k′H(m, k′, u, v)]

(And things get downright laughable when we speak of discoveringAH, and discovering and proving things about it.)

4

Page 5: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Synopsis of current state

Not too bright.

State-of-the-art examples from 30-40 years ago:

• List reversal and sorting

• Factorial and Fibonacci

State-of-the-art examples today:

• List reversal and sorting

• Factorial and Fibonacci

Several new ideas and technologies have emerged.

But state of the art has not advanced much.

5

Page 6: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Main varieties of automatic programming

Deductive:

• Constructive type theories

• Classical logic done constructively

The produced program is guaranteed to be correct.

Inductive:

• Summer’s approach (IGOR, etc.)

• Genetic approaches (ADATE, etc.)

• Inductive Logic Programming (GOLEM and its successors,etc.)

No correctness guarantee.

6

Page 7: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Deductive Automatic Programming

Took off after the discovery of unification in the 1960s

Requires a formal specification

Given as a formula in an appropriate theory. Typically of the form

∀ i, o . R(i, o)⇔ · · ·

Usually R is functional, and we want a constructively definedfunction f : I→O such that

∀ i, o . f(i) = o⇔R(i, o).

When R is not functional, we only require soundness:

∀ i, o . f(i) = o⇒R(i, o)

and sufficiency:

∀ i . [∃ o . R(i, o)]⇒ [∃ o . f(i) = o]

7

Page 8: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Example

Main idea same in all varieties

Consider the spec:

∀L : List(Int), x : Int . R(L, x)⇔∃L′ : List(Int) . app(L′, [x]) = L

That is, R(L, x) holds iff x is the last element of L.

Discover a program last : List(Int)→Option(Int) such that

Goal : ∀ L : List(Int), x : Int . last(L) = some(x)⇔R(L, x)

So last returns an integer option. Axiomatization of the optiondomain:

∀ x : Int . none 6= some(x)∀ x, y : Int . some(x) = some(y)⇔x = y

∀ x : Option(Int) . x = none ∨ [∃ n : Int . x = some(n)]

8

Page 9: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Example (continued)

We also have the following axiomatization of lists:

∀ x, L . nil 6= cons(x, L)∀ x1, x2, L1, L2 . cons(x1, L1) = cons(x2, L2)⇔x1 = x2 ∧ L1 = L2

∀ L . L = nil ∨ ∃ x, L′ . L = cons(x, L′)

and the following definition of append (univ. quantified):

app(L, nil) = L

app(cons(x, L1), L2) = cons(x, app(L1, L2))

We also have an induction principle for lists (quite important).

9

Page 10: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Example (continued)

So how do we go about synthesizing last?

Answer: We try to prove Goal , by induction on L!

But how can we prove Goal without knowing the definition of last?

Answer: No matter. The proof will fill in the details.

I.e., the proof will tell us how the program must behave if it is tosatisfy its spefication.

10

Page 11: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Example (continued)

Consider the basis case, when L = nil .

Then Goal becomes:

Goal ′ : ∀ x . last(nil) = some(x)︸ ︷︷ ︸F1

⇔ ∃ L′ . app(L′, [x]) = nil︸ ︷︷ ︸F2

.

But F2⇔ false, so the goal becomes:

Goal ′′ : ∀ x . [last(nil) = some(x)⇔ false],

or, equivalently,

Goal ′′′ : ∀ x . last(nil) 6= some(x)

which is finally equivalent to

Goal ′′′′ : last(nil) = none.

11

Page 12: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Example (continued)

This is therefore the definition of last for the basis case.

By reversing the chain of equivalences, we can prove that thisdefinition is correct (according to the specification).

The inductive step is a little more involved, but the idea is thesame: Keep building a chain of equivalences backwards, until wearrive at a defining clause for last .

In this case, we derive the following two more clauses:

last([x]) = some(x)last(cons(x, cons(y, L))) = last(cons(y, L))

The recursive clause is obtained by applying the inductivehypothesis. This is a general pattern:

Induction ←→ Looping

12

Page 13: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Drawbacks

• Formal specifications are difficult to construct

• Sometimes they are impossible

• Approach only works for pure logic or functional programs

• Has not been shown to scale

• Requires very well-engineered interactive theorem-provingsystems

• Cannot be used to program reactive systems, non-terminatingsystems, etc.

• Generated programs are usually very inefficient

• More importantly: to write a specification, one must often havein mind an algorithm for the problem.

• In other words, one must already know how to code theprogram! (In fairness, that is not always the case.)

13

Page 14: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Genetic programming

Discovered in the 1980s (although genetic algorithms go back tothe ’50s)

Main idea:

• Start with a population (say 104) of random computerprograms.

• Assign a fitness value to each program.

• Create a new population by performing “genetic operations” onselected programs.

Continue this loop until some program achieves a satisfactoryfitness.

14

Page 15: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Genetic programming (continued)

Programs to be operated on are selected with probabilityproportional to their fitness.

Usual operations:

• Mutation (on one program only): Randomly alter part of aprogram’s structure.

• Crossover (on two programs): Randomly shuffle two parts ofthe two programs.

• Reproduction (on one program): Simply carry over a programunchanged into the new population.

From these, crossover is the most important, and performed mostfrequently (with the greatest probability).

15

Page 16: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Representations

Programs are represented as ASTs (abstract syntax trees).

E.g., the simple “program” f(x) = 3 + 2 · x would be:

� ��+�

��

QQQ� ��

3 � ��∗

��

QQQ� ��

2 � ��x

The set of terminals (AST leaves) and non-terminals (functionsymbols) must be carefully chosen.Typing issues can affect the applicability of crossover and mutation.

16

Page 17: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Strengths and drawbacks of GP

Well-suited for optimization and control problems, and for games.

Too computationally intensive. Evaluating the fitness of programsentails evaluating the programs themselves, which can be verytime-consuming. [ADATE takes 6.5 days to evolve a program forlist intersection.] Scalability issues.

Heavily representation-dependent

Very weak on understanding and explanation (though not as bad asneural nets): Typically the generated programs are awful spaghetticode. (One can mitigate that by making structure and succinctnesspart of the fitness function.)

Utterly cognitively implausible

17

Page 18: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Generalization by recurrence detection

Seminal work by Summers (1977)

One of the most psychologically plausible approaches (but limited)

Main procedure idea:

• Examine a number of input-output pairs:

[] → none[5] → some(5)

[8,2] → some(2)[7,5,1] → some(1)

[2,13,6,4] → some(4)

18

Page 19: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Generalization by recurrence detection (continued)

• Abstract a finite program (set of rewrite rules) that covers alland only the given pairs:

nil → nonecons(x, nil) → some(x)

cons(x, cons(y, nil)) → some(y)cons(x, cons(y, cons(z, nil))) → some(z)

cons(x, cons(y, cons(z, cons(w, nil)))) → some(w)

This is done by replacing constants with arbitrary variables.

• Express the rewrite rules using selectors (hd and tl , i.e., carand cdr):

19

Page 20: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Generalization by recurrence detection (continued)

l = nil→ f1(l) = none

l = cons(x,nil)→ f2(l) = some(hd(l))

l = cons(x, cons(y,nil))→ f3(l) = some(hd(tl(l)))

l = cons(x, cons(y, cons(z,nil)))→ f4(l) = some(hd(tl(tl(l))))

l = cons(x, cons(y, cons(z, cons(w,nil))))→ f5(l) = some(hd(tl(tl(tl(l)))))

• Finally, detect regularities in the finite program:

l = nil→ f1(l) = nonel = cons(x, nil)→ f2(l) = some(hd(l))

l = cons(x, cons(y, nil))→ f3(l) = f2(tl(l))l = cons(x, cons(y, cons(z, nil)))→ f4(l) = f3(tl(l))

l = cons(x, cons(y, cons(z, cons(w, nil))))→ f5(l) = f4(tl(l))

20

Page 21: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Generalization by recurrence detection (continued)

Final induced definition:

l = nil → last(l) = nonel = cons(x, nil) → last(l) = some(x)

l = cons(x, cons(y, l′)) → last(l) = last(cons(y, l′))

or in more standard (ML-like) notation:

last([]) = nonelast([x]) = some(x)

last(x::y::rest) = last(y::rest)

The recurrence detection is done purely syntactically, by patternmatching.

21

Page 22: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Generalization by recurrence detection - assessment

The class of recursive functions that can be induced by thistechnique is rather restricted.

Summer’s ideas have been extended. Basic scheme was augmentedin the 1980s (mainly by Kodratoff and Wysotzki).

Similar techniqes have been used for“programming-by-demonstration” systems such as Tinker (1993).

The gist is this: Inferring control structures from traces.

More recently, this has been attempted via grammar inference.

Schmid (2003) and others are continuing this line of work. Butresults have been quite limited.

22

Page 23: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

ILP (Inductive Logic Programming)

Synthesizes logic (rather than functional) programs

Inputs:

• A background theory B, say some facts about lists, e.g.,

app(cons(x, L1), L2, cons(x, L3))⇐ app(L1, L2, L3)

• A set of positive examples E+ (almost always atoms):

last(nil , none), last([5, 2], some(2)), . . .

• A set of negative examples E−:

¬last([5, 2], some(5)), . . .

23

Page 24: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

ILP (continued)

• We require:

1. ∀ e− ∈ E− . B 6|= e−

2. ¬ ∀ e+ ∈ E+ . B |= e+

• Output: A conjecture h such that

1. ∀ e+ ∈ E+ . B ∧ h |= e+

2. ∀ e− ∈ E− . B ∧ h 6|= e−

Of course the conjuction of all the positive examples is a trivialsolution

But we want predictive power—the generated hypothesis should dowell on unseen data

24

Page 25: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

ILP algorithms

Start with a very specific hypothesis and keep generalizing

Start with a very general hypothesis and keep specializing

Use a combination

Many successful ILP systems view induction as the inverse ofdeduction, and form hypotheses by inverting deductive inferencerules

A typical inference rule is absorption:

A⇒ q A,B⇒ p[Absorption]

A⇒ q B, q⇒ p

The conclusion here logically entails the premises

25

Page 26: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

ILP (continued)

ILP has been successful in data mining, but in automaticprogramming the results have been lackluster

Nothing beyond the usual toy examples (sorting, etc.)

The generated programs are often inefficient

The method itself is inefficient for recursive programs, since testingexamples requires running arbitrary code

26

Page 27: Konstantine Arkoudas Selmer Bringsjord Cog Sci; Comp Sci ...kryten.mm.rpi.edu/PRES/NACAP08/ka_sb_autprogatNACAP08.pdfAutomatic Programming Konstantine Arkoudas Selmer Bringsjord Cog

Conclusions

The goals of AP have changed over time:

less ambitious→more ambitious→ less ambitious

The last 25 years have been dominated by inductive methods

State of the art has not advanced beyond toy examples

Single most successful system in practice has been AMPHION, adeductive system based on Manna’s work (deployed at NASA)

It is striking how psychologically implausible most methods are,and how uninformed by the human case

Future: AP as human assistants only; semi-automatic; mix ofdeductive and inductive techniques

27