24: Course Overview; What Do Computer Scientists Do? | Video Lectures | Introduction to Computer Science and Programming | Electrical Engineering and Computer Science

Topics covered: Course overview; what do computer scientists do?

Instructor: Prof. Eric Grimson, Prof. John Guttag

Related Resources

Slides (PDF)
Transcript (PDF)

Download this transcript - PDF (English - US)

OPERATOR: The following content is provided under a Creative Commons license. You're support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare course at ocw.mit.edu.

PROFESSOR: All right. Today's lecture, mostly I want to talk about what computer scientists do. We've sort of been teaching you computer science in the small, I want to pull back and think in the large about, what do people do once they learn about computer science? And then I'll wrap up with a quick overview of what I think we've accomplished this term.

So what does a computer scientist do? What they really do is, almost everything. Graduates of our department, other departments, have done things like animation for movies you've all seen, they keep airplanes from falling out of the sky, they help surgeons do a better job of brain surgery, that's something Professor Grimson has worked on. All sorts of exciting things. Mostly what they have in common, and it's incredibly varied, what you can do with computer science, but it all involves thinking computationally. And if I had to use a single phrase to describe 6.00, that's the phrase I would use. The semester is really about computational thinking. I think this will be a fundamental skill used by everyone in the world by the middle of the current century. And it'll be like the, it will become one of the three r's, reading writing arithmetic. And I haven't quite figured I how to put an r in the front of it, but sooner or later.

So what is it? Well, the process is the process that we've sort of been advocating throughout the semester. You identify or invent useful abstractions. Sometimes they're out there, and we can just pluck them. Sometimes you have to invent them ourselves. We then formulate a solution to a problem as some sort of a computational experiment. Typically using those abstractions. Then comes the part that many you get bogged down in, but it'll get easier for you as you go on. Is to design and construct a sufficiently efficient implementation of the experiment. And I want to emphasize the word sufficiently here, in that it only has to be fast enough to run it and get an answer. And it doesn't have to be the fastest possible. We then need to validate the experimental setup, convince ourselves that the code is right, and then run the experiment, and then evaluate the results, and then repeat as needed. And that's, of course, the key. By now you've all learned that these experiments rarely are done the first time you run them. But of course, this is true of experiments in biology and physics and chemistry and everything else. But this is the basic process. And I think, it's a view that's not universally held, but I think is the correct view of what computational thinking is all about. It's an experimental discipline.

So the two a's are abstraction, choosing the right abstraction, and operating in terms of multiple layers of abstraction simultaneously. And that's a little bit tricky. Something that you've worked on this term. You invent some beautiful, high level of abstraction. But then you have to think about it, and implement it using the rather low level abstractions provided by the programming language. So we'll do a simulation of, well, the stock market, we've looked at it just recently. And you've got this abstraction of a stock, and at one level, when we're thinking about the market, we think of a stock abstractly, as something that has a price that moves up and down. But then at the same time, we say, well, is the movement Gaussian, or uniform, and we're operating at a somewhat different level. And then at a lower level, we're asking questions like, well, how should we represent it? is? It a dictionary, is it a list, that sort of thing. And we always bounce back and forth and spend a lot of time thinking about how the layers relate.

Now the other thing that's important, and it really distinguishes, I think, computing from a lot of other disciplines. Is, we don't just write elegant descriptions of abstractions on paper, the way you say, would do in mathematics. But we have to then automate those attractions. And we always think in terms of, how can we mechanize the abstractions? And that's the computational part, in many ways. How can we do that? Well, we can do it because we have precise and exacting notations in which to express these models. So I'll say a few words about the model of stocks, or a few words about the model of a drunk wandering around a field, but I can't get away with just the words. Eventually I have to convert the words to code. And that's sort of the acid test of truth. Have I really understood what the words mean? Because if I don't, I can't actually convert it to code.

And that's both the cursing and the bless of being a computer scientist. It's the curse because, you can't fake it, right? And that's one of the reasons that many students end up spending a lot of time in a course like 6.00. Because they know whether or not their program works. When you write a proof in math, you can delude we into thinking it's a solid proof, when it isn't. When you write an essay, you can delude yourself into thinking it's brilliant, when it isn't. But here, you look at what it does, and it either did what you thought it would do or didn't. And so that means you sometimes have to work extra hard, but the blessing is, when it's done, you really know you've done it. And you've got something useful. And that's because there's a machine that will execute your descriptions. And that's what makes it fun.

