Sólo con el ordenador no es suficiente

Introducción

En los tiempos que corren los programas informáticos de Matemáticas son fundamentales para el trabajo de cualquier persona relacionada con ellas: estudiante, profesor, investigador…Los paquetes informáticos de los que disponemos en la actualidad (Matlab y Mathematica por ejemplo) son realmente buenos y completos. Con ellos podemos realizar todo tipo de operaciones, ya sean numéricas, simbólicas, gráficas…El potencial de estos programas es inmenso.

Visto esto mucha gente puede llegar a pensar que de una forma u otra los conocimientos matemáticos pierden importancia frente a estos programas. ¿Para qué necesitamos realizar cálculos numéricos largos y engorrosos si el programa nos los hace en muy poco tiempo y sin rechistar? ¿Por qué realizar operaciones simbólicas complicadas si el programa las resuelve con gran facilidad? ¿Por qué dibujar gráficas que siempre quedarán imperfectas cuando el programa las representa a la perfección?

Los conocimientos matemáticos son fundamentales

Pues sí, por desgracia nos equivocamos. Los conocimientos matemáticos son fundamentales aun con la existencia de estos programas. ¿La razón? Muy sencilla: porque, como todos los programas, tienen fallos. Sí, los tienen. No son perfectos. Y algunos diréis: si te refieres a los fallos numéricos (los errores lógicos que se cometen al realizar aproximaciones) no sigas, esos fallos siempre estarán. Sí, cierto. Y en realidad generalmente para nuestros cálculos esos fallos tampoco son tan importantes ya que estos programas suelen realizar aproximaciones realmente buenas. El problema viene cuando los fallos que encontramos son de concepto: a veces el ordenador no es capaz de realizar ciertas operaciones que en la práctica son relativamente sencillas y te las devuelve sin hacer; otras directamente las hace mal. Y en ocasiones hasta nos muestra auténticas barbaridades totalmente inexplicables. Lo primero es malo, pero en cierto modo se puede vivir con ello. Las otras dos opciones no son asumibles se mire por donde se mire.

Y tampoco la cosa depende de la versión del programa. Generalmente en las versiones nuevas se arreglan errores que se cometían en las antiguas, como en cualquier programa informático: cosas que antes se hacían mal ahora se hacen bien y cosas que antes no se podían hacer ahora sí se pueden al añadir funciones nuevas. Lo que no tiene mucho sentido es que en versiones nuevas se cometan errores que no aparecían en las antiguas: cosas que antes no se podían hacer o que se hacían bien ahora se hacen mal.

¿Cómo pueden ayudar los usuarios?

¿Qué podrían hacer los usuarios de estos programas para ayudar? Pues la verdad es que bien poco. Los grandes paquetes informáticos de Matemáticas no son de código abierto y por tanto los usuarios no tienen acceso al código fuente. Puede que el programador haya cometido un fallo en alguna línea de código que ocasione alguno de los errores que se producen, pero por desgracia los usuarios nunca tendrán la posibilidad ni siquiera de intentar buscar ese error. Debemos confiar a ciegas en que el programa no tenga errores. En los ejemplos siguientes veremos que no podemos tener tanta confianza, que tenemos que estar alerta y que nuestro conocimientos sobre Matemáticas serán fundamentales para no comernos ninguna pifia del programa.

Ejemplos

Este estudio se ha realizado utilizando el paquete Mathematica, de Wolfram Research. Por tanto será este programa el que se lleve las críticas, aunque ésto no signifique ni mucho menos que sea el único que tiene estos fallos. Vamos a ver unos cuantos ejemplos de cómo Mathematica comete fallos en ciertos procedimientos:

1.- Cálculo de límites

Cualquier persona con nivel de Matemáticas de Bachillerato debe saber que para que exista el límite de una función de una variable en un punto deben existir los dos límites laterales y además deben ser iguales. Mathematica afirma que:

