Call Windows Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg
Showing posts with label evolution. Show all posts
Showing posts with label evolution. Show all posts

Sunday, 17 November 2013

representations, permutations, visualisations

Posted on 04:09 by Unknown
One of the things I’m interested in is evolutionary algorithms (EAs), and how to make them better.  An EA takes a population of “genomes”, “mutates” (changes a little) and selects (based on “fitness”), and mutates and selects, and ... until a suitably fit answer is found.

A recent advance has been the introduction of “evo-devo” algorithms.  (I’m putting all this biological terminology in scare quotes, because by the time the relevant process has been translated into a computer algorithm, it is so far removed from its biological inspiration as to make a biologist wince, or even exclaim in outrage.)  Evo-devo puts a distance between the genome (the representation that gets mutated) and the “phenotype” (the representation that gets selected based on fitness).  This can help the algorithm’s performance, by allowing simple easily mutatable genomes develop into complex structured phenotypes.

A colleague of mine at York, Jillian Miller, is the inventor of such an algorithm, Cartesian Genetic Programming (CGP).  The genome is a string of numbers (numbers are easy to mutate a little bit).  The string is then interpreted as a network phenotype.  The network itself has inputs and outputs, so is a form of program.

Now, let’s consider permutations.  A permutation of the numbers 1 to N is these numbers in some specific order.  So the permutations of 1 to 3 are: (1,2,3), (1,3,2), (2,1,3), (2,3,1), (3,1,2), (3,2,1).  A string of length N has N! (N factorial) permutations.  N! grows very fast; while 5! = 120, 10! = 3,628,800, and 100! > 10157.

Permutations are common in computer science.  One classic use is in the Travelling Salesman Problem: given a bunch of N cities, find the shortest path through all of them.  That is, find the permutation of 1 to N that gives the shortest path.  Given there are N! such permutations, clearly we don’t want to try them all.  Although exact algorithms that are essentially more efficient than trying all possibilities aren’t known (and it is strongly suspected that there aren’t any), there are algorithms that come up with very good approximate (nearly shortest path) answers most of the time.  EAs are one such class of algorithms: breed for fitter (shorter) paths.

Permutations as genomes are a bit tricky, though.  A permutation has structure: it must contain all the numbers from 1 to N, and each only once.  So you can’t mutate a single entry: you have to swap two entries, or do something else that maintains the permutation structure. “Crossover” is even harder: how do you take half of one permutation, half of another, and combine them into a valid permutation?  There are various techniques, but they are not very pretty.

Using an evo-devo approach to generate a permutation seems even harder: how do you ensure that your developed system is a valid permutation?  So, for example, with CGP we can have a list of outputs, but how do we ensure that this list is a valid permutation?  (Having a single output that is already a permutation merely moves the problem back inside the network somewhere.)

We need a further representation and development step that is guaranteed to produce a permutation.  Rather than try to get the network to produce a permutation immediately, let’s break it down into two steps: the network produces a list of numbers, then that list has to go through a further interpretation step to form a permutation.  Julian came up with an idea of how to do this: given a list of (say) real numbers (easy to produce with CGP), just sort them into ascending order.  The correspondingly sorted list of the indexes gives the required permutation.  VoilĂ !

A string of numbers is interpreted as a network, which outputs a real vector, which when sorted yields a permutation

What is happening here is easy to visualise using a technique called parallel coordinates.  A list of N real numbers can be thought of as a vector in N-D space.  But N-D space is hard to visualise if N > 3.  (I find it pretty hard to visualise even when N = 3.)

It’s hard to visualise a lot of dimensions this way

Parallel coordinates do what it says in the name: instead of drawing the N dimensions orthogonal to each other (rapidly running out of ways to do this in our 3D physical space), draw them parallel to each other.  It’s easy to draw lots of parallel lines.  Now plot the N-D point (x1,x2,...xN) as follows: plot the point x1 on axis 1, the point x2 on axis 2, and so on, then joint these points together with a line.  The line in the parallel coordinate plot represents the point in N-D space.

parallel coordinates view of a single N-D point

We can use these parallel coordinated to visualise how a vector of real numbers can represent a permutation by its components being sorted into ascending order.

(top) a vector of 20 real numbers, a 20-D point, drawn in parallel coordinates; (bottom) the same vector, with the parallel axes ordered so that the components are in increasing order: the sorted axis indexes are the permutation represented by the N-D point. 

