konstantine arkoudas selmer bringsjord cog sci; comp sci...
TRANSCRIPT
Automatic Programming
Konstantine Arkoudas
Selmer Bringsjord
Cog Sci; Comp Sci; RAIR LabRensselaer Polytechnic Institute (RPI)
Troy NY 12180 [email protected] • [email protected]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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