So some examples of computational thinking. How difficult is this problem? That's what we talked about when we talked about complexity. And we talked about, for many problems, for all problems, there's an intrinsic difficulty of solving the problem with the computation. Independent of how efficient your particular solution is. And then the question is, how can I best solve it? Theoretical computer science has given us precise meaning to these and related questions. Thinking recursively, another good example. Where we take a seemingly difficult problem, and reformulate it into one which we know how to solve. Very often, it's a smaller instance of the original problem. And we say, gosh, this is hard to solve. But then we think, well suppose the list only had two elements in it, would I know how to sort it? Yeah. Well, then we can build up and say, therefore I can use that idea to sort a list of any size.

As part of this thinking recursively we learn about reduction, we learned how to, say, reduce the problem of deciding what courses to take to an optimization problem in terms of the knapsack problem. Once we did that, we could say, oh, we know how to solve all knapsack problems, dynamic programming has been around a long time, we'll just do that. So we do a lot of these reductions, in betting, transformations, transforming one problem into another, and simulations. So some other examples, choosing an appropriate representation, modeling the relevant abstracts of a problem to make it practical. And this is the essence of abstraction that computer scientists learn, is how to figure out what's relevant and ignore what is irrelevant, or less relevant. Focus on the important things. That's an enormous skill in not only computing, but in life.

We worry about worst-case scenarios, damage containment, error correction, all of this we talked about, we talked about debugging, defensive programming, making sure the types were right, but again these are very general things that we think about. And we think about the fact, sometimes, it's kind of a nice idea, the fact that there exists really hard problems is actually a good thing. Because that's what let's us do things like use encryption to get privacy of our data, or privacy for our communications, privacy of our phone calls. Because we have learned that some problems are intrinsically difficult to solve, and that's what coding is all about. Or encryption is all about. That's a nice thing.

I now want to talk more specifically about what one group of computer scientists does. And that's my research group. Which consists of mostly graduate students, but every year I try and incorporate a few undergraduates in it. We work in the area of medicine, it's also the area in which Professor Grimson does most of his work. The goal is pretty simple: we want to help people live longer and better lives. Right? I don't think any of you will think that's a worthless goal. But, a second goal is, we want to have fun while we're doing it. Because life is way too short to do anything that's not fun for very long. So we push the frontiers of computer science, electrical engineering, and medicine. Working in close collaboration with physicians, and here you've got logos of some of the hospitals with which we work. It is, of course, fairly technical work. We use machine learning, clustering, data mining, algorithm design, signal processing. And everything we do ends up, eventually, getting translated to code which we then run. And so we worry a lot about software systems and the quality. We do write systems that, for example, inject electrical signals into people's brains. And it's kind of important, when you do that, that the software does what it's intended to do. At least if you like the people.

So some specific activities, and this is only a sampling. We work on extracting clinically useful information from electrical signals in the human body. Mostly the heart, the brain, and connected anatomy. For those of you who've never studied anatomy, I've labeled the heart and the brain in the diagram for you. The two major projects in this area we've been working on, is predicting adverse cardiac events and detecting and responding to epileptic seizures. And I want to say a few words about each of those. We'll skip this. So example one, treating epilepsy. I suspect most of you are surprised by the fact that one percent of the world's population has epilepsy. This is true in almost every part of the world. It's true in the United States, it's true in underdeveloped countries in Central Africa. It seems to be one of the few diseases that's invariant to economic situations. One of the reasons that people are surprised by this number is, most folks who have epilepsy try to keep it a secret. There's a long history, getting back to witches, people with epilepsy were deemed to be witches, were burned at the stake, things of that nature. People who have epilepsy are not allowed by the FAA to work on maintenance of aircraft. It's a ridiculous restriction, but it's in the law, so I know someone with epilepsy who's kept it a secret because he doesn't want to lose his job. That's a different sermon.

