Richard team taught the intro physics course I took my first year at Reed (where I learned that I was decent but not great at physics). On the strenuous recommendations of two good friends and physics majors (Peter Shirley and Neil Alexander) I later took the classroom part of second year physics from Richard. It was, as Peter had said, the best applied math course on campus, and Richard was a total genius with colored chalk, leaving the board covered with true works of art at the end of class. This was one of the most profound examples of the difficulty of capturing certain kinds of process in one’s notes, an issue I still struggle with as a teacher. Richard’s lectures were amazing to watch, but near impossible to wrestle into a notebook. I tried all sorts of things, including using colored pencils, to try to capture the glory of his board work, but it all failed. I suspect the only other person I had who’s lecturing was both as beautiful and as frustrating was Edsger Dijkstra.

More important than the classes I had with Richard, however, was his impact on me as a budding computer scientist. I’d taught myself BASIC in high school, but had never had any kind of instruction on programming or computing before my first semester at Reed, when we learned PASCAL in a series of labs in that intro physics course; labs which clearly owed their existence to Richard’s grasp of the growing importance of computation in math and science. Richard was friends with Steve Jobs, and it was through that connection and Jobs’ fond memories of his time as a quasi-student at Reed that Reed got an early Lisa, and then some of the first Macintosh computers. I remember playing with MacPaint on that clunky Lisa (I think with Peter Shirley again) and just being blown away – it was totally clear that we were seeing the future.

It was in significant part through Richard that I got to spend the summer of ’84 working at Reed designing fonts and programming for the earliest Macs. This was a very exciting opportunity, and I really felt like I was contributing to something. Probably my most notable achievement was the design of a bitmap math font (we’re just a little before PostScript here). Richard was very excited by the bitmap graphics on the Mac (taken for granted now, but still a novelty in the early 80’s), and as a scientist and mathematician he recognized the potential and value of not being tied to the ASCII character set that dominated computing at the time. So as a math nerd with computing interest and calligraphy experience (I was fortunate enough to take one of Robert Palladino’s last calligraphy courses at Reed in 1983), I was tasked with making a math font. This mostly consisted of designing a set of Greek characters, along with other common math symbols. It was hardly LaTeX (which would have been a nightmare to run on those boxes), but it was useful and widely used, and available for several years in big free font packs that you could get on a set of floppies from a fellow in (I think) Utah that had taken on the task of coordinating the distribution of free fonts. Those early bitmap fonts were, however, supplanted in short order by the much better PostScript fonts, and when I wrote my undergrad math thesis in MacWrite a year and a half later, I used the PostScript Symbol font instead of my own work. Sigh.

I also did some programming (I think I worked some on GriffinTerm, an early Mac terminal emulator), but my regret is that I didn’t make more of that opportunity. Richard was a strange guy who I at least found hard to read, but he was also clearly visionary and well connected. It’s hard to know what might have happened if I’d pushed myself more and made more of that opportunity. Sadly, I didn’t really understand the value of making things, and was mostly focused on “learning things” by taking courses and doing homework. I compare that to Thomas, who has done more extra-curricular “making” in his first year than I may have ever done at in my time at Reed, and it reminds me of why it’s so important to support our students at UMM in their “making”.

So farewell and thanks to Richard Crandall, a fellow who certainly made things, and who helped give me a great opportunity to make things.

A momentary interruption in the (slow) posting on the road trip (which has been done for nearly two weeks now!) to provide a time sensitive plug for those of you interested in genetic programming, evolutionary computation, and the like.

The Springer journal Genetic Programming and Evolvable Machines is celebrating its first 10 years with a special anniversary issue of articles reviewing the state of the field and considering some of its possible futures. For the month of July (which ends in two days!) the entire issue is available for free download.

Included in the issue are:

• Human-competitive results produced by genetic programming
• Theoretical results in genetic programming: the next ten years?
• Genetic Programming and Evolvable Machines: ten years of reviews
• Open issues in genetic programming
• Grammar-based genetic programming: a survey
• Developments in Cartesian Genetic Programming: self-modifying CGP
• Bio-inspired artificial intelligence: theory, methods, and technologies

Once the month ends these will all start costing money again with two exceptions: the article on human-competitive results and the survey of 10 years of reviews will remain free in perpetuity.

