[MUSIC] Welcome to lesson 2 of our second course in MATLAB. Of course, we didn't learn anything in lesson one. And now we're going to get started for real, and we're going to start by revisiting functions. Of course, we spent a long time visiting functions in our first course. And believe it or not, there were still a few things about functions that we just couldn't fit in. And anyway, there were things that were just a little bit too advanced for that course. And now you're ready to advance, and I think you'll find that each lecture in this lesson covers an advanced topic that's important and fun too. Speaking of fun, if I had to pick my favorite topic of this course, recursion would be it. It's such a simple idea, and yet such a powerful idea that I can hardly wait to tell you about it. Recursion lets you solve some types of problems easily that would otherwise be extremely difficult. And if you don't know what recursion is, you had better buckle up and get ready to be amazed. Okay, so what is it? Well, it's too early to give a complete answer to that question, but we can start with this. Recursion is having a function call itself. Wait what? A function calling itself? How's that even possible? And why in the world would we want to do it anyway? Okay, well, let's slow down a little bit. We need to take this one step at a time. And the first step is to look at an example. That's the best way to show you how this amazing recursion business works. And our first example is the most popular recursion example of all. We're going to write a function that calculates the factorial by calling itself. Here you can see the traditional definition of factorial. It has two parts. Part 1 says that the factorial of 0 is 1. Part 2 says that the factorial of a positive integer n is equal to the product of all the integers from 1 to n. So for example, 3! = 1 * 2 * 3 which is six. Simple. But now let's look at this recursive definition. It's called a recursive definition because it uses recursion. It also has two parts. And Part 1 also says that the factorial of 0 is 1. But Part 2 is different. It says that the factorial of any positive integer n = n * the factorial of n- 1. And that's the recursion. Recursion is an English word derived from a Latin word which means to run back. And as we can see in this second part of the recursive definition of the factorial, we run back to the definition of the factorial again. But how can this work? You can't calculate the factorial of n unless you already know the factorial of n- 1. For example, it says that the factorial of 12 equals 12 times the factorial of 11. That's kind of cheating. And then we can't use the recursive definition to calculate the factorial of 12 unless we happen to know the factorial of 11. I don't know about you, but the factorial of 11 is not something that I carry around in my head. So the recursive definition seemed to hit a dead end. But before we give up on it completely, let's look again at that factorial of 3. As we said, the traditional definition says that it's equal to 1 * 2 * 3 which is 6. Okay, but now let's look at the recursive definition. Part 2 of the recursive definition says that the factorial of 3 = 3 * the factorial of 2. So here we go again needing to know one factorial in order to calculate another factorial. But this time, let's hit the pause button in our calculation of the factorial of 3. And while it's paused let's use the recursive definition to calculate the factorial of 2. Part 2 of the recursive definition says that the factorial of 2 = 2 * the factorial of 1. Okay, let's pause that one too. And use the recursive definition to calculate the factorial of 1. Part 2 of the recursive definition says that the factorial of 1 = 1 * the factorial of 0. Okay, let's pause that one and use the recursive definition for the factorial of 0. This time we hit part one of the recursive definition, which says that the factorial of 0 is 1. No pause necessary for that one. And now we can work backwards. We calculate 1! As 1 * 1 = 1, and 2! As 2 * 1 = 2. And finally, 3! Is 3 * 2 = 6. So to get the factorial of 3, we used our definition four times. For 3, for 2, for 1, and for 0. And guess what, 6 is the right answer. And I can hear the applause, but I'm going to wait for it to die down a bit anyway. So I hope you can see that the recursive definition is equivalent to the traditional definition. We could do the same thing with the factorial of 12. It would take us a while but we get the right answer to that one too, 479,001,600 which by an interesting coincidence is roughly my net worth. How about that? I'm not bragging mind you, I just want you to know that I don't need money. I'm teaching this course because I'm a wonderful person. But enough about me, the most interesting thing about the second definition of the factorial is that it refers to itself. A definition of a concept that refers to itself is called recursive definition. And use of a recursive definition is called recursion. Put another way, recursive is the adjective, recursion is the noun. And speaking of grammar, you'll get in trouble with your grammar teacher if you use a recursive definition of a word. Like say, Escher is the artist that created the Escher prints. That's nonsense because this description of Escher requires that you already know who Escher is. That is called circular reasoning. And our recursive definition of the factorial function seems to be circular nonsense at first too. Because the second part of it requires that you already know a factorial, but it is not circular. The crucial aspects of the recursive definition that keep it from being circular are a, that the factorial of n refers not to the factorial of n, but to the factorial of n- 1, which is closer to 0 than n. And b, the definition of the factorial of 0, which is given by the first part is not recursive. So yes, the recursive definition of the factorial of a positive integer n, requires the factorial of another integer, but it requires it only for a smaller integer. Therefore, it's not circular reasoning. It's more like spiral reasoning, because instead of going around and around in a circle we're spiraling in towards 0. And when we get there we can use the first part of the definition which conveniently defines the factorial of 0 without recursion. And then go into reverse as we did for the factorial of three until we back out to the factorial of n. Well, that took a while. But I hope that by now, I've managed to convince you that the recursive factorial definition at least works. Of course, even if I have, you're probably also convinced that recursion is just a complicated way to do a simple thing. Well, fair enough. In a few minutes, I think we'll take care of that, because we'll take a crack at a problem that is simpler to solve with recursion than without it. In the meantime, we need to tie all this to MATLAB. So let's translate this recursive definition into a recursive MATLAB function. Okay, here we are in MATLAB online. We'll assume that you know how to use MATLAB online. But if you're not familiar with it, you can learn all about it in the first lesson of our introduction to programming with MATLAB. Right over here in the current folder windows, a function called artifact which stands for recursive factorial and which implements our recursive definition of the factorial. I'm going to double-click it and there it is in the editor window. When we look at this thing, we can see that it's a direct translation of the mathematical definition in the MATLAB code. If the argument n is equal to 0 and the output argument f is set equal to 1. If n is anything else, then f is set equal to n times the factorial of n-1. In other words, if n is not 0, the function calls itself with the argument n-1. Wait a minute, how can a function call itself? They're even legal? Well, ask yourself this with Mike Fitzpatrick do something illegal? Well, of course, I wouldn't. I'm a law abiding citizen. And anyway, a function calling itself is completely legal in MATLAB. And not only in MATLAB, it's also legal in C, C++, C#, Fortran, Java, JavaScript, Python and most other languages too. This call of itself is defined as a recursive function call and it can be a very useful programming tool. And while we're defining terms of function like our fact, it makes a recursive function call is a recursive function. So we started our trip through recursion wonderland with a recursive definition. And now along the way, we've met a recursive function and implements that recursive definition. So a recursive function call is legal. That doesn't mean it makes sense, at least not yet and to make maters worse remember that input and output arguments like n and f here are local variables which means. They have local scope and local scope means these variables are accessible only to our fact. And not, for example, to whatever function happens to call our fact. But what if our fact calls our fact? What happens then? R and f accessible to r factor naught, at least can make your head spin. To keep from getting dizzy and to see what happens with local variables during a function call that's recursive, we need to take a detour. Let's start our detour by remembering the reason for local scope in the first place. The reason for local scope is to make it possible to use the same variable names inside multiple functions without a clash. How does this work? Well, let's peek under the hood. MATLAB just like most other programming languages stores local variables in a special area of memory called the stack. It's called the stack, because only its top is accessible. Think of a stack of dishes. You can't add a dish anywhere, but on top of the stack. And you can't remove a dish from anywhere, except the top of the stack. The computer stack works just like that. When a function is called, MATLAB puts the local variables for that function on top of the stack. And when the function returns, it takes them off the top of the stack. To get a little more detailed when a function is called, a new area at the top of the stack is allocated for the function to store all of its local variables. This area is called a stack frame or just a frame. Think of that frame as a dish full of variables like this. Here we're showing the stack frame of a function named my_func, which was called from the Command Window. The functions commands such as assignment statements, if statements for loops, etc., are stored in that other part of the computer memory that we call the rest of memory. But all of its variables which include x, n and z are stored in its stack frame which we are showing as a dish. Now, suppose my_func calls a function name zonk. As soon as that happens, MATLAB places a frame for zonk on top of the stack and zonk becomes the active function. Making a function active is called well, function activation. Because the active functions variable values are all recorded inside its frame, that frame is also known as an activation record. You may hear some computer scientists using that term, but we'll stick with the term frame. And speaking of computer scientists, one of them might tell you that instead of actually putting variables in those frames, only pointers to variables are stored there or that variables are added only as their assigned value. Maybe that's true, but you know what? No paying attention any of that. It doesn't make any difference. The model of a stack of dishes with variables and each dish is all you need to understand recursion. You don't need any more detail than that. Anyway, at the same instance, the zonk becomes active. My_func becomes inactive, because there can never be more than one active function at a time. Well, unless there's some sort of parallel programming going on somewhere and that is a subject for another day. When my_func becomes inactive, you might say that it's been paused like a video you're watching on MATLAB programming when you decide to take a break to watch a surfing video. Well, that MATLAB video is paused and doing nothing. The surfing video is active, showing the crashing surf and playing audio. In the same way here in our computer while my funk is paused and doing nothing, the function zonk starts running and working away with its two variables x and max. It can do anything it wants to at the variables in its frame including adding new ones. But other than one exception that we will explain when we introduce nested functions later in this course, it can't access the frame of the function that called it which in this case is my_func. The most important thing to notice though, with the stack business. Is even though zonk and my_funct both have a variable name x, there's no confusion between them. It's just like having one good looking man named Mike in the MATLAB video, and a second Mike just as good looking in the surfing video. They're different people, even though they have the same name, just like any other two amazingly handsome Mikes in the world, and there are plenty of drop dead gorgeous Mikes like that MATLAB Mike in this world. And the same holds for the X's, of course they don't look nearly as good as the Mikes in the videos. But like the Mikes and the videos, they are two separate things, separate variables, with separate values and separate frames accessed by separate functions. They're separate, get it? Changing one doesn't have any effect on the other, at all. Now let's suppose zonk completes its business and returns, what happens then? Well, at that instant MatLab removes zonk's frame from the stack, causing his local variables x and Mikes to disappear completely, and it makes my_funct active again. At that point my_funct continues exactly from where it left off before it called zonk, and it's x is waiting right there in its frame on top of the stack with the same value that it had when my_funct was paused. It's like when the surfing video ends and you unpause the programming video, at that point the programming video continues exactly from where it left off, with its own version of that drop dead gorgeous Mike, doing whatever he was doing before. Perhaps making a recursive reference to himself, you might wonder how my_funct remembers where it left off in the code so it can start from the same point exactly in the same statement. Well, that information is stored in the stack frame too, we aren't showing it on the plate, but it's in the stack frame. We also aren't showing the MATLAB copies input values in the input arguments when the function is called, and copies output values from the output arguments when it returns. But it takes care of all those details when it's adding and removing frames to and from the stack. If you want to learn more about stack frame handling, look in a book on programming languages, and if you want to learn it in great detail look for books on compilers. So that's how the stack works, but how does all this make recursion possible? Well, it does it in two ways, and we'll illustrate it with our little artifact function, which has just two local variables, n and f. First, as we've seen, the stack limits an active function's access to only its own frame, so there's no confusion when two frames on the stack have variables with the same name. And second, it generates a new stack frame every time a function is called, even if it called itself. Let's illustrate that by first imagining that my_funct calls rfact, that's just an ordinary function call, nothing special here, no recursion yet. But now get ready for the magic, abracadabra and rfact calls itself. Well, like every magic trick doesn't seem all that magical if you know how the trick is done, all that happens, is that a second frame is created for rfact. It's placed on the stack on top of the first one, and rfact starts running again from the beginning of its code. This second artifact has a brand new set of variables n and f to work with on that second frame, while the n and f belonging to the first call of rfact just sitting there in the first frame. And you can guess what happens if rfact calls itself again and again. Each call of the recursive function will get its very own new stack frame, so it will have its very own set of local variables. These variables have no relation to the variables or the other instances of the same function, even though they have the same names, because they sit in there very own stack frames. There are separate sets of variables, with separate values, and separate frames, accessed by separate activations of the same function, and are just as separate as if they belong to separate functions. By the way four stack frames is what is required when we call rfact with an input of 3, because rfact gets called four times. Once for n equals 3 at the initial call, and once each for n equals 2, 1 and 0, as we described earlier when we apply the recursive function to mentally calculate the factorial with 3. So now the fourth activation of our rfact is busily working away, while it's other three activations are all paused. Eventually the fourth rfact will finish when it does, its frame is popped off the stack, its execution ends and the third activation of rfact continues from where it left off. And when the third rfact finishes, its frame will pop off the stack, and its execution ends and so forth until we're back to my_funct. Okay, now we see the recursion can work thanks to the stack frame idea, but now it's time to see some recursion in action, let's run rfact. Okay, rfact is still here in the editor, and now I'm going to call it from the command window, let's start with an argument of 0. And then let's try 3, I don't like all this space, The vertical space I'm talking about. So I'll use format compact, And I'm going to give us more space in the command window. There, and now let's give it 12. These are all correct answers by the way, and it will work for any other number we input to it, or will it? Let's try minus 3 and let's try 2.5, minus 3 first. And 2.5, Oops, what happened here? Well first, let's read these error messages which about exactly the same. Out of memory, the likely cause is an infinite recursion within the program. Out of memory, what the heck is this all about? All we got here are two variables and they're just scalars, n and f,there is no arrays or anything big, two double precision values will fit in 16 bytes. There's no way that two lousy scalars can take up all the MATLAB's available memory which, is typically billions of bytes. And it goes on to say, error in rfact Line 5, which means that it ran out of memory while it was trying to run this command right here on line 5. Well, it ran out of memory because when we asked MATLAB to allocate space, we actually asked for just a little bit more than 16 bytes of memory, we asked for infinity. Here's what happened, As you know, every time we carry out line five, which has the recursive call, we allocate another frame on the stack and a new copy of n in it. And that's going to keep happening until we finally call our fact with n equal to 0. Now, we go into this base case on line three here, instead of the recursive case on line five. Well, what if for some reason we never hit that condition? In other words, what if n never equals 0? Well, we'll keep on calling our fact over and over and over again, never stopping. That's what happened here? When we start with n equals minus 3, and subtract 1, we get to minus 4 and then minus 5 and so on and on and on. And if we start with 2.5 and subtract 1, we get to 1.5. And then, minus 0.5 and so on and on and on. In both cases, we're getting deeper and deeper into a negative hole and friends, there is no 0 down there in that hole. This subtraction of 1 would go on forever, but each time we subtract 1 from n, we also make a recursive call to our fact. And each recursive call requires a new stack frame with a new end till we finally run out of memory in the stack. Picture a stack of say, 50 or 60,000 dishes representing frames on the stack. MATLAB runs out of memory for those frames, and gives us a bright red error message. The situation is called infinite recursion, so MATLAB is correct. And this is the most common error when writing recursive functions, is similar to infinite loops that we sometimes accidentally make with while statements. When the condition in the while statement, remember, it's true forever, and we get stuck in an infinite loop from which we can never escape. The major difference is that the while loop doesn't need a new stack frame for every iteration, so it doesn't necessarily run out of memory. So to summarize the problem, we start with a negative number, we'll never get to 0. We'll just keep subtracting 1 and getting further from 0. We'll just match straight towards negative infinity. And if we start with a positive non integer, we'll skip right over 0, and again match toward negative infinity. In both cases, we'll keep adding frames to the stack until we run out of memory. So we need to fix the function and it's really quite easy to fix. We just add a check that our input argument is not a negative number, and that it's not a fractional number. In other words, it's a non negative integer. And while we're at it, let's make sure that it's a scalar, too because our factorial definition doesn't make sense for a raise. We've done input checking before in many other situations, we just add this check at the beginning. So what are we checking here? First, we check for a non-scalar, and then we check for non integer and finally we check for a negative. And if any of these things are true, we call the error function with a message explaining the problem calling that error function ends execution and returns control to the command window. Now, let's see what happens with that negative 3. I was still getting this ugly red error message. Wait, this is actually good. This ugly red error message is our ugly red error message. And more importantly, it's a helpful message that tells the user what the actual problem is, non-negative integer scalar input expected. Now, let's test it on a non integer. And again, we've caught the error and explained it to the user. I'll let you test it with a non-scalar, okay? This is getting kind of messy, I think I'll clear the screen. [SOUND] There, let's clear the workspace. [SOUND] All right? Everything's clear. In general, when writing any recursive function, we need to be absolutely sure that we will eventually hit a condition to stop the recursion. That condition is called the base case. And the base case for our fact is that n is equal to 0, which sends us into this branch, the function right here. F equals 1, the other branch, the one in which our fax calls itself is the recursive branch. And it's reached whenever n is not equal to 0 which is the recursive case. Every recursive function has at least one base case and at least one recursive case. Most of them like our fact here have one of each. Well, we've written a robust function that can't be tricked into infinite recursion. But before we leave it, let's try four more examples. First, let's try a big input value, I don't know 170. Well, that's a really huge number written out it would require 307 digits, I must go one bigger on the input. What happened here is that we've gone beyond the biggest integer that MATLAB can store in double precision variables. And so, the answer it gives you is infinity. And of course, if you go bigger than that you're going to get infinity. For example, let's do 69,898, that's a big input. Infinity and let's go one bigger than that, 69,899. Well, here's that atom memory message again, the same one we hit when we skipped over 0, and we're heading down the infinite recursion hole. But this time our problem is not infinite recursion. There's no error in our code this time. The problem is that the input of 69,899 requires too much stack space. The MATLAB stack is pretty big, but it's not quite big enough to hold 69,900 activation records for our fact. Before we leave our fact, I want to use it to show you a couple of handy features of MATLAB. I'm going to clear everything. And now I'm going to call our fact with an input of 4. But before I do, I'm going to right-click on this dash on statement 2, select Conditional Breakpoint and a window pops up with a text box that I can type into. It explains that I can enter a condition that will be checked before line two is executed. Well, I'm going to put in n == 0, and I'm going to click OK. This is the first of the two handy features, I want to show you. It's called a conditional breakpoint. And it's marked by this yellow circle here. If you took our Introduction to Programming with MATLAB, you might remember that we set breakpoints in lesson four. And each breakpoint was marked by a little red circle. It's like a red light at an intersection, which of course means stop. And just like a car that comes to a red light, MATLAB stops when it comes to a breakpoint. But a conditional breakpoint like this one is marked with a yellow circle, and it's like a yellow light at an intersection, which used to mean check for cross traffic, slow down, and stop if you can. But nowadays it means put the pedal to the metal and roar through there like your life depends on getting through that intersection. And come to think of it It might. Meanwhile, back here in MATLAB, a conditional breakpoint means to check some condition and stop only if the condition is true. You can put any condition in there that would be valid in an if statement or a while statement. And it can be as complicated as you want, but here we just want to stop when n equals zero. We know by now from our understanding of how our fact works, and n will start out equal to four when we call it with four. And it'll decrease by one each time our fact calls itself until n equals 0 on the fifth call, at which time there should be five stack frames on the stack. Let's run it. Well, it stopped and the command window puts a K in front of the prop just as it does with an unconditional breakpoint, and it gives a line number in blue and underlined. The blue underline means that it's a link that will take you to the statement in the editor window when you click it. Here in the editor window, you can see two tiny arrows to the left of the code, a green one on top of a yellow circle pointing at line 2, and a white one pointing at line 8. We'll get to the white one in a minute. But the green arrow indicates that this is the line in this fifth call of our fact that will be executed next. Yeah, I know, it looks black. But that is just because it is on the top of this conditional breakpoint's circle. The conditional part of this conditional breakpoint is that the execution did not stop until our condition of n equals zero was true. And sure enough, over here in the workspace we can see that n does in fact equal 0. Okay, and now here comes the second handy feature that I want to show you. MATLAB lets you look at the stack. Here's how you do it. If you look up here, you'll see the label function call stack. And below it you see a box with the name of the active function, which is our fact. Now click on the down arrow over here, and you'll see the stack. It shows our fact five times, one, two, three, four, five with base at the bottom. Each of these rfacts represents one stack frame. And as we expected, there are five of them. The top of the stack is at the top. And the bottom of the stack is always base, which means the command window. So how do you see what's in one of these frames? Well, we've already noted that the variable n shows up in the workspace, and its values equals zero. This is a local variable belonging to the top stack frame. But as you will remember, each frame on the stack has its own local n. And guess what, you can look at those too. Let's look at the frame just below the current frame. That's the one for the activation of rfact that called the current activation. You remember what the value of its n is? Well, we'll see whether you're right in a minute. But before we do, I want to draw your attention to this tiny white arrow again. It's pointing at the code on line 8 to show you that the previous activation was on line 8 when it called rfact recursively to start the current activation. The arrow is white instead of green to indicate that it does not belong with the stack frame that we're looking at. Okay, now I'm going to look at this stack frame, By clicking it. Doing that shows us the previous activation, and a couple of things in it are different. First, the value of its local variable down here in the workspace is different. Now you can see whether you were right about its n value. If you said one, congratulations, you were right. The second difference is that the green arrow is now pointing at line 8 instead of the white arrow. The white arrows back up here. Okay, I hear you saying it's black, at least looks black. But it's supposed to be green. It's bright green in the installed version. And MATLAB Online is supposed to look as much as possible like the installed version and so that's what I'm calling it, green. And hey, I'm not complaining, but if you can maybe keep your voice just a little bit lower or turn your microphone down, it'd be great, because when 5000 of you say something at once, It's really deafening in my end. As much as I love having all of you taking this course, I'm having to use earplugs to protect my hearing. Anyway, green means that this is the line being executed in the activation that we're looking at. Which is activation 4. And it makes sense that it would be line 8, because that's the line that contains the recursive called rfact with the argument n-1 right here. And I forgot to mention that the command window down here also tells us it's on line 8. This information about the stack is always available to you for any set of function calls whenever execution pauses at a breakpoint. And it makes no difference whether it's the red kind of break point or the yellow kind. When execution pauses, you can click on the stack frame of any function on the stack to see its code. And a point in that code at which it is waiting and the value of its local variables. In other words, you can see the complete state of each activation. In the case of rfact here, each activation has exactly the same code and each activation other than the fifth one is paused in exactly the same line, line 8. Their only differences are their n values, which are 1, 2, 3, And 4. So we've seen all the n's and all these stack frames, but you might be wondering where their f's are. Aren't those f's local variables too? Well, yes they are. But maybe I should say yes they will be, because in MATLAB variables are created only when they're assigned values. The variable n is an input variable. And so it's assigned a value in each of these activations start. But until something is assigned to f in a given activation, it won't exist in that activation. Let's make f exist in the fifth activation. Let's execute three lines in the current activation, which is the fifth one by clicking here on Step three times. That word step means execute one line of the current activation regardless of the activation we happen to be looking at, which in this case, is the first one. Here we go. Click, click, click, and we've just executed f = 1 right here. And now over here in the workspace window, we see that f has been created and given the value 1. Remember this f belongs to the top or fifth activation in rfact. If we check the fourth activation, We will see that there's no f there yet. Because even though that activation is in the process of executing line 8, in which f will be assigned a value, f has not yet been assigned a value by this statement because the statement is still over here waiting on the return value from the recursive call to the fifth activation. If we now take three more steps, One, two, three, that fifth activation will finish and return 1. We're now looking at the fourth activation. And I can prove that by clicking the stack and counting the frames one, two, three, four, that fifth frame is gone and the fourth frame execution is in the middle of line 8. We can complete line 8 by clicking Step again. And when we do the return value of 1 is multiplied times n which also equals 1 and 1 times 1 = 1 which is assigned to f, which is immediately created in this activation and shows up in the workspace with a value of 1. You get all that don't forget to rewind button. Well, we've done a huge amount of work just to get an f in the fourth activation with a value of 1. But all this work is worth it if it's helped you understand MATLAB's brake system. And if it's helped you learn how to stop execution when a specific condition is true. How to look at the stack while execution is stopped, and why you step through the code. These two features of MATLAB's break system are extremely helpful for anyone who writes serious code, whether or not you're using recursion. And since you're enrolled in this course, you're probably going to be writing some serious code. In fact, this brake system and the fact that it's so easy to use is a big part of the reason that I use MATLAB and then I've been teaching MATLAB to so many thousands of students for over 20 years. Well, we certainly haven't stepped all the way through this process of calculating the factorial of 4. What we have gone all the way through our discussion of rfact, I suggest that you continue to step through it. And while you're doing that, you can experiment with this button here, Name Step In, which is handy when you're on a line with a function call and you want execution to stop at the first step inside that function without having to put an extra break in there. And you can try Step Out, which causes the function you're in to complete its work and return but then stops in the caller on the line where it was called again without you having to insert an extra break. I don't use them quite as much but they can be helpful too. If you continue stepping through until the first activation of rfact has returned, you'll have gotten an understanding of the brake system of the recursive factorial and of the concept of recursion itself. We spend all this time with the recursive factorial here because it's simple and easy to understand. At the same time though, it's not a very good function to show you why recursion is valuable. That's because the traditional non-recursive implementation of the factorial is even simpler. Let's take a look at the non-recursive version. First, let me end my debugging session by clicking the Quit Debugging button up here and clear this messy command window. Okay, let's have a look at the function here in the file, ifact.m. The name ifact means iterative factorial. And I'm going to double click it to load it into the editor window. And there it is. And the factorial is calculated with one very simple for loop right here. Not even an if statement is required other than the one for checking the input argument, and it works great as you can see. And as this last example shows, unlike its recursive brother rfact, ifact doesn't run out of stack space when we input 69,899. [MUSIC]
