• Es importante hacer notar que el cuerpo de una expresión lambda sólo se evalúa cuando se lleva a cabo una β-reducción (es decir, cuando se aplica la expresión lambda a unos argumentos), y no antes.

• Por tanto, el cuerpo de la expresión lambda no se evalúa cuando se define la expresión.

• Por ejemplo, al evaluar la expresión:

  lambda x, y: x + y

  el intérprete no evalúa la expresión del cuerpo (x + y), sino que crea un valor de tipo «función» pero sin entrar a ver «qué hay» en el cuerpo.

  Sólo se mira lo que hay en el cuerpo cuando se aplica la expresión lambda a unos argumentos.

• En particular, podemos tener una expresión lambda como la siguiente, que sólo dará error cuando se aplique a un argumento, no antes:

  lambda x: x + 1/0

• La evaluación de la llamada a suma(4, 3) implicará realizar los siguientes tres pasos y en este orden:

  1. Sustituir el nombre de la función suma por su definición, es decir, por la expresión lambda a la cual está ligado.

  2. Evaluar los argumentos que aparecen en la llamada.

  3. Aplicar la expresión lambda a sus argumentos (β-reducción).

• Esto implica la siguiente secuencia de reescrituras:

  suma(4, 3)                    # evalúa suma y devuelve su definición
  = (lambda x, y: x + y)(4, 3)  # evalúa 4 y devuelve 4
  = (lambda x, y: x + y)(4, 3)  # evalúa 3 y devuelve 3
  = (lambda x, y: x + y)(4, 3)  # aplica la expresión lambda sus argumentos
  = (4 + 3)                     # evalúa 4 + 3 y devuelve 7
  = 7

• Como una expresión lambda es una función, aplicar una expresión lambda a unos argumentos es como llamar a una función pasándole dichos argumentos.

• Por tanto, también podemos decir que llamamos o invocamos una expresión lambda, pasándole unos argumentos durante esa llamada.

• En consecuencia, ampliamos ahora nuestra gramática de las expresiones en Python incorporando las expresiones lambda como un tipo de función:

  ⟨llamada_función⟩ ::= ⟨función⟩([⟨lista_argumentos⟩])
  ⟨función⟩ ::= identificador
                           | (⟨expresión_lambda⟩)
  ⟨expresión_lambda⟩ ::= lambda [⟨lista_parámetros⟩]: ⟨expresión⟩
  ⟨lista_parámetros⟩ ::= identificador(, identificador)*
  ⟨lista_argumentos⟩ ::= ⟨expresión⟩(, ⟨expresión⟩)*

• En detalle:

  • Línea 1: Se evalúa area, que devuelve su definición (una expresión lambda).

  • Líneas 2–4: Lo siguiente a evaluar es la aplicación de la expresión lambda de area sobre su argumento, por lo que primero evaluamos éste.

  • Línea 5: Ahora se aplica la expresión lambda a su argumento 12.

  • Línea 6: Lo siguiente que toca evaluar es el 3.1416, que ya está evaluado.

  • Línea 7: A continuación hay que evaluar la aplicación de cuadrado sobre 12. Primero se evalúa cuadrado, sustituyéndose por su definición…

  • Línea 8: … y ahora se aplica la expresión lambda a su argumento 12.

  • Lo que queda ya por evaluar es todo aritmética.

• A veces no resulta fácil determinar el orden en el que hay que evaluar las subexpresiones que forman una expresión, sobre todo cuando se mezclan funciones y operadores en una misma expresión.

• En ese caso, puede resultar útil reescribir los operadores como funciones, cuando sea posible, y luego dibujar el árbol sintático correspondiente a esa expresión, para ver a qué profundidad quedan los nodos.

• Por ejemplo, la siguiente expresión:

  abs(-12) + max(13, 28)

  se puede reescribir como:

  from operator import add
  add(abs(-12), max(13, 28))

  y si dibujáramos el árbol sintáctico veríamos que la suma está más arriba que el valor absoluto y el máximo (que están, a su vez, al mismo nivel de profundidad).

• Un ejemplo más complicado:

  abs(-12) * max((2 + 3) ** 5), 37)

  se reescribiría como:

  from operator import add, mul
  mul(abs(-12), max(pow(add(2, 3), 5), 37))

  donde se aprecia claramente que el orden de las operaciones, de más interna a más externa, sería:

  1. Suma (+ o add).

  2. Potencia (** o pow).

  3. Valor absoluto (abs) y máximo (max) al mismo nivel.

  4. Producto (* o mul).

• En el ejemplo anterior:

  lambda x, y: x + y

  los dos identificadores que aparecen en el cuerpo (x e y) aparecen también en la lista de parámetros de la expresión lambda, por lo que ambos son identificadores cuantificados y no hay ningún identificador libre.

• En cambio, en la expresión lambda:

  lambda x, y: x + y + z

  x e y son identificadores cuantificados (porque aparecen en la lista de parámetros de la expresión lambda), mientras que z es un identificador libre.

• En realidad, un identificador cuantificado y un parámetro están vinculados, hasta el punto en que podemos considerar que son la misma cosa.

• Tan sólo cambia su denominación dependiendo del lugar donde aparece su identificador en la expresión lambda:

  • Cuando aparece antes del «:», le llamamos «parámetro».

  • Cuando aparece después del «:», le llamamos «identificador cuantificado».

• Por ejemplo: en la siguiente expresión lambda:

  lambda x, y: x + y
         ┬     ┬
         │     └────── identificador cuantificado
         └── parámetro

  el identificador x aparece dos veces, pero en los dos casos representa la misma cosa. Tan sólo se llama de distinta forma («parámetro» o «identificador cuantificado») dependiendo de dónde aparece.

• A los identificadores cuantificados se les llama así porque sus posibles valores están cuantificados o restringidos a los posibles valores que puedan tomar los parámetros de la expresión lambda en cada llamada a la misma.

