DAVID MALAN: This is CS50, and this is the start of Week 1. What we thought we'd do today is take a look back at something many of you have probably walked past for some time now and might look a little bit familiar. This thing here, this of course is in the-- AUDIENCE: Science. DAVID MALAN: Science center. So this is actually one of the earliest computers back from the 1940s. It was one of the first electromechanical computers that was capable of particularly long, self-sustained computations, and what we actually see in the science center is only a little piece of this thing. What we thought we'd do then is take a look back at a video that was made some time ago, introducing this thing to the world. And you'll see from the music and voice that indeed those were very happy times. 

[VIDEO PLAYBACK] -A triumph of mathematical and mechanical skill is this great new automatic calculator at Harvard University. Intricate problems in mathematics, put through the machine in coded form on tape, are accurately solved in a minute fraction of the time required for human calculation. Designed to expedite all forms of mathematical and scientific research, the giant mechanical brain will work for the United States Navy until the war's end. 

DAVID MALAN: So what you might not know is that it was in this same device that a term we all now take pretty much for granted was coined, that of a bug. So one of the engineers working in this computer literally found a small moth in the machine that resulted in some incorrect calculations. And as the story goes that moth was taped to this log journal here, back from September 9 in 1940-something, and thus was born for the world the term "bug". So henceforth we consider bugs to be any sort of mistakes in programs, whether man-made or, in this case, insects. 

So a few announcements, as we proceed. So CS50 has a tradition of offering lunches of sorts on most Fridays during the semester, where we take 30 to 40 students to Fire and Ice in the Square for casual chitchat, talk about computer science, talk about the future. We invite alumni and friends from industry to chat up students as well. Really toward an end of making what's a fairly large class all the more intimate, at least once in while for subsets of students. So if you would like to join us this Friday, 1:15 PM, go to CS50.net/lunch to RSVP. And we'll do this recurringly, so not to worry if you're not among the first 30 or so this week. 

So scribe notes. A word on the resources that will now start being available to students in the class. So that your heads needn't be down during lectures scribbling down everything I say and so forth, what we do instead is provide from the teaching staff a canonical set of notes. So we have one of our teaching fellows, Andrew Sellergren, who sits down each week, reviews the videos, and then writes down what we think is a fairly authoritative set of notes. And Andrew's fond, also, of putting snarky footnotes in the bottom. So you'll hopefully enjoy these as a reference book for fun, and also, come quiz time, as an opportunity to review what happened in individual lectures. So those are linked on the lectures page. 

Problem set 0, meanwhile, is out. And in terms of the resources available to you-- the walkthrough. Milo led the first on Friday. It was filmed, put online by Saturday. And so realize, if you're not really sure where to begin, for this or future p-sets, always turn first to the walkthrough or the video thereof. Sectioning is in progress; at cs50.net/section is where you should submit your preferences, if you haven't already, by today. Because sections will start this coming Sunday, Monday, and Tuesday. We do sections those three days, every week of the semester for the most part. And we also introduce, again, different tracks. So you'll be asked on this sectioning form, if you haven't seen it already, if you're among those less comfortable, more comfortable, or somewhere in between. And if you're sort of on the fence, generally somewhere in between is what most students end up checking. Office hours begin tonight. 

So Scratch is fairly low key, even though it's quite natural to run into various bugs, or be uncertain as to how to implement something. So realize that we will start office hours this week. They'll be at Annenberg Monday, Tuesday, Wednesday, Thursday, from 8:00PM to 11:00PM during brain break. Upper classmen can get in, and if you ever have trouble getting in the door, because they'll be swiping, just talk your way in and explain you're with CS50. Typically 20 to 30 of us on staff will be there to help you one on one. 

Upon arrival the idea is this: you'll bring your laptop, you'll have your charger, we'll have extra power cords, particularly along the south wall of Annenberg where there's lots of electrical outlets. And the main entry point to office hours Q&A is to go to cs50.net/discuss and to post your question there. And to label it with pset 0 or pset 1, whatever the week might happen to be. And then what we'll do is have a table of teaching fellows and course assistants, generally 8 or 10 or so of us, going through, keeping a watchful eye on the board, and plucking off questions really as quickly as we can, referring you to related posts if you haven't found those yourselves, online references, as appropriate. And then if there are problems, as there inevitably will be, or it just makes more sense to sit down one on one, work through problems with someone. 

Or you just come into office hours really needing that mindset. You don't want to go through the electronic form, you really want to meet with someone. Communicate that to us, and what will happen is when your question has been seen by a staff member, and we determine, yup, this should be dispatched to one of the 20 or 30 team members here locally, you will see at top left this little Enter the Queue button starts flashing on cs50.net/ discuss. And this is telling you that you now have been invited, so to speak, to enter the queue. And by clicking that button, your name will then appear on an iPad that the CS50 greeter, one of the course's heads, will be holding near the entrance of Annenberg, who will then see as depicted here, the students who have questions on the left, the staff members who are present on the right. And with a click of left and right, your web browser will start flashing as soon as, for instance, Professor McGonnagal is ready to see you at a particular table in Annenberg. 

So we did some of this last year. We've rebooted office hours and re-implemented much of the software. So realize that this will be warm up this week. But also realize too, in years past, as you might have heard from friends, office hours had indeed 50 to 150 students at once. And it's simply not possible for us to handle that effectively, one on one, throughout the evening. And so what we're really going to try to do this year is capitalize on the fact that a lot of questions are frequently asked and can often be better answered asynchronously. So you can sort of think through the staff's response, and we can think through your code, without the heated pressure of necessarily struggling through it side by side. So we estimate that roughly a third or half of the questions will be dispatched in person, and we'll try to pluck off as many as a half or more electronically, during office hours. And we'll continue to use Discuss throughout the week as well. 

And lastly, realize that this course can be taken pass/fail. So if you are on the fence or just think that you're really not sure if this is the world for you, or this is really quite foreign to you, realize that this is a wonderful way of gaining up some confidence with which to step into the class, like I did frankly, years ago. And then have five weeks to sort of figure out for yourself if you want to stay pass/fail, switch to a letter grade, or the like. And typically what pass/fail does, I think, for students is that, if you put in that 10 hours, 20 hours, whatever it may be on some problems, and you're banging your head against the wall, and you really just can't chase something down, and you have so many other things you need to do, honestly, what I think pass/fail is, it takes the edge off of situations like that. Where you've taken the thing 90% of the way. You know, it's not quite perfect. But you got a lot out of it, nonetheless. So consider pass/fail as giving you that mental model, perhaps. 

All right, so last week we dove into Scratch, and we talked about programming on a fairly high graphical level. And today we make the transition to a language called C, a lower level programming language on top of which many modern languages are now built, including some of the ones we'll be using towards term's end. And syntactically, what they look like is all quite similar. So let's start to make this transition here. So this was a program last week that was the simplest of hello world programs. It simply printed to the screen hello world, with a little speech bubble coming out of the cat. Well, if we begin now to translate this to another language, realize that the ideas today and on Wednesday are identical, but the syntax starts to change. So whereas last week we had, when green flag clicked, say hello world. Today we're going to have int, main, void, printf, return, with some other syntax in there as well. Curly braces, and parentheses, and quotes, and whatnot. But realize that the core of the idea here is the printing, and ultimately the fact that main is now going to be synonymous with the starting of a program. Main is going to be where the green flag kicks things off. 

