6.3: What Happens in a Function Stays in a Function

When we launch a script (or a function) from the command window we may view this program as the "main" program (to use a somewhat archaic term). The (command-window) workspace of this main program is the set of variables of which the main program is aware (and which have been assigned at some point during the execution). When this main program calls a function, say function_name, we can view the process as the creation of a second virtual processor, as shown in Figure \(6.1\) 2. In particular, it is critical to note that the two workspaces - the variables assigned by the main program and by function_name - are distinct: the main program is unaware of the variables in workspace_function_name and function_name is unaware of the variables in workspace_command-window. The only connection between these two virtual processes are the inputs and outputs: function_name receives the inputs from the main program, and the main program receives the outputs from function_name; note the direction of the arrows - inputs are not affected by function_name. Furthermore, workspace_function_name will disappear when execution of function_name is completed and there will be no permanent record of workspace_function_name (unless of course you have written data to a file).

We make several comments. First, there are in fact ways to share variables between the workspaces (global variables), however it is best to avoid global variables if possible since with proliferation they become a sort of programming duct tape. Second, although our picture is for a main program and a function, the same picture applies when one function calls another function (which may call another function, ...). In such a case the left virtual processor is associated to the "calling program" more generally (e.g., a calling function) and the right virtual processor is associated to the "called function." Again, the critical point is that the workspaces of these two functions are distinct. Third, our picture of Figure \(6.12\) is a good mental model, but not necessarily representative of actual implementation. It is perhaps more realistic to envision an operation in which the "state" of the calling program is saved, the called function "takes over" the processor, and then the calling program is moved back in when the called function has returned control. This picture suggests that it is rather expensive to call a function, and that is indeed the case in particular in MATLAB ; for this reason, it is good to construct functions which, within their designated

Figure 6.1: Two Virtual Processors

task, compute as much data as possible with each call - for example, operate on arrays rather than scalars - so as to minimize the number of calls. (Note this is not a recommendation to put many different unrelated tasks or many lines of instructions within a single function since obviously this compromises re-use, encapsulation, and efficiency. You do not want to do too much; you just want to operate on as much data as possible.) We discuss this further below.