It's characterized by recurrent seizures, generated by abnormal electrical activity in the brain. It's really less a disease than a description of symptoms, because there are lots of independent, different causes of it. It can be inherited, that's a significant fraction. Or it can be acquired, typically by some sort of insult to the brain. People who have strokes or serious infections will develop epilepsy. Hemorrhages, and increasingly head injuries. Turns out to be an illness that is of now great interested the Defense Department because people are coming back from Iraq with epilepsy. So those of you who don't have a strong stomach, you might want to avert your eyes. Here's one manifestation of it. On the left is an EEG, and that's, in this case, a recording of the electrical activity in the surface of this girl's brain. You can see she's wearing what looks like a very funny looking shower cap. That's where the electrodes are. And it's recording the electrical activity in the brain, on the right is obviously a video. Well, pretty frightening. Not all seizures are quite that frightening. In fact, most of them are not. Sometimes people have what are called absence seizures, where they just sort of black out for a period of time. Still not a good thing if you're, say, driving a car when that happens.

The key issue here, is that the onset of the seizure seems unpredictable. And in particular, it seems unpredictable to the person who has the seizure. And that's the real risk. Seizures are typically self-limiting. They will correct themselves over time. Eventually this girl will return to, quote, normal. The seizure itself will probably be over in a minute or two, and for about an hour she'll be confused, and then she'll be OK again. But, because they're unpredictable, even people who have as few as, say, two a year, it dominates their life. So, if you're that girl, and even if you're going to have one of those a year, you're never going to be allowed on a bicycle. Because if that happens when you're on a bicycle, it's really bad. If you're an adult, and you have one or two year, you should never drive a car. Imagine if you've been driving a car when that happened.

Almost everybody with epilepsy eventually suffers a serious injury. They have a seizure while they're on a flight of stairs, and they fall down and fracture their skull. They get intra-cranial hematomas, they get burns if they're cooking at the stove, they drown in the bathtub. And it's the unpredictability that's bad. Death is high, two to three times out of the general population. Typically by accident related to the seizure. And then there's something called sudden unexplained death in epilepsy patients, SUDEP, which is estimated to be one per 100 patients per year. Just will die, and no one knows why. Frequently it will be at night, while they're in bed, and the conjecture is, they have a seizure, and end up face down in the pillow, smother, that kind of thing. So you can imagine, if you're a parent, you have a child with this, you don't sleep much. Really very sad.

So we want to do something about that. And our idea is to detect the seizure early. There are two onset times, electrographic and clinical. Electrographic is when the brain first starts looking suspicious, and clinical is when there's a overt physical symptom, that stiffness you saw in that young girl. Probably it went by too fast for any of you to notice, but if you'd looked carefully at the EEG on the left of that picture, you would have seen it going abnormal before she had any clinical symptoms. Because the symptoms are caused by the electrical activity in the brain, by definition, it proceeds the symptoms, or at least doesn't follow them. So our idea was to try and detect the electrographic onset. If you could do this, you could provide warning. So you could tell somebody, sit down before you fall down. Get out of the bathtub. Back away from the stove. Just an oral warning would be tremendously useful. You could summon help. You could tell a parent, come quick, your child is having a seizure right now in bed or elsewhere.

There are fast-acting drugs, Ativan, which if you inhale at the start of a seizure, can stop it, reduce it. And our particular interest is neural stimulation. There is reason to believe, it's yet to be proved, that if you apply the correct electrical stimulation at the very beginning of a seizure, you can block it. Or at least ameliorate it greatly. So, here's a picture of an EEG. And I'll just point out, seizures can be tricky to find. You might think this is a seizure, but it isn't. That's blinking your eyes. Oh well. Here is the seizure, but in fact, it's begun about here. Where things don't look particularly ominous. So it's pretty subtle to detect. One of the problems is, EEG varies across patients. And epileptics have abnormal baselines. Yeah?

STUDENT: [INAUDIBLE]

PROFESSOR: Highly variable in patients, but that's kind of typical. But that would be plenty of time to back away from the stove, or get off a bicycle. Not so much time to get off the Mass Turnpike, if you're driving a car. But it would be great, if you can give 10 or 15 seconds warning. In fact, if you could give five seconds warning, it would be tremendously useful. And for the treatments, it's even different, right? Yes, you're exactly right, in that particular case. The problem is, one of the things I've discovered in medicine, my work, is that almost all healthy people look alike, and all sick people look different. So, EEG, if you have epilepsy, your quote, normal EEG, when you're not having a seizure, looks weird compared to people who don't have epilepsy. People have been building seizure detectors for about 40 years now, and they don't work very well. Every EEG that gets shipped comes with a seizure detector, and the first thing most hospitals do is, turn it off. Because it just doesn't work. The good news is, that even though each epileptics brain signals look different, once you've learned what an individual's signal looks like, it's pretty consistent. Both the interictal, between seizure, and the start of the seizure.