• Dicho valor además vendrá determinado automáticamente por la ligadura que crea el intérprete durante la llamada a la expresión lambda.

  Es decir: el intérprete liga automáticamente el identificador cuantificado al valor del correspondiente argumento durante la llamada a la expresión lambda.

• En cambio, el valor al que esté ligado un identificador libre de una expresión lambda no viene determinado por ninguna característica propia de dicha expresión lambda.

• La parte que la membrana de la cápsula expone al exterior de la misma se denomina la interfaz de la cápsula, e incluye también los puntos de entrada y salida de señales y datos antes mencionados.

• En general, la interfaz de una cápsula es todo aquello que nos permite interactuar con la cápsula desde el exterior de la misma y, en sentido contrario, también representa la forma que tiene la cápsula de mandar señales o datos al exterior.

• La cápsula tiene un espacio de nombres local que guarda las ligaduras que van dentro de la cápsula y que previenen el name clash, haciendo que una cápsula pueda contener elementos internos con el mismo nombre que otros elementos externos a la misma sin que haya conflictos.

• Una caja negra es una cápsula que:

  • expone justamente aquello que es necesario conocer para poder usarla (el qué hace), y

  • oculta todos los demás detalles internos de funcionamiento (el cómo lo hace).

• La «tapa» de la caja negra (lo que incluye su interfaz) es precisamente la barrera de separación entre el qué hace y el cómo lo hace.

• Con una caja negra sólo se puede interactuar mediante sus entradas y salidas, sin necesidad (ni posibilidad) de saber lo que hay dentro.

• Abstraer es quedarse con la idea esencial de aquello que se está estudiando. El producto resultante de ese proceso se llama abstracción.

• Por tanto, la abstracción es, al mismo tiempo, una acción y un producto:

  • Como acción, es el proceso mental que consiste en centrarse en lo que es importante y esencial en un determinado momento e ignorar los detalles que en ese momento no resultan importantes.

  • Como producto, es una cápsula que contiene un mecanismo más o menos complejo y a la que se le da un nombre. De esta forma, podemos referirnos a todo el mecanismo simplemente usando ese nombre sin tener que conocer su composición interna ni sus detalles internos de funcionamiento.

• Por tanto, para usar la abstracción nos bastará con conocer su nombre y saber qué hace, sin necesidad de saber cómo lo hace ni qué elementos la forman internamente.

• En consecuencia, las abstracciones están encapsuladas, pero no de cualquier manera, sino de forma que:

  • lo que queda visible desde el exterior de la cápsula es qué hace la abstracción, y

  • lo que se oculta en el interior es cómo lo hace.

• Creamos abstracciones para:

  • Controlar la complejidad.

  • Expresar conceptos abstractos.

  • Evitar repeticiones de código.

  • Crear casos generales a partir de patrones que se repiten.

• De hecho, por lo que respecta a area, cuadrado no representa una definición concreta de función, sino más bien la abstracción de una función, lo que se denomina una abstracción funcional, ya que a area le sirve igual de bien cualquier función que calcule el cuadrado de un número.

• Por tanto, si consideramos únicamente los valores que devuelven, las tres funciones siguientes son indistinguibles e igual de válidas para area. Ambas reciben un argumento numérico y devuelven el cuadrado de ese número:

  cuadrado = lambda x: x * x
  cuadrado = lambda x: x ** 2
  cuadrado = lambda x: x * (x - 1) + x

• En otras palabras: la definición de una función debe ser capaz de ocultar sus detalles internos de funcionamiento, ya que para usar la función no debe ser necesario conocer esos detalles.

• Por ejemplo, si queremos usar la función cubo (que calcula el cubo de un número), nos da igual que dicha función esté implementada de cualquiera de las siguientes maneras:

  cubo = lambda x: x * x * x
  cubo = lambda x: x ** 3
  cubo = lambda x: x * x ** 2

• Para usar la función, nos basta con saber que calcula el cubo de un número, sin necesidad de saber qué operaciones concretas realiza para obtener el resultado.

• Los detalles de implementación quedan ocultos y por eso también decimos que cubo es una abstracción, la cual se puede representar con una caja negra con una entrada y una salida:

• Por supuesto, nos las podemos arreglar sin definir el concepto de cubo, escribiendo siempre expresiones explícitas (como 3*3*3, 5*5*5, etc.) sin usar la palabra «cubo», pero eso nos obligaría siempre a expresarnos usando las operaciones primitivas de nuestro lenguaje (como *), en vez de poder usar términos de más alto nivel.

  Es decir: nuestros programas podrían calcular el cubo de un número, pero no tendrían la habilidad de expresar el concepto de elevar al cubo.

• Una de las habilidades que deberíamos pedir a un lenguaje potente es la posibilidad de construir abstracciones asignando nombres a los patrones más comunes, y luego trabajar directamente usando dichas abstracciones.

• Las funciones nos permiten esta habilidad, y esa es la razón de que todos los lenguajes (salvo los más primitivos) incluyan mecanismos para definir funciones.

• Por ejemplo: en el caso anterior, vemos que hay un patrón (multiplicar algo por sí mismo tres veces) que se repite con frecuencia, y a partir de él construimos una abstracción que asigna un nombre a ese patrón (elevar al cubo).

• Esa abstracción la definimos como una función que describe la regla necesaria para elevar algo al cubo.

• Esa técnica combina la abstracción con la generalización.

• De esta forma, analizando ciertos casos particulares, observamos que se repite el mismo patrón en todos ellos (es decir, abstraemos el concepto esencial), y de ahí extraemos un caso general (es decir, hacemos una generalización) que agrupa a todos los posibles casos particulares que cumplen ese patrón.