So now let's tease apart some of the building blocks here before we dive into some concrete examples. So we called this a statement last week, whereby it's just an instruction. Do this--in this case, say hello world. Well in C, if we look at just that line, this is how we're going to start expressing that particular puzzle piece: printf("hello world");. And now we'll tease these apart more and more over time, but realize that there's a pattern here. So one, we have this thing called printf, which is essentially analogous to the word Say. That's what it's going to do. Printf, and f here means "formatted". So it just means you can insert various aesthetic details. So quote unquote is the beginning of what we're going to start calling a string. A word, a phrase, a sentence. A string in a programming language is a sequence of zero or more characters. So h-e-l-l-o, comma, and so forth is, quote unquote, a string. And now backslash n, a little syntactically odd, but we already defined that last week as meaning what? It's just a new line. It's just a way of conveying to the computer you want the equivalent of hitting the Enter there, but you don't want to actually hit Enter and therefore mess up all of the formatting of your actual program. Now the parentheses enclose this string, open paren and close paren, and inside of that is our string. Because that's because in C, and other programming languages, things like printf take arguments, or take parameters. 

So start thinking now of this purple Say block as a function, as a method, as a procedure. You can really call it whatever you want for now, but it's sort of a miniature program that only does one thing, in a single line, no less. So printf is also what we're going to start calling a function, and functions do something-- in this case prints a formatted string to the screen-- but functions also take arguments or parameters. And by arguments or parameters, thank you, we mean that their behavior can be influenced by what you pass in inside of the parentheses. So in this case, printf needs be told what to print, and we just pass in, in double quotes here, the string that we actually want to print. And the semicolon on the very end of this line is just a historical nuisance whereby at the end of most lines of code, you put a semicolon to make super clear to the computer that this line of code ends here. Now this is good because as we'll see as programs get more complex, the semicolon will make super clear to us humans, and also the computer, where lines of code start and end. Realize that some languages don't have some of these same details. And in fact, in JavaScript, you don't always need something like the semicolon. But more on that to come. 

So loops. We had something like this, very intuitively, obvious, do something again and again and again. Like putting on socks, or saying hello, in this case. Well, starting today in C, we could express this Scratch block as while (true) printf("hello world"). So notice we're starting to build on literally the puzzle piece from before. We have the same purple block, but it's inside of this bracketed Forever block, and the best way to translate that to C is as follows. There's no Forever keyword. You can't just type f-o-r-e-v-e-r in C. So the closest analog is while. 

Now, while (true) seems a little stupid because does the value of true ever change? Presumably not. It's like saying while one, while on, while true. It's all the same thing, true is always the case. So this loop is actually inducing what kind of loop? Just an infinite loop, right. A Forever loop or as we called it last week, just an infinite loop. So sometimes that's bad. Sometimes that's a bug, sometimes that's why you get the spinning beach ball or hourglass or the like. But in this case, we deliberately, for whatever reason, wanted to print the same thing again and again and again. Or in the case of like a watch, you want to do something again and again and again. So infinite loops might make sense. And this is how in C we might translate Forever to code. 

So now this one's a little more specific. We had repeat 10 times the following statement. So while (true) doesn't quite work there, because true is always true. So if we instead look at the C version, now the syntax gets a little more cryptic. But to be honest once you start to see this, it all gets pretty familiar quickly. So this is what's called a for loop. A for loop is going to tell the computer to do something again and again and again for as long as these things are true. Now what do we mean by that? Well, there's three parts to a for loop, and we're going to come back to this in context of actual examples in a moment. So don't worry if it doesn't quite sink in all at once. But int i = 0 is, long story short, saying give me a variable that's of type integer, so give me a number called i, and initialize it to 0. That is give me like an algebraic variable x and initialize it to 0. But in this case we called it i. Then in the middle, it says i is less than 10. That's telling the computer do the following stuff so long as i is less than 10. And obviously it starts less than 10 because it starts at 0. Then lastly, you can perhaps guess what i++ means. It's a little bit of syntax that just means increment i. So add 1 to i, again and again and again. 

And so as we'll see this loop, this syntax, rather, implements precisely the same thing that, frankly, in Scratch was just so much easier to express. Repeat 10, and you're done. In C, and in most programming languages, we have to be a little more instructive for the computer and actually specify something like this. But we'll come back to this and other syntax. 

What about variables? In Scratch we had something like these orange blocks, where I could declare a variable. Let's arbitrarily call it counter. Let's initialize it to 0, and then let's forever do something. In this case in Scratch I'm saying the counter, so the cat's going to have a little speech bubble that's speaking the number that's in this variable. And then we have change counter by 1. So all of this is wrapped inside of a Forever lock. So we already now have the building blocks in C with which to translate this. 

One way we could do that is this. Give me an integer, call it counter. Initialize it to 0 in the first line there. While (true), so I'm stealing that idea from just a moment ago, go ahead and do the following. Print out the counter, and then increment the counter, again, and again, and again. Or again, ++ just means add 1 to something. But there is a new piece of syntax here. What's jumping out as not among our previous examples? Yes, this %d. So you can maybe infer what this is doing, frankly, based on what the Scratch block is doing. But again in C, we just have to be a little more particular when it comes to expressing ourselves. 

So printf("%d\n"). Well most of that we can throw away as familiar. The quotes just means it's a string, backslash n is just a new line. So the only new thing here is %d. And all that is is a placeholder. %d is going to denote a decimal number. And %d means computer, put a decimal number here. Well, what number do you want to put there? Well, as you can perhaps infer, after the comma we say counter, that's the name of a variable that we declared or created a couple lines earlier. So this is just C's way of plugging in a variable into a string dynamically. Because by contrast, if I had instead done something like this, printf("counter"), what would this program instead do, presumably? It'll literally print "counter". Which is not the effect that I want. I need to substitute in some numeric value. So we'll see that functions then, like printf, can take not only just single arguments, like "hello world". They can take quote unquote comma, and then some variables that will get plugged into, as we'll see the previous string via these % sign placeholders. 

Well what about Boolean expressions? Boolean expressions were these values, true or false. Yes or no. 1 or 0. On or off. So in Scratch they look like this, and notice that the bottom block here is actually the conjunction of two smaller blocks. So I kind of dragged and dropped three puzzle pieces together to make that longer puzzle piece there so that I could convey the idea that I want x to be less than y and y to be less than z. And so I can translate these two separate lines as follows. The top one can be very trivially translated to C, with just x < y. Maybe with some parentheses for good measure. And then in C, you don't write a-n-d to denote the conjunction of something. You instead write &&. And as we'll eventually see, a single ampersand happens to mean something different. So && just denotes the idea of AND. 

So again, even though this starts to look rather complex, one of the purposes of introducing Scratch, besides just having sort of a fun on-ramp where you can do something that's very graphical, and animated, and shareable and the like, is also to convey the idea that all of the ideas we start diving into today and onward have been embodied in even that simple interface since day one. What about this one here? 