In the spirit of full disclosure, I’m on the editorial board of the journal and contributed to one of the articles. Still, it’s a cool resource marking an interesting time in the development of the field, so take advantage of it while you can!

Because it was late and I was in a hurry, I ended up just uploading the whole set (over several attempts), but marked them as private so people wouldn’t end up seeing two copies of that first group of images, figuring I’d sort things out in the morning.

The morning came, and it turned out that I really didn’t have a workable plan. All the pictures were on Flickr, but there was no good (i.e., automated) way to figure out which were the duplicates. If I could identify them, then deleting the duplicates and making the rest visible would be easy, but I didn’t have a clue how to find the duplicates using Flickr’s tools.

Sigh.

This would, however, be pretty straight forward in a script if I had all the data I needed, and this is where Flickr redeemed itself. They have a very rich API for accessing (and modifying) photos and their associated information (like tags), so if I could figure out how to use that I’d be golden. I’d poked a little with some Ruby Flickr libraries in the past, but none of them ever seemed very complete and they were always struggling to stay on top of Flickr’s changes and extensions to the API. A little searching this time, however, turned up Flickraw, which uses some really nifty Ruby metaprogramming to essentially build the Ruby part of the API “on the fly”, ensuring that it will be complete and up-to-date all automagically!

It turns out that Flickraw was indeed powerful, flexible, and easy to use. After authenticating (following the example on the Flickraw web site), I was able to use it to pull down a list of all the photos from “The boys next door”

my_owner_id = "68457656@N00"
play_title = "The boys next door"
my_stream = flickr.photos.search(
              :user_id => my_owner_id, 
              :text => play_title, 
              :per_page => 500)

I then split that list into the initial set of publicly visible photos, and the photos I’d uploaded after things got screwy and kept private (i.e., visible only to me):

public_photos = my_stream.find_all {|photo| photo.ispublic == 1}
private_photos = my_stream.find_all {|photo| photo.ispublic == 0}

My next task was to determine which of the private photos were duplicates of one of the public photos people were already looking at. All I really needed was the list of duplicates, but I decided to create lists of both the duplicates and the non-duplicates. I had to compare titles here because the Flickr IDs would be different; as far as Flickr knew they were all different photos. Happily, I had named them in a way that they each had a unique title, so if two photos had the same title, I knew they were the same shot uploaded twice.

dups = []
non_dups = []
private_photos.each do |photo|
  public_duplicate = public_photos.find { |pub| photo.title == pub.title }
  if public_duplicate
    dups.push(photo)
  else
    non_dups.push(photo)
  end
end

At this point, I could apply tags to all the photos in the two groups, and all the rest of the fiddling could be done through Flickr’s web tools:

non_dups.each do |photo|
  flickr.photos.addTags(:photo_id => photo.id, 
                        :tags => "to_keep")
end

dups.each do |photo|
  flickr.photos.addTags(:photo_id => photo.id, 
                        :tags => "to_delete")
end

I could have actually done everything with the Ruby script (delete the duplicates, change the remaining images to publicly visible, and add them to the appropriate set), but wanted to do that via Flickr so I could see what was happening as I went. And once the tags were in place, the work in Flickr was quite straightforward. The result: A set of 339 images that contains all the photos I uploaded, with no duplicates, all accomplished without deleting any of the original uploads.

Big thanks to Maël Clérambault, the author of Flickraw, for his excellent little library, and thanks to Flickr for providing this very nice set of API calls. (Now go fix Flickr Uploadr, damnit!)

As for the play – I just heard that they took second at today’s sub-sections competiton, which means they move on to sections next week, and Tom got a star performance award! Congratulations all!

The joy of programming is taking a crappy piece of code, full of hacks and bad practices, and rewriting it to be better in every way. — LynnKale

for a moment I couldn’t think of a word for “thing to tell me how to do other things,” googled ‘how to’ and figured the word (documentation) — _eli

It’s gems like this that make my day. Both authors are UMM CSci alum, now off doing cool stuff. It’s neat to be able to stay in touch on-line.

I’ve been sitting on this for a while I waited for EuroGP to get their web site updated; they have, freeing me up to do a little unabashed chest-thumping, leavened with some praise for UMM‘s excellent students.

