Working on a demo for the MPE system consisting a grid of cells, each playing the film Run Lola Run at 60×32 pixels. Each cell is one frame behind (or ahead) of its left (or right) neighbor. The idea here is to ultimately have enough pixel space to display the entire movie all at once (much like Brendan Dawes’ Cinema Redux), only in motion. Too bad this is quite a blatant copyright violation.
(Special thanks goes to Chris Kairalla for suggesting “Run Lola Run” as the source content.)
This week, in The Nature of Code, we’re talking about genetic algorithms. A genetic algorithm is a search technique that involves a simulated population of candidate “solutions” (represented by virtual chromosomes) that evolve towards an optimal state. The process is a computational model of principles from biological evolution, such as selection, inheritance, crossover, and mutation.
One of the more challenging aspects to developing a genetic algorithm is coming up with a good “fitness function” for your candidate solutions, i.e. how well does this candidate solve the problem? Without a good fitness function, you won’t get anywhere since the function determines the likelihood of reproducing for the next generation. This is Survival of the Fittest in code.
Nevertheless, as per Flake, a better natural selection catch-phrase might be “Survival of the Survivors.” In the biological world, there is no fitness “function.” The longer you survive, the more likely you are to reproduce.
With that in mind, the above example is a simple evolution simulation, where the simple ability to live longer affords creatures (called “bloops”) a greater chance of having a child (the example uses asexual reproduction for simplicity, but could be modified to incorporate two parents). A bloop’s DNA determines its size and speed (the larger it is, the slower it moves.) The bloops wither away and die unless they find food, in which case their strength increases, causing them to they survive longer and hopefully reproduce.
There’s nothing inherently interesting about this example (other than as a demonstration of the technique itself) and it yields a fairly obvious result:
Bloops that are too big can’t move, don’t find food, die, and aren’t very likely to have children. Bloops that are tiny can move around very quickly, but aren’t terribly likely to find food either because of their small size. After about 10 minutes or so of running, the bloops evolve towards a “midpoint” where a reasonably sized, reasonably fast family of bloops take over (see above screenshots for “before” and “after.)
Since color is encoded into the genes, you can follow bloops from generation to generation (though it should be noted that color plays no role whatsoever in a bloop’s ability to survive.)
I’ve posted a brief tutorial on using JWNL, a Java library for accessing WordNet.
“WordNet is a large lexical database of English, developed under the direction of George A. Miller. Nouns, verbs, adjectives and adverbs are grouped into sets of cognitive synonyms (synsets), each expressing a distinct concept. Synsets are interlinked by means of conceptual-semantic and lexical relations.”
I wonder how useful it would be to create a Processing library with some basic WordNet functionality (or that simply exists as an interface to JWNL for all things WordNet.) There are many lovely examples of text-based Processing work out there. Two that jump to mind are State of the Union by Brad Borevitz as well as anything ever made by Ariel Malka.
The power of WordNet is not that it provides access to word meanings (which it does), but that it provides information about the relationships between words (and when I say “word,” I really mean set of synonyms, or synset). It’s the myspace for semantic concepts. You’re probably familiar with synonyms and antonyms. In addition, WordNet provides links for less well-known semantic relationships, such as hypernymy, hyponymy, meronymy, troponymy, and entailment. Do I see some sort of tree / network visualization in Processing’s future?
March 4th 2007. New York City
3 Minutes
Wherein we pick a name we like (Tech Trek: Inside ITP) and catch ITP researcher and teacher Dan Shiffman working on 6, 32-inch TVs. His project is was just up and running when we talked to him. It’s an open source Java framework for spanning real-time graphics applets/applications across multiple screens.
Coming soon to a Processing library folder near you, I’m pleased to announce a new project I’m developing at ITP with Chris Kairalla, tentatively titled “Most Pixels Ever.”
“Most Pixels Ever” (not to be confused with “Best Pixels Ever”) is an open source Java framework for spanning real-time graphics applets/applications across multiple screens. The above video is a quick demonstration of the first prototype. Three client applications on three Mac Pros connect to six 32 inch LCD displays (each Mac has a dual video card, but this could just have easily work with 6 client machines). One of the Macs is also running a server application. The server tells each client about the master pixel dimensions of all the screens combined (here 8160×768). The client keeps track of its own location dimensions (say 2720×768) as well as its location with in master dimensions (say 5040,0). The server keeps everyone in line, making sure that frames are rendered in sync.
In theory, the system is scalable to whatever your network will allow. If you want to run 100 LCD displays off of 100 mac minis, you can (and I really hope you do.)
We’ve got quite a bit of testing and tweaking to do before we release the library to the public along with documentation and instructions. So stay tuned!
Thanks to Caleb Clark for the video.