So conditions. So the Scratch block on the left there looks a little more complex. But it's just some dragging and dropping of familiar pieces. If x is less than y, say so. Else if x is greater than y, say so. Else, we can logically assume it's inferred that they must be equal. So say that they are equal. Now in C on the right, same exact thing. And notice that the curly braces are going to be a feature of C and other languages that do this sort of encapsulation. Just like the if block is this yellow thing that's sort of grabbing the purple block inside of it. Similarly are these braces-- these curly braces-- meant to conjure up that same idea of embracing one or more lines of code that are indented inside of them. So on the right-hand side here, if x less than y, printf ("x is less than y"). Else if x is greater than y, print out the same. Else print out that they are equal. 

So in short, there's a fairly direct mapping or translation of the language we've seen thus far, including for some of the more sophisticated features. So you might not be using this for your project, or might not be using this for your project this week. But we have these things called arrays in C. In Scratch, they're called lists. And we saw these with the Fruitcraft RPG last week. The little blue guy that was walking around, picking up cherries and oranges and the like. Well in Scratch, that was implemented with this orange block that contains words; in this case, we're literally adding "orange" to a variable called inventory. So in C, this syntax is going to get a little more cryptic. And we'll come back to this next week and do more interesting things in the world of cryptography with it. But at the bottom here, these two lines essentially translate to what we're doing in one Scratch block up there. But more on that to come. 

So putting it together, here is a program in C. So let's quickly tease apart some of the pieces of syntax here, but then let's actually start writing some code, familiarize you with some of the tools we'll be using, and see if we can build on now some of these basic building blocks from last week, now syntactically in C. So at the top here, this is perhaps one of the most boring programs you could write in most any programming language. But it's sort of has special meaning because it's the canonical program that any computer scientist writes when teaching someone a programming language-- a hello world program. 

So at the very top, we see this notion of #include and then, in angled brackets, stdio.h. We're going to come back to that, but really what that means is that there is a file in this world called standard I/O, s-t-d-i-o dot h, and that's just a text file that someone wrote years ago. And inside of that text file are a whole bunch of functions, or methods, or procedures, that someone else wrote that we are the beneficiaries of because we can now use that person's code. The functions he or she wrote. In this case, printf is not something that I wrote, it's not something that CS50 wrote. It's something that someone wrote years ago and put in a file called stdio.h and then, as an aside, put another part of the function in another file. But we'll get there. 

So #include <stdio.h> is just our way of saying, in C, give me access to functions that someone else wrote. And in this case I care because I want printf. Now we get int main (void). So this is one of these things, frankly, that on day 0, pretty much I've to kind of zone out, because it's just not interesting intellectually, some of the syntax. But for now know that functions, otherwise known as procedures, or methods, generally produce some value. They do something. They come up with an answer. They produce output. So int next to main is just our shorthand way of saying that this function, this procedure, is eventually going to give you back a number. And why that is, we'll come back to. Main is just the default world standard for the default function that's going to get executed in a C program when you run it. Void just means this thing, main, takes no arguments, in this case. So I'm being super explicit. There's no strings in there, there's no commas. Void means no arguments to main. 

Now lastly, thankfully, the last two lines are familiar. Inside the curly braces we have a printf and we have a return. And the return is kind of unfortunate that we have to put it there, because in this case it's not doing all that much of interest. But in a computer program, when a function returns 0, that means all is well. Nothing went wrong. By contrast, if a function returns 1, or negative 1, or negative 1,337, or some random numbers like that, that generally means that an error actually has occurred. So if you're on your Mac or your PC, if you've ever saw some annoying message because your computer has crashed or frozen, and there's a cryptic error message, and then some code, like system code 1,2,3,4, some number, that generally is an unnecessary detail to tell most of us humans, but that is what some function or some program has actually returned, a non-zero value. And the benefit of this is that 0 means all as well, and then you essentially have an infinite number of things that can go wrong. Which is why they chose 0 for good and a non-zero value for bad, as we shall soon see. 

So let's go ahead and write this. So recall that the other day I used my Mac to open up a terminal window, and then I opened up text program, like TextEdit, and I started writing some code. Well that's fine. But your experience is going to be different on a Mac, or on a Solaris computer, a Linux computer, whatever operating system you happen to be using. And so in the course, what we instead to use is something called the CS50 Appliance. So the CS50 Appliance is a downloadable piece of software that allows you to run an operating system called Linux, specifically Fedora Linux, on your own Mac or PC. And you do this by downloading something called a hypervisor. So all of this will be documented in problem set 1. And you'll be guided toward what you need to download. But the end result, whether you have a Mac or PC, is you download some free software. You then download the CS50 Appliance, and you tell that free software--the hypervisor-- to run the CS50 Appliance in a window on your computer. And what happens is this. 

I have now, notice here, what appears to be a desktop environment. And let me actually shrink this single window. So this now is my Mac, with a little window here, and inside of this window happens to be a completely different operating system. Indeed there's this start menu down here, reminiscent of Windows, that has a whole bunch of sub menus, including a link to the CS50 manual, Dropbox, and the like. And what this environment now is a standard environment that all of us can now use, so that no matter what your computer is, what you have installed on it, what version of Mac OS or Windows you're running, we all now have the same environment. And now in this environment we can start writing some code. 

So I'm going to go ahead and open a program called gedit. This is comparable to notepad.exe, or TextEdit on a Mac. And this is just a super simple text editing program that looks like this at first glance. Now at the very top, I have a white palette, at the bottom I have this black window that says jharvard@appliance. And that's because the user account that we pre-created for everyone is called John Harvard. He has a folder where all of his files are going to go, and here's where we can start writing some code. So let me go ahead here and zoom in just a bit, and I'm going to do #include <stdio.h>, int main (void), and then I'm going to do printf("hello world") ; return 0. Now this is all quite black and white. 

Let me go ahead and do one thing to teach gedit what I'm actually doing. Let me go to Save As. I'm going to choose at the left hand side here jharvard. So again, even if you've never used Linux before, frankly these days, all of them are devolving into essentially the same type of interface-- Mac OS, Windows, and Linux. So I chose jharvard's home folder here. And I'm going to save this file as hello.c. So at the very top, I typed hello.c; naming a C program with the .c extension is what's common practice. And I hit Save. And now what's nice is that I've effectively taught gedit, that this is a C program. Notice that my black and white text is now color coded, or syntax highlighted, which just draws my attention to the different semantic parts of the program. At the top left there, as my programs get more complex, I'm going to have a summary of all of the things I have written. So that's it up there. So let me now zoom out and go down to this terminal window. 

So this is perhaps new to many people. If you've never used a command line environment, you've never used DOS, or you've never used Linux, or you've never opened your Mac OS terminal window, there's a lot of things you could do with the GUI, such as pointing, and clicking, and dragging, and dropping, and the like, but generally-- certainly in the world of computer science-- using a command line, where you don't have your mouse generally, you only have your keyboard, is actually a lot more powerful than interface, once you get acclimated to the various commands. And you sort of free yourself of needing to point and click at everything. So in gedit we'll sort of have the best of both worlds. We can drag and drop text, we can see it nice and color coded. But when it comes time to run our program, we'll sometimes just use this small window here. 

