1
00:00:00 --> 00:00:00



2
00:00:00 --> 00:00:02
The following content is
provided under a creative

3
00:00:02 --> 00:00:03
commons license.


4
00:00:03 --> 00:00:06
Your support will help MIT
OpenCourseWare continue to

5
00:00:06 --> 00:00:10
offer high quality educational
resources for free.

6
00:00:10 --> 00:00:13
To make a donation or view
additional materials from

7
00:00:13 --> 00:00:16
hundreds of MIT courses,
visit MIT OpenCourseWare

8
00:00:16 --> 00:00:21
at ocw.mit.edu.


9
00:00:21 --> 00:00:24
PROFESSOR: One of the things
that you should probably have

10
00:00:24 --> 00:00:29
noticed is as we're moving in
the terms, the problem sets are

11
00:00:29 --> 00:00:36
getting less well defined. line
And I've seen a lot of email

12
00:00:36 --> 00:00:40
traffic of the nature of what
should we do with this, what

13
00:00:40 --> 00:00:41
should we do with that?


14
00:00:41 --> 00:00:44
For example, suppose
the computer player

15
00:00:44 --> 00:00:45
runs out of time.


16
00:00:45 --> 00:00:49
Or the person runs out of
time playing the game.

17
00:00:49 --> 00:00:51
Should it stop right away?


18
00:00:51 --> 00:00:55
Should it just give
them zero score?

19
00:00:55 --> 00:00:57
That's left out of
the problem set.

20
00:00:57 --> 00:01:00
In part because one of the
things were trying to

21
00:01:00 --> 00:01:06
accomplish is to have you folks
start noticing ambiguities

22
00:01:06 --> 00:01:07
in problem statements.


23
00:01:07 --> 00:01:12
Because that's life
in computing.

24
00:01:12 --> 00:01:14
And so this is not like
a math problem set or

25
00:01:14 --> 00:01:17
a physics problem set.


26
00:01:17 --> 00:01:19
Or, like a high school physics
lab, where we all know what the

27
00:01:19 --> 00:01:25
answer should be, and you could
fake your lab results anyway.

28
00:01:25 --> 00:01:27
These are things where you're
going to have to kind

29
00:01:27 --> 00:01:29
of figure it out.


30
00:01:29 --> 00:01:32
And for most of these things,
all we ask is that you do

31
00:01:32 --> 00:01:36
something reasonable, and
that you describe what

32
00:01:36 --> 00:01:38
it is you're doing.


33
00:01:38 --> 00:01:41
So I don't much care, for
example, whether you give the

34
00:01:41 --> 00:01:44
human players zero points for
playing after the

35
00:01:44 --> 00:01:46
time runs out.


36
00:01:46 --> 00:01:50
Or you say you're done
when the time runs out.

37
00:01:50 --> 00:01:54
Any of that -- thank you,
Sheila -- is ok with me.

38
00:01:54 --> 00:01:57
Whatever.


39
00:01:57 --> 00:02:00
What I don't want your
program to do is crash

40
00:02:00 --> 00:02:01
when that happens.


41
00:02:01 --> 00:02:02
Or run forever.


42
00:02:02 --> 00:02:05
Figure out something
reasonable and do it.

43
00:02:05 --> 00:02:08
And again, we'll see this as an
increasing trend as we work

44
00:02:08 --> 00:02:11
our way through the term.


45
00:02:11 --> 00:02:14
The exception will be the
next problem set, which

46
00:02:14 --> 00:02:17
will come out Friday.


47
00:02:17 --> 00:02:20
Because that's not a
programming problem.

48
00:02:20 --> 00:02:23
It's a problem, as you'll see,
designed to give you some

49
00:02:23 --> 00:02:28
practice at dealing with some
of the, dare I say, more

50
00:02:28 --> 00:02:31
theoretical concepts
we've covered in class.

51
00:02:31 --> 00:02:34
Like algorithmic complexity.


52
00:02:34 --> 00:02:39
That are not readily dealt
with in a prograing problem.

53
00:02:39 --> 00:02:43
It also deals with issues
of some of the subtleties

54
00:02:43 --> 00:02:46
of things like aliasing.


55
00:02:46 --> 00:02:48
So there's no programming.


56
00:02:48 --> 00:02:52
And in fact, we're not even
going to ask you to hand it in.

57
00:02:52 --> 00:02:55
It's a problem set where we've
worked pretty hard to write

58
00:02:55 --> 00:02:58
some problems that we think
will provide you with a

59
00:02:58 --> 00:03:00
good learning experience.


60
00:03:00 --> 00:03:03
And you should just do it
to learn the material.

61
00:03:03 --> 00:03:07
We'll help you, if you need --
to see the TAs because you

62
00:03:07 --> 00:03:10
can't do them, by all means
make sure you get some help.

63
00:03:10 --> 00:03:13
So I'm not suggesting that
it's an optional problem

64
00:03:13 --> 00:03:15
set that you shouldn't do.


65
00:03:15 --> 00:03:19
Because you will come to
regret it if you don't do it.

66
00:03:19 --> 00:03:20
But we're not going
to grade it.

67
00:03:20 --> 00:03:23
And since we're not going to
grade it, it seems kind of

68
00:03:23 --> 00:03:25
unfair to ask you
to hand it in.

69
00:03:25 --> 00:03:28
So it's a short problem set,
but make sure you know

70
00:03:28 --> 00:03:31
how to do those problems.


71
00:03:31 --> 00:03:33
OK.


72
00:03:33 --> 00:03:36
Today, for the rest of the
lecture, we're going to take

73
00:03:36 --> 00:03:41
a break from the topic of
algorithms, and computation,

74
00:03:41 --> 00:03:43
and things of the sort.


75
00:03:43 --> 00:03:47
And do something
pretty pragmatic.

76
00:03:47 --> 00:03:52
And we're going to talk
briefly about testing.

77
00:03:52 --> 00:04:01
And at considerable
length about debugging.

78
00:04:01 --> 00:04:04
I have tried to give this
lecture at the beginning of the

79
00:04:04 --> 00:04:06
term, at the end of the term.


80
00:04:06 --> 00:04:08
Now I'm trying it kind of
a third of the way, or

81
00:04:08 --> 00:04:10
middle of the term.


82
00:04:10 --> 00:04:13
I never know the right
time to give it.

83
00:04:13 --> 00:04:17
These are sort of pragmatic
hints that are useful.

84
00:04:17 --> 00:04:20
I suspect all of you have
found that debugging can

85
00:04:20 --> 00:04:24
be a frustrating activity.


86
00:04:24 --> 00:04:27
My hope is that at this point,
you've experienced enough

87
00:04:27 --> 00:04:30
frustration that the kind of
pragmatic hints I'm going to

88
00:04:30 --> 00:04:35
talk about will not be, "yeah
sure, of course." But they'll