Pero como todos sabemos esto es falso. Ese límite no existe ya que aunque los dos límites laterales existen son distintos: el límite por la izquierda vale -1 y el límite por la derecha vale 1. Lo extraño del caso es que con Mathematica podemos calcular los límites laterales por separado y éstos sí los hace bien. Conclusión: el programa nos da un resultado falso de nuestra operación.

2.- Gráficos ficticios

Mathematica realiza las gráficas dando un cierto número fijo de valores a la función que nosotros le indiquemos. Para funciones de una variable la cosa ha mejorado bastante con las nuevas versiones, pero los algoritmos utilizados para ellas son muy complicados de usar para funciones de dos variables, por lo que los desarrolladores del programa optaron por no usarlos. ¿Cuál es el problema? Pues muy sencillo: puede que por esa asignación de un número fijo de valores obtengamos gráficas que no correspondan con la realidad. Por ejemplo: si le damos una función f(x,y) cualquiera con una cierta oscilación y se da el caso de que esta función f coincide en todos los puntos usados por Mathematica con otra cierta función g(x,y) que no tenga oscilaciones obtendremos una gráfica que no corresponderá a la de la función f. Veamos un ejemplo:

Si escribimos la sentencia Plot3D[y^2+Sin[23*x],{x,0,2Pi},{y,-1,1}] Mathematica nos devuelve la siguiente gráfica:

¿No la veis rara? Pues lo es. El término Sin[23*x] debería producir oscilaciones en la gráfica, pero no las produce. Al parecer esto ocurre porque los puntos que utiliza Mathematica para representar la función están casualmente sobre una superficie con bastantes menos oscilaciones que la real. Este problema se soluciona pidiéndole a Mathematica que utilice un número distinto de puntos. Por ejemplo, con Plot3D[y^2+Sin[23*x],{x,0,2Pi},{y,-1,1},PlotPoints->50] obtenemos una gráfica más lógica:

Por tanto, aunque no parece que sea demasiado coherente teniendo en cuenta la potencia de este programa, lo mejor es probar varios valores de PlotPoints en cada caso para asegurarnos de que la gráfica es correcta. Pero, ¿y si no lo sabíamos?

3.- Simplificar

Mathematica suele ser muy cuidadoso a la hora de simplificar. Para ello dispone de dos órdenes: Simplify y FullSimplify. La primera de ellas usa ciertos métodos y no tarda mucho tiempo; la segunda utiliza más métodos que la primera pero tarda más. Un ejemplo: cualquiera de nosotros hemos utilizado muchas veces la simplificación Arcsen(sen(x))=x. Pero ésto sólo es cierto cuando:

Y Mathematica lo hace bien, devuelve la expresión sin simplificar y para que lo haga debemos indicarle que x pertenece a ese intervalo. Pero en otras ocasiones pasan cosas poco comprensibles. Veamos un par de casos:

• Cualquier persona familiarizada con las propiedades de los logaritmos puede ver de una forma muy sencilla que:

  

  Pero al escribir en Mathematica Simplify[Log[8]/Log[2]] el programa devuelve la expresión sin simplificar. Para obtener el resultado debemos utilizar la otra orden: FullSimplify[Log[8]/Log[2]]. Sí, al final el programa es capaz de simplificar, pero en una expresión tan sencilla sería esperable que Simplify lo hiciera.

• Por desgracia FullSimplify no es infalible. Mathematica es capaz de calcular factoriales y también de simplificarlos. Por ejemplo, FullSimplify[(n+1)!/n!] devuelve n+1. Perfecto, lo hace de maravilla. Entonces no se entiende cómo no es capaz de resolver FullSimplify[12345678901!/12345678900!]. Es sencillo ver que esta expresión vale 12345678901, pero Mathematica no es capaz de resolverlo. Intenta calcular los factoriales y como ve que son números demasiado grandes no los hace, pero no es capaz de cambiar de opción y simplificar primero. Como se puede ver no parece lógico.

En el artículo original hay más ejemplo sobre simplificaciones erróneas.

4.- Tratamiento de casos