So I'm going to go ahead and do this. In the bottom black and white window, I'm going to go ahead and write clang. And clang is the name of a compiler. It's a program that converts my source code into, so, object code. 0s and 1s, that we saw briefly last week. Recall from last week, we promised that we were going to go from something like this--we needed to be something like this-- and this is certainly not something that a human's going to do manually. So instead we're going to use a program, and that program in this case is called Clang. And the name of my program is hello.c. So in order to compile hello.c from source code into object code, or 0s and 1s, it should suffice to just do this and hit Enter. 

Okay, nothing seems to have happened. But I know now, or from last week, that the default name of a program, when written in C, is foolishly called a.out. Most uninteresting name you could come up with. A is the first letter of the alphabet, out is what was outputted, but so be it. This is my program, and now dot slash, as we'll see, is actually just a sort of security feature, because a.out is a program I wrote. It didn't come with my computer, it's not in Program Files. It's not in Mac OS's Applications folder. I need to be super explicit with the computer, and say this program, a.out, is in the current folder, the current directory. And the way you represent this in an environment like this is dot represents whatever folder you are currently in. And so ./ just means run a.out in the current folder. And I run this with Enter, and voila, my very first program. 

Now let me take a step back. This window's a little small, and realize that the bottom left of the appliance here is another icon. One is Chrome, which should be quite familiar, just a web browser inside of the appliance. And this black and white icon is just a bigger terminal window. So if it gets a little annoying to sort of have just this tiny little slice of a window with which to interact with programs, we can instead do this. And now let me start typing a few soon to be familiar commands. ls. So ls is the command for listing. So in a Mac OS or Windows, you would generally double-click a folder and then, voila, you see all of the various files and folders. In a command line environment, where you can only type commands or text, ls is the equivalent. So show me what's in this directory. 

Now there's a bunch of stuff here that's both a little familiar and a little unfamiliar. But notice that just like Windows and Mac OS, jharvard has a desktop folder. So any icons that are on my desktop happen to be in that folder. There's a downloads folder, stuff that Chrome might put there. Dropbox. So the appliance comes with built-in support for Dropbox so that over the semester, you can sync with your Dropbox account so that all of your programs are backed up. They're accessible on your other computer. If anything ever goes wrong with the appliance, you can very easily recover from Dropbox. So that folder's there for that. There's two files that I made--hello.c and a.out. And then to the right there's some other folders that we'll get to toward the end of the semester, with web programming. So when I do ./, a.out, Enter, that's saying go in the directory I'm in, the current directory, and run the program called a.out right there. 

All right, so that's nice and good, but it's not all that compelling to write a program called help a.out. So we can actually do this a little differently. So instead of just running clang, hello.c, let's add what's called a command line argument. So a command line argument, or a switch in this case, is just another word or phrase that you type at a prompt after the program you want to run. So in this case, clang is the program I want to run, -o means output a file that's no longer called a.out. Output a file called hello, and do so by compiling the last word on the line, hello.c. So in short, this is a very marginal improvement, whereby instead of having this stupidly named file a.out, I can now do clang -o hello, then hello.c, and then hit Enter. Nothing seems to happen, but again much like with 0--when nothing seems to happen that means nothing wrong happened-- so let's do ls now, Enter, and indeed I now have a hello program. So if I type hello now, command not found. OK, ./. So exactly right. So because this program I wrote, and it didn't come with the computer, ./hello, Enter, means I'm now running hello. 

So that's it there. Now what we'll eventually get to more and more command line arguments that allow us to do more, but just for those for whom this might be old hat, let me actually go into a directory here and just give you a teaser of how else we could go about implementing hello world. Let me go into here, and I'm going to open it. So actually, I'm going to explain what I'm doing, so this is useful. Let me back up. 

So I've been doing this a long time. So notice over on the right there are a couple of directories that are oddly named source1m and source1w. This is just silly convention we use. Source just means source code, 1 means this is week one, and m means it's Monday, and w means it's Wednesday. So nothing cryptic there. It's just shorthand notation. These blue things are folders, otherwise known as directories. I want to go into that folder now, and on a normal computer I could just double-click on a folder icon and there's all my files. But in a command line environment, I can't quite do that, so instead, I have to change directories manually. So if I type cd and then source1m, Enter, notice that my prompt, the thing in white at left, just changed. And so indeed, when it just said parentheses and then the little squiggle, the tilde symbol, that just meant I was in John Harvard's home directory, his My Documents, his personal files. But now in parentheses it says ~/source1m. This just means I'm in a folder called source1m that's in John Harvard's home directory. So if I now want to list the files in this folder, easy question, I type just ls. And now I see all of the files that I pre-created for today's lecture, all of which, or most of which, happen to end in .c. 

So let me go ahead now and run gedit of a program called holloway.c, which is written by some random hacker on the Internet, that looks a little like this. And we are not going to go through this one in any detail, but for those more comfortable, in particular, if you want to take a guess as to what this program does here. Rest assured, whether you're less or more comfortable, we're not even get to this sort of thing by the end of this semester. This is what's an example of an obfuscated C contest, which means write the most cryptic looking program you possibly can to outdo other smart people, who are similarly trying to write things and show off that they can write more cryptic things than you. So this is not an example of a well-written program from the perspective of style, this is an example of a program that wins a contest, for people trying to be vague and abstract. 

So if we run this thing, let me go into my terminal window, so to speak. So this black and white environment is called the terminal window generally. Let me go ahead and compile it. I'm not going to use clang, because this program is a little cryptic and it needs a different compiler, one called GCC. But it does the same thing. It takes source code to object code. And now if I run a.out, that program you just saw does this. So that fellow that year won that contest. Anyhow, we're not going in that direction, per se. 

So let's actually try to now tease apart what we can do with these basic building blocks to make more and more interesting programs. So we've written a program, we've run a program. Now we can actually simplify and no longer have to write the word clang at the prompt. It turns out as our programs get more cryptic, we can, or more complex rather, we can actually run this command. So let me go back to my home directory, so to speak, let me remove--rm is the remove command--I'm going to remove the file called a.out and hello. And now notice in a command line environment, much like in a GUI, you get prompted. I can't click a button though; I have to type y for yes, y for yes. And now if I type ls again, notice that those green programs--a.out and hello-- are gone. Beware rm. It can do bad things, just like you can by dragging things to your trash. 

So now let's go ahead--and I could do this--clang -o hello, hello-- I'm already bored typing that command. Even though I typed it a little quickly. So we can instead do make hello. So make is not a compiler. It's just a friendly program that comes with Linux, in this case--the operating system-- that automates the process of compiling programs. So instead of remembering clang -o filename and then so forth, especially once those lines get longer and longer, I can just write make. And this is going to spit out a whole bunch of stuff that we'll eventually see this semester. But notice now if I type ls, hello is back in my directory. And indeed I can run it with ./hello. So make just automates the process of running what was, in this case, a much longer, more complex command. So we're going to start using make, just because it's a lot more user friendly. 

But now let's do a more interesting program than just say hello. So in the programs we've written thus far there's main. That's just the default thing that kicks everything off. But there are other functions out there as well, and stdio.h is the thing that we saw at the top of our file before, and that's what's known as the standard library. Inside of the standard library is a whole bunch of functions that someone else wrote, and we can start using these functions to write more interesting programs ourselves. 

