[MUSIC] So we got in trouble calling the multable with no arguments, We got strange results when we called it with the wrong arguments. Well, how can we avoid these problems. First let's note a limitation of the function declaration. A function declaration specifies the name and the number of input and ar, output arguments. But in our head, and in our code, we make additional assumptions about our function, that aren't specified in the declaration. And we write the code and the documentation for the function, which specifies the rest. What the function does. What types of values should be in the input arguments, and what those values represent. So rather than just assuming that the caller of the function will comply with the assumptions in our code, we need to write our code so that it checks its input. If a function checks all its assumptions about its inputs and outputs, and provides a meaningful error message when they're violated, it's termed a robust function. All built in MATLAB functions are written in this way. In general, you should always check that the function is called correctly. That is, in accordance with your assumptions about the inputs and the outputs. This can make finding bugs later much easier. But how do you do it? Well we do it with the if statement. Lets make our Mult function table robust. First we check whether the function was called with at least one input. If nargin is smaller than one then no input argument was provided in that case we call the built in error function. It prints out the message we give it in red and then terminates the function. That's how easy it is and we get to print in red. That's the only way to do that. Next we check to see whether the function was called with m just as we did in the earlier version of the function but this time we add an elseif to check for the correct type of m. The type we want is a positive integer. The elseif uses a combination of three conditions. If any one of them is true, m is not a positive integer. We use the or operator to combine these conditions. The first condition uses the built in isscalar function to check whether m is a scalar. It returns true if its argument is scalar and false otherwise. So we need to use the logical negation to turn that around. By putting the tilde in front of isscalar, because not scalar is the error case. Then we check for the error m less than one, and then we check for non-integer. Here's how we do that. We use the built-in fix function, which rounds its argument to an integer. If m is not an integer then its rounded value won't be the same as m itself. If any of these conditions is true then we have an error, so we use the error function, telling the user that m needs to be a positive integer. And then error automatically quits the function. Now we repeat the same check for n that we did for m. At last, we can compute the multiplication table. It's funny how the error checking was more painful than the actual computation. That's not that unusual. But it's worth the pain now to avoid pain later when assumptions are violated during actual function calls. Finally, we compute the sum, if requested by the caller, just as we did before. And that's our new and improved, and most importantly, robust function. But we're not done. We got a robust function, but it's not a good program yet. There's more to good programming than good code. We need to include an explanation of our assumptions in human language and not just in MATLAB code. Well, can we do that? You can probably guess the answer. Yes, we can. We can do it with the help of comments. A comment is extra text that's not part of the code, so MATLAB simply disregards it. You create a comment using the percent sign. A MATLAB editor will then show that percent sign, and everything that follows it, in green. Anything after the percent sign, including the percent sign, until the end of the line becomes a comment and MATLAB ignores it. The purpose of a comment is to provide extra information for human users. You use comments to document your code. It's typically used to explain important or complicated parts of the program. For example, you should use comments at the beginning of your functions to explain what the function does. And what it's inputs are and what it's outputs are. And guess what, and this is very cool. If we do it this way, that is if we insert these comments after the function declaration but before the function code, just as shown here for the multable function. The built in help function in MATLAB will work for our function just like it does with its built in functions. It'll print out all the text we've provided in these comments. So your function will behave just like a built in function. Let's try it and see it for ourselves. Here's the improved version in the editor. You can see all the changes that we've made here. Let's ask for help with it, just as if it were a built in function. But before we do that, we hardly have any room here for our command window. I think I'll get rid of the work space over here by clicking this little arrow and clicking Close. That's gone. And maybe I can move the command window over here somewhere, like that. And let's make it a little bit bigger. I don't need as much space there. Let's get things, you can get things set up the way you like them. And then go from there. So, let's try asking for help. Look at that. It looks just like we've written a built in function. You see how you get bold type wherever you use all caps? That's just so cool. So, it tells you what you need to do. And the user feels comfortable, trying out this function. But, now we've got to see what happens if we give it the wrong input. So let's try a few things here. No inputs. Now we're printing the red stuff out. To the user must have at least one input argument. So far so good. M needs to be a positive integer. Let's give it a fraction. Hm, needs to be a positive integer. That's not an integer. It's positive, but it's not an integer. Let's give it a vector. Well, a vector is not a positive integer. Maybe we should add an error message that says, what part of positive integer do you not understand? That would just be mean, we won't do that. And anyway, we'd need to count the number of times a user called it with a bad input. How in the world would you do that? Anyway, in how is a help page that provides meaningful error messages for any inputs that violate the assumptions made about it in that help page. And does it still work correctly for valid input? Let's check that. Yeah, whew, good. We didn't break the thing when we added all that error checking. [MUSIC] You know, I think we can congratulate ourselves now. We've written a function that's robust, and does what it says it'll do. [MUSIC]