ECAL session notes: Open-Ended Simulations
As before, what follow is a very slightly cleaned up version of the notes I took during the third ISAL summer school session at ECAL 2017. Also as before, note that this is very rough, made while I was reviewing them tonight. Apologies for any typos or other mistakes.
Unfortunately I had some laptop issues toward the latter part of the talk and ended up taking notes by hand for part of it, which meant missing out some partial implementation examples that were presented towards the second half. My hand-written notes were sort of vague and barely legible in general…So these notes are more on the presented conepts as I understood them towards the first part of the talk.
Susan Stepney, University of York
High level goal: start off with, perhaps, a 2D critter that becomes 3 dimentional, then poly-nuclear, then glows in the dark, then critters that walk, then birds that sing, etc etc
What is open-endedness?
- Processes that do not stop and have no specific objective
- Perpetual production of novelty
- A system in which components continue to evolve new forms continuously, rather than grinding to a halt when an “optimal” position is reached.
- Unbounded evolution - Evolution without a definite maximum fitness, hence no optimal goal or solution to reach
- Perpetual production of complexity is the essence of life. T.Ray - “would consider a system to be living if it is self replicating, and capable of open-ended evolution”
“The continual production of novelty.”
What is novelty? The speaker presents the following introductory concepts, guided by examples, before continuing with a potential method [as you can probably see as soon as you start reading the examples the first thing that tends to come to mind is OOP]
Instances, Models, Meta-Models
Example 1: maps
- Instance: thing in the world; eg coastline.
- Model: concept; map of coastline, navigational instructions, some kind of representation of an instance
- Meta-model: a model of a model; concepts in the model: roads, motorways, legends of the map; meta-model of geological map. Meta models can vary. Sometimes there is no explicit meta-model - eg navigational instructions.
“All models are wrong, some models are useful.”
With maps there tends to be only one instance. Eg, there is only one Sweden.
Example 2: ordinary differential equations for chemical reactions.
- Instance: A reaction
- Model: Mathematical equation.
- Meta-model: rates of change, initial conditions, concentrations, rate constants (parameters)
Models can have parameters for different instances.
Example 3: simulations
- Instances: Ants, boids, food items, etc.
- Model: Ant, Boid, Food, etc.
- Meta-model: Aggregate, Agent, Behaviour, etc.
Instances, Models, Meta-Models:
- Things in the “world”
- Exist at runtime.
- Kinds of things
- Instance types
- Exist at design time
- Kinds of kinds of things
- Types of concepts
- Exist at language design time
Maps nicely onto object oriented style implementations
DEFINITION of novelty
- Variation: novel instances (conforms to the model)
- New things, different parameter values;
- Innovation: novelty in the model (conforms to the meta-model)
- New kinds of things
- New instance types
- New concepts
- Flyer suddenly turns into crawler; both are agents but different models. [This is my main issue - how does a flyer “suddenly” turn into a crawler if you didn’t design for that sort of possibility at some point in your software? Isn’t that the first big leap we have to make?]
- Emergence: novelty in the meta-model
- New kinds of kinds of things
- New levels
- New types of concepts
- Eg: new levels in evolution; you have an agent that suddenly turns into a flock - ie an aggregate
DEFINITION of open-ended system
An open ended system has the ability to continually produce innovative or emergent novelties;
- variation alone is not enough
- variation: new instances
- innovation: new concepts
- emergence: new kinds of concepts
- novelty is relative to a model and meta-model
- you can’t say what is novel until you know what exists
Object oriented open-endedness
Instances can be compared to instantiated objects, models to classes, meta-models to meta-classes/interfaces.
Variation can be linked back to the creation of new objects, innovation to creation of new classes, emergence to creation of new meta-classes. Traditional OO simulations cannot even in principle exhibit open-endedness. Fixed code: no new classes or meta-classes.
Engineering vs scientific models
We see flocking in a boids system. Speaker said that “flocking” was an example of emergence - the emegence of an aggregate.
- Meta-model: engineering design paradigm, eg OO, goes through design stage –>
- Model: engineering design, eg a class, goes through implementatoin stage –>
- Instance: execution, instantiation of models at runtime, goes through execution stage where we can begin to observe scientific models:
- Instance: Observing executing code, build model obased on observation –>
- Model: Observation model, eg boids, flocks, build meta-model based on observation –>
- Meta model: Based on observed models (eg agents, aggregates, etc)
Engineering: top down; science: bottom up
Closing the loop
We need to close the loop and make a jump between the observations we are able to make at simulation runtime and the implementation of the new concepts we observe (ie new models and meta-models)
- When we implement a simulation in OO code, the engineering model is fixed. We can get variation in executing code (eg new instances), but not in the implementation.
- We can observe results of the execution by building a scientific model, so innovation and emergence may be observed and modeled. But, the simulation cannot access/exploit these novelties! They are in a different model, one that is not implemented in the code.
“The whole is other than the sum of its parts” - Kurt Koffka
If there is something special about something being an organism, it would be nice if our code could capture it/the concept. We want the simulation to close the loop: modify the engineering side based on the scientific side. [to me this sort of seems like this mostly captures the novelty that we already exhibit once we exhibit it…which is nice, but isn’t the most important thing the ability to generate that novelty at runtime in the first place? How we then model it back into our code seems like a side-question after that first monumental step, one that we haven’t fully figured out how to implement yet in the first place? Is this trying to solve a problem we don’t have yet?]
Steps to close the loop
- Novelty is recognized outside of the simulation (eg maybe by a separate observer process)
- Novelty is anticipated, using hand-coded rules to recognize and report it once it appears
- Code is modified to capture novelty as a component of the simulation
- Novelty is emergently recognized by the simulator; new code is generated by the simulator to capture the recognition
- Novelty is emergently captured by the simulator; new shortcut code is generated by the simulator to capture the specific emergence explicitly.
We want the system to recognize new things. Eg an agent recognizes a flock, and so the system is modified.
One way to do this may be by having two programs: One simulation with concrete models, and one “generator” that knows how to produce new classes based on output from the simulation.
Steps to Open ended systems
- open ended novelty
- not just variations (instance changes)
- innovation (model changes) is required, as well as emergence (meta model changes)
- requires reflection to change the code in simulations/ALife systems
“Don’t just build a classical object oriented system and think you’re going to find open-endedness, it is more complicated than that.”