89
00:04:35 --> 00:04:37
actually make sense to you.


90
00:04:37 --> 00:04:40
We'll see.


91
00:04:40 --> 00:04:41
OK.


92
00:04:41 --> 00:04:45
In a perfect world, the
weather would always be

93
00:04:45 --> 00:04:48
like it's been this week.


94
00:04:48 --> 00:04:54
The M in MIT would stand for
Maui, instead of Massachusetts.

95
00:04:54 --> 00:04:57
Quantum physics would be
easier to understand.

96
00:04:57 --> 00:05:03
All the supreme court justices
would share our social values.

97
00:05:03 --> 00:05:06
And most importantly, our
programs would work the

98
00:05:06 --> 00:05:09
first time we typed them.


99
00:05:09 --> 00:05:12
By now you may have noticed
that we do not live

100
00:05:12 --> 00:05:14
in an ideal world.


101
00:05:14 --> 00:05:20
At least one of those things
I mentioned is not true.

102
00:05:20 --> 00:05:22
I'm only going to
address the last one.

103
00:05:22 --> 00:05:24
Why our programs don't work.


104
00:05:24 --> 00:05:27
And I will leave the supreme
court up to the rest of you.

105
00:05:27 --> 00:05:29
There is an election coming up.


106
00:05:29 --> 00:05:33
Alright, First a
few definitions.

107
00:05:33 --> 00:05:42
Things I want to make sure we
all understand what they mean.

108
00:05:42 --> 00:05:46
Validation is a process.


109
00:05:46 --> 00:05:52
And I want to emphasize
the word process.

110
00:05:52 --> 00:06:09
Designed to uncover problems
and increase confidence that

111
00:06:09 --> 00:06:16
our program does what we
think it's intended to do.

112
00:06:16 --> 00:06:23
I want to emphasize that it
will increase our confidence,

113
00:06:23 --> 00:06:29
but we can never really be
sure we've got it nailed.

114
00:06:29 --> 00:06:33
And so it's a process
that goes on and on.

115
00:06:33 --> 00:06:37
And I also want to emphasize
that a big piece of it

116
00:06:37 --> 00:06:40
is to uncover problems.


117
00:06:40 --> 00:06:43
So we need to have a method
not designed to give us

118
00:06:43 --> 00:06:45
unwarranted confidence.


119
00:06:45 --> 00:06:50
But in fact warranted
confidence in our programs.

120
00:06:50 --> 00:06:55
It's typically a
combination of two things.

121
00:06:55 --> 00:07:05
Testing and reasoning.


122
00:07:05 --> 00:07:09
Testing, we run our program
on some set of inputs.

123
00:07:09 --> 00:07:13
And check the answers, and say
yeah, that's what we expected.

124
00:07:13 --> 00:07:16
But it also involves reasoning.


125
00:07:16 --> 00:07:20
About why that's an appropriate
set of inputs to test it on it.

126
00:07:20 --> 00:07:23
Have we tested it
on enough inputs?

127
00:07:23 --> 00:07:26
Maybe just reading the code and
studying it and convincing

128
00:07:26 --> 00:07:29
ourselves that works.


129
00:07:29 --> 00:07:37
So we do both of those as part
of the validation process.

130
00:07:37 --> 00:07:42
And we'll talk about all
of this as we go along.

131
00:07:42 --> 00:07:58
Debugging is a
different process.

132
00:07:58 --> 00:08:11
And that's basically the
process of ascertaining why

133
00:08:11 --> 00:08:18
the program is not working.


134
00:08:18 --> 00:08:24
Why it's failing
to work properly.

135
00:08:24 --> 00:08:29
So validation says whoops,
it's not working.

136
00:08:29 --> 00:08:35
And now we try and
figure out why not.

137
00:08:35 --> 00:08:37
And then of course, once we
figure out why not, we try and

138
00:08:37 --> 00:08:43
fix it. but today I'm going to
emphasize not how do you fix

139
00:08:43 --> 00:08:45
it, but how do you find
out what's wrong.

140
00:08:45 --> 00:08:48
Usually when you know why it's
not working, it's obvious what

141
00:08:48 --> 00:08:51
you have to do to make it work.


142
00:08:51 --> 00:08:56
There are two aspects of it.


143
00:08:56 --> 00:09:02
Thus far, the problem sets have
mostly focused on function.

144
00:09:02 --> 00:09:06
Does it exhibit the
functional behavior?

145
00:09:06 --> 00:09:12
Does it give you the answer
that you expected it to give?

146
00:09:12 --> 00:09:17
Often, in practical problems,
you'll spend just as much time

147
00:09:17 --> 00:09:21
doing performance debugging.


148
00:09:21 --> 00:09:23
Why is it slow?


149
00:09:23 --> 00:09:28
Why is it not getting the
answer as fast as I want it to?

150
00:09:28 --> 00:09:31
And in fact, in a lot of
industry -- for example, if

151
00:09:31 --> 00:09:36
you're working on building a
computer game, you'll discover

152
00:09:36 --> 00:09:39
that in fact the people working
the game will spend more time

153
00:09:39 --> 00:09:42
on performance debugging than
on getting it to do

154
00:09:42 --> 00:09:43
the right thing.


155
00:09:43 --> 00:09:45
Trying to make it
do it fast enough.

156
00:09:45 --> 00:09:51
Or get to run on the
right processor.

157
00:09:51 --> 00:10:02
Some other terms we've talked
about is defensive programming.

158
00:10:02 --> 00:10:05
And we've been weaving
that pretty consistently

159
00:10:05 --> 00:10:08
throughout the term.


160
00:10:08 --> 00:10:13
And that's basically writing
your programs in such a way

161
00:10:13 --> 00:10:31
that it will facilitate both
validation and debugging.

162
00:10:31 --> 00:10:34
And we've talked about a
lot of ways we do that.

163
00:10:34 --> 00:10:39
One of the most important
things we do is we use assert

164
00:10:39 --> 00:10:44
statements so that we
catch problems early.

165
00:10:44 --> 00:10:46
We write specifications
of our functions.

166
00:10:46 --> 00:10:48
We modularize things.


167
00:10:48 --> 00:10:49
And we'll come back to this.


168
00:10:49 --> 00:10:53
As every time we introduce a
new programming concept, we'll

169
00:10:53 --> 00:10:57
relate it back, as we have been
doing consistently, to

170
00:10:57 --> 00:11:00
defensive programming.


171
00:11:00 --> 00:11:03
So one of the things I want
you to notice here is that

172
00:11:03 --> 00:11:08
testing and debugging
are not the same thing.

173
00:11:08 --> 00:11:13
When we test, we compare
an input output pair

174
00:11:13 --> 00:11:16
to a specification.


175
00:11:16 --> 00:11:44
When we debug, we study the
events that led to an error.

176
00:11:44 --> 00:11:47
I'll return to testing
later in the term.