So let me go back to the appliance. I'm going to close this terminal window. I'm going to close the things we wrote earlier, and just go into hello.c, and notice now I can do the following. Hello world is not all that interesting; I'd like to personalize this program for myself. So instead of saying world, I'm going to go ahead and say-- I could type David--but this really is sort of fundamentally the same. But let's try out this placeholder idea. Recall that in C, rather in printf, we had these placeholders, and there are more than just %d. So %d was, quick sanity check. Okay, decimal number, that's it. Decimal digits, that's all. So %c, as we will encounter, is going to be a character. Put a character here, a letter a through z, or punctuation symbol. A single character, %f, anyone know from other languages? So a floating point value. A real number. So not a decimal number--this is actually a real number with a decimal point, and some number of digits to the left and right of it. %s, string. That one we're going to see quite often. A string, again, is just a word, a phrase, a sequence of individual characters. And lastly, lld? So this is more of a corner case. Long, long decimal. So if you want not just a number that's this big, you want a bigger number, you're going to have to specify to the computer that it's of a particular size. 

So let's tweak this a little bit. Rather than just hard code in David, let me slightly dynamically say %s. So put %s here, which is a placeholder for a string. Then let me do comma, and then "David" over here. Now this is not all that intellectually interesting, because all I've done now is really create more work for the computer. Rather than tell the computer do this all at once, I'm now saying do this and insert a string here eventually, comma, here is that string. So this is not a better improvement, but it's at least a step toward a more interesting program. Because now, let me go ahead and make this window a little bigger, let me go ahead and run make hello. And now, ./a.out is not working, why? All right, now it's called hello. So again make, and also clang with a -o, renamed the program to be something more interesting. And voila: now it says hello David. 

All right, still a stupid program. So now let's actually go back here and introduce the notion of a variable. Wouldn't it be nice if I could declare a variable whose type is string? And the variable's value actually comes from the user him or herself. So arbitrarily, I'm going to call my variable s, which is just a common convention when you have one variable called the string. I'm going to do equal sign, and then I'm going to call a function called GetString. So GetString is not something that comes built into C. It's a function that the CS50 staff wrote, really just for these first couple of weeks, to simplify the process of getting user input and gaining user input in the form of strings, or numbers, and such. So GetString is like printf, but obviously rather than print it's going to do what its name says, get a string. But to use GetString, we're going to have to make a change here, beyond this. So intuitively, this program, hopefully, is going to somehow get a string from the user, and then what's it going to do with that string, called s? It's just going to print it, right? Still not a stimulating program because all it's going to do is plug in that value into where %s says it should go. 

So let's at least see this in action. Let me save and zoom out. Now in my terminal window down here, the small slice of one, let me again do make hello. Okay, and ah, damn; I got a whole bunch of errors. Let me scroll up, and we see our first-- so let's actually do this in an even bigger window so you can see how badly I screwed up-- so make hello. Okay, that's a disaster, right? I've written three lines of code, and it's given me 12 errors. So why is this? So fortunately, oftentimes when you see many, many errors spitting out at once, it's really just because you've confused the computer up here. And it remains confused by the time it gets down here. And so it just starts tripping, and stumbling, and spitting out more scary stuff than actually applies. So in general, always start with the top one. 

So the very top most instance of red, the error message is this. Use of undeclared identifier string, did I mean standard in? I did not. I meant string, but this is because, too, the word string that I keep using verbally actually doesn't exist in C either. It's something we'll use just for the first week or two here, but it exists in a file called cs50.h. So for now, know that there's this other library that the staff wrote, so it's been written more recently than stdio.h. But inside of cs50.h is a definition, a synonym of sorts, that creates this word string. 

So now let me go back to my terminal window. I'm going to clear this whole mess by Ctrl-L. We'll just wipe everything clean, and I'm going to go ahead and make hello again, Enter. So what has happened now? Now all of those errors went away. So what have I really done? I've just taught the computer that string exists, and it's in that file called cs50.h. So stop complaining, because now you know where to find that function's declaration so to speak. Where it exists in the world. 

So now I'm going to go ahead and run hello. I seem to have an infinite loop, nothing's happening. So I need to type something here, right. The first line of code in my program was GetString. So it's literally waiting for me to get a string. So in that sense yes, it is an infinite loop. Apparently in GetString is default behavior that we wrote--the staff-- that just says wait and wait and wait and wait and wait, until the user gives you a string by typing something in. So let me go ahead and type in D-a-v--i-d, Enter. And there it is, hello David. 

Now does this seem like it's just an act? Let me go ahead and type in Tommy. Enter, okay, seems to be working. Works for Rob, works for Zamyla, works for--okay. So it's going to work, most likely. So it should print out whatever we actually give it, and we can be a little difficult here. Let's see if we do something like hello. Can go over here, let's see, copy, paste. I'm not going to be able to paste that many times here. Paste, okay, Shift+Ctrl+V. So what could happen that's bad here? 

Okay, so, segfaults. So some of you with prior backgrounds will know that generally, giving computers lots of inputs when they're probably not meant to receive long names like this--bad things happen. Indeed, in the world of the web, too, this happens quite a bit, whereby when you're designing a website, when you're designing Facebook, you have to make arbitrary decisions up front, like how long will someone's Facebook username be? Or how long will someone's first name be? How long will someone's phone number be and the like. And if programmers make bad assumptions, programs break because you try giving them more output, more input rather, than they have memory. Or RAM allocated for it, and so if now I hit Enter, that program actually worked, because we were at the library and we actually anticipated this particular case. But undoubtedly this semester, you will write at least one program that will say these words. Remember this weeks from now, maybe two days from now. Segmentation fault is a bad thing. It will refer to your doing something that the computer did not anticipate. And in that case, you, the programmer, did not anticipate. Much like what this pile of socks, there were various corner cases we could have encountered. Similarly in programs if you don't anticipate how long is someone's name going to be. Or what if I have a malicious user, and his or her name is actually pretty short, but they're just trying to mess with me? What's going to be the behavior of my program? Well, in that case, something might actually crash. 

So let's do this. In 90 minutes, this is an awful long time to do computer science. Why don't we get into the habit of taking a five minute break here, and when we come back, we'll dive into some more complex and compelling programs? Five minutes. 

All right. So one quick comment. I am told that though this was on the screen before, what came out of my mouth was cs50.net/rsvp. This is correct. cs50.net/lunch. So now you may try RSVPing for this at /lunch. But let's do this now. So this has been super fast, super new for a lot of folks. Old hat for some folks. So let's rewind for just a moment, and see how we got to this hello world output just a moment ago. 

So first, there's this CS50 Appliance. Again, piece of software, problem set 1's going to tell you how to download it, where to download it, what to click and so forth. And then once you follow those instructions, you'll be able to maximize your window, and your Mac or PC will look a little something like this. A black background, a home folder at the top where all your files go, a trash can at the top left, a menu at the bottom. So again, pretty similar in spirit to Mac OS or Windows, even though it happens to be Linux. So what did we next do? Well, we started writing programs. And recall from last week that all it takes to write a program is a simple text editor, like Notepad or TextEdit. Frankly, you can even use Microsoft Word. But bad things will eventually happen, because that's a very heavy-handed solution for writing a program, plus it'll save it in the wrong file format. But it's just a text editor, a word processor, is all that's needed to write a program. 

