Professional Documents
Culture Documents
Lecture 1 CS 50
Lecture 1 CS 50
So a silly example, to be fair, but just realize how much opportunity there
was even in something as simple as that for ambiguity or scenarios
you didn't anticipate.
And indeed, among the things we're going to do today
as we begin to formalize these ideas with code, with programming code,
are how you think about breaking down problems into their constituent parts,
considering what happened-- what should I do if this happens?
What should I do if this happens?
What should I do if this happens?
Because unless you anticipate the kind of silliness
that I was deliberately acting out there,
who knows what the computer might end up doing?
After all, odds are everyone in this room
like me has seen like a spinning beach ball or an hourglass
on your computer or your Mac or PC freezes or crashes.
And almost always that's just the result of some human error.
Someone at Google or Microsoft or Facebook or wherever made some mistake.
He or she did not anticipate some situation,
didn't anticipate you typing in a word that you did,
didn't anticipate you running 20 programs at once,
didn't anticipate some scenario.
And so as such, the computer's behavior was effectively undefined.
And so the incorrect solution was outputted.
So how do we begin to think about this?
What would be ideal if we somehow--
if we somehow formalize this by way of actual code.
And we'll do that with sort of another old school
problem, one that's a lot more digital these days
but it's still with us today.
Whether you have an Android phone or iPhone or anything else,
odds are you have like a little app for your contacts or your address book.
And then there are a whole bunch of names,
probably alphabetical by first name or last name,
and a whole bunch of telephone numbers and maybe more information like emails
and so forth today.
But the physical incarnation of that icon on your phone
is this old thing, a phone book.
And if I wanted to look for an old friend like, say, Mike Smith, how might
I go about finding him in this old school phone book?
Well, just as in my digital form, I might just
scroll through the list looking for him.
So could I look at the first page, look down, not see him, turn the page,
look down, not see him, turn the page, look down, not see him, and so forth.
Is this algorithm correct?
AUDIENCE: Yes.
SPEAKER 1: Yeah, it's correct.
It's kind of dumb right because it's going
to take forever to get to Mike if there's like 1,000 pages here,
but it is correct.
And it's the equivalent really of sort of slowly methodically scrolling
through your list of contacts without the luxury of like searching
or autocomplete or the like.
Well, I could do a little better.
Back in grade school, I generally learned to count by two.
So I could instead do 2, 4, 6, 8, 10, 12.
I'm flying through the phone book now clearly faster.
But is that algorithm correct?
AUDIENCE: No.
SPEAKER 1: No why?
AUDIENCE: You might miss him.
SPEAKER 1: Yeah, I might miss him, right?
Like Mike, just by chance, might be sandwiched between--
so it is, no pun intended-- between the two pages then I'm flying past
and I might miss him.
But I can at least fixed this mistake or bug, so to speak.
A bug is a mistake in a program, just human error.
If I hit like the T section, t comes after Smith.
So I can maybe double back at least one page and solve that bug.
So it costs me a little bit more time to double back, but if I do it right,
it only costs me like one extra page turn.
So better and now correct.
But obviously no one in this room is going to look for Mike Smith
by starting on the first page.
Where are you going to roughly look?
In the middle, maybe a little toward the end because you know where S's are.
And so you open the book to the middle.
You look down and you see the M section.
So I haven't gone far enough.
But what's nice about this old school technology
is that we can now tear this problem in half, throw half of it
away, and be left with fundamentally the same problem but a smaller version
thereof.
This now is maybe not 1,000 but 500 pages, but it is the same problem.
And I can apply the same logic, go roughly to the middle, look down.
I went a little too far this time, the T section.
But I can again tear off almost a quarter of that problem,
leaving me now with a total size of the maybe 250 pages
after dividing it in half twice now.
And now I can repeat and repeat and repeat.
And so long as Mike is in the phone book,
I should ultimately find him once and only once
on the final page of the phone book, at which point I can call him.
So the real question then is how much better was this.
It's a little wasteful.
You can't sort of undo here in the analog world.
But let's consider how we can think about how good that algorithm was,
the one that we all probably took for granted and should have started with.
Well, if here's a simple plot and on the x or horizontal axis
is the size of the problem--
so the number of pages in the phone book, however you want to measure it--
and then the y or vertical axis is time to solve--
so maybe number of seconds, number of page turns,
however you want to count up the steps--
that's a relationship, size to time.
And the first algorithm I'm going to draw
like this-- a straight line in red.
And I'm going to call it n where n is just like the number of pages
in the phone book.
Computer scientists tend to use n as a variable so to speak, just a symbol.
And it's a straight line for the following reason.
If the phone book gets a little longer next year, a little longer next year,
by like one page, that means I might have
to spend one more step looking for Mike.
So the slope of this line is linear.
There's a one to one relationship between number
of pages Verizon or the phone company puts in the book and the number of page
turns I need to make.
The second algorithm, though, is also a straight line,
but it's lower drawn here in yellow.
And n over 2 means it's twice as fast or equivalently takes half as much
time because for a given size problem, if you kind of follow my hand straight
up, the yellow line should be below the red line
because I'm flying through the phone book two pages at a time.
So it should take me half as much time.
But if I use the first algorithm, I have to go all the way up
to the red, which measures that number of seconds.
But the third algorithm is a fundamentally different shape.
And this is where the sort of beauty of computer science and algorithms
specifically comes out.
It doesn't become straight ultimately.
It looks like it's gradually easing off.
But it's going to do this forever.
It's just becoming such a slow increase in time--
you can't even really see it especially if the screen were even wider.
We'll call this logarithmic, log n, more on that down the road.
But the shape is fundamentally different.
It's curved.
And what's powerful about this-- and you can think about it much more easily,
intuitively.
If Verizon next year doubles the size of the phone book
because like maybe Cambridge and another town
merge together into one book, no big deal
because if Verizon doubles the size of the phone book next year,
how many more page turns do I need to find Mike?
AUDIENCE: Just one.
SPEAKER 1: Just one, right?
Because I just split the problem in half one more time, no big deal,
instead of flipping through an additional 1,000 or 500 pages.
And so this intuition with which you entered Sanders today,
odds are you can harness it already to solve problems more effectively so
long as you start to notice the patterns and the sort of useful inputs
with which you can solve problems.
But we need to begin to formalize the process.
We need to be able to express ourselves a little less organically than we
did with the peanut butter and jelly.
So how might we more methodically express
that algorithm with the phone book for which we probably nonetheless
have an intuitive understanding?
Well, let me start counting at zero just because programmers and computer
scientists tend to start counting at zero
because that's like all the light bulbs are off.
So you might as well start there.
And then step zero would be pick up phone book.
It's sort of an action.
Do this.
Step one is open to the middle of the phone book.
That's pretty much what I did a moment ago.
Step two is look at the names--
another action or verb
Step three, if Smith is among names.
So this is a different construct.
And that key word here is going to be if.
It's a question you're asking yourself.
It's kind of a proverbial fork in the road.
If Mike is among the names on the page you're looking, then call Mike.
And I've deliberately indented it because in many computer languages,
indentation means logically that you should only
do step four if line three were true.
Or the answer to that question is yes.
Else, if Smith is earlier in the book, he's meant to my left, then step six,
open to the middle of the left half of the book.
So that's when I tore it in half, threw it away, and then repeated
on the left half.
Else, if Smith-- oh, sorry.
Then go back to step two, a key step.
Now that I've divided the problem in half
and I'm looking in the middle of the left half,
the problem is fundamentally the same as I claimed before.
Just do the same thing but on a smaller problem.
And what's beautiful about this algorithm-- it's recursive,
so to speak, as we'll see down the road to--
is that you keep doing the same thing, same thing, same thing,
but because the problem keeps getting smaller,
eventually you're not going to do this forever.
You're going to find the answer you're looking for.
And so we go back to step two.
Step eight, else if Smith is later in the book, to my right,
open to the middle of the right half of the book
and then again go back to step two.
Else-- what's the fourth scenario to consider?
AUDIENCE: [INAUDIBLE]
SPEAKER 1: Yeah, what if Mike isn't in the phone?
He's unlisted.
We'd better anticipate that less my program crash or my computer freeze
because, like, it doesn't know what to do if Mike isn't there.
So I'll quit in this particular case.
And now let's tease this apart by highlighting
in yellow those operative verbs or actions.
Henceforth, we're going to call things like these yellow words functions,
so to speak, in a programming language.
These are verbs or actions, and I'll call them out, albeit in English
because there's no one language here.
This isn't like a formal vocabulary we're introducing.
It's just my most distinct way of expressing that algorithm.
And that's what pseudocode is.
It's English like syntax that anyone in the room
should hopefully be able to follow if you're
nice and clean and precise about it.
But there's another type of keyword in here
and that's the if and the else if and else if and the else.
These are the keywords that languages typically
use to represent these forks in the road-- go left,
go right, go here, go there, do different things.
And each of those decisions, if you will, is based on the answer
to a question.
And these questions we're going to call Boolean expressions named
after a person named Bool years ago.
And a Boolean expression is just a question with a yes or no answer
or really more technically a true false answer.
And notice the fact that everything falls into like buckets of two--
yes, no, true, false--
means we can use those light bulbs really to our advantage.
Maybe off shall be no or false.
Maybe on will be true or yes.
Just using a one light bulb can we represent any of these answers
to these questions.
And so those are Boolean expressions.
And then lastly, there is these things--
go to step two, which is perhaps the most explicit.
It's inducing some kind of loop or cycle.
Do something again and again.
And all of these ideas, functions, conditions, Boolean expressions, loops,
and more are going to permeate several languages that we explore over
the course of the semester.
But of course this unto itself is not yet real code.
And today in just a little bit, we're going to dive
into real programming code, albeit graphically using a language
called Scratch, and then follow that on later next week with a programming
language called C.
But before that, let me make just a couple of introductions.
Behind CS50 and its lectures and sections and office hours and more
is a whole team, nearly 100 staff every year,
that are here to make this course successful for you
so that irrespective of your prior background or lack thereof,
you too can succeed, especially if you are among those 68%.
And allow me to invite up Maria and Brian and Doug and Rob
to come say hello from the course's staff.
[INAUDIBLE]
SPEAKER 1: All right, so before--
Ouch!
OK, that's what the word ouch looks like as a waveform.
Let's now call this ouch.
And now I need sound.
Whoops-- scripts.
Sound, play sound ouch logically.
So just to give you a sense of what we did, if touching edge play sound ouch,
turn around.
Ouch.
Ouch.
Ouch.
It's a little bit of a delayed reaction, but we've now
sort of combine these different ideas.
And already we've kind of moved quickly beyond where we started.
All we did initially was say something.
Then we move the cat.
Now we moved it forever.
Then we moved it forever unless you hit the edge in which case
you should turn around.
So just by building on these very simple ideas can
we make more complicated programs still.
And let's fast forward for just a moment before we tease apart
some of the more sophisticated features to take a look back at actually
the very first program I myself wrote back in graduate school
when Scratch first came out.
I called it Oscar Time since I always loved Sesame Street.
And this was the program I made that combines many, many, many, many hours
after first starting with Scratch a whole bunch of these same ideas.
And rather than I playing this, it would be more fun
if someone else perhaps plays.
Could we get a brave volunteer maybe a little farther back?
Yeah, what's your name?
AUDIENCE: Mansi.
SPEAKER 1: Mansi, come on up, Mansi.
All right, thank you to Mansi.
[APPLAUSE]
[GROWL]
That did not work out very well either.
But in this case, the two sprites are interacting
because one is checking whether or not it's touching the other.
Meanwhile, you can do this.
Let me introduce events, which is another program too.
It's not very long, but it again has two sprites, two little puppets here.
And if I hit Play here, nothing happens until I hit the space bar.
When if you played this game growing up, one says Marco and then the other
says Polo.
But one is saying Polo in response to the other saying Marco.
Let me look at the sprite for the orange puppet here and you'll see this.
Forever do the following.
If key Space pressed-- so if the space bar is pressed--
then say Marco for two seconds and then broadcast an event.
And an event for our purposes today, it's like a whisper.
Whisper something that only other sprites can hear, not humans.
Meanwhile if I look at the blue puppet, it's not much going on there.
When you receive that event, that whisper, say polo.
And so we have interaction between these two sprites
much like Oscar was responding to the trash being dragged and dropped
over his trash can.
Finally, we have this one here-- hi, hi, hi--
which combines some of these ideas as well that allows you--
[SEAL BARKING]
--to implement perhaps a familiar idea--
[SEAL BARKING]
--from like a video game on your phone or the computer.
[SEAL BARKING]
This is very annoyingly barks in perpetuity--
[SEAL BARKING]
--until you figure out how it works.
How do I make this stop?
[SEAL BARKING]
Yeah, so if you look at the code at top right--
[SEAL BARKING]
--it mentions to the space bar and it stopped.
Why?
What does hitting the space bar actually seem to do logically?
Nice.
Death is up to seven.
Nice.
Last level!