Knapsack pro code#
I've often made the mistake of believing the comments somebody wrote in your code about what some function does. When you're debugging somebody else's code, debug the code, not the comments. Well, does it do what you think it does? Does append do what you think it does? Go back and say, alright, I've obviously, some assumption is not right. You thought you knew what the built-in function sort did, method sort did. And I'll sit there staring at the output, staring at the code, not realizing that that output was not produced by that code. I then click on the shell, rather than hitting F5, try and run it and say, it's not doing what I thought I should do. I sit there in idle, and I edit some code. This is a mistake I make all the time in Python. A huge one is, are you actually running the code you're looking at in your editor. Think about reconsidering your assumptions. Know what you've already tried, don't waste your time trying it again. This gets back to my main theme of Tuesday, which is be systematic. That leads you to end up doing the same thing over and over again. People will look at things and they'll come in and that'll talk to a TA, and the TA will say, did you try this? And the person will say, I don't know. And if your program doesn't work, that should be your first guess.Ĭouple of other hints. And so when I'm looking for a bug, I always say, oh, have you done this dumb thing you always do. Every experienced programmer over time develops a personal model of the mistakes they make. You call a function and it returns a value, but maybe it, on purpose or on accident, modifies one of the actual parameters. Think through all of that.Īnd again, a related problem that people run into is side-effects. So when you copy, what are you getting? When you copy a dictionary, for example. Or a list of anything that could be mutable. When you decide to make a copy of something like a list, you have to think hard about are you only copying the top level of the list, but if it's, say, a list that contains a list, are you also getting a new copy of everything it contains? It doesn't matter if it's a list of integers or a list of strings or a list of tuples, but it matters a lot if it's a list of lists. Frequently that introduces bugs into the program.Ī particular instance of that is deep versus shallow copy. And by that I mean two different ways to get to the same value, the same object. Where we're going to ask you to just look at some code, that there's some issues there with the fact that you alias things, maybe on purpose, maybe on accident. And you'll see that, by the way, on the problem set that we're posting tomorrow. Particularly when you use double equals, are you asking whether you've got the same object or the same value? They mean very different things, as we have seen. So look carefully at when variables are being initialized. Or conversely, inside the loop when it should be outside the loop. So it's initialized outside the loop when it should be initialized inside the loop.
Go through a loop, and then forget to reinitialize it when it needs to be reinitialized again. A very common bug is to initialize a variable. If you've made a mistake with upper and lower case.
And if you've typed in l when you should've typed a 1, or a 1 when you should've typed an l, you're likely to miss it. The problem is, when you read code you see what you expect to see. Did you spell all the identifiers the way you think you did. These are just dumb little things to look for. And this just helps me not get confused about what order to do things in. And I often end up using the same names for the actuals and the formals. You may have noticed that when Professor Grimson and I used examples in class, we were pretty careful how we name our parameters. You might have a function that takes to floats and you just passed them in the wrong order. There are some simple things that you should always look at when you're looking for bugs. Because if a bug were there, you'd have already found it. First of all, keep in mind that the bug is probably not where you think it is. PROFESSOR: I want to take a few minutes at the start of today's lecture to wrap up a few more things about debugging. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. The following content is provided under a Creative Commons license.
Knapsack pro pdf#
Download this transcript - PDF (English - US).
0 kommentar(er)