The Python/numpy code that generated these plots is:
N = 20
P = range(N) # indexes
V = rand(N) # random vector

# plot unsorted vector
for dim in range(N):
ax1.plot([dim, dim], [0, 1], '0.5', linewidth=0.25)
ax1.text(dim, -0.2, str(P[dim]), ha='center', fontsize=32)
ax1.plot(range(N), V, '.k', markersize=20)
ax1.plot(range(N), V, 'k')

# sort, and plot sorted vector
P = argsort(V) # sort indexes
V = sort(V) # sort vector (for plotting)
for dim in range(N):
ax2.plot([dim, dim], [0, 1], '0.5', linewidth=0.25)
ax2.text(dim, -0.2, str(P[dim]), ha='center', fontsize=32)
ax2.plot(range(N), V, '.k', markersize=20)
ax2.plot(range(N), V, 'k')
Note that the code that generates the permutation is the single line P = argsort(V): the rest is just plotting code.

Here I started from a random vector, rather than the non-random output of some CGP network.  Sorting a random vector is one way to construct a random permutation, but as far as Julian and I can tell from the literature, this CGP use for representing evolved, non-random permutations isn’t standard.  Julian has been using it for several years in his module on evolutionary algorithms, and will be publishing a paper on some results next year.


Read More
Posted in algorithm, evolution, python, research | No comments

Thursday, 23 August 2012

in praise of waste paper