• Luego, hacemos una encapsulación, metiendo ese caso general en una «caja negra» que oculte sus detalles internos, y finalmente le damos un nombre a la «caja», con lo que acabamos creando una abstracción.

• Por ejemplo, cuando vemos que en nuestros programas es frecuente tener que multiplicar una cosa por sí misma tres veces, deducimos que ahí hay un patrón común que se repite en todos los casos.

• De ahí, creamos la abstracción que describe ese patrón general y le llamamos «elevar al cubo»:

• Ese patrón general representa a cada miembro del grupo formado por sus casos particulares, y se construye colocando un parámetro allí donde los casos particulares se diferencian entre sí (es decir, hacemos una parametrización).

• La función resultante es, al mismo tiempo:

  • una encapsulación (porque los detalles internos de la función quedan ocultos dentro del cuerpo de la expresión lambda como si fuera una caja negra),

  • una abstracción (porque se puede invocar a la función usando simplemente su nombre sin necesidad de saber cómo está hecha por dentro y, por tanto, sabiendo qué sin tener que saber cómo lo hace), y

  • una generalización (porque, al estar parametrizada, representa muchos casos particulares con un único caso general).

• Al invocar a la función, se ligan sus parámetros con los argumentos de la llamada, lo que produce un caso particular a partir del caso general.

• En resumen, el proceso conceptual sería el siguiente:

  1. Observar que hay varios casos particulares que se parecen según un patrón común y que representan el mismo concepto.

  2. Generalizar esos casos particulares y parametrizar el caso general creando una expresión lambda.

  3. Abstraer la expresión lambda dándole un nombre.

• Veamos cada paso por separado con detalle.

• Haciendo eso, deducimos un patrón común que subyace a todas esas expresiones.

• En este caso, el patrón es que en todas ellas hay «algo» que se multiplica por sí mismo tres veces.

• Al deducir ese patrón estamos realizando un proceso de abstracción, porque nos estamos centrando en lo que ahora mismo importa (es un producto de «cosas») e ignorando los detalles que ahora mismo no importan (qué son esas «cosas»).

• Ese patrón representa el concepto abstracto de «elevar al cubo».

• Ahora bien: ¿cómo se materializa ese concepto?

• Los parámetros son nombres que tomarán los valores de los argumentos aplicados a la expresión lambda. En este caso, la x es el único parámetro que tiene la expresión lambda anterior.

• Esa expresión describe el patrón común como un caso general de las expresiones anteriores, ya que representa a todos los posibles casos particulares (potencialmente infinitos) que se ajustan a ese mismo patrón. Por ese motivo decimos que es una generalización.

• Un cuantificador es un símbolo que convirte constantes en variables. En este caso, convierte las constantes 3, 5, etc. en el identificador x.

• Ese identificador está cuantificado porque está afectado por el cuantificador lambda. De lo contrario, sería un identificador libre.

• Al invocarla con un argumento concreto, el parámetro toma el valor de ese argumento y así se van obteniendo los casos particulares deseados:

  (lambda x: x * x * x)(3) → 3 * 3 * 3
  (lambda x: x * x * x)(5) → 5 * 5 * 5

• La expresión lambda puede usarse simplemente aplicando los argumentos necesarios en cada llamada, sin necesidad de manipular directamente la expresión que forma su cuerpo y que es la que lleva a cabo el procesamiento y el cálculo del resultado.

• Por eso podemos decir que la expresión lambda está encapsulada formando una caja negra con una parte expuesta, visible y manipulable desde el exterior (sus parámetros) y otra parte oculta dentro de la cápsula (su cuerpo), que no necesitaríamos manipular para poder usar la expresión lambda.

• Así, ahora podemos usar su nombre en lugar de la expresión lambda y con ello creamos una abstracción lambda:

  cubo = lambda x: x * x * x

• De ahora en adelante, podemos invocar a la función usando su nombre, sin tener que recordar incluso que debajo hay una expresión lambda concreta:

  cubo(3) → 3 * 3 * 3
  cubo(5) → 5 * 5 * 5

• La función cubo así creada es una abstracción porque:

  • Para usarla sólo basta con saber su nombre y qué hace.

  • No es necesario saber cómo lo hace.

  • Es una caja negra que expone el qué y oculta el cómo.

• Ahora ya ni siquiera tenemos que saber cómo es la expresión lambda a la que está ligada el nombre. Por tanto, trabajamos a un nivel mayor de abstracción.

• La importancia de la abstracción reside en su capacidad para ocultar detalles irrelevantes y en el uso de nombres para referenciar objetos.

• La principal preocupación del usuario de un programa (o de cada una de sus partes) es qué hace. Esto contrasta con la del programador de esa parte del programa, cuya principal preocupación es cómo lo hace.

• Los lenguajes de programación proporcionan abstracción mediante funciones (y otros elementos como procedimientos y módulos, que veremos posteriormente) que permiten al programador distinguir entre lo que hace una parte del programa y cómo se implementa esa parte.

• Una función, además, encapsula porque crea una cápsula alrededor de ella que sólo deja visible al exterior parte de su contenido; en particular, la cápsula de una función sólo deja pasar fuera lo necesario para poder usar la función, y oculta dentro todo lo demás, es decir, lo que no es necesario conocer ni manipular para usarla.

• La abstracción es esencial en la construcción de programas. Pone el énfasis en lo que algo es o hace, más que en cómo se representa o cómo funciona. Por lo tanto, es el principal medio para gestionar la complejidad en programas grandes.

• De igual importancia es la generalización.

• Mientras que la abstracción reduce la complejidad al ocultar detalles irrelevantes, la generalización la reduce al sustituir, con una sola construcción, varios elementos que realizan una funcionalidad similar.

• Los lenguajes de programación permiten la generalización mediante variables, parametrización, genéricos y polimorfismo.

