Silica-Paleontology with graph databases: Rooting through the relics of digital evolution

Silico-paleontology with graph databases
Rooting through the relics of digital evolution
Nic McPhee & David Donatucci (w/ Thomas Helmuth)
Division of Science and Mathematics
University of Minnesota, Morris
Morris, Minnesota, USA
May 2015
Genetic Programming Theory and Practice
University of Michigan
Ann Arbor, MI
McPhee & Donatucci (UMN Morris) Graph database analysis of GP dynamics May 2015, GPTP, Ann Arbor MI 1 / 26

Overview The Big Picture
The Big Picture
Genetic programming clearly works.
But we rarely know why or how.
Databases allow examination of the internal interactions of a run.
Graph databases better suited for this than relational databases.
Silico-paleontology can help us understand and improve our tools.

Overview Outline
Outline
1 What do we know? (And how do we talk about it?)
2 Using a graph database
3 Let’s go exploring!
4 Conclusions

What do we know? (And how do we talk about it?)
Outline
We throw so much away
Summary results are highly lossy
Plots are better (but can still obscure details)
Can we zoom in to individual runs?
4 Conclusions

What do we know? (And how do we talk about it?) We throw so much away
We keep/see/share so little
EC research has the potential to generate
huge amounts of data.
What do we normally do with that data?
We normally throw it away – &
paleontologists weep!
https://www.flickr.com/photos/blmoregon/14566767645/
https://www.flickr.com/photos/
nicmcphee/1323950471

What do we know? (And how do we talk about it?) Summary results are highly lossy
Oooh – a table of results!
Treatment
Problem L T I
RSWN 55 13 17
SYL 22 1 2
SLB 75 19 10
NTZ 57 15 7
These show successes on 4 problems
for 3 different treatments
L seems to be winning

What do we know? (And how do we talk about it?) Summary results are highly lossy
Oooh – a table of results!
Treatment
Problem L T I
RSWN 55 13 17
SYL 22 1 2
SLB 75 19 10
NTZ 57 15 7
But why?!?!?
What’s actually happening in all those
matings and crossovers and mutations
that makes the difference?

What do we know? (And how do we talk about it?) Plots are better (but can still obscure details)
Let’s draw pretty pictures
0.00
0.25
0.50
0.75
1.00
0.00
0.25
0.50
0.75
1.00
lexicasetourney
0 100 200 300
generation
error.diversity
So much more data!
Diversity over time across all
the runs.
L’s diversity (top) is consis-
tently higher than T (bot-
tom).
That might be important
(and supports some hy-
potheses).

What do we know? (And how do we talk about it?) Plots are better (but can still obscure details)
Let’s draw pretty pictures
0.00
0.25
0.50
0.75
1.00
0.00
0.25
0.50
0.75
1.00
lexicasetourney
0 100 200 300
generation
error.diversity
Still, this mushes all the runs
together.
And that likely obscures in-
teresting things.

What do we know? (And how do we talk about it?) Can we zoom in to individual runs?
Zooming in
0.2
0.4
0.6
0.8
0 25 50 75
generation
error.diversity
Focusing on one successful
L run now.
Three big diversity changes:
First 15 generations
have a sharp drop then
steep rise
Around generation 40 a
sharp drop and rise
Sharp drop at end just
before a solution is
found

What do we know? (And how do we talk about it?) Can we zoom in to individual runs?
Zooming in
0.2
0.4
0.6
0.8
0 25 50 75
generation
error.diversity
What’s happening at those
sections of the run?
We want to be able to dig
through a run and see what
happened.

Using a graph DB
Outline
Goals
Neo4j
Cypher
4 Conclusions

Using a graph DB Goals
Goals
We want to store and analyze all the
individuals and their relationships.
Ancestry relationships are naturally
modeled with a graph
So graph databases seem a natural tool
for the relationship part.
www.hokstad.com/family-tree-using-graphviz-and-ruby
(a) Distribution of ﬁtness values (b) Ge
(d) Genealogy of the best individual (e) Ro
Fitness value (Pearson’s R2
)
0.0
[Burlacu et al., 2013]

Using a graph DB Neo4j
Neo4j graph database
Part of the new-ish NoSQL movement
Neo4j’s initial release was 2007
Started to take off in 2010
Represent individuals as nodes
Represent parent-child relationships as
edges
Easy to represent complex relationships
Easy to search for relationships
Efﬁcient recursive queries, esp.
compared to traditional databases
http://neo4j.com

Using a graph DB Cypher
Cypher query language
Neo4j uses the Cypher query language.
Fundamental elements of Cypher
queries:
START
MATCH
WHERE
RETURN
Uses "ASCII art" to describe
relationships:
(p)- ->(c)
(p)-[r:PARENT_OF]->(c)

Using a graph DB Cypher
Can model (complex) paths
Find Nic’s parents:
(Nic)<-[:PARENT_OF]-(p)
Find all Nic’s grandparents:
(Nic)<-[:PARENT_OF*2]-(gp)
Find everyone at most 5 steps from Nic:
(Nic)<-[:PARENT_OF*1..5]-(a)
Find all Nic’s siblings:
(Nic)<-[:PARENT_OF]-()-[:PARENT_OF]->(s)

Let’s go exploring!
Outline
Setup
Comparing the end-games
4 Conclusions

Let’s go exploring! Setup
What are we exploring?
Tom Helmuth provided a lot of data:
A number of program synthesis problems taken from intro
computing texts
Three different selection mechanisms: Lexicase, tournament, and
implicit ﬁtness sharing (IFS)
All using Clojush implementation of Lee Spector’s PushGP system
https://github.com/lspector/Clojush
Population size 1,000; ≤ 300 generations
See [Helmuth and Spector, 2015] for more.
We used batch-import tool and custom scripts to import into Neo4j.
https://github.com/jexp/batch-import