A few weeks from now the Eleventh European conference on Genetic Programming (EuroGP) will happen in Naples Italy. The only other time I’ve been to EuroGP was in 2001 when we were here on sabbatical the first time. I really love the conference, and it’s small and intimate and tends to have a really high signal-to-noise ratio. Unfortunately, it’s also an expensive flight from Minnesota for a three day event, and the timing tends to be really awkward in my teaching schedule, so I’ve never made it back. One of my many fond memories of that conference was winning the best paper award with Riccardo Poli for a pair of papers we’d written together as part of that sabbatical visit. (Oddly, both times I’ve attended have happened to be the only two times it’s been in Italy. The little photo is from the 2001 event at Lake Como.)

The best paper nominations for this year’s event have been released, and I’m quite excited that both of the papers that I submitted this year are on the list. One is another join project with Riccardo, and the other is a paper with two UMM undergrads: Brian Ohs and Tyler Hutchison.

That’s Tyler in the photo up top, presenting some work he did with Andy Korth and I that won the best student paper award at MICS a year ago; Tyler also did the cover illustration for the forthcoming book Riccardo, Bill Langdon, and I are just wrapping up. In a big happy, Tyler was able to pull together the funds to fly out for the conference, so we’ll be able to do a joint presentation enlivened by his presence and cool drawings. Unfortunately Brian can’t make it, but it’s cool that Tyler can; this will be the first of my students co-authors that’s made it to a European conference with me.

The competition is gonna be tough for the best paper award, including a very nice paper by one of Riccardo’s students (Stephen Dignum). Fingers crossed!

The full program is also now on-line (as a PDF) — it looks like some cool material. I’m quite looking forward to the conference, although I must say I’m a bit nervous about the ongoing trash crisis in Naples (here and there).

It’s pretty cool when you update your repository and see

At revision 400

We just hit that on the genetic programming book that Riccardo and Bill and I are working on; we’re currently averaging close to 10 commits a day here in the final stages. We hope to wrap it up in the next 1.5 weeks and then off to the printers for fun (and no profit in the traditional sense)!

P.S. Anyone want to proof read a few pages? Get in touch and we can work something out.

Chris posted some cool questions on my earlier post about decentralized behavior in social insects:

so what kinds of things do computer scientists do w/this idea? is sort of what evolutionary computing is about? i picked up the evolution of cooperation recently (tit for tat wins prisoner’s dilemma) you must be familiar w/this, yes?”

There’s really three different (but related) ideas in this question:

• Decentralized and emergent behavior
• Evolutionary computation
• Game theory and cooperation

I’ll take them one at a time, with more on the first of the three, at least for now.

Decentralized and emergent behavior

People in computing are still trying to figure out how to best use the amazing things that we’re learning about critters like social insects. Probably the most promising application area is where you need flexible autonomous agents that don’t require some sort of central control.

One of the easiest examples would be robot exploration of a distant planet like Mars. Communication between here and there is slow enough that if you rely on control from Earth (as we currently do), things move very slowly. If, on the other hand, you “let them loose” there is a real risk that they’ll fall off a cliff or get stuck on a rock or whatever, and the process of replacing them is a lot slower (and more expensive) than the process of controlling them from here. An alternative, though, is to send a lot (dozens, maybe hundreds) of small and (relatively) cheap robots that work independently. In this scenario you expect to lose some, but count on enough surviving that you still accomplish the primary task. So instead of sending the great, lumbering Lost in space robot, you send a swarm of robotic ants, planning to lose a some (like worker ants) but doing great things in aggregate.

And this isn’t just a science fiction exercise. There are very real military applications of these ideas; imagine a hoard of reconnaissance robots, for example, in a battle theatre. You have to presume you’ll lose some of them, and you can’t have them depend on a single central control as that would present a serious weak point. There are also people exploring applications of these ideas for tasks like cleanup in extremely hazardous environment such as Chernobyl. Out on the edges of the spectrum, you have people proposing swarms of micro- or nano-devices, none of which are very smart, but which can in aggregate accomplish significant tasks.

One vision I’ve daydreamed about for several years, for example, would be replacing the massive combine harvester style of agriculture with a swarm of little “agribots”. These could handle things like planting, weeding, pest control, and potentially even harvesting without the need for huge expensive machines or grinding physical labor. One thing this could allow is the use of highly mixed plantings instead of the massive, fragile mono-cultures that define most of modern agriculture. Highly mixed plantings are essentially impossible in the current state of industrial agriculture, which favors vast fields of uniform crops, but were very common in pre-industrial agriculture.