So in the CS50 Appliance, we can do this in one simple way. We can just click on this icon at bottom left. And again, problem set 1 will advise you of this, and voila-- you get this black and white interface where we can start writing code. So let's start writing a super simple program again. I'm going to go up to File, Save, and I'm going to call this, let's say, hello2.c. And I'm just telling it by clicking on jharvard, put it in its home directory, I don't really care where this one goes. And then Save. And now I can start writing my program. And I recall from earlier that I have to write int main (void). Zoom in on top left. And then I want to say printf, take two. And now a newline, close quote, close parentheses, semicolon. And then I go down here to my terminal window that's embedded in gedit, just for convenience. And I'm going to go ahead and write make hello, but not hello alone, hello2. 

So my file's called hello2.c. My file therefore should be called hello2, in this case. Dammit, what did I do wrong? All right, so I clearly omitted a line, if you recall what previous programs look like. But let's see if we can't tease this apart. Unfortunately, most people who write the programs with which we write programs don't simplify things all that well. So we have to kind of skim over what doesn't quite make sense here and see if we can figure out what's wrong. The very first line there says implicitly declaring C library function printf with type int. OK, I understood part of that. But it seems to be alluding to the fact that I used printf wrong, somehow. And what sense is it wrong? I just didn't teach the computer that it's in a file called stdio.h. Now I only have to just memorize now that printf is in stdio.h, and indeed there'll be other functions in that same file that we'll get used to. 

So now let me go ahead and hit Ctrl-L to just clear that away, rerun make hello2, and voila. And this command again, more complex than we'll explain for today's purposes. But it did run clang, and clang takes source code and spits out 0s and 1s. And those 0s and 1s in this case are called what? Okay, object code. And the file that they're in is called, so, hello2, in this case. Because my text file was hello2.c, Enter. And now I have take two exclamation point, exclamation point, exclamation point. All right, so we have now the ability to get strings, apparently. Well, what else can we get from users? 

Well in the CS50 library, there's other functions that are going to simplify our lives in these first few days. GetChar, GetDouble, GetFloat, GetInt, GetLongLong, GetString. Well, let's pluck off the easiest of these first. GetString literally does that. It just sits there, waiting for the user to type something in, and as soon as I type something in and hit Enter, it does something with that value. So let's go back to that example to see exactly what GetString was doing. Let me go ahead and open up in gedit, hello.c, and recall that right before the break, this is where we left off. 

So let's now tease this apart in a little more detail. So on line 6, there's two things happening at the moment. The equal sign is separating first half and second half. So on the left hand side of the equal sign, we're saying string s. And then, just layman's terms, what is string s doing, do you think? It's creating a what? So it's creating a string called s. Now what does that really mean? Well, it's reserving space for a string called s. That's not quite right. What is this doing? Well computers, as you know, have hard drives; that's where your files are stored. Computers have RAM, and that's where programs are loaded while they are running. So when you double-click an icon and Microsoft Word opens up, Microsoft Word is running, so to speak, in RAM, which is the electronic part of your computer. Not the physical, mechanical part that's spinning, where data is generally stored long term. So string s is pretty much telling the computer give me enough RAM to fit a string. Now that's a bit of an oversimplification, because how big is the string going to be? Well we actually don't know yet, so in the weeks to come we'll actually pull back the layer that is string and we'll tell you what it really is. String, for now, is just a nice simplification of our world. But string s declares a string called s, for now. Declares a string. It reserves some space in RAM for the string the user is about to type. 

Now let's look in the right of the equal sign. So it says GetString(). And a little sanity check. The fact that there's nothing inside of the parentheses implies what about GetString? It takes no arguments. That is, you cannot influence its behavior in any way. Every time you use it, it will get a string and that's it. By contrast, printf, hopefully its behavior does change every time. Otherwise, it's a pretty useless printing function if it does the same thing. If it always prints David or something arbitrary all the time. So printf makes sense to have an argument. GetString doesn't really need an argument, because I wanted to get a string from the user and it's the user who's going to supply the dynamism by typing in different letters each time at the keyboard. 

So what does GetString do ultimately? Think of it as this little black box. And this black box takes no input, but when you bang on it, it spits out a string that the user has typed in. And the fact that there's an equal sign there means take what is spit out on the right and store it inside what's on the left. So equal sign here, it actually doesn't mean equality, it rather technically means assignment. Take the value on the right, and put it in the variable on the left. So that's all that's happening there. 

Now in line 7, we're calling printf. So printf hopefully is getting a little boring by now. So print a formatted string. What string? Print out, "h-e-l-l-o, %s !\n". All right, so what do I want to plug-in for %s? Literally, whatever is stored in s. So in this case, little sanity check, how many arguments does printf take? Okay, I heard one. I heard one again. Two, I heard two. And how about three? Okay, three? Excellent. Three possible answers, only one of them is correct. So arguments again influence the behavior of a function. In the past, printf did only take one argument. "hello world" was a single argument. However, now, notice where this comma is. This comma is outside of the quote/unquote, which means hey printf, here comes a second argument. 

So commas in most programming languages separate multiple arguments. So the answer here is definitely not one, because there is this comma. So minimally, printf is apparently taking two arguments this time. But the opportunity for a trick question here is what about this comma? Does this imply that there's actually three arguments? This, this, and this. So no, because that comma is inside of the quotes, which means it's really just an aesthetic of English. It has nothing to do with the number of arguments in this program. So this comma is outside of the double quotes. And then return 0. For now let's just sort of take this one on faith for today, and just know that when functions are done executing lines of code, they should generally return some value. In this case, just because main must return an int, that's just the way the language C works. 

So because nothing went wrong, feels like this program's fine, I just hard coded in return 0. But in contrast, and I'm going to write this in pseudo code now, much like Joseph did when we did the sock example last week. If something went wrong--this is not actual code--went wrong, then return, let's say, 1. Else return 0. So this is where we're going with this. This is not actual C code, just pseudocode. But this is how you might return different possible values. But for now I'm just going to go ahead and return 0. All right, any questions thus far on syntax, functionality, or the like? Yeah, in back. 

AUDIENCE: [INAUDIBLE] DAVID MALAN: Can you speak a little louder? Why did this program return 0, and? AUDIENCE: [INAUDIBLE] DAVID MALAN: Oh, that's because I got lazy, sorry. No good academic response, return 0. I can kind of salvage this, by saying technically C, if main does not explicitly return a value, 0 will be returned automatically for you. Which is true, I'm not just covering up. But, I should have done it this way. No interesting takeaway than that other than my mistake. Yeah? 

AUDIENCE: Usually when you type in void, that means you don't return something. DAVID MALAN: Correct. If instead, you specify before the name of a function, for instance here, void, then the function does not return anything. And therefore I would just say, return or nothing at all, and that would be consistent. And we'll come back to that. And just FYI, one of the catches with learning programming in a world that has hundreds of books and hundreds of websites out there is you will invariably see different syntax in different books by different people. Realize we'll do our best in sections and lectures to be consistent. But sometimes you will see conflicting syntax. So whenever in doubt, just ask. And in general, we'll take care in lectures and sections to almost always present it in the right way. And I say almost always, because case in point. Other questions? 

