Showing posts with label physical world. Show all posts
Showing posts with label physical world. Show all posts

Saturday, February 7, 2009

Engineers who are citizens

After a 2-month hiatus, yesterday's talk by David Douglas inspired me to write again. The talk was entitled "Citizen Engineers, Computing and Clouds". So I went expecting a talk on regular folk who do engineering, perhaps the open source community, perhaps rapid prototyping in your home, perhaps harnessing the ideas and contributions of hobbyists for a greater good. The abstract mentioned engineering and computing's relationship to current social and world problems, specifically environmental impact, so I went hoping for a hint of an idea as to how computing, computer science, could help or hurt sustainability and the fight against climate change.

It was an interesting talk, but Douglas's "citizen engineers" are not regular folk doing engineering in their free time (as one might have guessed by extension from "citizen journalists"). Instead, I heard some interesting stuff about the carbon footprint of data centers (on a par with air travel), the lack of openness about power consumption and carbon footprint by Google, and how companies should incorporate environmental impact reduction into their business practices lest they go out of business.

Which is all very well, but here is what I would like to know. Are there advances in computer science that can be immediately applied to sustainability problems, and how? Is cloud computing better for the environment than older forms of computing, and how? Some obvious things were mentioned: data center computing doesn't require nearly as much plastic components as end-user computing, because who cares what the machines look like inside a data center? But here is what I would have liked to hear and didn't: here's a sustainability problem -- you can cast it in this very cool new way which immediately suggests a computational solution.

Maybe the deeper wisdom of tackling world problems with computing is that you can't address any abstract, computational aspect of any of them without thinking at the same time about very physical and mundane things like amount of plastic and power required. I'm thinking of this as the analog to the embodied intelligence idea: the physical imprint, the body that carries out the computation will be part of the problem and part of the solution. Maybe that was the message of the talk, that I'm finally getting.

Saturday, September 13, 2008

On the complexity of stuff

Last post got me thinking, which in my case means asking lots of questions and refusing to think through the answers, at least at first. Later, arguably, I will forget all about these very pressing questions and so will never find the answers until one day, I read something written about this elsewhere and bemoan the passing of time and my laziness.

But back to the pressing questions. One afternoon over tea with Dr. Peshkin, I heard him express an excellent question: what is the complexity of physical objects? In computational theory, there are complexity classes for problems. If an abstract machine (whose abilities can be approximated by a modern PC) can find the answer in a relatively short period of time, it belongs to one complexity class (called the 'polynomial-time' class or P) . If you need a machine that's capable of pursuing several solution lines at a time and non-deterministically switching between them, then it belongs to another, intuitively harder class of problems (called NP for 'nondeterministic polynomial time'). There's more classes, but the point is: you can tell if a problem fits into one of them. This is a useful thing for writing programs: you don't want to tell your computer to do something that's provably going to take from now until the end of time.

So is there a similar classification for objects? Objects are kind of like problems if you try to make them with your new personal fabber (PF). You need to tell the fabber how to make them, of course. And thus I think we can define useful complexity classes for objects in terms of the fabber that can make them and the instructions that it would require.

But what's the complexity of a fabber? Why, it's the class of objects it can make! :-) There's got to be a better way of course, but maybe we can establish equivalence classes, like in computability theory. Push-down automata can solve context-free grammars. A 2D laser printer can build planar objects. OK, this is a really uninformative example, but I have to think more to come up with useful classes in the complexity of stuff.

For now, let's all agree that stuff is pretty complex.