• La generalización es esencial en la construcción de programas. Pone el énfasis en las similitudes entre elementos. Por lo tanto, ayuda a gestionar la complejidad al agrupar individuos y proporcionar un representante que puede utilizarse para especificar cualquier individuo del grupo.

• Generalización: Es el proceso de identificar un patrón común entre varios casos particulares y crear un modelo más general que los abarque a todos.

• Parametrización: Es el proceso de definir un elemento que representa un caso general utilizando parámetros que permiten obtener los casos particulares del caso general sin tener que reescribirlo, ligando valores concretos a los parámetros.

• Parámetro: Es una parte que cambia en cada caso particular de un patrón común.

• En resumen, creamos abstracciones:

  • Cuando queremos reducir la complejidad, dándole un nombre a un mecanismo complejo para poder referirnos a todo el conjunto a través de su nombre sin tener que recordar continuamente qué piezas contiene el mecanismo o cómo funciona éste por dentro.

  • Cuando queremos que nuestro programa pueda expresar un concepto abstracto, como el de «elevar al cubo».

  • Cuando queremos evitar repeticiones de código en nuestro programa, de forma que el mismo concepto aparezca sólo una vez, evitando problemas de inconsistencia y mantenimiento del código.

  • Cuando creamos casos generales a partir de patrones que se repiten en varios casos particulares.

• En este otro ejemplo, tenemos una expresión lambda que calcula la suma de tres números a partir de otra expresión lambda que calcula la suma de dos números:

  suma = lambda x, y: x + y
  suma3 = lambda x, y, z: suma(x, y) + z

  En este caso, hay un identificador (suma) que no aparece en la lista de parámetros de la expresión lambda ligada a suma3.

  En consecuencia, el valor de dicha expresión lambda dependerá de lo que valga suma fuera de suma3.

• Se dice que una expresión lambda es pura si, siempre que la apliquemos a unos argumentos, el valor obtenido va a depender únicamente del valor de esos argumentos o, lo que es lo mismo, del valor de sus parámetros en la llamada.

• Podemos decir que hay distintos grados de pureza:

  • Una expresión lambda en cuyo cuerpo no hay ningún identificador libre es más pura que otra que contiene identificadores libres.

  • Una expresión lambda cuyos identificadores libres representan funciones que se usan en el cuerpo de la expresión lambda, es más pura que otra cuyos identificadores libres representan cualquier otro tipo de valor.

  En el ejemplo anterior, tenemos que la expresión lambda de suma3, sin ser totalmente pura, a efectos prácticos se la puede considerar pura, ya que su único identificador libre (suma) se usa como una función.

• Por ejemplo, las siguientes expresiones lambda están ordenadas de mayor a menor pureza, siendo la primera totalmente pura:

  # producto es una expresión lambda totalmente pura:
  producto = lambda x, y: x * y
  # cuadrado es casi pura; a efectos prácticos se la puede
  # considerar pura ya que sus identificadores libres (en este
  # caso, sólo una: producto) son funciones:
  cuadrado = lambda x: producto(x, x)
  # suma es impura, porque su identificador libre (z) no es una función:
  suma = lambda x, y: x + y + z

• La pureza de una función es un rasgo deseado y que hay que tratar de alcanzar siempre que sea posible, ya que facilita el desarrollo y mantenimiento de los programas, además de simplificar el razonamiento sobre los mismos, permitiendo aplicar directamente nuestro modelo de sustitución.

• Es más incómodo trabajar con suma porque hay que recordar que depende de un valor que está fuera de la expresión lambda, cosa que no resulta evidente a no ser que mires en el cuerpo de la expresión lambda.

• Para poder usar una abstracción funcional nos basta con conocer su especificación, porque es la descripción de qué hace esa función.

• Igualmente, para poder implementar una abstracción funcional necesitamos conocer su especificación, ya que necesitamos saber qué tiene que hacer la función antes de diseñar cómo va a hacerlo.

• La especificación de una abstracción funcional describe tres características fundamentales de dicha función:

  • El dominio: el conjunto de datos de entrada válidos.

  • El rango o codominio: el conjunto de posibles valores que devuelve.

  • El propósito: qué hace la función, es decir, la relación entre su entrada y su salida.

• Hasta ahora, al especificar programas, hemos llamado «entrada» al dominio, y hemos agrupado el rango y el propósito en una sola propiedad que llamamos «salida».

• Por ejemplo, cualquier función cuadrado que usemos para implementar area debe satisfacer esta especificación:

  \begin{cases} \text{\textbf{Entrada}}: n \in \mathbb{R} \\ \texttt{cuadrado} \\ \text{\textbf{Salida}}: n^2 \end{cases}

• La especificación no concreta cómo se debe llevar a cabo el propósito. Esos son detalles de implementación que se abstraen a este nivel.

• Este esquema es el que hemos usado hasta ahora para especificar programas, y se podría seguir usando para especificar funciones, ya que éstas son consideradas subprogramas (porciones de código que forman parte de un programa y que siguen el esquema de «entrada - proceso - salida» como cualquier programa).

• Pero para especificar funciones resulta más adecuado usar el siguiente esquema, al que llamaremos especificación funcional:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & \texttt{True} \\[0.5em] & \texttt{cuadrado(\(n\):\,float)\;->\;float} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuadrado(\(n\))} = n^2 \end{array}\right.

• «Pre» representa la precondición: la propiedad que debe cumplirse justo en el momento de llamar a la función.

• «Post» representa la postcondición: la propiedad que debe cumplirse justo después de que la función haya terminado de ejecutarse.

• Lo que hay en medio es la signatura: el nombre de la función, el nombre y tipo de sus parámetros y el tipo del valor de retorno.

• La especificación se lee así: «Si se llama a la función respetando su signatura y cumpliendo su precondición, la llamada termina cumpliendo su postcondición».

• En este caso, la precondición es True, que equivale a decir que cualquier condición de entrada es buena para usar la función.