At some level there’s a serious conflict between these approaches to problem solving and traditional computing. Most computer science is built on notions of precision and exact reproducibility. When you sort a list, for example, you want to sort a list in an exact and predictable way. It’s hard to predict with any precision the behavior of distributed systems with no centralized control. You can say things about their general behavior (they “tend” to do this or that), but it’s hard to perform any sort of exact analysis. This has made it hard to sell these ideas in certain quarters, especially if people want or need some level of precise understanding.

Evolutionary computation

These kinds of decentralized, distributed systems are not inherently connected to the area of evolutionary computation (EC), although EC is often used to to aid in the programming them.

In EC you evolve an (often approximate) solution to a problem. You typically start with a randomly generated collection of potential solutions to a problem. Some of these are better solutions than others, so you pull out the best and mutate and/or recombine them in some way to generate a new population. Again, some of those are better than others, so you use the better ones to make a new population. This process is repeated until either a reasonable solution is found, or you get bored and try again.

This can work very well in certain circumstances, usually where (a) you’re OK with an approximate solution (evolution is best at producing solutions that are “good enough” rather than “perfect”), (b) you’re working in a domain that we don’t understand well (there’s no point in goofing around with evolving approximate solutions if we have tools that provide exact solutions), and (c) you do have a good way of judging the quality of solutions (without which you can’t decide who are the “winners” in the evolutionary process).

EC is used in a whole host of settings, some of which are very cool. (There was a great example a few years ago of evolving a satellite antenna which I could say some more about if folks are interested.) Writing programs to control highly distributed, decentralized systems remains a very challenging problem, but we can often measure how well a swarm of agents solves a problem even if we don’t really understand how they accomplish the task. Consequently EC is often at least one of the tools that is considered when developing distributed, decentralized multi-agent systems.

Game theory and cooperation

The prisoner’s dilemma problem has long since been a favorite of mine, and I could blather on about it at great length. Sticking to the general theme here, however, it’s a nice example of a problem where the agents involved have to make decisions without being able to coordinate or communicate beforehand.

I’m definitely aware of (and highly recommend) Axelrod’s Evolution of cooperation and his other work on the prisoner’s dilemma problem; it’s easy to over-interpret some of the ideas in his book, but there is still much to be said there about cooperation, trust, and responding to threats. Hofstadter also has an nice discussion of this and a host of related problems in several chapters of Metamagical themas.

The evolution of cooperation has long been (and remains) a central question in biology as well as in evolutionary computation. Prisoner’s dilemma has, as a result, been a subject of considerable study in the EC community. It (along with numerous other examples from game theory) has also formed the basis of numerous EC studies in areas such economics and market studies.

Thanks to Chris for the excellent questions!

“I would have sent to Rome that’s worthy death?”

“The naturalist looking at species as he might succeed from a fork low down in the separation of the species of any species in a more or less from their sap this is unimportant for the instincts already possessed by certain plants so that natural selection of mere piles of superimposed strata and watch the sea separating an island even if we believe that pure water can effect little or no offspring.”

“The troubling aspects of a building block semantics in a given tree in the context and false.”

The answer and (much) more is below the fold.

That probably wasn’t too hard.

Except, of course, I’m a mean person and it was a trick question. In fact none of those sentences was actually written by a human being. All three of these pseudo-quotes were generated using simple statistics and the notion of N-grams (which I will describe below) to capture and reproduce the sense of a text, without really understanding it at a larger scale. I wrote a program to create these examples as an opening illustration for my Dagstuhl talk, and since they’re a lot of fun I thought I’d summarize the key concepts here.

A quick intro to N-grams

The essential idea is to look at the frequency of the occurrences of groups of adjacent symbols (called N-grams). In this example the symbols are words, and we’re using N=3, so we’re looking at triplets of adjacent words. The preceding sentence, for example starts with the following sequence of triplets:

• (“In”, “this”, “example”)
• (“this”, “example”, “the”)
• (“example”, “the”, “symbols”)
• Etc.

Note that the triplets overlap, so most words will in fact appear in three N-grams (triplets), once at the end, once in the middle, and once at the beginning, as happens for “example” above.

