What the hell do you do and how should you do it
Jeff Markowitz | February 18, 2009
I recently saw a talk by a luminary, i.e. one of the few people you may have heard of, in computational neuroscience. It touched on issues of attention and object recognition, covering a good deal of theoretical and experimental ground. At least, the majority of the talk focused on how to mathematically model brain data, unifying neurobiological facts and behavioral data. This is the MO of computational neuroscience, all well and good. I started to worry when this particular luminary bragged about how much code was written for a particular simulation. Again, listing it is one thing, but this luminary bragged about it. You can write 10 trillion lines of Assembly and I will be suitably impressed at the ability of a graduate student to sit and write code for a 30 year PhD project. Just don’t expect everyone’s knees to buckle and accept that your simulation, by virtue of the size of its codebase, does anything meaningful.
Unfortunately, it seems that people are increasingly impressed by the mechanics of a simulation as opposed to whether the simulation simulates anything, and whether that thing is even worth simulating in the first place. In other words, a simulation’s validity is proportional to its complexity (i.e. lines of code) or the size of the supercomputer required to run it. This is obviously bunk, but neuroscience labs are beginning to arm themselves with GPU clusters now that CUDA has gained some traction, and we all seem to be abuzz about how quickly we can run large-scale simulations. Or, some are beginning to use brain-inspired algorithms in more realistic settings, for instance using natural video as input. There is a danger of pure science dabbling a bit too much in the applied here. A mathematical model of the brain should worry about modeling the brain first and doing cool things second. With the scaling up of hardware it seems that, myself included, the field could get a bit too obsessed with doing things better suited for industrial computer scientists who do the applied thing for a living. Having some fun with our brain-inspired algorithms shouldn’t be banned, but it shouldn’t be priority one either.
All of this presses on perhaps the core issue in computational neuroscience today: what the hell is computational neuroscience and how are you supposed to do it? Originally, the term was coined by Eric Schwartz to unify all work that used computational tools to investigate the brain. As far as defining the field goes, I think this is as good as one can do. This covers people working on computational issues in imaging, compartmental modeling (commonly using Genesis or Neuron), dynamical approaches to modeling, connectionist approaches to language, etc. etc. . This much diversity under one umbrella can be scary since it’s virtually guaranteed that no two computational neuroscientists will agree on anything. It’s a motley crew to say the least, but the common thread seems to be using computation to elucidate aspects of the brain. As for how to do computational neuroscience, it’s still the Wild West, and we’ll just have to wait for the big paradigm shift I suppose. But, this means that we’re still in search of a paradigm, and so we’ve got a lot of theoretical yards left to go. We need good old-fashioned theorizing, with or without big supercomputers and googleplexes of Assembly code. Here’s to hoping that we don’t waste too much time with our cool new toys, we’ve still got a brain to hack.
(Image from Flickr user Brookhaven National Laboratory)