177
00:11:47 --> 00:11:50
But I do want to make a
couple of quick remarks

178
00:11:50 --> 00:11:55
with very broad strokes.


179
00:11:55 --> 00:11:58
There are basically two
classes of testing.

180
00:11:58 --> 00:12:05
There's unit testing, where we
validate each piece of the

181
00:12:05 --> 00:12:08
program independently.


182
00:12:08 --> 00:12:14
Thus far, for us it's been
testing individual functions.

183
00:12:14 --> 00:12:28
Later in the term, we'll talk
about unit testing of classes.

184
00:12:28 --> 00:12:33
The other kind of testing
is integration testing.

185
00:12:33 --> 00:12:37
Where we put our whole program
together, and we say does

186
00:12:37 --> 00:12:46
the whole thing work?


187
00:12:46 --> 00:12:52
People tend to want to rush
in and do this right away.

188
00:12:52 --> 00:12:54
That's usually a big mistake.


189
00:12:54 --> 00:12:59
Because usually
it doesn't work.

190
00:12:59 --> 00:13:05
And so one of the things that
I think is very important is

191
00:13:05 --> 00:13:08
to always begin by
testing each unit.

192
00:13:08 --> 00:13:12
So before I try and run my
program, I test each part

193
00:13:12 --> 00:13:16
of it independently.


194
00:13:16 --> 00:13:19
And that's because it's
easier to test small

195
00:13:19 --> 00:13:21
things than big things.


196
00:13:21 --> 00:13:25
And it's easier to debug small
things than big things.

197
00:13:25 --> 00:13:27
Eventually, it's a big
program, I run it.

198
00:13:27 --> 00:13:31
It never works the first
time if it's a big program.

199
00:13:31 --> 00:13:34
And I end up going back and
doing unit testing anyway,

200
00:13:34 --> 00:13:36
to try and figure out
why it doesn't work.

201
00:13:36 --> 00:13:39
So over the years, I've just
convinced myself I might as

202
00:13:39 --> 00:13:44
well start where I'm
going to end up.

203
00:13:44 --> 00:13:47
What's so hard about testing?


204
00:13:47 --> 00:13:56
Why is testing
always a challenge?

205
00:13:56 --> 00:13:59
Well, you could just try it
and see if it works, right?

206
00:13:59 --> 00:14:02
That's what testing
is all about.

207
00:14:02 --> 00:14:07
So we could look at
something small.

208
00:14:07 --> 00:14:13
Just write a program to
find the max of x and y.

209
00:14:13 --> 00:14:24
Where x and y are floats.


210
00:14:24 --> 00:14:28
However many quotes I need.


211
00:14:28 --> 00:14:31
Well, just see if it works.


212
00:14:31 --> 00:14:34
Let's test it in all possible
combinations of x and y and see

213
00:14:34 --> 00:14:37
if we get the right answer.


214
00:14:37 --> 00:14:40
Well, as Carl Sagan would have
said, there are billions and

215
00:14:40 --> 00:14:43
billions of tests we
would have to do.

216
00:14:43 --> 00:14:47
Or maybe it's billions and
billions and billions.

217
00:14:47 --> 00:14:49
Pretty impractical.


218
00:14:49 --> 00:14:53
And it's hard to imagine a
simpler program than this.

219
00:14:53 --> 00:14:57
So we very quickly realize that
exhaustive testing is just

220
00:14:57 --> 00:15:01
never feasible for an
interesting program.

221
00:15:01 --> 00:15:05
So as we look at testing, what
we have to find is what's

222
00:15:05 --> 00:15:12
called a test suite.


223
00:15:12 --> 00:15:21
A test suite is small enough
so that we can test it in a

224
00:15:21 --> 00:15:27
reasonable amount of time.


225
00:15:27 --> 00:15:47
But also large enough to
give us some confidence.

226
00:15:47 --> 00:15:51
Later in the term, we'll spend
part of a lecture talking

227
00:15:51 --> 00:15:54
about, how do we find
such a test suite?

228
00:15:54 --> 00:15:58
A test suite that will make
us feel good about things.

229
00:15:58 --> 00:16:02
For now, I just want you to
be aware that you're always

230
00:16:02 --> 00:16:06
doing this balancing act.


231
00:16:06 --> 00:16:09
So let's assume we've
run our test suite.

232
00:16:09 --> 00:16:15
And, sad to say, at least one
of our tests produced an output

233
00:16:15 --> 00:16:19
that we were unhappy with.


234
00:16:19 --> 00:16:21
It took it too long to
generate the output.

235
00:16:21 --> 00:16:26
Or more likely, it was
just the wrong output.

236
00:16:26 --> 00:16:29
That gets us to debugging.


237
00:16:29 --> 00:16:36
So a word about debugging.


238
00:16:36 --> 00:16:38
Where did the name come from?


239
00:16:38 --> 00:16:42
Well here's a fun
story, at least.

240
00:16:42 --> 00:16:45
This was one of the very
first recorded bugs in the

241
00:16:45 --> 00:16:48
history of computation.


242
00:16:48 --> 00:16:54
Recorded September 9th, 1947,
in case you're interested.

243
00:16:54 --> 00:16:58
This was the lab book of
Grace Murray Hopper.

244
00:16:58 --> 00:17:00
Later Admiral Grace
Murray Hopper.

245
00:17:00 --> 00:17:04
The first female admiral
in the U.S. navy.

246
00:17:04 --> 00:17:10
Who was also one of the
word's first programmers.

247
00:17:10 --> 00:17:14
So she was trying to write this
program, and it didn't work.

248
00:17:14 --> 00:17:16
It was a complicated program.


249
00:17:16 --> 00:17:18
It was computing the arctan.


250
00:17:18 --> 00:17:20
So you can imagine, right?


251
00:17:20 --> 00:17:23
You had a whole team of
people trying to figure

252
00:17:23 --> 00:17:25
out how to do arctans.


253
00:17:25 --> 00:17:27
Times were different
in those days.

254
00:17:27 --> 00:17:30
And they tried to run it,
and it ran a long time.

255
00:17:30 --> 00:17:32
Then it basically stopped.


256
00:17:32 --> 00:17:35
Then they started
the cosine tape.

257
00:17:35 --> 00:17:39
That didn't work.


258
00:17:39 --> 00:17:41
Well they couldn't figure
out what was wrong.

259
00:17:41 --> 00:17:45
And they spent a long time
trying to debug the program.

260
00:17:45 --> 00:17:47
They didn't apparently
call it debugging.

261
00:17:47 --> 00:17:51
And then they found
the problem.

262
00:17:51 --> 00:17:56
In relay number 70, a
moth had been trapped.

263
00:17:56 --> 00:17:59
And the relay had closed
on the poor creature,

264
00:17:59 --> 00:18:02
crushing it to death.


265
00:18:02 --> 00:18:06
The defense department didn't
care about the loss of a moth.