Well, that tells a computer scientist, let's use machine learning to figure out what that patient's EEG looks like. And build a highly specific detector that will work great for one person, and not at all for anybody else. And then we'll just install it, and you know, everyone gets their own. So instead of one size fits all, it's design a detector to fit the patient. We have been working on this now for about six years. We've done, we've looked at about 80 patients now, more. And, highly successful. And I'm not going to weigh you down with all the statistical tests and everything, but we've done the kind of things I talked about in class. Looking at the data, doing the statistics, and suffice it to say, it works great. For nine out of 10 patients, roughly. And for the tenth, we just have to say, sorry, we can't do it. But, you know, you can't help everybody all the time.

We're currently, what you see here, is a picture of a neural stimulator. The stimulator itself gets implanted under the clavicle, and then a wire runs up and wraps around the left vagus nerve, which is the longest nerve in the human body. It runs all away from the head, down into the lower intestine. Latin for wanderer. Does amazing things, like control whether you're hungry or not. Its main, one of its main functions, is it controls the parasympathetic nervous system for the heart. And it's the nerve that the brain uses to tell the heart, slow down. But, in addition to transmitting down from the brain, you can transmit up the nerve. And in fact, the left one, for reasons I don't understand, translates much better up than the right one does. Which transmits much better down. So use the left one. And the notion is, if at the start of a seizure, we put a current on that wire, we stimulate the brain and we stop the seizure. That's the theory. It's been shown to stop seizures in rats. But I don't much care about helping rats.

People purport to have shown it stops seizures in adults, or in people. The level of evidence is, honestly, ambiguous. Because what they've done is, they've implanted it, and they give the patient a magnet. And say, when you're having a seizure, swipe the magnet across, sorry about that, swipe the magnet across the stimulator, it will turn it on and stop your seizure. Well, could you imagine that little girl trying to swipe a magnet across her chest? Not likely. So most people don't do it successfully. Some people report, I thought I was about to have a seizure, I swiped the magnet and I didn't have it. Well, how do we know? Did they really stop it, or did they just imagine they were going to have one? So it's pretty ambiguous, but we're now in the process of doing some real tests at Beth Israel Deaconness Medical Center. And we've been admitting patients, and controlling the stimulator, and so far I'm optimistic.

All right, one more example. Predicting death. Well, that's kind of ominous sounding. About one and a quarter million Americans have an acute coronary syndrome each year. That's to say, some sort of a cardiac event. A heart attack, or an arrhythmia of some sort, various kinds of things, unstable angina. And of that one and a quarter million people, 15 percent to 20 percent of them will die of a cardiac-related event within the next 4 years. Pretty high. In fact, about 5% within the next 90 days, there about. So what do you do? The key thing, we have treatments. We actually know how to treat most of these things. But we don't know who to give the treatments to? So, for example, who gets an implanted defibrillator? Who should be treated aggressively with statins? We think we've found a new way to decide who should get which of these kinds of treatments. Something called morphological variability, which I'll talk about only briefly. We've tested it on a fairly large database. We have a database with about 8,000 patients. We've looked at 2 days for each patient, each day has 24 hours, each hour has 60 minutes, each minute has, on average, 70 heartbeats. That's a lot of heartbeats. Over a billion. So a lot of the techniques we've talked about this term, about how do you deal with big things, I live with every day. Actually, more accurately, my students live with every day, and I commiserate.

But the tests are pretty convincing. As an example, they're implanted defibrillators, they, too, go under the clavicle. Fortunately we have two clavicles. And then they connect to the heart, and they notice, they have a sensor, they notice the heart is beating very badly, and they shock the heart. So you've all seen medical shows, where people put paddles on, say, clear, the patient goes boom boom, and then they say, sinus rhythm restored. Well, this does the same thing, but you walk around with it. Now, you don't want to turn on all the time, because as you can see, it delivers quite a jolt. Interestingly, this is an article from this fall, from the New York Times, 90 percent of the people who get one implanted, and the device itself costs about $50,000, let alone the cost of implanting it. 90 percent receive negative medical benefit. How do I know that they received medical benefit? Well, I know that 90% of them are never turned on. Remember, there's a sensor that decides whether to apply the shock. 90 percent of them, the sensor never says, turn on. So 90 percent of them can deliver no benefit because they're never used. On the other hand, clearly having the surgery to implant this, is some risk. So that's why the benefit is not only neutral, but negative. You've had fairly serious surgery, you've risked infection, and, in fact, this year several people died. I think three or four died when leads broke off on these things.