AUDIENCE: Does %s exist outside the appliance? DAVID MALAN: Does %s exist outside of the appliance? Yes. So %s has to do with C. The fact that we are using it in the appliance fundamentally has nothing to do with the features of the language we're using. Indeed, last week when we used my Mac, I wrote C code on my Mac. I could have used %s on my Mac, and you could use it on your Windows computer if you install a compiler, like Visual Studio from Microsoft. So %s. Everything we're doing inside of this window today has to do with C. And fundamentally nothing to do with the operating system in question. By contrast, the black and white terminal window--when I'm typing things like ls, and rm, and cd-- that has to do with the operating system and navigating around. Yeah. AUDIENCE: I meant the library, the CS50 library. DAVID MALAN: Okay, so if you mean the keyword string, that only exists in the CS50 library, correct. That does not exist in C itself, and indeed in a couple of weeks we will throw away the CS50 library and start doing things from scratch ourselves, so to speak. Other questions? Yeah. 

AUDIENCE: [INAUDIBLE] DAVID MALAN: Good question. Are the commands case sensitive? And let me make a distinction here. So commands are generally the things we'll write at the bottom of the window, in the terminal window. Anything up here would be statements or C code. But in both cases, the answer is the same, yes. Both of these environments, the C code at the top and the operating system command line at the bottom, are case sensitive. So you must capitalize GetString with capital G, capital S. You must write printf in all lowercase. You must type ls in all lowercase. So in almost every situation this semester, case will, in fact, matter. Yes. 

AUDIENCE: [INAUDIBLE] DAVID MALAN: Ah, so okay, what if we had a file called hello.d. So it turns out D is a programming language. And so in some cases, we could actually write a program in that file and have it compiled in that fashion. We can, and actually, short answer is, I don't know. So we're going to do this. Let me go ahead and create a new file. And the spin here, honestly in general, is whenever any doubt this semester, and you have your appliance or computer open, go ahead and try something. So I'm going to save a file called hello.d. Save this. And I'm going to run make hello Enter. It seemed to infer that c was more likely than d, in this case. Other questions. Yeah. 

AUDIENCE: [INAUDIBLE] DAVID MALAN: Okay, say that once more. AUDIENCE: [INAUDIBLE] DAVID MALAN: How would you go about diagnosing that or troubleshooting that? So most likely, because they're different languages, most likely you would get a completely different program outputted. You would get completely different error messages. And also just in terms of design, it would arguably be a poor design decision to be writing two different languages with almost identically named files, in the exact same directory, using an automatic tool like make. So I can also push back and say in 15 years of doing this, never made that mistake. Could happen. But there's just various, I think, logistical defenses in place. Plus the error messages that would ensue, that would eventually reveal what the issue is. But a possible corner case. 

All right, so let's introduce just a couple of other features here now, so we can start building up into more and more complex program. So first of all, math. So math examples are just kind of easy in the first week. This is not to say that all programming is about mathematics. Certainly, understanding various features of mathematics, algebra in particular, is quite relevant here. In higher level CS classes, linear algebra, calculus, and the like. But realize most of what we'll do this semester reduces not to math, and certainly not to arithmetic, per se, but really to just logic and to careful thinking. And so this linkage that computer science has long had, especially at the high school level, with mathematics, is a little misleading. Because most of the programs that we'll write, really, are sort of higher level and focus on solving problems that, sure, might use some addition, subtraction, and various mathematical formulas or the like, but at the end of the day, it's about thinking and not just implementing what you might have done on like a TI calculator in high school. 

So with that said, let's now do something with these mathematical operators that do exist so that we can trip over some of the underlying aspects of programming, or in this case C. So there are, as the CS50 library suggested, and today we're only using GetString--and in a moment perhaps one other function-- but there are different data types in a computer. At the end of the day, computers only know 0s and 1s. But recall that last week we talked about the binary system in representing numbers, like the number 0, and 1, and 2, all the way on up to 8, as in Nate's video. And then we can count much higher as we did on stage here. But if you want to represent not just numbers but letters, we, the humans, have to come up with some arbitrary conventions, whereby if at the end of the day all my computer has is the ability to express 0s and 1s, well we'd better start standardizing patterns of 0s and 1s that represent different things. A pattern of 0s and 1s that represents the letter a. Patterns of 0s and 1s that represent the letter z. Patterns of 0s and 1s that represent the color blue, or red, or the like. We need to use all of these 0s and 1s to express ourselves in different contexts, in different ways that aren't necessarily numeric. 

So in terms of representation, C has different data types, and we've seen one of these so far. We saw int, and notice what's not on the screen right now is string. String does not, in fact, exist in C. Again, it's a simplification we're presenting for the first couple of weeks. A char is an individual character. A float is a real number, with a decimal point and numbers to the left and the right of it. A double is what, for those with back prior background? So a double is twice something. Adds twice as much precision. So what does this mean? So in each of these cases, the world has sort of standardized how many bits are used to represent each of these things. So if you've watched Nate's ASCII video already for part of pset 0, or later this week you will, you'll probably know that ASCII-- character representations-- use how many bits? And you might even remember from our demo last week of how many people were on stage. So 7 or 8, typically. So generally 8, and there's something called as extended ASCII that uses all 8 bits, instead of 7. But in general, we talk in powers of 2, so in this case, 8. So a char in a programming language is usually 8 bits. So an int is generally 32 bits. A float is generally 32 bits. A double is generally 64 bits. And what does that mean? It means you can represent bigger numbers, or in the case of real numbers, you can have a lot more numbers after the decimal place. A lot more precision, in that case. Now a long long is unfortunately named. So there's an int which is 32 bits. There is a long which is, nope, 32 bits. And a long long which is 64 bits. However some of those are context sensitive; it depends what kind of computer you have. So in general, we'll specify in a homework or in a quiz when it actually matters. But the point is there's all of these different representations here. 

So let's actually dive into a program. Rather than write this one from scratch, let me go ahead and open up from today's source code--all of which is online--if you want to tinker around online, or return on Wednesday with the appliance on your computer, instructions for which will link on the course's homepage. Here's a super simple program. But it's got a little something new at the top that we didn't have before. A whole lot of blue lines of text. So these blue lines represent comments. So it's quite useful in a program to be able to write some comments to yourself, or to colleagues, or friends, or teaching fellows, that sort of describe what's going on in this file, but have nothing to do with C code itself. Nothing to do with the program functionally, it's just aesthetics. So the way you do this in C is you generally start your comments with /*, and you end your comments with */. And if you're really anal and like to draw sort of pictures, then you'd put a whole lot of stars, you'd make a little box like this. But none of that matters. The only thing that matters is the very first and the very last. This is what's called a multi-line comment. And it's just human convention to often do the stars and box things in like this if you have a lot of free time. 

So after you've written in some comments, generally, come the actual guts of the program. Here's our familiar #include <stdio.h>. And just quick, this is necessary or not necessary? AUDIENCE: Necessary. DAVID MALAN: So it's actually not necessary. So why, though, is it not necessary? So there's no printf. Indeed. All we're doing in this program is mathematics. So I can actually delete that. So you don't always have to include anything at the top of a program. 