266
00:18:06 --> 00:18:08
But they did care about
the fact that the

267
00:18:08 --> 00:18:09
relay was now stuck.


268
00:18:09 --> 00:18:11
It didn't work.


269
00:18:11 --> 00:18:14
They removed the moth,
and the program worked.

270
00:18:14 --> 00:18:18
And you'll see at the bottom,
it says the first actual

271
00:18:18 --> 00:18:21
case of a bug being found.


272
00:18:21 --> 00:18:23
And they were very
proud of themselves.

273
00:18:23 --> 00:18:25
Now it's a wonderful
story, and it is true.

274
00:18:25 --> 00:18:28
After all, Grace
wouldn't have lied.

275
00:18:28 --> 00:18:31
But it's not the first use of
the term "bug." And as you'll

276
00:18:31 --> 00:18:34
see by your handout, I've
attempted tend to trace it.

277
00:18:34 --> 00:18:38
And the first one I
could find was in 1896.

278
00:18:38 --> 00:18:44
In a handbook on electricity.


279
00:18:44 --> 00:18:44
Alright.


280
00:18:44 --> 00:18:48
Now debugging is
a learned skill.

281
00:18:48 --> 00:18:51
Nobody does it well
instinctively.

282
00:18:51 --> 00:18:55
And a large part of being a
good programmer, or learning

283
00:18:55 --> 00:18:59
to be a good programmer,
is learning how to debug.

284
00:18:59 --> 00:19:02
And it's one of these
things where it's harder.

285
00:19:02 --> 00:19:05
It's slow, slow, and you
suddenly have an epiphany.

286
00:19:05 --> 00:19:08
And you now get the hang of it.


287
00:19:08 --> 00:19:09
And I'm hoping that
today's lecture will

288
00:19:09 --> 00:19:13
help you learn faster.


289
00:19:13 --> 00:19:17
The nice thing, is once you
learn to debug programs, you

290
00:19:17 --> 00:19:20
will discover it's a
transferable skill.

291
00:19:20 --> 00:19:25
And you can use it to debug
other complex systems.

292
00:19:25 --> 00:19:28
So for example, a
laboratory experience.

293
00:19:28 --> 00:19:31
Why isn't this
experiment working?

294
00:19:31 --> 00:19:35
There's a lecture I've given
several times at hospitals, to

295
00:19:35 --> 00:19:41
doctors, on doing diagnosis
of complex multi illnesses.

296
00:19:41 --> 00:19:44
And I go through it, and
almost the same kind of stuff

297
00:19:44 --> 00:19:46
I'm going to talk to you
about, about debugging.

298
00:19:46 --> 00:19:50
Explaining that it's really
a process of engineering.

299
00:19:50 --> 00:19:54
So I want to start by
disabusing you of a couple

300
00:19:54 --> 00:19:56
of myths about bugs.


301
00:19:56 --> 00:20:07
So myth one is that bugs
crawl into programs.

302
00:20:07 --> 00:20:12
Well it may have been true in
the old days, when bugs flew

303
00:20:12 --> 00:20:15
or crawled into relays.


304
00:20:15 --> 00:20:17
It's not true now.


305
00:20:17 --> 00:20:20
If there is a bug in the
program, it's there

306
00:20:20 --> 00:20:22
for only one reason.


307
00:20:22 --> 00:20:27
You put it there. i.e.
you made a mistake.

308
00:20:27 --> 00:20:29
So we like to call them
bugs, because it doesn't

309
00:20:29 --> 00:20:31
make us feel stupid.


310
00:20:31 --> 00:20:37
But in fact, a better
word would be mistake.

311
00:20:37 --> 00:20:45
Another myth is that
the bugs breed.

312
00:20:45 --> 00:20:47
They do not.


313
00:20:47 --> 00:20:50
If there are multiple bugs in
the program, it's because

314
00:20:50 --> 00:20:53
you made multiple mistakes.


315
00:20:53 --> 00:20:56
Not because you made one
or two and they mated and

316
00:20:56 --> 00:20:59
produced many more bugs.


317
00:20:59 --> 00:21:00
It doesn't work that way.


318
00:21:00 --> 00:21:02
That's a good thing.


319
00:21:02 --> 00:21:05
Typically, even though
they don't breed,

320
00:21:05 --> 00:21:09
there are many bugs.


321
00:21:09 --> 00:21:19
And keep in mind that the
goal of debugging is not

322
00:21:19 --> 00:21:29
to eliminate one bug.


323
00:21:29 --> 00:21:39
The goal is to move towards
a bug free program.

324
00:21:39 --> 00:21:42
I emphasize this because it
often leads to a different

325
00:21:42 --> 00:21:44
debugging strategy.


326
00:21:44 --> 00:21:47
People can get hung up on
sort of hunting these things

327
00:21:47 --> 00:21:49
down, and stamping them
out, one at a time.

328
00:21:49 --> 00:21:52
And it's a little bit like
playing Whack-a-Mole.

329
00:21:52 --> 00:21:52
Right?


330
00:21:52 --> 00:21:55
They keep jumping up at you.


331
00:21:55 --> 00:22:00
So the goal is to figure out
a way to stamp them all out.

332
00:22:00 --> 00:22:04
Now, should you be proud
when you find a bug?

333
00:22:04 --> 00:22:07
I've had graduate students
come to me and say I found

334
00:22:07 --> 00:22:08
a bug in my program.


335
00:22:08 --> 00:22:11
And they're really
proud of themselves.

336
00:22:11 --> 00:22:14
And depending on the mood I'm
in, I either congratulate

337
00:22:14 --> 00:22:18
them, or I say ah,
you screwed up, huh?

338
00:22:18 --> 00:22:23
Then you had to fix it.


339
00:22:23 --> 00:22:28
If you find a bug, it probably
means there are more of them.

340
00:22:28 --> 00:22:31
So you ought to be a
little bit careful.

341
00:22:31 --> 00:22:34
The story I've heard told is
you're at somebody's house for

342
00:22:34 --> 00:22:36
dinner, and you're sitting
at the dining room table,

343
00:22:36 --> 00:22:39
then you hear a [BANG].


344
00:22:39 --> 00:22:42
And then your hostess walks in
with the turkey in a tray, and

345
00:22:42 --> 00:22:49
says, "I killed the last
cockroach." Well it wouldn't

346
00:22:49 --> 00:22:53
increase my appetite, at least.


347
00:22:53 --> 00:22:57
So be worried about it.


348
00:22:57 --> 00:23:00
For at least four decades,
people have been building

349
00:23:00 --> 00:23:02
tools called debuggers.


350
00:23:02 --> 00:23:04
Things to help you find bugs.


351
00:23:04 --> 00:23:07
And there are some
built into Idol.

352
00:23:07 --> 00:23:12
My personal view is most of
them are not worth the trouble.