Let’s say you go through a text (a book, say), and make a great big list of all the N-grams and how often they each occur. What would that tell us about that text? That depends pretty crucially on the value of N. If N=1, for example, then we’re simply counting up the frequency of individual words. This could be very useful in certain circumstances; we could, for example, probably use that to decide whether the text is a crime novel or a technical paper on econometrics. N=1, however, doesn’t give us any sense of the larger structure of the document; we may find it difficult to distinguish between two particular novels, and we’d be unable to recognize when words tended to appear in related contexts (does the author tend to mention the butler whenever missing candlestick is discussed?).

If, on the other hand, we take N to be much larger (several 100s or 1,000s of words) then we capture lots of long range structure, but we lose any kind of statistics. Almost all sequences of 100 consecutive words, for example, are likely to be unique. Consequently they will tend to only appear once in our table for a given text, and are unlikely to appear in the tables for any two texts (although if they did that would be a useful plagiarism flag). Very large sequences don’t really work, therefore, as a tool for looking for relationships between documents, or even patterns within a text.

Experience in fields such as computational linguistics suggest that taking N=3 is a useful compromise position. [1] Different triples occur often enough (assuming the text has some length) that their distribution is meaningful (like when N=1), while there’s enough structure and overlap with N=3 that you can capture some long-range regularities as well.

Generating my “pseudo-quotes”

All of which is illustrated by my pseudo-quotes above. Each was generated by first computing the frequency of triples in three texts: Coriolanus, The origin of species, and a paper I wrote last fall with a couple of UMM students. [2] I also kept track of the frequency with which words occurred as the first word of a sentence, and the frequency of pairs containing the first two words in every sentence.

The program starts generating a sentence by picking a first word based on the frequency of first words (so if 20% of the sentences started with “The”, there would be a 20% chance of starting our new sentence with “The”). Given that choice, the program would take the table of frequencies of all the pairs of first two words, and pull out just those pairs that used our chosen first word. Once we have the first two words, we can repeatedly generate words based on the frequencies of 3-grams in our big table. If we’re using Coriolanus, and the last two words we’ve generated were (in order) “I” and “would”, then the relevant triples that occur in that play more than once are:

with another 11 “I would” triples that occurred a single time. Thus “I would have” (the prefix we chose in the “Shakespearean” sentence above) was more likely to be chosen than “I would he” by a ratio of 3:2, and three times more likely to be chosen than any of the triples that occurred just once. It was, on the other hand, less likely to be chosen than either “I would they” or “I would not”, but the (digital) dice rolled in its favor on this particular run.

Now that we have that start, we continue choosing words based on the last two that we’ve added to the sentence. So we look in our table at what triples start “would have”, and chose (this time) “sent” as the next word. We then look up “have sent” and chose “to”. The process continues (in my program at least) until we choose a “word” that’s in fact a terminal punctuation mark (a period, a question mark, or an exclamation point), thus ending the sentence.

A few observations

As we can see from the pseudo-quotes that I opened with, this process can generate sentences whose style is clearly recognizable, and which can make a great deal of sense at the local level (e.g., at the level of phrases). This process, however, doesn’t “understand” or respect larger structural connections or semantics. The third pseudo-quote, for example,

“The troubling aspects of a building block semantics in a given tree in the context and false.”

lacks a verb. The large Darwin pseudo-quote

“The naturalist looking at species as he might succeed from a fork low down in the separation of the species of any species in a more or less from their sap this is unimportant for the instincts already possessed by certain plants so that natural selection of mere piles of superimposed strata and watch the sea separating an island even if we believe that pure water can effect little or no offspring.”

rambles all over the shop, containing very sensible phrases like “The naturalist looking at species” as well as nonsense such as “pure water can effect little or no offspring”.

What we did with it

In the research I was reporting on, Riccardo Poli and I applied this idea of N-grams as a tool for capturing regularities in a language to computer programs that were represented as sequences of simple “machine” instructions in a highly simplified programming language that was designed for a specific set of test problems. We used a type of Estimation of distribution algorithm (EDA) to essentially evolve the triplet frequencies, instead of taking them from a text like I did with Coriolanus, and then used those to generate programs much like I did with the text examples. We would generate a set of, say, 100 programs this way, and try each of them on our test problem. Some were better than others, so we’d take the better ones (say the top half) and use those to update the frequencies; triplets that appeared in those better programs would have their frequencies increased somewhat, while those that didn’t would have their frequencies reduced.

