This term I'm teaching an undergraduate course in Artificial Intelligence (AI). I got the job just as the semester started, and so I didn't get a chance to develop my own approach to the teaching of this very splendid and worthwhile subject. Of course, as a mixed blessing, there came the inevitable recourse to Russell & Norvig, who've shepherded thousands of similar courses over the last 10 years, and all over the place.
Book and lecture notes in hand, I've been so far following my first pass at a teaching algorithm:
1. Read the chapter. Make sure you understand it.
2. Prepare lecture slides.
3. Do a couple of exercises. Choose a couple for the next problem set.
4. Go over the slides a couple of times, mumbling things you want to say that are not explicitly written on the slide.
5. Enter classroom; deliver lecture; forget to use all your little "pedagogical devices"; watch students yawn...
6. Goto 1
This is as boring for the poor souls in my class as it is unsatisfying for me. I've "only" lost 4 students so far (out of a high point of 19), mostly due to a harsh problem set early on. But I need to come up with a better algorithm.
At least I have a nice subroutine in the "deliver lecture" department. At the beginning of each class, I call on random students to tell me, in their own words, about the concepts we discussed last time. In the spirit of modularity and reuse, I took this feature from a library of little gems by a senior faculty in my department. Thank you, senior faculty!
Saturday, September 20, 2008
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.
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.
Friday, September 12, 2008
On the computability of universal rapid-prototyping
The new issue of Seed magazine (No. 25) has an article on machines that can make a copy of themselves. Well, actually, they can only make all the parts (other than batteries) that are needed to make a copy of themselves. That's not half-bad either. A machine that's cheap (and for which the materials are cheap!) and that can make all the parts for a copy of itself -- that's a big step towards universal availability of rapid-prototyping. And that may very well lead to something like personal factories, by analogy with personal computers and a similarly revolutionary idea.
By the way, in addition to RepRap mentioned in Seed, Technocrati and tens of other online sources (presumably because the project is affiliated with Google?), Fab@Home and its inventor Evan Malone (then at Cornell) have been pursuing universal rapid-prototyping at least since 2006.
The very idea raises questions about the interplay of the computational and the physical. If you can readily manufacture articulated, controllable things in your home, how do you then make them do useful things? As of now, fabbers (for that is what we shall call these nifty machines) don't make computer chips or electronics as part of the process. But people are working on it, and it doesn't defy the imagination to consider building (programmable?) circuits directly into the fabricated parts. Ah. So many things to ask from a computational perspective. Here's one: what is the computational class of circuits built by a fabber? Meaning: what class of problems can these circuits compute? What about any physically realizable fabber? There's a research project in there, yours for free.
More on all that later.
By the way, in addition to RepRap mentioned in Seed, Technocrati and tens of other online sources (presumably because the project is affiliated with Google?), Fab@Home and its inventor Evan Malone (then at Cornell) have been pursuing universal rapid-prototyping at least since 2006.
The very idea raises questions about the interplay of the computational and the physical. If you can readily manufacture articulated, controllable things in your home, how do you then make them do useful things? As of now, fabbers (for that is what we shall call these nifty machines) don't make computer chips or electronics as part of the process. But people are working on it, and it doesn't defy the imagination to consider building (programmable?) circuits directly into the fabricated parts. Ah. So many things to ask from a computational perspective. Here's one: what is the computational class of circuits built by a fabber? Meaning: what class of problems can these circuits compute? What about any physically realizable fabber? There's a research project in there, yours for free.
More on all that later.
Sunday, August 3, 2008
Bayesian faith
I have often maintained that people who refuse to believe the mountains of accumulated scientific knowledge in domains where they have counter-scientific but unyielding faith aren't necessarily behaving irrationally. At the risk of being quoted out of context as supporting religious dogma over science (I don't, never have - if you quote this post, please quote its entirety), let me show you what I mean by that.
One of the intellectually rich contributions of computational thinking is the notion of Bayesian belief -- the idea that a rational agent must update its beliefs about possible events in the world based on some prior information and the evidence it sees. Sounds pretty straightforward, doesn't it? Well, maybe it doesn't until things are defined more rigorously. 'Belief' that X in this case is a probability the rational agent maintains in its mind that X is true. Classic example: do I believe I should take an umbrella with me today, as I go out to work (where else!?)? Well, that depends on what I a priori believe about the weather today (the forecast was for 40% chance of rain - maybe I shouldn't) and on what I see when I look out the window (evidence: menacing clouds ride low, gusts of wind seem to indicate a thunderstorm is on the way - oh-oh, maybe I should).
How exactly does one arrive at that decision, at that degree of belief? The beautiful thing is: there's a theorem about that. The best anyone can do was written down by a British Presbyterian minister by the name of Thomas Bayes in the 18th century. Bayes' theorem says that the likelihood of something is equal to its prior probability times the evidence, normalized. The trick is: if you a priori believe something to be 100% true (or false), then no amount of evidence to the contrary will sway you. To see that for yourself, check out the awesome intuitive introduction to Bayesian reasoning by Eliezer Yudkowsky (or the intuitive and short version by Kalid at BetterExplained), then try updating a prior probability of 1 in any of the examples.
It turns out that there is much evidence that our brain operates in a fashion consistent with Bayesian updating, on many levels from immediate visual perception (I can see the letters I'm typing but the higher-level prior context provided by my brain will prevent me from spotting some typos), to common-sense decision-making like in the umbrella example. The scientific method too can be described in Bayesian terms, as we inspect new evidence and deduce how much it discriminates between conflicting theories, and how much information is contained in it.
So, if Bayesian-like processes in our brains are responsible for rationality, and if you have 100% faith in something, then mathematically, no evidence will be of consequence. You will still believe your pet theory with 100% probability. Maybe that's how unquestioned beliefs operate: they aren't necessarily functionally unquestioned (the brain machinery is constantly at work) but the resulting belief is predictably stable.
But where could those crazily strong prior beliefs come from? That's a very important question, but one for another post.
One of the intellectually rich contributions of computational thinking is the notion of Bayesian belief -- the idea that a rational agent must update its beliefs about possible events in the world based on some prior information and the evidence it sees. Sounds pretty straightforward, doesn't it? Well, maybe it doesn't until things are defined more rigorously. 'Belief' that X in this case is a probability the rational agent maintains in its mind that X is true. Classic example: do I believe I should take an umbrella with me today, as I go out to work (where else!?)? Well, that depends on what I a priori believe about the weather today (the forecast was for 40% chance of rain - maybe I shouldn't) and on what I see when I look out the window (evidence: menacing clouds ride low, gusts of wind seem to indicate a thunderstorm is on the way - oh-oh, maybe I should).
How exactly does one arrive at that decision, at that degree of belief? The beautiful thing is: there's a theorem about that. The best anyone can do was written down by a British Presbyterian minister by the name of Thomas Bayes in the 18th century. Bayes' theorem says that the likelihood of something is equal to its prior probability times the evidence, normalized. The trick is: if you a priori believe something to be 100% true (or false), then no amount of evidence to the contrary will sway you. To see that for yourself, check out the awesome intuitive introduction to Bayesian reasoning by Eliezer Yudkowsky (or the intuitive and short version by Kalid at BetterExplained), then try updating a prior probability of 1 in any of the examples.
It turns out that there is much evidence that our brain operates in a fashion consistent with Bayesian updating, on many levels from immediate visual perception (I can see the letters I'm typing but the higher-level prior context provided by my brain will prevent me from spotting some typos), to common-sense decision-making like in the umbrella example. The scientific method too can be described in Bayesian terms, as we inspect new evidence and deduce how much it discriminates between conflicting theories, and how much information is contained in it.
So, if Bayesian-like processes in our brains are responsible for rationality, and if you have 100% faith in something, then mathematically, no evidence will be of consequence. You will still believe your pet theory with 100% probability. Maybe that's how unquestioned beliefs operate: they aren't necessarily functionally unquestioned (the brain machinery is constantly at work) but the resulting belief is predictably stable.
But where could those crazily strong prior beliefs come from? That's a very important question, but one for another post.
Saturday, July 26, 2008
Randy Pausch 1960-2008
RIP Randy Pausch, CS professor at CMU who achieved his childhood dreams and delivered a poignant "Last Lecture" when he was diagnosed with terminal cancer.
His main legacy is Alice, a free software tool that pretends to teach kids how to tell stories in 3D graphics, but really teaches them serious programming. Programming, in the words of Don Slater from the Alice promotional video, is telling the machine in front of you how to do what you need it to do. But instead of focusing on the minutia of a programming language syntax, it gives students the ability to easily create and animate 3D virtual inhabited worlds. The characters are objects with members and methods, and the environment supports variables, loops, conditionals, recursion, -- most things necessary for a thorough introduction to programming, which can be done entirely through a drag-and-drop interface where no mistakes can be made.
The trick is that the students' attention gets engaged from day one with a storytelling/world-building experience and without the frustration of compiler errors and segmentation faults. The Alice team cite statistics for at-risk students getting better grades and a lower drop-out rate in computer science. "At-risk" of course means students who don't fit the traditional CS mold, precisely the students CS departments would like to recruit and keep in the name of diversity, creativity, and a richer talent pool.
Basically, Alice is like an all-virtual Lego MindStorms on crack. For some reason, I think this sort of inappropriate language for an obit (which this isn't) would be appreciated by the late Prof. Pausch. Alice takes to university level what the Lego programming interface gave to younger kids: the same wonderment at just having created something with your own drag-and-dropping hands, at at watching it do its stuff. This is how many an engineer gets her calling.
Randy Pausch and the Alice team say: look, kiddo, you can take these abstract things and stack them any which way, and depending on how you do it, your machine will make you a world full of action and character, joy and meaning. This is so close to magic. And by the way, you have now learned Java. I wish I was learning to program all over again.
His main legacy is Alice, a free software tool that pretends to teach kids how to tell stories in 3D graphics, but really teaches them serious programming. Programming, in the words of Don Slater from the Alice promotional video, is telling the machine in front of you how to do what you need it to do. But instead of focusing on the minutia of a programming language syntax, it gives students the ability to easily create and animate 3D virtual inhabited worlds. The characters are objects with members and methods, and the environment supports variables, loops, conditionals, recursion, -- most things necessary for a thorough introduction to programming, which can be done entirely through a drag-and-drop interface where no mistakes can be made.
The trick is that the students' attention gets engaged from day one with a storytelling/world-building experience and without the frustration of compiler errors and segmentation faults. The Alice team cite statistics for at-risk students getting better grades and a lower drop-out rate in computer science. "At-risk" of course means students who don't fit the traditional CS mold, precisely the students CS departments would like to recruit and keep in the name of diversity, creativity, and a richer talent pool.
Basically, Alice is like an all-virtual Lego MindStorms on crack. For some reason, I think this sort of inappropriate language for an obit (which this isn't) would be appreciated by the late Prof. Pausch. Alice takes to university level what the Lego programming interface gave to younger kids: the same wonderment at just having created something with your own drag-and-dropping hands, at at watching it do its stuff. This is how many an engineer gets her calling.
Randy Pausch and the Alice team say: look, kiddo, you can take these abstract things and stack them any which way, and depending on how you do it, your machine will make you a world full of action and character, joy and meaning. This is so close to magic. And by the way, you have now learned Java. I wish I was learning to program all over again.
Tuesday, July 1, 2008
The Boston Phoenix weighs in on the eternal question
Will robots take over the world?
There's endless speculation, and I promise to post some links and actual commentary shortly, but meanwhile, I'm a little late in on this: http://thephoenix.com//Boston/Life/61912-Rage-against-the-machines/ (published May 28, 2008), where I sound like a total ass.
There's endless speculation, and I promise to post some links and actual commentary shortly, but meanwhile, I'm a little late in on this: http://thephoenix.com//Boston/Life/61912-Rage-against-the-machines/ (published May 28, 2008), where I sound like a total ass.
Monday, June 30, 2008
A tournament of social computers
It is where they don their armor and charge, in the name of 10,000 euros.
"They" are pseudo-code strategies for a strange game that the organizers claim will shed some light on the computational properties of social behavior.
The rules of Project Cultaptation's Social Learning Strategies Tournament are complex, but the game is simple. Your strategy has to invade a population of 100 agents over thousands of simulation runs, based on its accumulated score. You get points by pulling levers of an n-armed bandit machine. But you can only pull a lever that you know about. And that knowledge can come from two sources: either you try your random luck, or you look at someone pulling levers next to you. Seems like a no-brainer, but the devil is in the details of this clever setup. Observing someone may be error-prone. The scoring may change over time, maybe faster than the expected lifetime of the agents.
I'm sorry to say that the deadline for entries to the tournament is over; it was today. Playing with the simulation has been truly fun. Of course, I really doubt that my entry will win -- I hope it gets past the round-robin selection phase! But I'd like to make a prediction about the winner.
I think the winning strategy will be very simple -- 10 lines of elementary pseudo-code maximum -- and stochastic -- with in-built randomness. I might have my reasons for that, but the chief ones come from history (the strategy that won the Prisoner's Dilemma tournament back in the 1980s was a very simple tit-for-tat) and perhaps misplaced reasoning-by-analogy (there's randomness in the environment, therefore a good strategy should include some of that too).
And I think the results won't tell us much about the fundamental nature of social learning, that is, gleaming truths about the way the world works from observing the behavior of others.
Why not? For instance, because in the tournament, my actions don't influence anything about the world beyond my own ability to score and therefore reproduce (ha ha). Or because there is no competition for resources -- all agents can choose the same action and they will all receive the same scores, same as it would be if only one agent chose it. Or even because there is no timeline, no sequences in this game, no planning a few steps ahead even.
Still, I can't wait to see the results, and they will be fascinating for all the simplifications of the game. And if I'm wrong, if the winning strategy is complex, or deterministic, or biologically plausible, it'll be pretty exciting to reason why that should be the case, and how the tournament actually captured some fundamental property of learning in groups.
"They" are pseudo-code strategies for a strange game that the organizers claim will shed some light on the computational properties of social behavior.
The rules of Project Cultaptation's Social Learning Strategies Tournament are complex, but the game is simple. Your strategy has to invade a population of 100 agents over thousands of simulation runs, based on its accumulated score. You get points by pulling levers of an n-armed bandit machine. But you can only pull a lever that you know about. And that knowledge can come from two sources: either you try your random luck, or you look at someone pulling levers next to you. Seems like a no-brainer, but the devil is in the details of this clever setup. Observing someone may be error-prone. The scoring may change over time, maybe faster than the expected lifetime of the agents.
I'm sorry to say that the deadline for entries to the tournament is over; it was today. Playing with the simulation has been truly fun. Of course, I really doubt that my entry will win -- I hope it gets past the round-robin selection phase! But I'd like to make a prediction about the winner.
I think the winning strategy will be very simple -- 10 lines of elementary pseudo-code maximum -- and stochastic -- with in-built randomness. I might have my reasons for that, but the chief ones come from history (the strategy that won the Prisoner's Dilemma tournament back in the 1980s was a very simple tit-for-tat) and perhaps misplaced reasoning-by-analogy (there's randomness in the environment, therefore a good strategy should include some of that too).
And I think the results won't tell us much about the fundamental nature of social learning, that is, gleaming truths about the way the world works from observing the behavior of others.
Why not? For instance, because in the tournament, my actions don't influence anything about the world beyond my own ability to score and therefore reproduce (ha ha). Or because there is no competition for resources -- all agents can choose the same action and they will all receive the same scores, same as it would be if only one agent chose it. Or even because there is no timeline, no sequences in this game, no planning a few steps ahead even.
Still, I can't wait to see the results, and they will be fascinating for all the simplifications of the game. And if I'm wrong, if the winning strategy is complex, or deterministic, or biologically plausible, it'll be pretty exciting to reason why that should be the case, and how the tournament actually captured some fundamental property of learning in groups.
Subscribe to:
Posts (Atom)
Posts