353
00:23:12 --> 00:23:17
The two best debugging tools
are the same now that they

354
00:23:17 --> 00:23:20
have almost always been.


355
00:23:20 --> 00:23:41
And they are the print
statement, and reading.

356
00:23:41 --> 00:23:47
There is no substitute
for reading your code.

357
00:23:47 --> 00:23:50
Getting good at this is
probably the single most

358
00:23:50 --> 00:23:53
important skill for debugging.


359
00:23:53 --> 00:23:57
And people are often
resistant to that.

360
00:23:57 --> 00:24:00
They'd rather single step
it through using Idol or

361
00:24:00 --> 00:24:06
something, than just read it
and try and figure things out.

362
00:24:06 --> 00:24:09
The most important thing to
remember when you're doing all

363
00:24:09 --> 00:24:17
of this is to be systematic.


364
00:24:17 --> 00:24:21
That's what distinguishes good
debuggers from bad debuggers.

365
00:24:21 --> 00:24:26
Good debuggers have evolved
a way of systematically

366
00:24:26 --> 00:24:29
hunting for the bugs.


367
00:24:29 --> 00:24:33
And what they're doing as they
hunt, is they're reducing

368
00:24:33 --> 00:24:42
the search space.


369
00:24:42 --> 00:24:52
And they do that to localize
the source of the problem.

370
00:24:52 --> 00:24:55
We've already spent a fair
amount of time this semester

371
00:24:55 --> 00:24:58
talking about searches.


372
00:24:58 --> 00:25:00
Algorithms for searching.


373
00:25:00 --> 00:25:07
Debugging is simply
a search process.

374
00:25:07 --> 00:25:09
When you are searching a list
to see whether it has an

375
00:25:09 --> 00:25:14
element, you don't randomly
probe the list, hoping to find

376
00:25:14 --> 00:25:15
whether or not it's there.


377
00:25:15 --> 00:25:18
You find some way of
systematically going

378
00:25:18 --> 00:25:20
through the list.


379
00:25:20 --> 00:25:24
Yet, I often see people, when
they're debugging, proceeding

380
00:25:24 --> 00:25:28
at what, to me, looks almost
like a random fashion of

381
00:25:28 --> 00:25:32
looking for the bug.


382
00:25:32 --> 00:25:35
That is a problem that
may not terminate.

383
00:25:35 --> 00:25:39
So you need to be careful.


384
00:25:39 --> 00:25:43
So let's talk about how we
go about being systematic,

385
00:25:43 --> 00:25:57
as we do this.


386
00:25:57 --> 00:26:00
So debugging starts when
we find out that there

387
00:26:00 --> 00:26:06
exists a problem.


388
00:26:06 --> 00:26:14
So the first thing to do is to
study the program text, and

389
00:26:14 --> 00:26:32
ask how could it have
produced this result?

390
00:26:32 --> 00:26:38
So there's something subtle
about the way I've worded this.

391
00:26:38 --> 00:26:41
I didn't ask, why didn't
it produce the result I

392
00:26:41 --> 00:26:43
wanted it to produce?


393
00:26:43 --> 00:26:47
Which is sort of the question
we'd immediately like to ask.

394
00:26:47 --> 00:26:53
Instead, I asked why did it
produce the result it did.

395
00:26:53 --> 00:26:58
So I'm not asking
myself what's wrong?

396
00:26:58 --> 00:26:59
Or how could I make it right?


397
00:26:59 --> 00:27:01
I'm asking how could
have done this?

398
00:27:01 --> 00:27:04
I didn't expect it to do this.


399
00:27:04 --> 00:27:07
If you understand why
it did what it did,

400
00:27:07 --> 00:27:10
you're half way there.


401
00:27:10 --> 00:27:22
The next big question you
ask, is it part of a family?

402
00:27:22 --> 00:27:25
This gets back to the question
of trying to get the

403
00:27:25 --> 00:27:28
program to be bug free.


404
00:27:28 --> 00:27:33
So for example, oh, it did
this because it was aliasing,

405
00:27:33 --> 00:27:35
where I hadn't expected it.


406
00:27:35 --> 00:27:39
Or some side effect of
some mutation with lists.

407
00:27:39 --> 00:27:42
And then I say, oh you
know I've used lists

408
00:27:42 --> 00:27:44
all over this program.


409
00:27:44 --> 00:27:46
I'll bet this isn't the
only place where I've

410
00:27:46 --> 00:27:50
made this mistake.


411
00:27:50 --> 00:27:53
So you say well, rather than
rushing off and fixing this

412
00:27:53 --> 00:27:57
one bug, let me pull back and
ask, is this a systematic

413
00:27:57 --> 00:28:01
mistake that I've made
throughout the program?

414
00:28:01 --> 00:28:03
And if so, let's fix them
all at once, rather

415
00:28:03 --> 00:28:06
than one at a time.


416
00:28:06 --> 00:28:11
And that gets me to
the final question.

417
00:28:11 --> 00:28:21
How to fix it.


418
00:28:21 --> 00:28:28
When I think about debugging, I
think about it in terms of what

419
00:28:28 --> 00:28:35
you learned in high school
as the scientific method.

420
00:28:35 --> 00:28:36
Actually, I should
ask the question.

421
00:28:36 --> 00:28:38
Maybe I'm dating myself.


422
00:28:38 --> 00:28:40
Do they still teach
the scientific method

423
00:28:40 --> 00:28:41
in high school?


424
00:28:41 --> 00:28:43
Yes, alright good.


425
00:28:43 --> 00:28:47
All is not lost with the
American educational system.

426
00:28:47 --> 00:28:51
So what does the scientific
method tell us to do?

427
00:28:51 --> 00:29:05
Well it says you first start by
studying the available data.

428
00:29:05 --> 00:29:12
In this case, the available
data are the test results.

429
00:29:12 --> 00:29:17
And by the way, I mean
all the test results.

430
00:29:17 --> 00:29:20
Not just the one where it
didn't work, but also

431
00:29:20 --> 00:29:23
the ones where it did.


432
00:29:23 --> 00:29:25
Because maybe the program
worked on some inputs

433
00:29:25 --> 00:29:27
and not on others.


434
00:29:27 --> 00:29:30
And maybe by understanding why
it worked on a and not on b,

435
00:29:30 --> 00:29:33
you'll get a lot of insight
that you won't if you

436
00:29:33 --> 00:29:35
just focus on the bug.


437
00:29:35 --> 00:29:37
You'll also feel a little bit
better knowing your program

438
00:29:37 --> 00:29:42
works on at least something.


439
00:29:42 --> 00:29:44
The other big piece of
available data we have is, of

440
00:29:44 --> 00:29:49
course, the program text.


441
00:29:49 --> 00:29:52
As you the study the program
text, keep in mind that

442
00:29:52 --> 00:29:55
you don't understand it.