So, clearly we're putting in too many of them, if only 10 percent are used. On the other hand, roughly every one minute and 50 seconds, somebody in this country dies a sudden cardiac death. More often once every two minutes. 100 of them during the course of this lecture. If these people all had defibrillators implanted, many of them would not die. So, we have a therapy, we just don't know who to give it to. So, what does this look like? Again, this is pretty strong stuff. That's what sudden cardiac death looks like. An apparently healthy guy, suddenly he's dead. It's things like this that remind us why we can do real useful things with our talents or skills. So how do you identify high risk cases? Lots of different ways, I won't go through them, but we're focusing again on the electrical signals in the heart. We're trying to evaluate the shape of the heartbeat and what's going on. I won't go through details, the only thing I wanted to point out is, we use dynamic programming to actually do this. So the key idea in our method depends upon dynamic programming.

We've evaluated it several times. Here's one evaluation. We took the 25 percent of the population that we thought was at the highest risk. And you'll notice that within, actually the first 30 days, 4.19 percent of those people were dead. This is a retrospective study, by the way. The ECG had been recorded, and we knew, we had follow-ups on them, and of the people we said were not, the other 3/4 of the population, a very small fraction died. So this is called a Kaplan Meier curve, and it shows a huge gap. And in fact, roughly speaking, if we think you were at high risk, you were 8 1/2 times more likely to die within a month, within 90 days. And the good news is, we don't do this just so we can say, make your will. Get your affairs in order. We actually do this so that we can say, all right, this is a person who should maybe get a defibrillator, maybe should have their arteries cleaned out. Maybe should take a blood thinner. Once we know who's at risk, we can do something about it. All right, all I want to do is just give you a flavor of the kinds of things you've been learning, are really useful, and can be used to really do things that are worth doing.

So wrapping up the term, what have you learned? Well, you know, I think we'll start with this. If you think what you could do in September, and what you can do now, you've really come a long way, right? So try and go back and do problem set number one, and see how long it takes you now, and how long it took you then. You'll discover that you really are at a place you were not in September.

We covered five major topics. Learning a language for expressing computations, that's Python. I already talked about the importance of having a notation. Learning about the process of writing and debugging programs. But more generally, learning about the process of moving from some relatively ambiguous problem statement. As you've all noticed in the current problem set, we left a lot of things unspecified. You know, and the email was flying back and forth, and often the answer was, you figure it out. Because that's one of the things we want you to learn. To go from some problem statement to a computational formulation. As a tool to that, you learned a basic set of recipes, bunch of different algorithms. And you learned how to use simulations to deal with problems that did not have nice closed form solutions. Why Python? Well, believe it or not, it's an easy language to learn, compared to other languages. Simple syntax, it's interpretive, which helps with the debugging, you don't have to worry about managing memory as you would in a language like C. It's modern. It supports, in a fairly elegant way, object-oriented programming and classes, and it's increasingly popular. It's used increasing in other subjects at MIT and other universities, increasing in industry, and a large and ever-growing set of libraries. We talked about writing, testing, and debugging programs. And if I had one message I want you to remember about all of this, it's be slow. Slow down, take it one step at a time, take your time and be methodical, systematic, and careful. Understand the problem first. Then think about the overall structure of the solution, and the algorithms independently of how you're going to code it up. So you might say, well, I'm going to use dynamic programming. And that's an independent decision from Python or Java or C++ , or anything else to implement it. And in fact, it's pretty easy to translate a well-organized program from one language to another. Break it into small parts, and we talked about unit testing and the importance of that. Nobody can build anything big in one fell swoop. So, break it into small parts, identify useful abstractions, both functional and data, code and unit test each part, and first worry about functionality. Are you getting the correct answer? And then efficiency. And a piece of that is, learn to use pseudo code to help yourself out.