Viendo lo cuidadoso que es generalmente Mathematica al simplificar extraña que otras veces no tenga en cuenta ciertos casos. Por ejemplo, es relativamente sencillo calcular la siguiente integral:

Pero Mathematica, incomprensiblemente, no valora la posibilidad de que n y m puedan ser iguales ni que puedan ser cero. Las respuestas dadas varían según la versión del programa que usemos, pero en ninguna de ellas lo hace bien.

Otro más de este tipo: Mathematica dispone del comando Solve para resolver ecuaciones y sistemas. Pero si le pedimos que nos resuelva un sistema dependiente de un parámetro no tiene en cuenta los valores del parámetro que hacen que el sistema sea compatible indeterminado o incompatible. Ni siquiera con el comando LinearSolve, específico para resolver sistemas lineales, arreglamos el problema. Necesitamos el comando Reduce para ello. No parece coherente que los desarrolladores de Mathematica esperen que los usuarios conozcamos todos los comandos relacionados con cada operación, sobre todo cuando lo que le estamos pidiendo al programa es que resuelva un sistema muy sencillo.

5.- Una gran pifia

Las integrales no se salvan de los errores. Mathematica 5.0,utilizando el comando Integrate, afirma que:

Eso es claramente imposible, ya que el integrando es siempre mayor o igual que cero y por tanto la integral no puede dar un resultado negativo. Esto se soluciona utilizando el comando NIntegrate, que nos da un valor numérico correcto:

De todas formas sigue sin ser lógico, ya que lo mejor que podía hacer el programa es devolvernos la integral sin calcular antes que darnos un valor falso. En la versión 5.1 este error está corregido.

Otras complicaciones sobre integrales:

• Hay casos en los que es capaz de calcular una integral indefinida, pero si le planteamos otra que se convertiría en la primera mediante un cambio de variable sencillo la devuelve sin calcular.
• Hay casos en los que la primitiva obtenida por el programa es muchísimo más enrevesada que la que podría calcular cualquier persona con conocimientos de integrales a mano.
• Y el error más gordo: hay casos en los que hasta llega a darnos como resultado una raíz cuadrada con un radicando negativo. Podríamos pensar que tomando la variable como compleja solucionaríamos el problema. En algunos casos es cierto, pero qué menos que el programa nos avisara de ello.

6.- Otros errores

Para terminar con los ejemplos vamos a enumerar unos cuantos más:

• Teniendo varios comandos para calcular el mismo valor en ocasiones el programa da resultados distintos en función del comando utilizado.
• A veces falla al aproximar una tabla de datos a través de ciertos conjuntos de funciones (interpolación polinómica).
• Hay casos en los que coloca las raíces de ciertas ecuaciones muy lejos de los valores reales. ¿Usa mal los métodos numéricos? ¿Le faltan algunos?
• Al calcular las raíces n-ésimas complejas de la unidad falla estrepitosamente para ciertos n conforme la versión del programa es más actual. Las versiones 3.0 y 4.1 lo suelen hacer bien, pero por ejemplo la versión 5.1 las coloca fuera de la circunferencia unidad (recordemos: las raíces n-ésimas complejas de la unidad tienen módulo 1, y por tanto deben estar sobre la circunferencia unidad).

Conclusión

Como hemos podido ver en los ejemplos anteriores los errores que pueden llegar a cometer estos programas son, en muchas ocasiones, de auténtico bulto. Además en la mayoría de los casos no recibimos ninguna señal sobre la posibilidad de que se esté cometiendo un error. Por tanto, como dijimos anteriormente, los conocimientos matemáticos del usuario que esté usando el programa en ese momento son esenciales para detectar esos errores y poder, si es posible, solventarlos. Los matemáticos podemos estar tranquilos, nuestro trabajo sigue siendo necesario.

Esta entrada se ha basado en el artículo ¿Podemos fiarnos de los cálculos efectuados con ordenador? escrito por Óscar Ciaurri y Juán Luis Varona y publicado en La Gaceta de la Real Sociedad Matemática Española correspondiente al cuatrimestre mayo-agosto de 2006.