6.3: Lo que sucede en una función permanece en una función

Cuando lanzamos un script (o una función) desde la ventana de comandos podemos ver este programa como el programa “principal” (para usar un término algo arcaico). El espacio de trabajo (ventana de comandos) de este programa principal es el conjunto de variables de las que el programa principal es consciente (y que han sido asignadas en algún momento durante la ejecución). Cuando este programa principal llama a una función, digamos nombre_función, podemos ver el proceso como la creación de un segundo procesador virtual, como se muestra en la Figura\(6.1\) 2. En particular, es fundamental señalar que los dos espacios de trabajo -las variables asignadas por el programa principal y por nombre_función- son distintas: el programa principal desconoce las variables en workspace_function_name y function_name desconoce las variables en workspace_command-window. La única conexión entre estos dos procesos virtuales son las entradas y salidas: nombre_función recibe las entradas del programa principal, y el programa principal recibe las salidas de nombre_función; tenga en cuenta la dirección de las flechas - las entradas no se ven afectadas por nombre_función. Además, workspace_function_name desaparecerá cuando se complete la ejecución de nombre_función y no habrá registro permanente de workspace_function_name (a menos que, por supuesto, haya escrito datos en un archivo).

Hacemos varios comentarios. Primero, de hecho hay formas de compartir variables entre los espacios de trabajo (variables globales), sin embargo lo mejor es evitar las variables globales si es posible ya que con la proliferación se convierten en una especie de cinta aislante de programación. En segundo lugar, aunque nuestra imagen es para un programa principal y una función, la misma imagen se aplica cuando una función llama a otra función (que puede llamar a otra función,...). En tal caso, el procesador virtual izquierdo está asociado al “programa de llamada” de manera más general (por ejemplo, una función de llamada) y el procesador virtual derecho está asociado a la “función llamada”. Nuevamente, el punto crítico es que los espacios de trabajo de estas dos funciones son distintos. Tercero, nuestra imagen de Figura\(6.12\) es un buen modelo mental, pero no necesariamente representativo de la implementación real. Quizás sea más realista visualizar una operación en la que se guarde el “estado” del programa llamante, la función llamada “se haga cargo” del procesador, y luego el programa llamante vuelva a entrar cuando la función llamada haya devuelto el control. Esta imagen sugiere que es bastante caro llamar a una función, y ese es efectivamente el caso en particular en MATLAB; por esta razón, es bueno construir funciones que, dentro de sus designadas

Figura 6.1: Dos procesadores virtuales

tarea, calcular la mayor cantidad de datos posible con cada llamada -por ejemplo, operar en matrices en lugar de escalares- para minimizar el número de llamadas. (Tenga en cuenta que esto no es una recomendación para poner muchas tareas diferentes no relacionadas o muchas líneas de instrucciones dentro de una sola función, ya que obviamente esto compromete la reutilización, la encapsulación y la eficiencia. No quieres hacer demasiado; solo quieres operar con la mayor cantidad de datos posible). Discutimos esto más adelante.