443
00:29:55 --> 00:29:59
Because if you really did,
you wouldn't have the bug.

444
00:29:59 --> 00:30:06
So read it with sort
of a skeptical eye.

445
00:30:06 --> 00:30:17
You then form a hypothesis
consistent with all the data.

446
00:30:17 --> 00:30:22
Not just some of the data,
but all of the data.

447
00:30:22 --> 00:30:42
And then you design and run
a repeatable experiment.

448
00:30:42 --> 00:30:45
Now what is the thing we
learned in high school

449
00:30:45 --> 00:30:48
about how to design
these experiments?

450
00:30:48 --> 00:30:53
What must this experiment have
the potential to do, to be a

451
00:30:53 --> 00:31:01
valid scientific experiment?


452
00:31:01 --> 00:31:03
Somebody?


453
00:31:03 --> 00:31:05
What's the key thing?


454
00:31:05 --> 00:31:14
It must have the potential
to refute the hypothesis.

455
00:31:14 --> 00:31:20
It's not a valid experiment if
it has no chance of showing

456
00:31:20 --> 00:31:23
that my hypothesis is flawed.


457
00:31:23 --> 00:31:28
Otherwise why
bother running it?

458
00:31:28 --> 00:31:31
So it has to have that.


459
00:31:31 --> 00:31:34
Typically it's nice if
it can have useful

460
00:31:34 --> 00:31:38
intermediate results.


461
00:31:38 --> 00:31:42
Not just one answer at the end.


462
00:31:42 --> 00:31:45
So we can sort of check
the progress of the code.

463
00:31:45 --> 00:31:56
And we must know what the
result is supposed to be.

464
00:31:56 --> 00:31:58
Typically when you run an
experiment, you say, and I

465
00:31:58 --> 00:32:01
think the answer will be x.


466
00:32:01 --> 00:32:08
If it's not x, you've
refuted the hypothesis.

467
00:32:08 --> 00:32:14
This is the place where people
typically slip up in debugging.

468
00:32:14 --> 00:32:18
They don't think in
advance what they expect

469
00:32:18 --> 00:32:20
the result to be.


470
00:32:20 --> 00:32:23
And therefore, they are
not systematic about

471
00:32:23 --> 00:32:27
interpreting the results.


472
00:32:27 --> 00:32:31
So when someone comes to me,
and they're about to do a

473
00:32:31 --> 00:32:36
test, I ask them, what do you
expect your program to do?

474
00:32:36 --> 00:32:38
And if they can't answer that
question, I say well, before

475
00:32:38 --> 00:32:43
you even run it, have
an answer to that.

476
00:32:43 --> 00:32:47
Why might repeatability
be an issue?

477
00:32:47 --> 00:32:50
Well as we'll see later in the
term, we're going to use a

478
00:32:50 --> 00:32:53
lot of randomness in a
lot of our programs.

479
00:32:53 --> 00:32:56
Where we essentially do the
equivalent of flipping

480
00:32:56 --> 00:32:58
coins or rolling dice.


481
00:32:58 --> 00:33:00
And so the program may
do different things

482
00:33:00 --> 00:33:03
on different runs.


483
00:33:03 --> 00:33:05
We'll see a lot of that,
because it's used a lot

484
00:33:05 --> 00:33:07
in modern computing.


485
00:33:07 --> 00:33:10
And so you have to figure out
how to take that randomness

486
00:33:10 --> 00:33:12
out of the experiment.


487
00:33:12 --> 00:33:14
And yet get a valid test.


488
00:33:14 --> 00:33:17
Sometimes it can be timing.


489
00:33:17 --> 00:33:18
If you're running
multiple processes.

490
00:33:18 --> 00:33:22
That's why your operating
systems and your personal

491
00:33:22 --> 00:33:25
computers often crash
for no apparent reason.

492
00:33:25 --> 00:33:28
Just because two things
happen to, once in a while,

493
00:33:28 --> 00:33:31
occur at the same time.


494
00:33:31 --> 00:33:34
And often there's human input.


495
00:33:34 --> 00:33:37
And people have to type
things out of it.

496
00:33:37 --> 00:33:41
So you want to get rid of that.


497
00:33:41 --> 00:33:43
And we'll talk more
about this later.

498
00:33:43 --> 00:33:46
Particularly when we get
to using randomness.

499
00:33:46 --> 00:33:50
About how to debug programs
where random choices

500
00:33:50 --> 00:33:52
are being made.


501
00:33:52 --> 00:33:58
Now let's think about designing
the experiment itself.

502
00:33:58 --> 00:34:01
The goal here, there
are two goals.

503
00:34:01 --> 00:34:02
Or more than two.


504
00:34:02 --> 00:34:11
One is to find the
simplest input that

505
00:34:11 --> 00:34:17
will provoke the bug.


506
00:34:17 --> 00:34:20
So it's often the case that a
program will run a long time,

507
00:34:20 --> 00:34:22
and then suddenly a
bug will show up.

508
00:34:22 --> 00:34:25
But you don't want to have to
run it a long time, every

509
00:34:25 --> 00:34:27
time you have a hypothesis.


510
00:34:27 --> 00:34:30
So you try and find a
smaller input that will

511
00:34:30 --> 00:34:32
produce the problem.


512
00:34:32 --> 00:34:35
So if your word game doesn't
work when the words are 12

513
00:34:35 --> 00:34:41
letters long, instead of
continuing to debug 12 letter

514
00:34:41 --> 00:34:47
hands, see if you can make it
fail on a three letter hand.

515
00:34:47 --> 00:34:51
If you can figure out why fails
on three letters instead of 12,

516
00:34:51 --> 00:34:58
you'll be more than half way
to solving the problem.

517
00:34:58 --> 00:35:01
What I typically do is I start
with the input that provoked

518
00:35:01 --> 00:35:05
the problem, and I keep making
it smaller and smaller.

519
00:35:05 --> 00:35:12
And see if I can't
get it to show up.

520
00:35:12 --> 00:35:15
The other thing you want to do
is find the part of the program

521
00:35:15 --> 00:35:18
that is most likely at fault.


522
00:35:18 --> 00:35:23
In both of these cases,
I strongly recommend

523
00:35:23 --> 00:35:29
binary search.


524
00:35:29 --> 00:35:35
We've talked about this
binary search a lot already.

525
00:35:35 --> 00:35:40
Again, the trick is, if you can
get rid of half of the data at

526
00:35:40 --> 00:35:45
each shot, or half of the code
at each shot., you'll quickly

527
00:35:45 --> 00:35:48
converge on where
the problem is.

528
00:35:48 --> 00:35:52
So I now want to work through
an example where we can

529
00:35:52 --> 00:35:53
see this happening.


530
00:35:53 --> 00:35:57
So this is the example
on the handout.

531
00:35:57 --> 00:36:07
I've got a little
program called Silly.

