Following two weeks of no updates to this blog — 1 week lost due to job preparation, another week lost due to lack of broadband connection — an update as to where I am with proceedings.
On the coding front, I can’t remember if I actually said this, but I think I did actually, I am now starting to tinker with the simulation I hacked, in adjusting some of the parameters that are actually quite key to the simulation: namely either the proximity setting, cohesion weighting, separation weighting, and velocity matching weighting, to begin with I’ve started to play with the proximity setting: and I have hit a snag. The first a quick backdrop:
One of the things I do need to understand is whether or not a collection of agents are actually flocking together, or whether or not they are just merely appearing to flock: how can I quantitatively say whether or not a collection of agents is flocking? One of the things that struck me first was whether or not I can measure the polarisation within a group of agents. From my understanding of flocks, one of the key parameters of whether or not something is actually flocking is whether or not the members are pointing in the same direction, and actually try to manage the direction they are heading in. So I thought the first point of call would be to try and measure the amount of polarisation in a group of agents.
Now the first variable of the above four I decided to alter to see what effect it had on the flock a whole, was the proximity setting. The proximity variable declares how far way another agent is before the originating agent believes that to be a neighbour in a flock. In simple terms, I believe this to be equivalent to how far an agent can see, assuming of course that each agent wants to flock with the what ever agent it sees near to it. My hypothesis in this area, was the fact that if you increase the distance and agent could see before it started to flock with another agent, then as the proximity setting goes up (in other words how far an agent can see) this should have an effect on the polarisation of the flock as a whole. Namely, as the proximity very all goes up the amount of polarisation of flock to go up as well.
(As an aside I’m using Dragon NaturallySpeaking to dictate this to my computer: a side effect of this, I am noticing that I am becoming rather more loquacious as a result — I apologise for the spurious ranting that this is producing)
To measure this, I took a reading of the direction each agent in the flock was proceeding along, from 0 to 360°. I then measured the standard deviation of the direction each bird was flying in. My thinking here was that a flock that was well polarised would have a small standard deviation of the different angles each agent was travelling in; a flock with poor polarisation would have its member agencies lying in all directions, so the standard deviation of the directions of flocks whole would be quite large.
I went off and recoded the simulation I’m using to try and find out if this actually occurs. I’m pleased to report that it does, but there is an issue. Imagine that you have a flock of birds, flying at let’s say 5°. Now imagine that the standard deviation this flock is 15°. This means that (from memory here could be bit shaky) 63% of the flock lies in between 5° plus or minus another 15° — in other words from 350° to 20°. In theory this is a nice time flock. However, because you have a number of birds flying in the upper 300s, when you come to work at the standard deviation, it all goes horribly to pot. Instead of a standard deviation somewhere around 15°, you actually get the standard deviation of in the hundreds, because the high figures mess with the standard deviation calculation. Oh well…
Now in a meeting with Will on Thursday 10th of May he suggested having a correction scaling factor, whereby if the degree a bird is flying is greater than 181°, subtracting 180 from the degree figure result. I haven’t had a chance to work this out on paper yet, but I’m not sure that it will actually work — something I need to at least try. However, I have an admission to make: I need to do some additional work on the statistics front here. At the moment I have each simulation running for about 100,000 time steps per setting of the proximity variable. In hindsight, what I need to do is run the simulation at each setting of the proximity variable a number of times: so for example, run the simulation with the proximity setting of 2.0 four 100,000 time steps, 10 times. I reckon this would also negate the issue I’m having above with some of the standard deviations looking a bit awry. To do this, and try and adjust the Java simulation so that it will take parameter settings from the command line. So for instance I can tell the simulation to run with the proximity setting of 1.0, 2.0, 3.0, etc, for 100,000 time steps. I can then wrap this with a quick shell script to loop through the proximity settings I want, move the data output files out of the way, correctly renaming them etc. I can then examine them to my hearts content!
(Now I appreciate this is probably not a good sign, but in my defence it is a Friday afternoon, but I’m having a sly pint of beer to accompany me through this emerging monologue, and it it is absolutely smashing. As such for posterity, I highly recommend Hogs Back Brewery, from Tongham in Surrey, T. E. A. (Traditional English Ale) available from Waitrose — a complete cracker)
Now, onto the progress of reading about particle swarm optimisation. Over the past week I have been experimenting I suppose, with a Python-based particle swarm program — I’m sure I’ve blogged about this before, but basically this week has seen me copy numerous versions of programme, and effectively got it to output every single variable it goes through either to the screen or a text file, in a bid to understand what it is doing. And, I think I’m nearly there. Yesterday saw me output the results of a 20 particle strong simulation running over 50 iterations to a text file, to assess what the hell it’s doing in SAS.
The Python program is eventually trying to find the optimiser solution for a particular equation, and it prints out the results it comes across on a visual display. The data associated with each particle in the simulation is effectively a triple tuple, consisting of position, velocity, fitness. In this particular programme, the position is equivalent to the X axis, and the fitness is equivalent to the y axis. Now from looking at the results, I couldn’t understand how the programme could generate an xy coordinates. It appears the programme does an additional manipulation of the results that the particle swarm generate, before actually translating it into the graphical representation I was viewing through the screen. From following what the code does, and by trying out the calculation in both SAS and Excel, lot of it seems to make sense, but I’m still not understanding exactly how the optimised position of the equation is found and visually displayed by the programme. However is the next hurdle to cross.