• Dicho de otra forma: no hace falta que se dé ninguna condición especial para usar la función. Siempre que la llamada respete la signatura de la función, el parámetro n puede tomar cualquier valor de tipo float y no hay ninguna restricción adicional.

• Por otro lado, la postcondición dice que al llamar a la función cuadrado con el argumento n se debe devolver n^2.

• Tanto la precondición como la postcondición son predicados, es decir, expresiones lógicas que se escriben usando el lenguaje de las matemáticas y la lógica.

• La signatura se escribe usando la sintaxis del lenguaje de programación que se vaya a usar para implementar la función (Python, en este caso).

• Recordemos la diferencia entre:

  • Dominio y conjunto origen de una función.

  • Rango (o codominio) y conjunto imagen de una función.

• ¿Cómo recoge la especificación esas cuatro características de la función?

  • La signatura expresa el conjunto origen y el conjunto imagen de la función.

  • El dominio viene determinado por los valores del conjunto origen que cumplen la precondición.

  • El codominio viene determinado por los valores del conjunto imagen que cumplen la postcondición.

• En el caso de la función cuadrado tenemos que:

  • El conjunto origen es float, ya que su parámetro n está declarado de tipo float en la signatura de la función.

    Por tanto, los datos de entrada a la función deberán pertenecer al tipo float.

  • El dominio coincide con el conjunto origen, ya que su precondición es True. Eso quiere decir que cualquier dato de entrada es válido siempre que pertenezca al dominio (en este caso, el tipo float).

  • El conjunto imagen también es float, ya que así está declarado el tipo de retorno de la función.

• Las pre y postcondiciones no es necesario escribirlas de una manera formal y rigurosa, usando el lenguaje de las Matemáticas o la Lógica.

• Si la especificación se escribe en lenguaje natural y se entiende bien, completamente y sin ambigüedades, no hay problema.

• El motivo de usar un lenguaje formal es que, normalmente, resulta mucho más conciso y preciso que el lenguaje natural.

• El lenguaje natural suele ser:

  • Más prolijo: necesita más palabras para decir lo mismo que diríamos matemáticamente usando menos caracteres.

  • Más ambiguo: lo que se dice en lenguaje natural se puede interpretar de distintas formas.

  • Menos completo: quedan flecos y situaciones especiales que no se tienen en cuenta.

