Entries for January 2006
How to normalise fitness scores
I've been thinking some more about how to normalise fitness scores, so that the number on its own is most meaningful. The issue really is one of making a comparison between agents tested under different conditions as much as possible into a comparison of like with like. This would be straightforward if there were clearly defined maxima and minima in the fitness space, but unfortunately it's not quite that simple.
Continue reading "How to normalise fitness scores"
Complex signatures from simple behaviour
I've spent about 3 hours today analysing one agent. This is longer than it usually takes, especially given that the agent's behaviour turned out to be quite simple. The reason it took me so long was that the agent's simple, 4-step control algorithm interacts with the environment in a way that creates a highly discontinuous [is this a word?] relationship between an environmental parameter (the length of oscillation between good food and bad) and the agent's effectiveness.
I'll put a little more detail behind the cut, but basically I realised that all of the apparent variety in this agent's performance was generated by artefacts of exactly how many epochs of good and bad food it had. I think this serves as an important warning to myself: sometimes the appearance of complexity is entirely deceptive.
Continue reading "Complex signatures from simple behaviour"
New category
I've found myself writing more about the day-to-day minutiae of what I'm finding than I had anticipated. This is useful to me, because I work things out in my head by writing them about them, and it's not always obvious which issues are going to turn out to be relevant a year from now. However, it must also be of very little interest to anyone else; or at least not of enough interest to justify wading through the many paragraphs I put online each day.
So I've started a new category—minutiae—to file all of these things away into. I'm going to try and write each minutiae post in such a way that the point is described by one or two paragraphs, and readers can safely ignore everything behind the cut. That way the detail is there for my reference, but hopefully everything that might actually be of general interest or ever make it into a paper ends up displayed on the main page of this blog without cluttering the site.
I've also moved some old posts into this category.
Establishing a fitness baseline
Having found that normalising agents' performance against the highest fitness achievable under the same set of conditions made me realise something else. For every individual trialset there is also a maximum possible fitness which depends on parameters, and which will feed back into the performance of an agent on a given trialset. So I decided to plot this. The pattern was more complex than I had anticipated, though in retrospect the causes of the pattern are straightforward.
Continue reading "Establishing a fitness baseline"
It's called research because you have to RE search
The past week in brief:
1-4 my to-do list from last week, of which I got as far as #3
5 Experiments I re-ran with fixed code, because the bug I mentioned last week about turned out to have a large effect on results (everything from the last couple of weeks; not all have finished yet).
6 Experiments running right now (testing out a simple shaping algorithm; trying larger numbers of interneurons)
7 Experiments I want to run soon (intermediate numbers of interneurons)
8 Programming to do (sensory flags; co-evolution?)
Continue reading "It's called research because you have to RE search"
Disambiguating performance
Today's update is going to be about two things: how important that bug I found on Thursday actually was, and some consideration of the appropriate way to compare fitness values.
Continue reading "Disambiguating performance"
A queueing system for parallel computing clusters
I had an idea for a pretty simple utility I could write that would save a little time when it comes to setting experiments off on the cluster. It would be less than a day's work to put together, but it's also something so obvious that I would have thought I should be able to find an existing program or script to do the same job. So before giving up any time to write a potentially redundant tool, I thought I'd describe it here and ask two questions: do you know of anything that does the job I describe, and if not, would such a thing be useful to you?
Continue reading "A queueing system for parallel computing clusters"
g++ and CRLFs
Recently, the version of gcc/g++ on the lab cluster was upgraded to 3.4.4 (I think from 3.3). I had to make some small changes to my code to make it compile on this new version, but it was nothing terribly complicated, and a pretty straightforward migration overall. However, I've been getting a strange warning since the upgrade:
In file ...
RDB_classes/VectorMatrix.h:574:39: warning: no newline at end of file
[full text after the cut, but basically it's the same thing 4 times]
This is even though I've added several blank lines at the end of the file, and tried messing around with the encoding to make sure there are both CRs and LFs.
Does this look familiar to anyone? And if so, what should I do about it?
I know it's only a warning and doesn't really impact anything, but I try to deal with all warnings so that I don't get into the habit of ignoring any of g++'s output.
Continue reading "g++ and CRLFs"
Slapping myself in the face
I have just found a bug I'd been looking for since Tuesday. Unfortunately it turns out to affect more of my experiments than I had realised, so it may invalidate my results from January so far. It's also possible that it didn't spoil anything—certainly the effects are subtle enough in most conditions that I didn't notice it until a run with just the right set of parameters—but I think I'm going to have to re-run quite a few experiments to find out.
Continue reading "Slapping myself in the face"
Comment settings
I've just noticed that this blog as it is currently set up requires commenters to give their email address, and then goes and publishes it in the "Posted by" line at the end of the comment. I don't like that, because it invites spam to commenters' addresses. I've figured out how to get Moveable Type to not require any identifying information, but that's not quite what I want either: I like making people give a name because even if they use a made-up handle it makes conversations easier to follow, and I still prefer to get peoples' email addresses so a reply can be made in private if necessary, but I don't want to get people spammed.
So, does anyone know if it's possible to get MT to require a name but not an email address, and/or to collect the commenter's email address without publishing it? Either of those things would be better than what I have it doing right now, but I can't find the appropriate options.
Incremental progress
I'm moving towards making the weekly updates a somewhat less detailed overview, overlapping with the more detailed ramblings I write more frequently but on no regular schedule. This week's is behind the cut.
Continue reading "Incremental progress"
David Baker: Computing structural biology
Last week I went to a talk by David Baker, in which he presented a major project of his lab: the Rosetta system for modelling and predicting protein folding.
Continue reading "David Baker: Computing structural biology"
Death and test data
For the past couple of days, I've been running and analysing the output from the fixed experiments in which agents are correctly saved every 100 generations, and agents die as intended, as I described on Wednesday. I'm nowhere near finished with this batch of data analysis, but while I wait for some tests to finish, and before I finish work for the week, I wanted to mention a few notable things I seem to be seeing:
CAVEAT: this is all preliminary; it describes incomplete data on which I have not yet done any significance tests.
- Agents score higher on the harder task
- Agents do better if trial sets are longer, but the search is slower
- Random trials marginally understimate performance relative to systematic trials
- The stupid threshold strategy is very common
- The population continues to improve after the supposed best agent has been found
Continue reading "Death and test data"
John Guttag: Shortening the Control Loop in the Management of Chronic Disease
Last week I went to a CSE colloquium at the University of Washington. The speaker was John Guttag, and he came to talk about treating chronic disease as a control problem (abstract), and why this approach helps with the management of many conditions. He started with a general description and justification of his approach, but most of the talk was taken up by two concrete examples—epileptic seizure management and heart failure prediction—which demonstrate the value of the approach in practice.
Continue reading "John Guttag: Shortening the Control Loop in the Management of Chronic Disease"
This week
Here is the update I wrote on Wednesday. Last week's update may be useful for context:
I have quite a lot to say this week, and for some of it I haven't yet sorted out the wood from the trees, so I'm going to try and break it down into useful sections, and put a summary up here. You may only want to read the summary, but the detail's there if you want it:
- I finished analysing the agent I described last week, and several similar ones. They are not very good, but I learned some useful things from them; mainly that my searches are often getting stuck in a local optimum, and that there is a source of noise I hadn't accounted for in the environment.
- A better agent: though I still haven't found one that does the phase locking I was hoping for, I've found one that behaves in a more useful reactive way, so it robustly does well. This is a bit of a mixed blessing, because the existence of a reactive strategy that works well probably makes it a lot less likely that a learning strategy will emerge.
- Programming done/to do: old bug fixed, a new one found & fixed, trying another way to generate the trials.
- Data to analyse: the experiments in which the agent does actually die when fitness reaches 0 are finished
- New experiments to run: ones in which non-optimal agents are saved correctly, so I can see whether anything interesting happens between the best agent being found and the end of the run.
- Next steps: maybe time to close off the temporal-correlation avenue and start looking at runs with useful sensory input?
Last week's update
What follows is edited from the status email I sent my lab last Thursday. It seems like as good a starting point as any for my weekly updates.
Continue reading "Last week's update"
About my work
UPDATE: This post is now obsolete. I'm in a transitional period right now, figuring out what to do next, and when I have a more detailed research statement I'll replace this post with it. Till then, here's a more recent post that brings things up to date.
Before I start in with the weekly updates, I realise they do need some context to make any sense, so here is a brief description of the overall project that I'm hoping will be the bulk of my PhD work, and some of the techniques that I [and my lab - none of these were invented by me] use. That is what follows; at this point it's fairly poorly structured, but within a month or two there will be a better-organised version serving as the introduction to a paper.
Continue reading "About my work"
About this blog
I started this blog last year as a bit of an experiment. I wasn't really too clear on what I intended to do with it, or who the audience was, and I think that has a lot to do with why it just sort of petered out over the past couple of months. Meanwhile I've had some time to think it through, and I've been making a serious effort to re-organise my work habits of late, so I think I know how this blog will fit in.
Although I do need to continue the write-ups of talks I go to, I see myself using this blog as more of a research notebook than before. Lately I've been using my paper notebook more, and this is certainly helpful, but there are a couple of reasons I think the blog will be a good supplement (not replacement). Firstly, I write much more slowly than I type, so while pen-and-paper is good for sketching out ideas and diagrams and tables of data, I find it really frustrating to try and write several pages at a time, but I know that I need to start doing this. The other reason is that from time to time I think it would be useful to get feedback from people on what I'm working on.
At the moment I write a weekly update that I send to my lab and file for my own future reference. I'm going to start putting bowdlerised [the internet does not need to hear about every stupid programming mistake I make, but it's useful for me to have a private record of them] versions of the weekly updates online. These are pretty linear—there's a lot of reference to "that problem I was talking about last week"—so I've been worrying about how to start, but I've decided to just jump in with the first one from this year, and hope it's comprehensible.
I also need to start writing more expansive things about the overall rationale behind my work. These should hopefully put the weekly updates into context, and help me stay focussed on the overall goals, rather than getting totally sidetracked with small details or demotivated because the overall plan is not clear to myself (both very easy traps to fall into). I'm not sure exactly what assumptions to make about the audience to write these for, so I think I'm going to take the path of least resistance, and write them for people with the same background as me. I don't want this to be incomprehensible to everyone else though, so I have one request of my audience: please ask questions. With feedback, I should be able to get better at pitching things right over time.