Let’s go exploring! Setup
Only just the beginning
We have data from hundreds of runs
Currently a very “by hand” process
Deﬁnitely learned valuable things about:
The behavior of lexicase
Role of alternation (a type of crossover) in PushGP
Impact of test cases on evolutionary dynamics
We’ll look at results from two runs:
Both successful on replace-space-with-newline problem
One using lexicase (sol’n found in 88 gens)
One using tournament selection (sol’n found in 151 gens)

Let’s go exploring! Comparing the end-games
How did we construct a winner?
How is a winner constructed at the end of a run?
This query ﬁnds all ancestors of a winner (zero total_error) going
back at most 8 steps:
MATCH (w) WHERE w.total_error = 0
MATCH (p)- ->(c)-[*0..7]->(w)
RETURN DISTINCT id(p), id(c);
8 steps is fairly arbitrary; returns a small enough set to visualize.

Comparing the end-games
Ancestry of winner(s) look very
different
Tournament selection (below):
Single winner w/ high
branching factor
Lexicase (right): 45 winners w/
much lower branching factor
Gen 142
Gen 143
Gen 144
Gen 145
Gen 146
Gen 147
Gen 148
Gen 149
Gen 150
233 5 2
3
2332
2
2
2
2
2
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners

Lexicase selection
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners
A number of observations:
45(!) “winning” individuals
Individual “86:261” is (a)
parent of all 45
Individual “86:261” is a
parent of 934 (of 1,000)
individuals in next
generation

Lexicase selection
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners
Seriously?!? 934 offspring?!?
Turns out to an be extreme case
of a common phenomena with
lexicase
Nodes marked with diamonds
all had at least 100 offspring
Shaded diamonds also have at
least 5 offspring that are ances-
tors of or are winners

Lexicase selection
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners
What’s the total error (ﬁtness) of
“86:261”?

Lexicase selection
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners
“86:261”?
4,034(!)
Bottom quartile!
But had 934 offspring!
Failed to return on 4 cases
(error 1,000 each)
Got 2 other answers wrong
(error 17 each)
Terrible total error, but
perfect on 194 of 200 tests
Great for lexicase!

Lexicase selection
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners
“85:086”?

Lexicase selection
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners
“85:086”?
100,000!
Rank 971 out of 1,000
But had 180 offspring
Got all the “print” cases
Failed to return value for all
100 “return” cases (error
1,000 each)
Terrible total error, but
perfect on 100 of 200 tests
Fine for lexicase

Lexicase selection
Gen 79
Gen 80
Gen 81
Gen 82
Gen 83
Gen 84
Gen 85
Gen 86
Gen 87
80:220
82:447
83:04783:124 83:619
84:319
85:086
86:261
87:71987:941 87:94742 Other Winners
High proportion of mutations:
Roughly half the offspring
in this graph created via
mutation
Probably why there’s less
branching

Tournament selection
Gen 142
Gen 143
Gen 144
Gen 145
Gen 146
Gen 147
Gen 148
Gen 149
Gen 150
233 5 2
3
2332
2
2
2
2
2
Much broader: 42 ancestors of a winner for tournament 9 gens
back; 14 for lexicase
About two-thirds created via crossover, so more branching than
lexicase

Number ancestors of “winners” over time
Gens from winner Lexicase Tournament
1 4 2
2 6 4
3 7 6
4 6 10
5 7 13
6 9 20
7 10 30
8 14 33
9 14 42
10 22 63
...
...
...
18 58 297

12 most fecund individuals
Lexicase Tournament
934 24
657 23
594 23
590 21
433 20
326 20
297 19
294 19
285 19
283 18
279 18
271 18

Conclusions
Outline
4 Conclusions

Conclusions
Conclusions
Still early days, but we can deﬁnitely see some useful things:
Differences in ways selection mechanisms work
Support for hypotheses (e.g., Tom’s paper)
Evidence for importance of crossover in PushGP
Impact of test cases on evolutionary dynamics
Future Work
Automate more of the work
Examine more runs/problems/etc.
Explore how to include this “on-line”

Conclusions
Thanks!
Thank you for your time and attention!
Thanks to M. Kirbie Dramdahl (University of Minnesota, Morris), and to
Lee Spector’s Computational Intelligence group (Hampshire College)
for ideas and feedback.
Contacts:
mcphee@morris.umn.edu
donat056@morris.umn.edu
thelmuth@cs.umass.edu
Questions?

References
References
Burlacu, B., Affenzeller, M., Kommenda, M., Winkler, S., and Kronberger, G. (2013).
Visualization of genetic lineages and inheritance information in genetic programming.
In Proceedings of the 15th Annual Conference Companion on Genetic and Evolutionary Computation, GECCO ’13
Companion, pages 1351–1358, New York, NY, USA. ACM.
Helmuth, T. and Spector, L. (2015).
General program synthesis benchmark suite.
In Proceedings of the 17th Annual Conference on Genetic and Evolutionary Computation, GECCO ’15, New York, NY,
USA. ACM.

Silica-Paleontology with graph databases: Rooting through the relics of digital evolution

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Silica-Paleontology with graph databases: Rooting through the relics of digital evolution

Ähnlich wie Silica-Paleontology with graph databases: Rooting through the relics of digital evolution (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Silica-Paleontology with graph databases: Rooting through the relics of digital evolution