When repeated over several generations, this process would evolve/learn/find/discover a set of frequencies that allowed it to generate successful programs with a reasonably high probability, at least on problems that had solutions that could be formed from repeated sequences of instructions. Even though it was limited to only 3-grams, the system was able to “learn” some fairly long sequences of instructions. In one case, for example, the evolved set of probabilities generated, given a particular starting pair, a particular sequence of 9 instructions with probability of over 60%, which is some 500,000 times more likely than generating a sequence of that length by randomly drawing instructions from a hat. The solutions that were generated tended to be composed of numerous copies of a small number of basic patterns, and it seems likely that this approach will do better in problem spaces where there are solutions that exhibit that kind of regularity.

If you’re interested in learning more, check out the paper: “A Linear Estimation-of-Distribution GP System”.

[1] Does anyone know of a theoretical justification for this?

[2] ”Semantic building blocks in Genetic Programming”, which will be appearing next month in the Proceedings of the European Conference on Genetic Programming (provide link).

Registration for both the Algorithm and Marathon competitions in this year’s TopCoder Open close in the last week of January, so start sharpening your … uh … programming … thingies …

I was participating in TopCoder events a fair bit when we first got to Colchester. I stopped, though, once the research really got up to speed, and I haven’t participated in TopCoder in several months. I’m not entirely sure I’ll be able to participate in this year’s open (there may be an unavoidable scheduling conflict), but it would be nice to try to add another t-shirt to my collection.

For those about to code, we salute you!

One way this has often played out has been in debates over programming languages and development tools. Students are (quite legitimately) concerned with their near term employment prospects, and so they tend to focus what they’ve heard of, and what they see in the job web sites. Unfortunately that is almost always an exercise in looking backwards in time. When I started in 1991, the problem was getting students out of Pascal and C and start thinking about objects. Now we’re working to add things like Ruby and Python to our Java-heavy toolkit. Constant throughout has been the difficult task of getting them to take (semi-) functional languages (Scheme, Haskell) seriously or, in fact, any language doesn’t have a “For dummies” book at their local mega-bookshop.

I need to be fair, though, and make it clear that we’ve always had students who could see the bigger picture, and have often pushed us faculty to open some important new doors. I suspect that we’ve actually been luckier in that respect at UMM than many other programs. That said, you still get groaners (often very vocal) who never seem to be happy unless you’re emphasizing whatever tool or language they’re firmly convinced is their only road to employment.

This is one of the reasons that it makes me so happy to see the list of programming languages used in the One Laptop Per Child project:

We will support five programming environments on the laptop: (1) Python, from which we have built our user interface and our activity model; (2) Javascript for browser-based scripting; (3) Csound, a programmable music and audio environment; (4) Squeak, a version of Smalltalk embedded into a media-rich authoring environment; and (5) Logo. We will also provide some support for Java and Flash.

OK, we can debate the details (and I’m sure people have and will), but let’s skip all that shall we? Let’s instead note that none of these was a “heavy hitter” 5 or 10 years ago, and there are plenty of people who would (wrongly in my opinion) argue that none are terribly important today. How many data structures classes in the U.S., for example, (a key “bread and butter” course in most computing curriculums) use any of these languages? I’m sure there are a few (especially Python), but proportionally I bet it’s pretty tiny. (Try searching either Amazon or the web for textbooks for such a course, for example.)

It’s also worth considering impact here. Sure, I doubt that anyone’s likely to start building inventory control systems in Logo, but should that be the issue? What’s the real opportunity for impact here? How do I change the world? By building accounting systems? Or by contributing to a project that plans to put computers and software in the hands to millions of kids all around the world?

You want to make the world a better place? You want to really fight terrorism? Then give people hope, a chance to grow and make their world better. Give them something to protect. Contribute to a project like this.

And, if you’re contributing to this project, you apparently program in Python, JavaScript, CSound, Squeak and Logo.

So let’s put an end to the whining about these not being “real” programming languages and nobody building “real” programs with them. I’ve written a crapload of Java code in my day that only a handful of people will ever use. Some bright bulbs used Squeak to build Scratch, which I suspect will be used by millions. Hmmm … which do I find more impressive?