When you start writing longer programs, you might spend more time debugging. So we’ll end this chapter with some debugging tips.
More Name Collisions
Functions and variables occupy the same workspace, which means that whenever a name appears in an expression, MATLAB starts by looking for a variable with that name; if there isn’t one, it looks for a function.
As a result, if you have a variable with the same name as a function, the variable shadows the function; metaphorically, you can’t see the function because the variable is in the way.
For example, if you assign a value to sin and then try to use the sin function, you might get an error:
>> sin = 3;
>> sin(5)
Index exceeds the number of array elements (1).
'sin' appears to be both a function and a variable.
If this is unintentional, use 'clear sin' to remove
the variable 'sin' from the workspace.
Since the value we assigned to sin is a number, and a number is considered a \(1 \times 1\) matrix, MATLAB tries to access the fifth element of the matrix and finds that there isn’t one.
In this case, MATLAB is able to detect the error, and the error message is pretty helpful. But if the value of sin were a vector, or if the argument were smaller, you would be in trouble. For example,
>> sin = 3;
>> sin(1)
ans = 3
Just to review, the sine of 1 is not 3!
You can avoid these problems by choosing function names carefully. Use long, descriptive names for functions, not single letters like f. To be even clearer, use function names that end in func. And before you define a function, check whether MATLAB already has a function with the same name.
Debugging Your Head
When you’re working with a new function or a new language feature for the first time, you should test it in isolation before you put it into your program.
For example, suppose you know that x is the sine of some angle and you want to find the angle. You find the MATLAB function asin, and you’re pretty sure it computes the inverse sine function. Pretty sure is not good enough; you want to be very sure.
Since we know \(\sin 0 = 0\), we could try
>> asin(0)
ans = 0
which is correct. Now, we also know that the sine of \(90^{\circ }\) is 1, so if we try asin(1), we expect the answer to be 90, right?
>> asin(1)
ans = 1.5708
Oops. We forgot that the trig functions in MATLAB work in radians, not degrees. The answer we got is \(\pi/2\), which is \(90^{\circ }\), in radians.
With this kind of testing, you’re not really checking for errors in your program; you’re checking your understanding. If you make an error because you are confused about how MATLAB works, it might take a long time to find, because when you look at the code, it looks right.
Which brings us to the Seventh Theorem of Debugging:
The worst bugs aren’t in your code; they’re in your head.