532
00:36:07 --> 00:36:10
And it's called Silly because
it's really a rather

533
00:36:10 --> 00:36:12
ugly program.


534
00:36:12 --> 00:36:14
It's certainly not the
right way to write a

535
00:36:14 --> 00:36:20
program to do this.


536
00:36:20 --> 00:36:25
But it will let us
illustrate a few points.

537
00:36:25 --> 00:36:31
So the trick, what we're going
to go through here, is this

538
00:36:31 --> 00:36:34
whole scientific process.


539
00:36:34 --> 00:36:37
And see what's going on.


540
00:36:37 --> 00:36:47
So let's try running Silly.


541
00:36:47 --> 00:36:50
So this is to test whether
a list is a palindrome.

542
00:36:50 --> 00:36:54
So we'll put one as the
first element, maybe a

543
00:36:54 --> 00:36:56
is the second element.


544
00:36:56 --> 00:37:01
And one is the third element.


545
00:37:01 --> 00:37:02
And just return, it's done.


546
00:37:02 --> 00:37:04
It is a palindrome.


547
00:37:04 --> 00:37:04
That make sense.


548
00:37:04 --> 00:37:08
The list one a one reads
the same from the front

549
00:37:08 --> 00:37:10
or from the back.


550
00:37:10 --> 00:37:11
So that's good.


551
00:37:11 --> 00:37:14
Making some progress.


552
00:37:14 --> 00:37:19
Let's try it again.


553
00:37:19 --> 00:37:28
And now let's do one, a, two.


554
00:37:28 --> 00:37:31
Whoops.


555
00:37:31 --> 00:37:33
It tells me it is a palindrome.


556
00:37:33 --> 00:37:37
Well, it isn't really.


557
00:37:37 --> 00:37:40
I have a bug.


558
00:37:40 --> 00:37:43
Alright.


559
00:37:43 --> 00:37:44
Now what do I do?


560
00:37:44 --> 00:37:46
Well I'm going to use
binary search to see if

561
00:37:46 --> 00:37:50
I can't find this bug.


562
00:37:50 --> 00:37:54
As I go through, I'm going to
try and eliminate half of

563
00:37:54 --> 00:37:59
the code at each step.


564
00:37:59 --> 00:38:02
And the way I'm going to
do that is by printing

565
00:38:02 --> 00:38:09
intermediate values, as I go
part way through the code.

566
00:38:09 --> 00:38:14
I'm going to try and predict
what the value is going to be.

567
00:38:14 --> 00:38:20
And then see if, indeed,
I get what I predicted.

568
00:38:20 --> 00:38:24
Now, as I do this, I'm going
to use binary search.

569
00:38:24 --> 00:38:28
I'm going to start somewhere
near the middle of the code.

570
00:38:28 --> 00:38:32
Again, a lot of times,
people don't do that.

571
00:38:32 --> 00:38:35
And they'll test an
intermediate value near the

572
00:38:35 --> 00:38:38
end or near the beginning.


573
00:38:38 --> 00:38:42
Kind of in the hope of
getting there in one shot.

574
00:38:42 --> 00:38:45
And that's like kind of hoping
that the element you're

575
00:38:45 --> 00:38:47
searching for is the first
in the list and the

576
00:38:47 --> 00:38:49
last in the list.


577
00:38:49 --> 00:38:50
Maybe.


578
00:38:50 --> 00:38:54
But part of the process of
being systematic is not

579
00:38:54 --> 00:38:57
assuming that I'm going
to get a lucky guess.

580
00:38:57 --> 00:39:00
But not even thinking
really hard at this point.

581
00:39:00 --> 00:39:03
But just pruning
the search space.

582
00:39:03 --> 00:39:08
Getting rid of half
at each step.

583
00:39:08 --> 00:39:09
Alright.


584
00:39:09 --> 00:39:12
So let's start with
the bisection.

585
00:39:12 --> 00:39:14
So we're going to choose
a point about in the

586
00:39:14 --> 00:39:16
middle of my program.


587
00:39:16 --> 00:39:19
That's close to the middle.


588
00:39:19 --> 00:39:21
It might even be the middle.


589
00:39:21 --> 00:39:24
And we're going to
see, well all right.

590
00:39:24 --> 00:39:26
The only thing I've done in
this part of the program, now

591
00:39:26 --> 00:39:31
I'm going to go and read the
code, is I've gotten the user

592
00:39:31 --> 00:39:34
to input a bunch of data.


593
00:39:34 --> 00:39:38
And built up the list
corresponding to the three

594
00:39:38 --> 00:39:41
items that the user entered.


595
00:39:41 --> 00:39:51
So the only intermediate value
I have here is really res.

596
00:39:51 --> 00:39:53
So I'm going to, just so when
I'm finished I know what it is

597
00:39:53 --> 00:39:59
that I think I've printed.


598
00:39:59 --> 00:40:04
But in fact maybe I'll do
even more than that here.

599
00:40:04 --> 00:40:12
Let me say what I
think it should be.

600
00:40:12 --> 00:40:14
And then we'll see if it is.


601
00:40:14 --> 00:40:20
So I think I put in
one a two, right?

602
00:40:20 --> 00:40:22
Or one a two?


603
00:40:22 --> 00:40:32
So it should be something
like one, a, two.

604
00:40:32 --> 00:40:35
So I predicted what answer
I'm expecting to get.

605
00:40:35 --> 00:40:38
And I've put it in
my debugging code.

606
00:40:38 --> 00:40:45
And now I'll run it
and see what we get.

607
00:40:45 --> 00:40:49
We'll save it.


608
00:40:49 --> 00:40:51
Well all right, a syntax error.


609
00:40:51 --> 00:40:53
This happens.


610
00:40:53 --> 00:40:55
And there's a syntax error.


611
00:40:55 --> 00:40:56
I see.


612
00:40:56 --> 00:40:57
Because I've got a
quote in a quote.

613
00:40:57 --> 00:41:22
Alright I'm just
going to do that.

614
00:41:22 --> 00:41:24
What I expected.


615
00:41:24 --> 00:41:27
So what have I learned?


616
00:41:27 --> 00:41:33
I've learned that with high
probability, the error

617
00:41:33 --> 00:41:37
is not in the first
part of the program.

618
00:41:37 --> 00:41:41
So I can now ignore that.


619
00:41:41 --> 00:41:46
So now I have these six lines.


620
00:41:46 --> 00:41:52
So we'll try and go in
the middle of that.

621
00:41:52 --> 00:41:55
See if we can find it here.


622
00:41:55 --> 00:42:02
And notice, by the way, that I
commented out the previous

623
00:42:02 --> 00:42:05
debugging line, rather
than got rid of it.

624
00:42:05 --> 00:42:08
Since I'm not sure I won't
need to go back to it.

625
00:42:08 --> 00:42:14
So what should I look at here?