As I said earlier, be systematic when debugging. Think about the scientific method. It's not just something that we use to torture middle school students. And when you write a program and it doesn't work, ask yourself, why it did what it did? Focus on understanding why the program is doing what it's doing, rather than why it's not doing what you wanted it to? Because as soon as you know why it's doing what it's doing, you'll know how to fix it. But if you skip that step, you'll waste an awful lot of time. Going from problem statement to computation. We said a lot of this, you break the problem into a series of smaller problems. Ideally, reducing it to a problem you already have code to solve, or somebody else's code to solve. My first instinct when I have to solve a problem is, I type, I go to Google, and I type, I think about, oh this is really an x problem, a shortest path problem. I type Python shortest path, and I see what code pops up on my screen. But I can't do that until I've realized, oh, it's really a shortest path, or it's really a knapsack. If I type Python select courses, I won't get anything useful.

Think about what kind of output you'd like to see. I often start thinking about a program by first asking myself, what's the output going to look like? And I'll actually write the output down. And then I'll see if I can't write a program to generate that kind of output. Often you can take a problem formulated as an optimization problem, a lot of thing reduce to finding the minimum or maximum values, satisfying some set of constraints. So when you're given something like, how do I find the directions from here to Providence, think about it as an optimization problem. And also, think about whether you really have to solve it. It's very often the case that an approximate solution is all you really need. And they're a lot faster. So, we think about approximation formally, in the sense of, say, Newton Raphson, we looked at, successive approximation. But more informally, an approximation can be, solve a simpler problem. That you don't really need to solve the problem you thought needed to solve, if you solve something simpler, it will do just fine. So you don't find the best solution, you just find a pretty good solution. Or you simplify the assumptions and say, well, I'm going to find directions, and to make my problem a little simpler, I'm not going to allow myself to take any roads except highways to get from city a to city b. It may not be the shortest, but it's an easier problem to solve because are so many fewer roads.

We talked about algorithms, we talked about big o notation, orders of growth, that's very important. We talked a little bit about amortized analysis, that you might want to, say, sort something first if you were going to do a lot of searching. We looked at a bunch of kinds of algorithms. I've listed them here. I'm, by the way, going to send you a list with all this stuff on it, among other things, so don't feel you need to transcribe it. But a lot of, surprisingly large number of algorithms, to cover in one semester, when you think about it. Exhaustive enumeration, successive approximation, greedy, divide and conquer, decision trees, dynamic programming. Quite a lot. Specific algorithms and specific optimization problems. We spent a lot of time on simulation. It's important, but maybe not as important as all that time, relative to the semester, but it gave me an excuse to talk about some things that I wanted to cover. So it gave me a framework to talk a little bit about probability and statistics. And it's my view, personally, that every MIT student should be made to take such a course. Since they're not, I tried to sneak it in here. But it's all, it's important stuff to know.

It gave me an excuse to build some interesting programs. So, what I hope you noticed, is as I went through these things, I actually tried to develop the programs incrementally, to talk about the abstractions, to talk about how I would test them. And so, just as important as the simulation itself, was the process of building the simulation. And so I just shows that as a mechanism to go through some case studies of building some interesting programs. It let us talk about random choice. Much of the world is, or at least appears to be, stochastic. And therefore, we have to model randomness in programs. And even we don't have to, it can be used to solve problems that are not inherently random, like finding the value of pi. It let us look at the issue of assessing the quality of an answer. We look at things, said, do we believe that that answer is right or not? And building models of, at least parts of, the world. Some pervasive themes that we talked about. The power of abstraction, systematic problem solving, these will be useful even if you never again write a program in your whole life.

What next? Well, many of you, almost all of you, have worked very hard this semester. I hope you feel that you've got a return on your investment. Only you know that. As I said earlier, take a look at the problem sets, and see whether you think you've learned anything. I'd like you to remember after you leave this course, that you've got a skill you can use to solve problems. And when you sit down, and there's some issue that you don't know, just knock out a program to get your answer. I do it all the time, and it's very useful.

If you want to take more courses, there are others you can take. 6.01, the first course for Course 6 majors, you will find easy. Experience says, people who take 6.00 first don't understand what all the fuss is about 6.01. You'll also find it fun and interesting. 6.034, the introduction to AI, is now using Python. You know everything you need to know to take that. 6.005, which is software engineering, you know everything you need to take that. And, for many of you, you can take 6.006, which is a really interesting kind of algorithms course. More advanced algorithms, particularly those you who like math would find 6.006 really fun. So if you want to take more courses, there are courses to take. Thank you all, good luck with the rest of the semester.