So let's simplify this a bit. And now notice what this program does. Not much of interest. int x = 1. Well, what is this doing? Well, think back to the mental model from before. The left hand side of this expression does what? Create space for an integer. So how much space? Well, we happen to know now that it's 32 bits. Previously, a string was technically 32 bits, but more on that in the future. But an int is 32 bits. So this expression on the left here, int x just says hey operating system, give me 32 bits of RAM-- otherwise known as 4 bytes of RAM-- so that I can put an integer in that space. What integer did you want to put? Well, just the number 1. int y gets 2, does the exact same thing even though the number is bigger, in terms of its magnitude. The number itself is still just 32 bits. It's just the pattern of bits is different to represent 1 versus 2. int z now says give me another 32 bits, call it z, and put the summation of 1 and 2 in there. So that now z is presumably storing the value 3, and then return 0. 

Now this program, does it do anything of interest? So it actually doesn't do anything interesting, in any sense, because why? It's doing some math. But it's not returning the answer, right. It's returning 0. It's not printing the answer. So this program is fundamentally worthless, as it stands now. It's doing some work. It's going to take some number of seconds, or microseconds, to run, but it's not actually doing anything useful for the human. 

So let's actually now open math2, where now I'm actually printing the result. So this too can be inferred from our previous examples. If I want to do some simple mathematics, int x = 1, y = 2. z is 1 plus 2 now. What is this going to print out obviously? Just 3. So quick sanity check. Let me move into this directory. So cd source1m. Let me go ahead and type make math2. No error messages came out, so let me run-- not a.out--let me run math2. Enter. And indeed, it printed out 3. Well let's take a look at a variant of this. In math3.c, we now have this example here. 

So this one's kind of interesting. So in this one here, answer is going to get 1 divided by 10, and notice I've declared it as a float. Why do I want it to be a float? Well, it's a fraction. It's going to be a real number. So it's going to be 0.1, hopefully--10%, in this case. And what do I then want to print out? Well, this answer. Well, let's tease these apart first. So on the left-hand side, declare a float, call it answer. On the right hand side, do 1 divided by 10 and put that answer inside of the variable. Now, this line looks a little more cryptic. But notice some familiar features. % means here comes a placeholder. f means here's a floating point value, just a real number, something with a decimal point. 0.2 means what? Anyone know from prior experience? Two decimal places. So we've not seen this before, but it's just a way of exercising a little more control over printf and saying don't give me 30 points after the decimal point, instead give me just 2. 

And then let's go ahead and run this. So make math 3, and now let me run math 3, Enter. And that is not right. We seem to have encountered our first genuine bug. Well, maybe I'm just not looking close enough. So let me go up here, and let me put 20 decimal point places there. And let me compile this, make math3, run. Pretty sure 1 divided by 10 is not 0. So what's going on? Well okay, so actually it doesn't have to do with this. That's a good thought. This is really just a coincidence that we're doing this. But just to prove that this is not it, I'll return something random. Don't do this at home, because it's just wrong. But make math3, let me run it. So has nothing to do with what I'm returning, only has to do with what I'm printing. But I heard it down here. What? AUDIENCE: So we need to write the numbers in the division as-- 

DAVID MALAN: Okay good. So we need to write the numbers participating in the division here as floating point values themselves. So the problem here is as before: C, as with a lot of languages, has different data types. And those data types, for instance, are these here. And the data types in question here, when I type 1 and then I type 10, are probably what data types? So it's probably an int, right? It's definitely not a float because there's no decimal point or anything like that. So really, I have an int divided by an int. 

So the interesting thing about math and a computer is that if you're doing division using integers-- 1 divided by 10, yes is 0.1. However, when you're dividing an integer by an integer, the answer has to also be an integer just because, for now. And what's the implication then? Well, if the answer is 1 divided by 10 equals 0.1, what the computer is going to do is I have no idea how to represent 0.1, because that's a floating point value, not an integer; it's going to chop off everything after the decimal point and just show you the 0 at the beginning. And the fact that it's printing as a floating point value, it's just an aesthetic thing. That's because I'm forcing the computer to print this as a floating point value. And indeed I've declared it as a float, but the math is happening over here. 

So let me actually fix this in one pretty easy way. Why don't I just do 10.0 and 1.0, although technically I could get away with just doing one of those. Now let me go ahead and make math3. Let me go ahead and now run math3, Enter. And now, oh boy. Now we have a new problem altogether. So better, right; we're closer to 0.1, but what clearly is wrong here? Unless we've been lying to you for years, right? 1 divided by 10 is actually not quite 0.1, so what's really going on here? Well you can kind of reason through this logically. If a computer only has a finite amount of RAM to begin with, and indeed a computer only is using 32 bits for a floating point value, it stands to reason that with a finite number of bits, 32 in this case, yes, you can represent a lot of stuff. It actually is four billion different values can be represented with 32 bits, 2 to the 32, but it's still finite. So the problem is there's an infinite number of real numbers, right. If you give me a real number, I can always find you one slightly bigger, slightly less, by just tweaking the numbers that are after the decimal point. So if you don't have an infinite number of bits, you cannot possibly represent an infinite number of real numbers. 

So there's this inherent imprecision in computers, and this gets tripped over all the time even in the simplest of programs like this. But also in some very real world problems as well. In fact, let's take a moment to just take a look at something that actually happened in reality. We'll watch just the first couple of minutes, and then we'll post the link online. But this is testament to just what can go wrong, quite honestly, in a very tragic way when these things are not appreciated or just we humans make mistakes when it comes to these kinds of implementation details of modern computers. 

[VIDEO PLAYING] -We now return to engineering disasters on Modern Marvels. Computers. We've all come to accept the often frustrating problems that go with them. Bugs, viruses, and software glitches are small prices to pay for the convenience. But in high tech and high speed military and space program applications, the smallest problem can be magnified into disaster. On June 4, 1996, scientists prepared to launch an unmanned Ariane 5 rocket. It was carrying scientific satellites designed to establish precisely how the earth's magnetic field interacts with solar winds. The rocket was built for the European Space Agency and lifted off from its facility on the coast of French Guyana. 

-At about about 37 seconds into the flight, they first noticed something was going wrong, that the nozzles were swiveling in a way they really shouldn't. Around 40 seconds into the flight, clearly the vehicle was in trouble, and that's when they made the decision to destroy it. A range safety officer with tremendous guts pressed the button, blew up the rocket before it could become a hazard to public safety. 

-This was the maiden voyage of the Ariane 5, and its destruction took place because of a flaw embedded in the rocket's software. 

-The problem on the Ariane was that there was a number that requires 64 bits to express and they wanted to convert it to a 16 bit number. They assumed that the number was never going to be very big, that most of those digits in the 64 bit number were 0s. They were wrong. 

-The inability of one software program to accept the kind of number generated by another was at the root of the failure. Software development had become a very costly part of new technology. The Ariane 4 rocket had been very successful. So much of the software created for it was also used in the Ariane 5. 

-The basic problem was that the Ariane 5 was faster, accelerated faster. And the software hadn't accounted for that. 

-The destruction of the rocket was a huge financial disaster, all due to a minute software error. But this wasn't the first time data conversion problems had plagued modern rocket technology. 

DAVID MALAN: We'll leave it at that. But this is testament to just how applicable even some of these lowest level details that we've begun to explore today are. So even as you get a little distracted perhaps by some of the syntax and arcaneness here, realize that over the term we'll be focused just on how applicable this is to worlds far beyond CS. We will see you on Wednesday.