626
00:42:14 --> 00:42:16
Well there are a couple of
interesting intermediate

627
00:42:16 --> 00:42:20
values here, right?


628
00:42:20 --> 00:42:29
There's tmp.


629
00:42:29 --> 00:42:35
And there's res.


630
00:42:35 --> 00:42:40
Never type kneeling.


631
00:42:40 --> 00:42:40
Right?


632
00:42:40 --> 00:42:44
I find something to tmp.


633
00:42:44 --> 00:42:48
And I need to make sure maybe
I haven't messed up res.

634
00:42:48 --> 00:42:51
Now it would be easy to
assume, don't bother looking

635
00:42:51 --> 00:42:53
at [UNINTELLIGIBLE].


636
00:42:53 --> 00:42:55
Because the code
doesn't change res.

637
00:42:55 --> 00:42:59
Well remember, that I
started this with a bug.

638
00:42:59 --> 00:43:02
That means it was something
I didn't understand.

639
00:43:02 --> 00:43:05
So I'm going to be
cautious and systematic.

640
00:43:05 --> 00:43:08
And say let's just
print them both.

641
00:43:08 --> 00:43:17
And see whether they're okay.


642
00:43:17 --> 00:43:31
Now, let's do this.


643
00:43:31 --> 00:43:39
So it says tmp is two a
one, and res is two a one.

644
00:43:39 --> 00:43:42
Well let's think it.


645
00:43:42 --> 00:43:44
Is this what we wanted, here?


646
00:43:44 --> 00:43:49
What's the basic idea
behind this program?

647
00:43:49 --> 00:43:51
How is it attempting to work?


648
00:43:51 --> 00:43:54
Well what it's attempting to
do, and now is when I have

649
00:43:54 --> 00:43:57
to stand back and form a
hypothesis and think about

650
00:43:57 --> 00:44:02
what's going on, is it gets in
the list, it reverses the list,

651
00:44:02 --> 00:44:05
and then sees whether the list
and the reverse were identical.

652
00:44:05 --> 00:44:10
If so it was a palindrome,
otherwise it wasn't.

653
00:44:10 --> 00:44:18
So I've now done this,
and what do you think?

654
00:44:18 --> 00:44:25
Is this good or bad?


655
00:44:25 --> 00:44:28
Is this what I
should be getting?

656
00:44:28 --> 00:44:29
No.


657
00:44:29 --> 00:44:30
What's wrong?


658
00:44:30 --> 00:44:32
Somebody? yeah.


659
00:44:32 --> 00:44:35
STUDENT: [UNINTELLIGIBLE]


660
00:44:35 --> 00:44:37
PROFESSOR: Yeah.


661
00:44:37 --> 00:44:47
Somehow I wanted to -- Got
to work on those hands.

662
00:44:47 --> 00:44:50
I didn't want to change res.


663
00:44:50 --> 00:44:57
So, I now know that the bug
has got to be between these

664
00:44:57 --> 00:45:00
two print statements.


665
00:45:00 --> 00:45:03
I'm narrowing it down.


666
00:45:03 --> 00:45:05
It's getting a little silly,
but you know I'm going to

667
00:45:05 --> 00:45:08
really be persistent and just
follow the rules here of

668
00:45:08 --> 00:45:14
binary search, rather than
jumping to conclusions.

669
00:45:14 --> 00:45:21
Well clearly what I probably
want to do here is what?

670
00:45:21 --> 00:45:31
Print these same two things.


671
00:45:31 --> 00:45:40
See what I get.


672
00:45:40 --> 00:45:41
Whoops.


673
00:45:41 --> 00:45:43
I have to, of course, do that.


674
00:45:43 --> 00:45:55
Otherwise it just tells me that
Silly happens to be a function.

675
00:45:55 --> 00:45:57
Alright.


676
00:45:57 --> 00:45:58
How do I feel about
this result?

677
00:45:58 --> 00:46:02
I feel pretty good here.


678
00:46:02 --> 00:46:02
Right?


679
00:46:02 --> 00:46:06
The idea was to make a
copy of res and temp.

680
00:46:06 --> 00:46:08
And sure enough,
they're both the same.

681
00:46:08 --> 00:46:12
What I expected them to be.


682
00:46:12 --> 00:46:14
So I know the bug is not above.


683
00:46:14 --> 00:46:17
Now I'm really honing in.


684
00:46:17 --> 00:46:25
I now know it's got to be
between these two statements.

685
00:46:25 --> 00:46:50
So let's put it there.


686
00:46:50 --> 00:46:50
Aha.


687
00:46:50 --> 00:46:52
It's gone wrong.


688
00:46:52 --> 00:46:55
So now I've narrowed the
bug down to one place.

689
00:46:55 --> 00:47:03
I know exactly which
statement it's in.

690
00:47:03 --> 00:47:09
So something has happened there
that wasn't what I expected.

691
00:47:09 --> 00:47:13
Who wants to tell me
what that bug is?

692
00:47:13 --> 00:47:13
Yeah?


693
00:47:13 --> 00:47:25
STUDENT: [UNINTELLIGIBLE].


694
00:47:25 --> 00:47:29
PROFESSOR: Right.


695
00:47:29 --> 00:47:33
Bad throw, good catch.


696
00:47:33 --> 00:47:37
So this is a classic error.


697
00:47:37 --> 00:47:38
I've not made a
copy of the list.

698
00:47:38 --> 00:47:40
I've got an alias of the list.


699
00:47:40 --> 00:47:44
This was the thing that tripped
up many of you on the quiz.

700
00:47:44 --> 00:47:58
And really what I should
have done is this.

701
00:47:58 --> 00:48:09
Now we'll try it.


702
00:48:09 --> 00:48:10
Ha.


703
00:48:10 --> 00:48:16
It's not a palindrome.


704
00:48:16 --> 00:48:21
So small silly little exercise,
but I'm hoping that you've sort

705
00:48:21 --> 00:48:23
of seen how by being patient.


706
00:48:23 --> 00:48:26
Patience is an important part
of the debugging process.

707
00:48:26 --> 00:48:28
I have not rushed.


708
00:48:28 --> 00:48:31
I've calmly and slowly
narrowed the search.

709
00:48:31 --> 00:48:35
Found where the statement
is, and then fixed it.

710
00:48:35 --> 00:48:38
And now I'm going to go hunt
through the rest of my code to

711
00:48:38 --> 00:48:42
look for places where I used
assignment, when I should have

712
00:48:42 --> 00:48:45
use cloning as part
of the assignment.

713
00:48:45 --> 00:48:48
The bug, the family here,
is failure to clone when

714
00:48:48 --> 00:48:50
I should have cloned.


715
00:48:50 --> 00:48:54
Thursday we'll talk a little
bit more about what to do once

716
00:48:54 --> 00:48:58
we've found the bug, and
then back to algorithms.

717
00:48:58 --> 00:48:58