Материал готовится,

пожалуйста, возвращайтесь позднее

пожалуйста, возвращайтесь позднее

OPERATOR: The following content is provided under a Creative Commons license. Your 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 at ocw.mit.edu.

PROFESSOR: OK, we're now, kind of on the home stretch, and we're entering the part of the course, that's actually my favorite part of the course. I can't promise it will be your favorite part of the course, but I hope so, at least for many of you. Throughout the term, we've been talking about ways to solve problems using computation. And one of the key lessons that I hope you're beginning to absorb is that we might use a completely different way to solve a problem with the computer than we would have used if we didn't have a computer handy. In particular, we might often use brute force, which you've never use with a pencil and paper, we might not do the mental gyrations required to try and formulate a closed form solution, but just guess a bunch of answers using successive approximation until we got there. A number of different techniques. And that's really what we're going to be doing for the rest of the term now. Except we won't be talking about algorithms per se, or not very much. Instead we'll be talking about more general techniques for using computers to solve problems that are actually hard. They don't just look hard, they in many cases really are hard. The plan of the next set of lectures is, I want to start with a simple example to give you a flavor of some of these issues. In the course of going through that example, I'll illustrate some both thinking tools and some software tools that can be used for tackling the example. Then abstract from the example to try and put in a more general framework. And then, dive back down and use that framework to tackle a series of other interesting problems.

Some things I would like you do think about learning along the way, is moving from an informal problem description to a more formal problem statement. So that's, in part, what we did with the optimization problems, right? We looked at an informal description about optimizing your way through the MIT curriculum, and then could formulate it using sigmas and other bizarre notation to try and formalize what we were really trying to do. And we did that as a preamble to writing any code. First understand the problem, formally, and then move on to the code. And we won't always be totally formal. I often like to use the word rigorous instead of formal. Implying that it won't look like math, per se, but it'll be precise and relatively unambiguous. So that will be one thing that I want you to think about as we go through these problems.

Another thing is inventing computational models. Almost every meaningful program we write is in some sense modeling the actual world. For writing a program to figure out how to keep a bridge from falling down, we're modeling the physics of bridges and wind and things like that. If we're writing a program to try and help us decide what stocks to buy or sell, we're trying to model the stock market in some sense. If we're trying to figure out who's going to win the Super Bowl, we're modeling football teams. But almost every problem, you build a piece of software, and you hope that it has some ability to mimic the actual situation you care about.

PROFESSOR: OK, we're now, kind of on the home stretch, and we're entering the part of the course, that's actually my favorite part of the course. I can't promise it will be your favorite part of the course, but I hope so, at least for many of you. Throughout the term, we've been talking about ways to solve problems using computation. And one of the key lessons that I hope you're beginning to absorb is that we might use a completely different way to solve a problem with the computer than we would have used if we didn't have a computer handy. In particular, we might often use brute force, which you've never use with a pencil and paper, we might not do the mental gyrations required to try and formulate a closed form solution, but just guess a bunch of answers using successive approximation until we got there. A number of different techniques. And that's really what we're going to be doing for the rest of the term now. Except we won't be talking about algorithms per se, or not very much. Instead we'll be talking about more general techniques for using computers to solve problems that are actually hard. They don't just look hard, they in many cases really are hard. The plan of the next set of lectures is, I want to start with a simple example to give you a flavor of some of these issues. In the course of going through that example, I'll illustrate some both thinking tools and some software tools that can be used for tackling the example. Then abstract from the example to try and put in a more general framework. And then, dive back down and use that framework to tackle a series of other interesting problems.

Some things I would like you do think about learning along the way, is moving from an informal problem description to a more formal problem statement. So that's, in part, what we did with the optimization problems, right? We looked at an informal description about optimizing your way through the MIT curriculum, and then could formulate it using sigmas and other bizarre notation to try and formalize what we were really trying to do. And we did that as a preamble to writing any code. First understand the problem, formally, and then move on to the code. And we won't always be totally formal. I often like to use the word rigorous instead of formal. Implying that it won't look like math, per se, but it'll be precise and relatively unambiguous. So that will be one thing that I want you to think about as we go through these problems.

Another thing is inventing computational models. Almost every meaningful program we write is in some sense modeling the actual world. For writing a program to figure out how to keep a bridge from falling down, we're modeling the physics of bridges and wind and things like that. If we're writing a program to try and help us decide what stocks to buy or sell, we're trying to model the stock market in some sense. If we're trying to figure out who's going to win the Super Bowl, we're modeling football teams. But almost every problem, you build a piece of software, and you hope that it has some ability to mimic the actual situation you care about.

Загрузка...

Выбрать следующее задание

Ты добавил

Выбрать следующее задание

Ты добавил