Hay números que pueden resultar fatídicos

 

Que controlar los minúsculos detalles numéricos de los ordenadores puede cambiar el mundo lo aprendimos a principios de los 80 de la mano de Richard Pryor en la infame Superman III. Si se acuerdan, en aquel despropósito de película (que han hecho buena algunas de las últimas producciones de Marvel), el bueno de Gus Gorman (el personaje de Pryor) hackeaba el sistema de pagos de su empresa para, centimito a centimito, hacerse millonario con solo dale al ‘enter’.

Pero no todo es alegría y despilfarro en la microvida de los bits y los bytes. A veces esos redondeos, esos errores de cálculo, los pequeños disparates de la informática, traen consecuencias fatales. Se hizo muy famoso aquel error de conversión entre unidades del sistema anglosajón y del sistema decimal que llevó a la destrucción de la sonda Mars Climate Orbiter en el 99. Mucho más trágico fue el error de redondeo que llevó al fallo en un misil Patriot en Arabia Saudí en el 91 y que se llevó 28 vidas por delante, además de decenas de heridos.

Cuando la precisión es importante, o los números pueden hacerse mayores de lo previsto, los errores pueden ser fatales. Quizá recuerden la explosión de la nave Ariane 5, que explotó en el 96, cuarenta segundos después de despegar, tras una década de desarrollo y con cuatro satélites científicos a bordo. Miles de millones de dólares se fueron «a paseo», como precisó castizamente tras el desastre un delegado español de la Agencia Espacial Europea.

El desastre de la Ariane 5 se debió a un problema de desbordamiento: «overflow», como dicen los ingleses y los modernos. Déjenme que les explique. Para almacenar la información, los ordenadores usan combinaciones de ceros y unos. En concreto, para almacenar cada número entero (positivo o negativo), se usan normalmente 32 bits, o sea, una combinación de 32 ceros y unos. La mitad de esas combinaciones se destina a números negativos y la otra mitad a positivos. El mayor número positivo que se puede almacenar con 32 bits es 231-1, es decir, 2 147 483 647. Así que, si tenemos en nuestro ordenador un contador que pasa de ese numerazo al siguiente, se produce el ‘desbordamiento’ y da la vuelta al contador.

El ordenador entonces interpretará el número siguiente no como 2 147 483 648 sino como el número más pequeño que podemos almacenar con 32 bits, o sea -2 147 483 648, lo cual es una incomodidad y un desastre, la verdad. Algo así pasó con el medidor de velocidad inercial de la Ariane 5, lo que produjo un desvío de su trayectoria y que el protocolo de seguridad iniciara inmediatamente la secuencia de autodestrucción mandándolo todo «a paseo».

La cosa tiene su interés para nosotros porque resulta que los sistemas Linux y Unix, presentes en miles de ordenadores, en concreto en la mayoría de servidores de internet, tienen un contador de tiempo muy particular, cuentan el número de segundos transcurridos desde el 1 de enero de 1970. Y ese número de segundos superará los fatídicos 2 147 483 647 el día 19 de enero de 2038 a las 3 horas y 14 minutos de la mañana.

¿Qué pasará entonces? El tiempo volverá a 1901 o a 1970, dependiendo del dispositivo, y vaya usted a saber las consecuencias de eso. Ya se está trabajando en ello, aunque no es fácil de solucionar.

Dicen que la primera vez que se superó el contador del 2 147 483 647 fue con el número de visionados de Gangman Style en YouTube. En realidad aquello fue solo una broma y el contador de YouTube estaba a salvo. Pero bueno, para entonces el mal ya estaba hecho.

6 Comments ¿Qué opinas?

  1. Esto suena a la historia del cambio del año 2.000 donde se vaticinaba prácticamente el fin de una era. No creo que pase nada, en cualquier caso bastaría con cambiar el tipo de variable de entero a real donde el rango de almacenamiento va de [-1.8E308, -4.9E324] para negativos y [4.9E-324, 1.8E308] para positivos. Aún así si sirve para dar trabajo como ocurrió hace 16 años, bienvenido sea el pánico.

  2. Mejor pasar a enteros de 64bits. Los flotantes tienen «problemillas» que los hacen menos recomendables para contar en enteros, como por ejemplo que su precisión es variable -en el sentido de que tienes una cantidad limitada de dígitos significativos, que además es menor que la del entero. Por ejemplo: en un float de 32 bit, con sus aprox. 5 dígitos significativos, ya no puedes contar de 1 en 1 cuando pasas de 1 millón 🙂

    Por desgracia las cosas son bastante más complicadas cuando hay que cambiar un estándar casi-universal. Si no, ya estaría resuelto.

  3. Creo que ahora el problema es mucho nas complicado. El problema del año 2000 fue que los sistemas no guardaban el numero de milenio para ahorrar memoria. Supongo que solo ciertos tipos de sistemas usaban dicha propiedad del año y se vieron afectados. No obstante si hubo muchos errores conocidos en los sistemas. Ahora sin embargo muchisimos programas, aplicaciones, etc, realizan calculos con una funcion que devuelve justamente el tiempo desde el 1de enero de 1970. Quien sabe como estaran hechos todos estos programas que usamos diariamente, que se usan en sistemas criticos, en servidores, en sistemas gubernamentales.. Ademas sumado al hecho de que ahora el mundo esta mucho mas informatizado que antes. Por otro lado no creo que se pueda cambiar el tipo de variable asi como asi, ya que todo el software lo asume ya como un entero largo.

  4. Mmmm… estás hablando de sistemas que utilizan un Int32 para almacenar el timestamp…
    A día de hoy los lenguajes más utilizados utilizan un Int64 para todo lo que sea almacenar el timestamp, así que no me creo que de aquí a 20 años vayamos a tener realmente un problema…

    Incluso aunque la máquina sea de 32 bits si la implementación interna del sistema operativo usa un Int64 para el timestamp, creo que tenemos siglos para preocuparnos por el tema 🙂

Comments are closed.

No te pierdas...