02 enero 2007

Cuando el software te la juega

Sobre la fragilidad de la cadena: donde todo se va al traste por un cambio de signo

Una noche de hace tres años me desperté con un amago de taquicardia. No era por problemas de salud sino porque, mientras dormía, alguna neurona seguía a lo suyo y me había avisado de que un trabajo que llevábamos meses haciendo podía estar mal. Trabajábamos elaborando cientos de simulaciones de dispersión sobre campos de vientos donde los datos eran miles de vectores medidos por el satélite QuikSCAT durante varios años. Cada vector venía definido por su módulo (velocidad del viento) y su acimut (dirección respecto al Norte geográfico). Y en mi nada pacífico sueño la neurona en vigilia me había preguntado sobre si estaba seguro de que los datos de acimut representaban hacia dónde soplaba el viento y no de dónde. Yo había asumido la primera opción en su momento en su momento y nos habíamos lanzado a una vorágine de cálculos con nuestros flamantes nuevos ordenadores multiprocesador.
En esa noche recordaba vagamente que había leido lo del sentido de los datos en uno de los informes técnicos. Pero si había metido la pata llevábamos meses trabajando sobre datos erróneos y nuestros resultados eran, por tanto, sólo basura (elegante y digital, eso sí). Con sudores fríos busqué el informe y al cabo de un rato pude dar con el párrafo que me confirmaba, menos mal, que había interpretado bien el significado de los valores.
Mi susto de medianoche acabó bien pero otros que no tuvieron tanta suerte. Según leo en el número de Science de antes de Navidad, Geoffrey Chang tenía una trayectoria profesional envidiable. Especializado en cristalografía de proteínas (¿se acuerdan del desentrañamiento de la estructura del ADN?), a los 28 años encontró empleo en un instituto de investigación de gran prestigio (Scripps Research Institute en La Jolla, California), al año siguiente recibió una medalla en la Casa Blanca que supone el máximo reconocimiento para jóvenes investigadores. Su laboratorio en el Departamento de Biología Molecular generó una serie espectacular de publicaciones sobre la estructura de proteínas de las membranas celulares…

Y de repente la pasó lo que tanto temían los galos de Asterix. Un grupo suizo publicó en Nature un artículo donde ponían en duda las estructuras de Chang y colaboradores. Estos revisaron su trabajo y acabaron descubriendo un "pequeño" problema: en uno de sus programas informáticos había un error que invertía dos columnas de datos cambiando parámetros que influían directamente en los resultados finales. Este programa había sido utilizado en varios trabajos más con lo que la catástrofe adquiría enormes dimensiones.
El escrito donde se retractan lo explica:

An in-house data reduction program introduced a change in sign for anomalous differences. This program, which was not part of a conventional data processing package, converted the anomalous pairs (I+ and I-) to (F- and F+), thereby introducing a sign change.
La expresión de Chang también fue expresiva. “I’ve been devastated”. Sus artículos siguen en las páginas de Science pero encabezados por un rótulo en rojo: This article has been retracted.
La comunidad científica ha aceptado que se trata de un error y no de un fraude pero la credibilidad del Chang Lab queda en entredicho por falta de cuidado, suficiente para quitar el sueño durante mucho tiempo y una muestra de que hay que controlar mejor las cosas.