• En este otro ejemplo, más completo, se especifica una función llamada cuenta:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & car \mathrel{\char`≠} \text{\texttt{""}} \land \texttt{len(}car\texttt{)} = 1 \\[0.5em] & \texttt{cuenta(\(cadena\):\,str,\;\(car\):\,str)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuenta(\(cadena\),\;\(car\))} \geq 0\ \land\\[0.1em] & \texttt{cuenta(\(cadena\),\;\(car\))} = cadena\texttt{.count(\(car\))} \end{array}\right.

• Con esta especificación, estamos diciendo que cuenta es una función que recibe una cadena y un carácter (otra cadena con un único carácter dentro).

• Ahora bien: esa cadena y ese carácter no pueden ser cualesquiera, sino que tienen que cumplir la precondición.

• Eso significa, entre otras cosas, que aquí el dominio y el conjunto origen de la función no coinciden (no todos los valores pertenecientes al conjunto origen sirven como datos de entrada válidos para la función).

• En esta especificación, count se usa como un método auxiliar.

  Las operaciones auxiliares se puede usar en una especificación siempre que estén perfectamente especificadas, aunque no estén implementadas.

• En este caso, se usa en la postcondición para decir que la función cuenta, la que se está especificando, debe devolver el mismo resultado que devuelve el método count (el cual ya conocemos perfectamente y sabemos qué hace, puesto que es un método que ya existe en Python).

• Es decir: la especificación anterior describe con total precisión que la función cuenta cuenta el número de veces que el carácter \underline{\textbf{\textit{car}}} aparece en la cadena \underline{\textbf{\textit{cadena}}}.

• En realidad, las condiciones de la especificación anterior se podrían simplificar aprovechando las propiedades de las expresiones lógicas, quedando así:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & \texttt{len(\(car\))} = 1 \\[0.5em] & \texttt{cuenta(\(cadena\):\,str,\;\(car\):\,str)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuenta(\(cadena\),\;\(car\))} = cadena\texttt{.count(\(car\))} \end{array}\right.

• Finalmente, podríamos escribir la misma especificación en lenguaje natural:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & car \text{ debe ser un único carácter} \\[0.5em] & \texttt{cuenta(\(cadena\):\,str,\;\(car\):\,str)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuenta(\(cadena\),\;\(car\))} \text{ devuelve el número de veces}\\[0.1em] & \text{que aparece el carácter } car \text{ en la cadena } cadena.\\[0.1em] & \text{Si } cadena \text{ es vacía o } car \text{ no aparece nunca en la}\\[0.1em] & \text{cadena } cadena \text{, debe devolver } 0. \end{array}\right.

• Probablemente resulta más fácil de leer (sobre todo para los novatos), pero también es más largo y prolijo.

• Es como un contrato escrito por un abogado en lenguaje jurídico.

• Una función describe la evolución local de un proceso, es decir, cómo se debe comportar el proceso durante la ejecución de la función.

• En cada paso de la ejecución se calcula el siguiente estado del proceso basándonos en el estado actual y en las reglas definidas por la función.

• Nos gustaría ser capaces de visualizar y de realizar afirmaciones sobre el comportamiento global del proceso cuya evolución local está definida por la función.

• Esto, en general, es muy difícil, pero al menos vamos a describir algunos de los modelos típicos de evolución de los procesos.

• La implementación de esa función deberá satisfacer la siguiente especificación:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & n \geq 0 \\[0.5em] & \texttt{permutas(\(n\):\,int)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{permutas(\(n\))} = \text{el número de permutaciones que}\\[0.1em] & \text{podemos formar con \(n\) elementos} \end{array}\right.

• Un programador con poca idea de programación (o muy listillo) se podría plantear una implementación parecida a la siguiente:

  permutas = lambda n: 1 if n == 0 else 1 if n == 1 else 2 if n == 2 else ...

  que se puede escribir mejor usando la barra invertida (\) para poder separar una instrucción en varias líneas:

  permutas = lambda n: 1 if n == 0 else \
                       1 if n == 1 else \
                       2 if n == 2 else \
                       6 if n == 3 else \
                       24 if n == 4 else \
                       ...                    # sigue y sigue

• Pero este algoritmo en realidad es tramposo, porque no calcula nada, sino que se limita a asociar el dato de entrada con el de salida, que se ha tenido que calcular previamente usando otro procedimiento.

• Este tipo de algoritmos se denominan algoritmos ad-hoc, y las funciones que los implementan se denominan funciones ad-hoc.

• Las funciones ad-hoc no son convenientes porque:

  • Realmente son tramposos (no calculan nada).

  • No son útiles, porque al final el cálculo se tiene que hacer con otra cosa.

  • Generalmente resulta imposible que una función de este tipo abarque todos los posibles datos de entrada, ya que, en principio, puede haber infinitos y, por tanto, su código fuente también tendría que ser infinito.

• Por ejemplo: f(n) = n + f(n + 1)

• Esta función matemática es recursiva porque aparece ella misma en su propia definición.

  Para calcular el valor de f(n) tenemos que volver a utilizar la propia función f.

• Por ejemplo: f(1) = 1 + f(2) = 1 + 2 + f(3) = 1 + 2 + 3 + f(4) = \ldots

• Cada vez que una función se llama a sí misma decimos que se realiza una llamada recursiva o paso recursivo.

• Ese punto en el que la función recursiva no se llama a sí misma, se denomina caso base, y puede haber más de uno.

• Los casos base, por tanto, determinan bajo qué condiciones la función no se llamará a sí misma, o dicho de otra forma, con qué valores de sus argumentos la función devolverá directamente un valor y no provocará una nueva llamada recursiva.

• Los demás casos, que sí provocan llamadas recursivas, se denominan casos recursivos.

• Tenemos el caso recursivo, pero necesitamos al menos un caso base para evitar que la recursión se haga infinita.

• El caso base del factorial se obtiene sabiendo que el factorial de 0 es directamente 1 (no hay que llamar al factorial recursivamente): 0! = 1

• Combinando ambos casos tendríamos:

  n! = \begin{cases} 1 & \text{si } n = 0 \text{\quad(caso base)} \\ n\cdot(n-1)! & \text{si } n > 0 \text{\quad(caso recursivo)} \end{cases}

• La especificación de una función que calcule el factorial de un número sería:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & n \geq 0 \\[0.5em] & \texttt{factorial(\(n\):\,int)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{factorial(\(n\))} = n! \end{array}\right.

• Y su implementación en Python podría ser la siguiente:

  factorial = lambda n: 1 if n == 0 else n * factorial(n - 1)

  que sería prácticamente una traducción literal de la definición recursiva de factorial que acabamos de obtener.

• En el ejemplo del factorial:

  • El caso base es fact(0), es decir, el caso en el que queremos calcular el factorial de 0, que ya vimos que es directamente 1 (sin necesidad de llamadas recursivas).

  • Si queremos resolver el problema de calcular, por ejemplo, el factorial de 5, podríamos intentar reducir el problema a calcular el factorial de 4, que es un número que está más cerca del caso base (que es 0).

  • A su vez, para calcular el factorial de 4, reduciríamos el problema a calcular el factorial de 3, y así sucesivamente.

  • De esta forma, podemos reducir el problema de calcular el factorial de n a calcular el factorial de (n - 1), que es un número que está más cerca del 0. Así, cada vez estaremos más cerca del caso base y, al final, siempre lo acabaremos alcanzando.

• En el ejemplo del factorial:

  • Supongamos que queremos calcular, por ejemplo, el factorial de 6.

  • Aún no sabemos calcular el factorial de 6, pero suponemos (por hipótesis inductiva) que sí sabemos calcular el factorial de 5.

    En ese caso, ¿cómo puedo aprovechar que sé resolver el factorial de 5 para lograr calcular el factorial de 6?

  • Analizando el problema, observo que se cumple esta propiedad: 6! = 6\cdot\overbrace{5\cdot4\cdot3\cdot2\cdot1}^{5!}=6\cdot 5!

    Por tanto, he deducido un método para resolver el problema de calcular el factorial de 6 a partir del factorial de 5: para calcular el factorial de 6 basta con calcular primero el factorial de 5 y luego multiplicar el resultado por 6.

    Dicho de otro modo: si yo supiera calcular el factorial de 5, me bastaría con multiplicarlo por 6 para obtener el factorial de 6.

• Generalizando para cualquier número, no sólo para el 6:

  • Si queremos diseñar una función fact(n) que calcule el factorial de n, supondremos que esa función ya existe pero que aún no sabe calcular el factorial de n, aunque sí sabe calcular el factorial de \pmb{(n - 1)}.

    Tenemos que creer en que es así y actuar como si fuera así, aunque ahora mismo no sea verdad. Ésta es nuestra hipótesis inductiva.

  • Por otra parte, sabemos que: n! = n\cdot\overbrace{(n-1)\cdot(n-2)\cdot(n-3)\cdot2\cdot1}^{(n-1)!}=n\cdot(n-1)!

    Por tanto, si sabemos calcular el factorial de (n - 1) llamando a fact(n - 1), para calcular fact(n) sólo necesito multiplicar n por el resultado de fact(n - 1).

    Resumiendo: si yo supiera calcular el factorial de \pmb{(n - 1)}, me bastaría con multiplicarlo por \pmb{n} para obtener el factorial de \pmb{n}.

  • Así obtengo el caso recursivo de la función fact, que sería: fact(n) = n\cdot fact(n-1)

• Combinando todos los pasos, obtenemos la solución general:

fact(n) = \begin{cases} 1 & \text{si } n = 0 \text{\quad(caso base)} \\ n\cdot fact(n-1) & \text{si } n > 0 \text{\quad(caso recursivo)} \end{cases}

• Podemos observar un perfil de expansión seguido de una contracción:

  • La expansión ocurre conforme el proceso construye una secuencia de operaciones a realizar posteriormente (en este caso, una secuencia de multiplicaciones).

  • La contracción se realiza conforme se van ejecutando realmente las multiplicaciones.

• Llamaremos proceso recursivo a este tipo de proceso caracterizado por una secuencia de operaciones pendientes de completar.

• Para poder ejecutar este proceso, el intérprete necesita memorizar, en algún lugar, un registro de las multiplicaciones que se han dejado para más adelante.

• En el cálculo de n!, la longitud de la secuencia de operaciones pendientes (y, por tanto, la información que necesita almacenar el intérprete), crece linealmente con n, al igual que el número de pasos de reducción.

  A este tipo de procesos lo llamaremos proceso recursivo lineal.

• Al igual que antes, usaremos el modelo de sustitución para visualizar el proceso del cálculo de 6!:

  factorial(6)
  = fact_iter(6, 1)
  = fact_iter(5, 6)
  = fact_iter(4, 30)
  = fact_iter(3, 120)
  = fact_iter(2, 360)
  = fact_iter(1, 720)
  = fact_iter(0, 720)
  = 720

• Este proceso no tiene expansiones ni contracciones ya que, en cada instante, toda la información que se necesita almacenar es el valor actual de los parámetros cont y acc, por lo que el tamaño de la memoria necesaria es constante.

• A este tipo de procesos lo llamaremos proceso iterativo.

• El número de pasos necesarios para calcular n! usando esta función crece linealmente con n.

  A este tipo de procesos lo llamaremos proceso iterativo lineal.

* * *

• En general, un proceso iterativo es aquel que está definido por una serie de coordenadas de estado junto con una regla fija que describe cómo actualizar dichas coordenadas conforme cambia el proceso de un estado al siguiente.

• La diferencia entre los procesos recursivo e iterativo se puede describir de esta otra manera:

  • En el proceso iterativo, los parámetros dan una descripción completa del estado del proceso en cada instante.

    Así, si parásemos el cálculo entre dos pasos, lo único que necesitaríamos hacer para seguir con el cálculo es darle al intérprete el valor de los dos parámetros.

  • En el proceso recursivo, el intérprete tiene que mantener cierta información oculta que no está almacenada en ningún parámetro y que indica qué operaciones ha realizado hasta ahora y cuáles quedan pendientes por hacer.

• No debe confundirse un proceso recursivo con una función recursiva:

  • Cuando hablamos de función recursiva nos referimos al hecho de que la función se llama a sí misma (directa o indirectamente).

  • Cuando hablamos de proceso recursivo nos referimos a la forma en como se desenvuelve la ejecución de la función (con una expansión más una contracción).

• Puede parecer extraño que digamos que una función recursiva (por ejemplo, fact_iter) genera un proceso iterativo.

  Sin embargo, el proceso es realmente iterativo porque su estado está definido completamente por dos parámetros, y para ejecutar el proceso sólo se necesita almacenar el valor de esos dos parámetros.

• Aquí hemos visto un ejemplo donde se aprecia claramente que una función sólo puede tener una especificación pero puede tener varias implementaciones distintas.

• Eso sí: todas las implementaciones de una función deben satisfacer su especificación.

• En este caso, las dos implementaciones son:

  factorial = lambda n: 1 if n == 0 else n * factorial(n - 1)

  y

  fact_iter = lambda cont, acc: acc if cont == 0 else \
                                fact_iter(cont - 1, cont * acc)
  factorial = lambda n: fact_iter(n, 1)

• Y aunque las dos satisfacen la misma especificación (y, por tanto, calculan exactamente los mismos valores), lo hacen de una forma muy diferente, generando incluso procesos de distinto tipo.

• Podemos definir una función recursiva que devuelva el n-ésimo término de la sucesión de Fibonacci:

  fib(n) = \begin{cases} 0 & \text{si } n = 0 \text{\quad (caso base)} \\ 1 & \text{si } n = 1 \text{\quad (caso base)} \\ fib(n - 1) + fib(n - 2) & \text{si } n > 1 \text{\quad (caso recursivo)} \end{cases}

• La especificación de una función que devuelva el n-ésimo término de la sucesión de Fibonacci sería:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & n \geq 0 \\[0.5em] & \texttt{fib(\(n\):\,int)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{fib(\(n\))} = \text{el \(n\)-ésimo término de la sucesión de Fibonacci} \end{array}\right.

• Y su implementación en Python podría ser:

  fib = lambda n: 0 if n == 0 else 1 if n == 1 else fib(n - 1) + fib(n - 2)

  o bien, separando la definición en varias líneas:

  fib = lambda n: 0 if n == 0 else \
                  1 if n == 1 else \
                  fib(n - 1) + fib(n - 2)

• Si vemos el perfil de ejecución de fib(5), vemos que:

  • Para calcular fib(5), antes debemos calcular fib(4) y fib(3).

  • Para calcular fib(4), antes debemos calcular fib(3) y fib(2).

  • Así sucesivamente hasta poner todo en función de fib(0) y fib(1), que se pueden calcular directamente (son los casos base).

• En general, el proceso resultante tiene forma de árbol.

• Por eso decimos que las funciones con recursividad múltiple generan procesos recursivos en árbol.

• La función anterior es un buen ejemplo de recursión en árbol, pero desde luego es un método horrible para calcular los números de Fibonacci, por la cantidad de operaciones redundantes que efectúa.

• Para tener una idea de lo malo que es, se puede observar que fib(n) crece exponencialmente en función de n.

• Por lo tanto, el proceso necesita una cantidad de tiempo que crece exponencialmente con n.

• Por otro lado, el espacio necesario sólo crece linealmente con n, porque en un cierto momento del cálculo sólo hay que memorizar los nodos que hay por encima.

• En general, en un proceso recursivo en árbol el tiempo de ejecución crece con el número de nodos del árbol mientras que el espacio necesario crece con la altura máxima del árbol.

• Se puede construir un proceso iterativo para calcular los números de Fibonacci.

• La idea consiste en usar dos coordenadas de estado a y b (con valores iniciales 0 y 1, respectivamente) y aplicar repetidamente la siguiente transformación:

  \begin{array}{l} a_{nuevo} = b_{viejo} \\[0.5em] b_{nuevo} = b_{viejo} + a_{viejo} \end{array}

• Después de n pasos, a y b contendrán fib(n) y fib(n + 1), respectivamente.

• En Python sería:

  fib_iter = lambda cont, a, b: a if cont == 0 else fib_iter(cont - 1, b, a + b)
  fib = lambda n: fib_iter(n, 0, 1)

• Esta función genera un proceso iterativo lineal, por lo que es mucho más eficiente.

• Es decir:

  • fact_iter(cont, acc) simplemente llama a:

    fact_iter(cont - 1, acc * cont)

    y luego devuelve directamente el valor que le entrega ésta llamada, sin hacer ninguna otra operación posterior antes de terminar.

  • En cambio, factorial(n) hace:

    n * factorial(n - 1)

    o sea, se llama a sí misma pero el resultado de la llamada recursiva tiene que multiplicarlo luego por n antes de devolver el resultado final.

• Por tanto, lo último que hace fact_iter es llamarse a sí misma. En cambio, lo último que hace factorial no es llamarse a sí misma, porque tiene que hacer más operaciones (en este caso, la multiplicación) antes de devolver el resultado.

• Cuando lo último que hace una función recursiva es llamarse a sí misma y devolver directamente el valor devuelto por esa llamada recursiva, decimos que la función es recursiva final o que tiene recursividad final.

• En caso contrario, decimos que la función es recursiva no final o que tiene recursividad no final.

• Las funciones recursivas finales generan procesos iterativos.

• La función fact_iter es recursiva final, y por eso genera un proceso iterativo.

• En cambio, la función factorial es recursiva no final, y por eso genera un proceso recursivo.

• En la práctica, para que un proceso iterativo consuma realmente una cantidad constante de memoria, es necesario que el traductor optimice la recursividad final.

• Ese tipo de optimización se denomina tail-call optimization (TCO).

• No muchos traductores optimizan la recursividad final.

• De hecho, ni el intérprete de Python ni la máquina virtual de Java optimizan la recursividad final.

• Por tanto, en estos dos lenguajes, las funciones recursivas finales consumen tanta memoria como las no finales.

• Las tuplas también pueden verse como un tipo de datos recursivo, ya que toda tupla t:

  • o bien es la tupla vacía, representada mediante () (caso base),

  • o bien está formada por dos partes:

    • El primer elemento de la tupla (al que se accede mediante t[0]), que hemos visto que puede ser de cualquier tipo.

    • El resto de la tupla (al que se accede mediante t[1:]), que también es una tupla (caso recursivo).

• Según el ejemplo anterior:

  >>> tupla = (27, 'hola', True, 73.4, ('a', 'b', 'c'), 99)
  >>> tupla[0]
  27
  >>> tupla[1:]
  ('hola', True, 73.4, ('a', 'b', 'c'), 99)
  >>> tupla[1:][0]
  'hola'

• Junto a las operaciones t[0] y t[1:], tenemos también la operación + (concatenación), al igual que ocurre con las cadenas.

• Con la concatenación se pueden crear nuevas tuplas a partir de otras tuplas.

• Por ejemplo:

  >>> (1, 2, 3) + (4, 5, 6)
  (1, 2, 3, 4, 5, 6)

• Eso significa que, si t es una tupla no vacía, se cumple que
  t == (t[0],) + t[1:].

  Esta propiedad es similar (aunque no exactamente igual) a la que se cumple en las cadenas no vacías.

• La forma normal de un rango es una expresión en la que se llama a la función range con los argumentos necesarios para construir el rango:

>>> range(2, 3)
range(2, 3)
>>> range(4)
range(0, 4)

>>> range(2, 5, 1)
range(2, 5)
>>> range(2, 5, 2)
range(2, 5, 2)

• El rango vacío es un valor que no tiene expresión canónica, ya que cualquiera de las siguientes expresiones representan al rango vacío tan bien como cualquier otra:

  • range(0).

  • range(a,\;a), donde a es cualquier entero.

  • range(a,\;b,\;c), donde a \geq b y c > 0.

  • range(a,\;b,\;c), donde a \leq b y c < 0.

>>> range(3, 3) == range(4, 4)
True
>>> range(4, 3) == range(3, 4, -1)
True

• Los rangos también pueden verse como un tipo de datos recursivo, ya que todo rango r:

  • o bien es el rango vacío (caso base),

  • o bien está formado por dos partes:

    • El primer elemento del rango (al que se accede mediante r[0]), que hemos visto que tiene que ser un número entero.

    • El resto del rango (al que se accede mediante r[1:]), que también es un rango (caso recursivo).

• Según el ejemplo anterior:

  >>> rango = range(4, 7)
  >>> rango[0]
  4
  >>> rango[1:]
  range(5, 7)
  >>> rango[1:][0]
  5