Posted on 11:45 by Unknown
I have a stack of "rough paper": paper printed on one side but no longer needed, that I keep by my desk for scribbled calculations and diagrams, for when I am thinking.  I've never really considered this, except occasionally to think that I should actually scribble these notes into my daybook as I go, so that they are part of my technical log.  That has always felt wrong to me for some reason.  Now I know why: Venkatesh Rao has the same experience, but understands it:
I can’t really work with ruled paper or blank two-sided paper. Both are pristine resources that I feel guilty about wasting with my manic scribbling of mostly useless thoughts. ...
... the reason I work best with one-sided printed paper is that it has already been bad-wasted. It’s going to the recycling bin anyway. So it is a particularly liberating medium to work with. More than liberating. You can feel virtuous because you are effectively redeeming bad waste.
Yes, exactly this.  I can draw a small diagram in the middle of an A4 sheet, dislike it, discard it, and draw again, and again, with no feelings of guilt (like Venkat, I use other people's discarded paper).  This freedom to redo things is very liberating.  If I was drawing in my daybook, or using some pristine pad of blank paper, I would feel constrained to be more frugal in my explorations.  As it is, I give the paper no thought whatsoever (except maybe a small glow of productivity when I discard a great wodge of it in the recycling bin at the end of the day: look at all that work I must have done!).

Venkat's post is about waste-enabled creativity: "civilizations are defined by the resources they can waste".  He talks about exploration-exploitation tradeoffs, where being able to waste resources allows cheaper, and hence more, trial-and-error exploration, and hence the discovery of potentially better solutions to exploit.

It's not just civilisations.  Biological life can be similarly defined.  Computer Scientists often (incorrectly) assume that biological evolution is a great optimisation algorithm.   This is incorrect for two reasons: (1) it's not "great"; it's wasteful: millions are born to give a varied pool from which a few fit are selected; (2) it's not an optimiser.  Biological life "wastes" enormous quantities of resource (a million cod are spawned so that two may survive to reproduce); it explores the vast evolutionary landscape like mad, and is fantastically creative as a result.

We Computer Scientists love bio-inspired algorithms, because of the (assumed) robustness of biological organisms.  But if only, we often wish, especially when we are being "good" frugal engineers, if only we could have all those lovely biological properties without all that waste.  Hmm.  Maybe in our attempt at software engineering and Artificial Life, the problem is that we are not wasting enough, and that we are wasting the wrong things. 
Read More
Posted in algorithm, evolution | No comments

Saturday, 29 January 2011

BoxCar 2D

Posted on 10:18 by Unknown
BoxCar 2D is a neat little evolutionary algorithm, that over time evolves dune buggies (inside a physics engine) that have to traverse an ever more rugged landscape.

BoxCar 2D screen shot
The little plateaus in the maximum fitness achievement give a lot of information about the environment. Will it ever get over that nasty spike at 396? Yes! But then there's that steep hill at 420... It finally powered over that at generation 39. But how long until it passes that gully around 490? At generation 54, it hauls itself out, and gets as far as the next bad obstacle at 529. Even after 700 generations, it can't get past that one... (Okay, I've been running this for too long, I admit. It's quite hypnotic. And it's fun watching later generations just power over obstacles that were literally insurmountable by their ancestors.)

average fitness over 400+ generations
What this shows is a combination of the power of evolution, and the restriction of a fixed representation. The algorithm can get so far, but to get further, there needs to be more novelty available. Look at the graph of average fitness. It rapidly shoots up to several 100 (here, fitness = distance travelled), but then it's just a noisy constant, with no overall improvement. Looking at the vehicles produced, it's easy to see why. They rapidly find good solutions within the constraints of a rigid octagonal body with wheels fixed to the vertices, but can then go no further. Watching the cars race across the terrain, it's clear they need more, maybe a flexible body, maybe something else. But they're locked into the one representation: that needs to change, to develop, too. I look forward to something like BoxCar 2D but with added evo-devo!
Read More
Posted in evolution | No comments
Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • hyperbolic hyperbole
    What's with hyperbolic discounting? It's everywhere ! I first consciously noticed the term at a workshop about six weeks ago, and n...
  • better use seaweed
    As Neils Bohr is alleged to have said , “prediction is very difficult, especially about the future”. My smartphone has a weather app on it t...
  • oh dear
    We have a garden pond to help encourage frogs and other amphibians. Hedgehogs may suffer, however. :-(
  • "Windows support" -- not
    Just had another scam phone call -- someone with a strong Indian accent claiming to be calling from "Windows Technical Support" (o...
  • national stereotypes
    I've just got back from a very productive three day meeting in Paris. Just around the corner from where I was working, there was a marv...
  • retrospective holiday diary day 1: travelling north
    We went to the Lake District last “summer” ; this “summer” it was time for touring the other side of the country: Northumbria. The holiday s...
  • retrospective holiday diary day 5: trains
    Monday 24 September, and the long-threatened rain finally arrived. So this was the ideal day for the planned Carlisle-Settle rail trip . Bu...
  • funfair mirror trees
    One of the trees in our garden has died.  It died last summer in the drought, but we gave it a year to prove to us it really was dead.  It i...
  • retrospective holiday diary day 3: Lindisfarne
    Saturday 22 September, and the weather was still fine, sunny holiday weather so we decided to take advantage of the sunshine, and do Lindisf...
  • more scammers
    So not long after the scam phone call , the phone rings again. It's British Gas -- they get to call me because I'm actually a custo...

Categories

  • 3D printer
  • algorithm
  • astronomy
  • birds
  • Bonnie Tyler
  • books
  • cognition
  • computer
  • conference
  • Doctor Who
  • driving
  • ducks
  • duodecimal
  • education
  • electricity
  • estimation
  • Evernote
  • evolution
  • font
  • food
  • fractals
  • game
  • garden
  • graphics
  • grimoire
  • history
  • holiday
  • humour
  • language
  • LaTeX
  • lego
  • lol
  • mathematics
  • medicine
  • money
  • music
  • obituary
  • pedantry
  • politics
  • probability
  • psychology
  • publishing
  • python
  • quotations
  • research
  • robots
  • science
  • science fiction
  • space flight
  • statistics
  • TPS
  • trains
  • tree
  • TV
  • weather
  • web

Blog Archive

  • ▼  2013 (119)
    • ▼  December (1)
      • that's not in the least bit suspicious
    • ►  November (17)
    • ►  October (12)
    • ►  September (10)
    • ►  August (9)
    • ►  July (8)
    • ►  June (10)
    • ►  May (19)
    • ►  April (10)
    • ►  March (9)
    • ►  February (4)
    • ►  January (10)
  • ►  2012 (103)
    • ►  December (16)
    • ►  November (8)
    • ►  October (14)
    • ►  September (6)
    • ►  August (13)
    • ►  July (8)
    • ►  June (6)
    • ►  May (9)
    • ►  April (10)
    • ►  March (7)
    • ►  February (5)
    • ►  January (1)
  • ►  2011 (79)
    • ►  December (7)
    • ►  November (5)
    • ►  October (10)
    • ►  September (7)
    • ►  August (6)
    • ►  July (5)
    • ►  June (6)
    • ►  May (6)
    • ►  April (9)
    • ►  March (9)
    • ►  February (3)
    • ►  January (6)
Powered by Blogger.

About Me

Unknown
View my complete profile