Claro que se trataba de un programa no comercial, hecho por ellos mismos. Pero no, no crean que estamos libres de problemas con los programas comerciales. Por ejemplo, todos usamos hojas de cálculo y algunas funciones estadísticas de Excel tuvieron problemas por el diseño de los algoritmos. Microsoft informó en su momento de había “mejorado” algunos algoritmos en el tránsito de Excel 2002 a 2003 pero tal vez no resolvieron demasiado bien las cosas. Les envío a una crítica sobre el generador de números aleatorios. Yo no he sido capaz de reproducir el problema por lo que supongo que esté resuelto pero, como la duda siempre queda, pueden echar un vistazo a algunas publicaciones del European Spreadsheet Risks Interest Group que ayudan a diseñar y tomar medidas preventivas. O si quieren preocuparse de verdad miren los enlaces al final de esta página empezando, por ejemplo, por este. ¿Alguien sabe si en Open Office hay estos problemas?
Algunos estarán pensando en otras aplicaciones como SPSS, Statistica o R. No se preocupen, seguro que funcionan bien. O no. Prueben siempre que puedan con un par de aplicaciones diferentes y confirmen que los resultados son similares, especialmente si trabajan con grandes matrices, grandes números o millones de datos, que es en los extremos donde los algoritmos se la juegan.

Una de las posibles conclusiones de esta historia es que los trabajos científicos se construyen y apoyan sobre un montón de aplicaciones que suponemos funcionan bien. Esta suposición abarca desde los aparatos de medida hasta el software de cálculo. Por ejemplo, en nuestro caso usamos datos tomados por un satélite. Eso significa asumir que te fías de los ingenieros que lo diseñaron, de los procesos de calibración, de que el software de pretratamiento está bien hecho y bien aplicado... Luego, nuestra cadena de tratamiento de los datos brutos consta de 11 pasos que se realizan con programas hechos por nosotros que, a su vez, usan rutinas programadas por otros. Cada paso arranca sobre los resultados del programa anterior con lo que si existen errores, estos van a propagarse a lo largo de la cadena de forma frecuentemente imprevisible e indetectable.

Lamentablemente, no es posible comprobar fehacientemente el buen funcionamiento de todas las piezas del rompecabezas pero sí es necesario invertir tiempo en hacer pruebas básicas y evitar los errores que en inglés llaman blunders, traducible por patochadas o, en castellano castizo, cagadas. Como Geoffrey Chang.
Para terminar de forma constructiva, voy a recomendarles una aplicación estadística que funciona en MS Excel y que es magnífica, gratuita e, incluso, probablemente bien hecha: Poptools.

3 comentarios:

Jacinto Ruiz dijo...

Tal y como están las cosas,me refiero a la complejidad de los programas informáticos y a la rápida expansión del conocimiento a traves de Internet, creo que es urgente que se investigue en la corrección automática de algoritmos. Es decir, debería dotarse a los compiladores de la capacidad de verificar lógicamente la estructura del código a compilar. Eso evitaría muchos errores que luego pueden ser fatales. Uno de los mucjos errores que ya han llegado a dar problemas ha sido la muy conocida división por 0.
Miro mi bola de cristal y veo que no tardará mucho para que se invierta unagran cantidad de dinero a investigar sobre la autocorrección del código.
¿qué opinas del tema?

Ángel M. Felicísimo dijo...

Creo que la evolución irá más allá. En este post comenté una posible evolución que esencialmente era perder de vista definitivamente la imagen del programador programando letra a letra su código:
"En informática la programación de los ordenadores por ordenadores será rutina y, además,el código "evolucionará" de forma autónoma. La imagen del programador tecleando código con sus manos será tan histórica como lo son ahora las memorias de ferrita."
Esta evolución implica lo que comentas ya que esas reglas de programación incluyen obligatoriamente comprobaciones de coherencia.
Normalmente estoy rodeado de ingenieros en informática pero estamos en malas fechas para encontrar alguno y preguntarles si existe ya algún esbozo de comprobación de código. Lo haré en cuanto pille a alguno desprevenido.
Saludos

José Guerrero dijo...

En R, para Linux Debian, había un bug en el cálculo de los coeficientes de correlación cruzada para series de tiempo (hace 2-3 años). Tal problema no se manifestaba en la versión para Windows. No sé si se ha resuelto. Con relación a la generación de números aleatorios usé el algoritmo que está aquí:

http://astronu.jinr.ru/wiki/upload/d/d6/NumericalRecipesinC.pdf

Grab this Widget ~ Blogger Accessories
 
º