Portada
mis comunidades
otras secciones
#10:
#3 No creo. Durante la primera guerra del golfo los U2 seguían funcionando. Saddam no tenía nada con qué derribarlos (sus defensas antiaéreas fueron destruidas en las primeras horas de la guerra). El SR-71 sólo tenía sentido para sobrevolar la URSS o países igualmente bien definidos. Y en los años 80 la tecnología de imágenes por satélite podía sustituirlo con ventaja.
El problema con los Scud venía más bien del hecho de que las plataformas de lanzamiento son móviles (remolcadas), y que se tarda bien poco en levantar y lanzar uno de esos cacharros (no son nada sofisticados... vienen a ser una V-2 mejorada). Y el desierto es enorme... tenía que darse la casualidad de que un avión de observación pasara por el lugar preciso en el momento adecuado. Si era así, la plataforma estaba condenada.
#9 Va a ser que no. Los misiles usados por Irak en la primera guerra del golfo eran de tipo SCUD-B, de fabricación soviética (denominación R-17 o R-300), "mejorados" localmente. Los franceses y los americanos le vendieron otras cositas, pero no misiles Scud.
El problema con los Scud venía más bien del hecho de que las plataformas de lanzamiento son móviles (remolcadas), y que se tarda bien poco en levantar y lanzar uno de esos cacharros (no son nada sofisticados... vienen a ser una V-2 mejorada). Y el desierto es enorme... tenía que darse la casualidad de que un avión de observación pasara por el lugar preciso en el momento adecuado. Si era así, la plataforma estaba condenada.
#9 Va a ser que no. Los misiles usados por Irak en la primera guerra del golfo eran de tipo SCUD-B, de fabricación soviética (denominación R-17 o R-300), "mejorados" localmente. Los franceses y los americanos le vendieron otras cositas, pero no misiles Scud.
#22:
Esto me recuerda (aunque con consecuencias menos graves para la integridad humana, no así para la integridad de mi curriculum académico) a unas prácticas de computación numérica en la facultad.
Se hacían en FORTRAN, ese moderno lenguaje de programación orientado a matemáticas, y recalco lo de "orientado" y "matemáticas". No me acuerdo cuál era el algoritmo que había que programar, pero era uno de estos que dadas una función y un intervalo, te indicaba el número de raíces de la función en dicho intervalo (nota para el que no lo sepa: una raíz de una función es donde el valor de esta es cero). Y sí, se supone que tiene su utilidad.
La cosa es que había un punto del código en el que, después de unas cuantas operaciones, tenías que comparar el resultado que te daba con 0, en cuyo caso se ejecutaba el código A, y si no se ejecutaba B. Y el problema era que siempre ejecutaba B. Por más que ponía ejemplos sabidos, por más que puse flags por todo el código a ver dónde la pifiaba (porque, mayormente, se trataba de informática, y lo de programar lo llevaba bien), por más que hice todo tipo de pruebas, no hubo narices a encontrar qué fallaba. Y sabía que mi código estaba bien. Lo sabía.
Así que se lo comenté al profesor en una tutoría y nos pusimos a revisar el código. Cuando le dije que estaba seguro de que mi código estaba bien... sonrió, pero cuando vio que no había por dónde atacarle a mi código, y tras una media hora haciendo pruebas, descubrimos que, después de hacer aquellas operaciones cuyo resultado había que comparar con 0, resulta que los números nunca daban exactamente cero, sino que, tras varios ejemplos, lo más cerca que quedaban era algo del tipo 0.00000000000001, cero arriba, cero abajo, el margen de error estaba en 10^(-14).
Tras... "defecarme" en todo lo "defecable", y descubrir que ese moderno lenguaje de programación "orientado" a "matemáticas" cometía unos errores de aproximación del copón (y era Fortran 90), hubo que "tunear" la comparación, añadiendo en la línea anterior otra comparación más (o cambiándola, no recuerdo), en la que se comprobaba si el módulo (valor absoluto) del resultado de las operaciones era inferior a 10^(-13), entonces se consideraba 0.
Así que ya sabeis amiguitos, siempre tened en cuenta los errores de aproximación y, como dice #4, usa doble, joder, usa doble...
Esto me recuerda (aunque con consecuencias menos graves para la integridad humana, no así para la integridad de mi curriculum académico) a unas prácticas de computación numérica en la facultad.
Se hacían en FORTRAN, ese moderno lenguaje de programación orientado a matemáticas, y recalco lo de "orientado" y "matemáticas". No me acuerdo cuál era el algoritmo que había que programar, pero era uno de estos que dadas una función y un intervalo, te indicaba el número de raíces de la función en dicho intervalo (nota para el que no lo sepa: una raíz de una función es donde el valor de esta es cero). Y sí, se supone que tiene su utilidad.
La cosa es que había un punto del código en el que, después de unas cuantas operaciones, tenías que comparar el resultado que te daba con 0, en cuyo caso se ejecutaba el código A, y si no se ejecutaba B. Y el problema era que siempre ejecutaba B. Por más que ponía ejemplos sabidos, por más que puse flags por todo el código a ver dónde la pifiaba (porque, mayormente, se trataba de informática, y lo de programar lo llevaba bien), por más que hice todo tipo de pruebas, no hubo narices a encontrar qué fallaba. Y sabía que mi código estaba bien. Lo sabía.
Así que se lo comenté al profesor en una tutoría y nos pusimos a revisar el código. Cuando le dije que estaba seguro de que mi código estaba bien... sonrió, pero cuando vio que no había por dónde atacarle a mi código, y tras una media hora haciendo pruebas, descubrimos que, después de hacer aquellas operaciones cuyo resultado había que comparar con 0, resulta que los números nunca daban exactamente cero, sino que, tras varios ejemplos, lo más cerca que quedaban era algo del tipo 0.00000000000001, cero arriba, cero abajo, el margen de error estaba en 10^(-14).
Tras... "defecarme" en todo lo "defecable", y descubrir que ese moderno lenguaje de programación "orientado" a "matemáticas" cometía unos errores de aproximación del copón (y era Fortran 90), hubo que "tunear" la comparación, añadiendo en la línea anterior otra comparación más (o cambiándola, no recuerdo), en la que se comprobaba si el módulo (valor absoluto) del resultado de las operaciones era inferior a 10^(-13), entonces se consideraba 0.
Así que ya sabeis amiguitos, siempre tened en cuenta los errores de aproximación y, como dice #4, usa doble, joder, usa doble...
#15:
#6 ¿Darías por buena la muerte de 28 personas si supieras que habrían muerto más personas de sobrevivir estos 28 soldados?
Es el peligroso espiritu de las agencias de seguridad nacional, de actuar y asesinar "por el bien común" o como lo llaman los americanos por "the greater good".
#7 y #9 Un buenisimo comentario en noticias parecidas, una gran cagada en esta noticia porque los misiles Scud eran misiles fabricados por la Unión Sovietica, así que ahora no vale.
http://es.wikipedia.org/wiki/Misil_Scud
Es el peligroso espiritu de las agencias de seguridad nacional, de actuar y asesinar "por el bien común" o como lo llaman los americanos por "the greater good".
#7 y #9 Un buenisimo comentario en noticias parecidas, una gran cagada en esta noticia porque los misiles Scud eran misiles fabricados por la Unión Sovietica, así que ahora no vale.
http://es.wikipedia.org/wiki/Misil_Scud
#11:
#7 "¿Y quién les vendió los misiles a Irak? Adivinen, es la misma respuesta que con la Guerra del Golfo."
Resulta que fue en la Guerra del Golfo. Y los misiles se los vendió la URSS y Libia, según parece: http://en.wikipedia.org/wiki/Scud_missile#Iran.E2.80.93Iraq_War
Resulta que fue en la Guerra del Golfo. Y los misiles se los vendió la URSS y Libia, según parece: http://en.wikipedia.org/wiki/Scud_missile#Iran.E2.80.93Iraq_War
#21:
#14, #18. En realidad la solución era mucho mas sencilla. Por lo que entiendo ellos convertian los tiempos de punto fijo a coma flotante y luego calculaban la diferencia para hallar la velocidad, algo así como:
t0 = float (t0_int);
t1 = float (t1_int);
speed = (x1 - x0) / (t1 - t0)
Al crecer el valor de t1_int la precisión de t1 baja. Se hubiera podido solucionar calculando la diferencia en tiempos antes de convertir a punto flotante:
tdiff = t1_int - t0_int;
speed = (x1 - x0) / float(tdiff)
Con lo que los valores de tdiff, son siempre pequeños.
Al parecer el orden de los factores sí altera el producto.
t0 = float (t0_int);
t1 = float (t1_int);
speed = (x1 - x0) / (t1 - t0)
Al crecer el valor de t1_int la precisión de t1 baja. Se hubiera podido solucionar calculando la diferencia en tiempos antes de convertir a punto flotante:
tdiff = t1_int - t0_int;
speed = (x1 - x0) / float(tdiff)
Con lo que los valores de tdiff, son siempre pequeños.
Al parecer el orden de los factores sí altera el producto.
Comentarios
Double, usa double, siempre.
Esto me recuerda (aunque con consecuencias menos graves para la integridad humana, no así para la integridad de mi curriculum académico) a unas prácticas de computación numérica en la facultad.
Se hacían en FORTRAN, ese moderno lenguaje de programación orientado a matemáticas, y recalco lo de "orientado" y "matemáticas". No me acuerdo cuál era el algoritmo que había que programar, pero era uno de estos que dadas una función y un intervalo, te indicaba el número de raíces de la función en dicho intervalo (nota para el que no lo sepa: una raíz de una función es donde el valor de esta es cero). Y sí, se supone que tiene su utilidad.
La cosa es que había un punto del código en el que, después de unas cuantas operaciones, tenías que comparar el resultado que te daba con 0, en cuyo caso se ejecutaba el código A, y si no se ejecutaba B. Y el problema era que siempre ejecutaba B. Por más que ponía ejemplos sabidos, por más que puse flags por todo el código a ver dónde la pifiaba (porque, mayormente, se trataba de informática, y lo de programar lo llevaba bien), por más que hice todo tipo de pruebas, no hubo narices a encontrar qué fallaba. Y sabía que mi código estaba bien. Lo sabía.
Así que se lo comenté al profesor en una tutoría y nos pusimos a revisar el código. Cuando le dije que estaba seguro de que mi código estaba bien... sonrió, pero cuando vio que no había por dónde atacarle a mi código, y tras una media hora haciendo pruebas, descubrimos que, después de hacer aquellas operaciones cuyo resultado había que comparar con 0, resulta que los números nunca daban exactamente cero, sino que, tras varios ejemplos, lo más cerca que quedaban era algo del tipo 0.00000000000001, cero arriba, cero abajo, el margen de error estaba en 10^(-14).
Tras... "defecarme" en todo lo "defecable", y descubrir que ese moderno lenguaje de programación "orientado" a "matemáticas" cometía unos errores de aproximación del copón (y era Fortran 90), hubo que "tunear" la comparación, añadiendo en la línea anterior otra comparación más (o cambiándola, no recuerdo), en la que se comprobaba si el módulo (valor absoluto) del resultado de las operaciones era inferior a 10^(-13), entonces se consideraba 0.
Así que ya sabeis amiguitos, siempre tened en cuenta los errores de aproximación y, como dice #4, usa doble, joder, usa doble...
#22 Lo que comentas no es fallo del FORTRAN, es cosa de como se representan los numeros en los ordenadores actuales. Basicamente es lo que pasa cuando mapeas algo continuo (los numeros reales por ejemplo) en algo discreto (la resolucion que te pueden dar 32, 64, 128 o mas bits). Cuando trabajas con numeros de coma flotante nunca puedes hacer lo de if(a == 0), porque como bien comentas lo normal es que nunca se de la condicion, y como bien dices, hay que ver si la variable esta lo suficientemente cerca del valor que queremos comparar:
if(fabs(a - numeraco) < CLOSE_ENOUGH)
#34 Estoy contigo, recuerdo de los primeros días en la universidad que nos insistieron en que nunca jamás utilizáramos el comparador de igualdad con números con decimales
#22 #34 Epsilon de la máquina
http://es.wikipedia.org/wiki/Epsilon_de_la_m%C3%A1quina
#34 #43 que sí, pero por aquel entonces era joven, y aunque conocía (vaya que si conocía) ese tipo de entresijos de la limitación finita de la representación numérica, no había caído en ello como posible causa, al estar hablando de un lenguaje de programación "orientado a matemáticas"...
Via: http://www.reddit.com/r/programming/comments/daa6p/patriot_missile_software_failure_28_soldiers_died/
Más info:
http://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dhahran
http://www.gao.gov/products/IMTEC-92-26
http://www.mc.edu/campus/users/travis/syllabi/381/patriot.htm
Relacionado: ejecutar esto en la barra de direcciones de firefox:
javascript:5.2-0.1
Que nos concedan la licencia para fabricarlos aquí que redondeamos la mar de bien.
#2 Ojo que como tenga que redondear la gente que trabaje en los bares, estos misiles haran genocidios enteros.
Anda... ¿y no había ningún familiar que sabía mucho de informática que hubiera implementado el código para resetear el contador cada poco tiempo? Cachis..
#14 Luego buscan un Desmond que lo resetée cada 108 minutos.
#14, #18. En realidad la solución era mucho mas sencilla. Por lo que entiendo ellos convertian los tiempos de punto fijo a coma flotante y luego calculaban la diferencia para hallar la velocidad, algo así como:
t0 = float (t0_int);
t1 = float (t1_int);
speed = (x1 - x0) / (t1 - t0)
Al crecer el valor de t1_int la precisión de t1 baja. Se hubiera podido solucionar calculando la diferencia en tiempos antes de convertir a punto flotante:
tdiff = t1_int - t0_int;
speed = (x1 - x0) / float(tdiff)
Con lo que los valores de tdiff, son siempre pequeños.
Al parecer el orden de los factores sí altera el producto.
esto con un colegio de informáticos de verdad no pasaría, ejem...
#9 EEUU y Francia no parece que tengan ni hayan tenidos Scuds, pero bueno... http://en.wikipedia.org/wiki/Scud_missile#Operators
Fascinante historia y enorme error informático... pero creo que el título lo expresa mal. En realidad el error no fue el redondeo, si no de almacenamiento o de incorrecta secuencia de cálculo.
Si para el almacenamiento se hubieran usado 32 bits en vez de 24, este problema no habría existido. Del mismo modo, si se hubiera mantenido el valor del tiempo en 1/10 de segundo en vez de ser transformado en segundos, este error tampoco habría aparecido.
La pregunta con dilema moral es: ¿cuántos iraquíes habrían matado esos 28 soldados en los años siguientes?
#6 ¿Darías por buena la muerte de 28 personas si supieras que habrían muerto más personas de sobrevivir estos 28 soldados?
Es el peligroso espiritu de las agencias de seguridad nacional, de actuar y asesinar "por el bien común" o como lo llaman los americanos por "the greater good".
#7 y #9 Un buenisimo comentario en noticias parecidas, una gran cagada en esta noticia porque los misiles Scud eran misiles fabricados por la Unión Sovietica, así que ahora no vale.
http://es.wikipedia.org/wiki/Misil_Scud
#15 Sólo intentaba mirar desde el otro lado del misil ... para los iraquís posiblemente fue una buena noticia: por fin funcionó uno de sus SCUDS. Los americanos son siempre los buenos sólo en las películas de Hollywood y en algunas mentes poco evolucionadas.
Por mi parte no doy por buena ninguna muerte violenta.
#6 la pregunta con dilema moral es: cuantos gilipollas como han nacido sin la ley del aborto?
#17 la unica mente poco evolucionada es la tuya y tu atroz antiamericanismo. Anda, vete a votar noticias de tus amigos Castro, Arafat, Ajmadineyad y Kim Jong Il
#33 Hombre aunque en parte este de acuerdo con tu comentario... meter a Arafat al lado de Castro, Ajmadineyad y Kim Jong Il es un poco bestia, no? Es como meter en el mismo saco a Isaac Rabin y a Ariel Sharon.
Estoy por votar erronea o amarillista... ese error de redondeo no mató a los soldados, a los soldados los mató el que disparó el misil.
#24 No, los mató el que ordenó disparar el misil.
Solo un pequeño fallo en la descripción de la noticia.
Según el artículo en inglés el retraso es de 0'000000095 segundos por cada decima de segundo no de "0'000000095 segundos cada segundo".
#39
¿y en dos horas eres capaz de analizar 250.000 kms^2 en fotografías? Dejaros de chorradas, el SR-71 es para lo que es (para evaluar la capacidad de defensa del contrario) y no puede superar a un satélite en la faceta de reconocimiento. Para empezar, su disponibilidad es ridícula y no hay suficientes para mantener uno de guardia (y con satélites si se puede hacer) Además, si con un satélite sabes cuando pasa a un SR-71 le detectas desde cientos de kms.
Un lanzador de SCUD es algo del tamaño del un camión, muy difícil de localizar desde el aire y sobre todo a Mach 3 desde 25.000 metros de altura. Como para detectar si está pensando en disparar o no.
#45 Si no tienes la necesidad de volar a Mach-3 y a 80.000 pies para evadir los SAM, un SR-71 no aporta ninguna ventaja sobre un U-2 (que sigue en servicio en la actualidad).
Como dice #50, el problema no es tomar las fotografías: es analizarlas. No sé si ahora habrá algún sistema automático para hacerlo en tiempo real, pero desde luego en 1990 tenía que hacerlo un ser humano, una vez descargadas las fotografías. La única posibilidad de ver un lanzador de Scud en operación era que lo identificara un piloto "a ojo". Los norteamericanos tenían permanentemente patrullas de F-15E dedicadas a la caza de scuds, pero el territorio a cubrir era demasiado grande.
#50 Discute con la wiki ¿vale?
http://es.wikipedia.org/wiki/Lockheed_SR-71#Marcas
Y no es el único sitio donde vi esta información, ese dato ya se sabía hace mucho tiempo. En una colección que completé de aviones de guerra también lo mencionaban. Uno solo de estos aviones podía fotografiar toda España en 2 horas.
Y claro que la disponibilidad es ridícula, como que ha sido retirado hace más de 10 años...
Y en cuanto a los radares ¿qué radares? Si fueron fulminados por los AGM45, AGM88 estadounidenses, ALARM Ingleses, y ARMAT franceses y los que quedaron fueron distorsionados por los EF-111A. La debilidad de los SR-71 de reconocimiento como tales podría ser lo que comenta #53 imposibilidad de ver los lanzadores porque se escondían en bunkers, bajo puentes, cuevas o entre la maleza. Aunque, en mi opinión, la vida de los civiles y militares amenazados podría hacer que mereciese la pena desplegar los Blackbird
Un error clasico de sistemas en tiempo real. Lastima que alcanzara su rango de "clasico" llevandose a 28 personas por delante ...
En la informatica tenemos todo todavia por aprender!
Tuve un amigo trabajando para TRW entre otros sitios en guiado de misiles y el mismo me decia que fallaban mas que una escopeta de feria (imagino que tambien por la complejidad) pero vamos que ellos mismos tenian criticas sobre este sistema, que por casualidad son los mismos que estaban haciendo el famoso laser del espacio.
Esto con la informática regulada no habría pasado [/porloscojones]
Y... ¿a nadie se le ha ocurrido que bastaba con reiniciar el sistema los lunes, miércoles y viernes?
#42 Se hizo. Los Israelies notificaron este fallo a los americanos. Pero a parte del reinicio (que para un sistema de alerta 24h no es precisamente lo indicado), el patch llegó justo un día tarde.
Ahora entiendo mejor por qué mi profe de física se ponía tan estricta con los redondeos!
Estamos matando las matemáticas caseras, vale con el redondeo pero espero que no me toquen la cuenta de la vieja.
Brevemente: no me lo creo.
Hubiera sido más fácil y más barato evitar que hubieran lanzado el misil que no tratar de destruirlo con otro misil.
#39 Para eso están los UAV, que encima son mas discretos y no muere nadie si los derriban.
Me como lo dicho en #9, al menos en lo relativo a los Scud, no en lo relativo a que Sadam era el "hijodeputa" de EEUU, el mismo que les hizo el favor de guerrear contra el Irán de los ayatolás con las armas químicas suministradas por occidente.
Desde luego que en estas cosas los EEUU se lo tendrían que hacer mirar, les pasó con el vietcong, con Irán, con Sadam, con Noriega, con los talibanes... todo el mundo que trabaja para ellos acaba siendo su enemigo y recibiendo sus tortas.
#40 Pero los UAV no son tan rápidos y su alcance es paupérrimo. Si quieres buscar Scud en el desierto, con un UAV tardarías semanas antes de encontrar el primero, y no harías ni la décima parte de lo que hace un SR71 en una hora...
Por cierto, ningún SR71 fue derribado en combate, y eso que fueron atacados con más de 4000 misiles. Lo de salvar vidas con el UAV frente al SR71 es una falacia. Te daría la razón si es por motivos económicos. Una hora de operación del Blackbird cuesta 20.000$. Pero tampoco es para tanto, más cuesta cambiar la órbita de un satélite para cambiar su frecuencia ¿no?
Pues no era por cuestion de que los skud volaban en metros y los patriot en yardas?? Siempre intentan colarnos una milonga de estas. O sea que ellos no lo han probado en el desierto que tienen para probar estas cosas??
No. Un error de redondeo no mató a nadie, lo que los mató fue un misil, y si hay que culpar a algo es a la estupidez humana por protagonizar conflictos bélicos entre ellos.
Como un editor sensacionalista convirtió 0'34 segundos en 0'000000095
Saddam y Rumsfeld haciendo migas...
Esta misma historia la contó mi profesor de Computación numérica el primer día de clases hace ya unos años... ahora todos saben el peligro del error relativo!!
creo que la próxima versión va a estar cargada de unsigned double, para asegurar.
No le den más vueltas. Eso fue un simple "daño colateral" sin importancia. Los yanquis matan a un montón de gente todos los meses por daños colaterales y no pasa nada.
Vaya, pues justamente yo leído por ahí hace poco que si no hubieran retirado el SR-71 el año anterior las plataformas de lanzamiento de los Scud hubieran sido detectadas con mucha más facilidad, y éstas, entre otras muertes, se podrían haber evitado.
#3 No creo. Durante la primera guerra del golfo los U2 seguían funcionando. Saddam no tenía nada con qué derribarlos (sus defensas antiaéreas fueron destruidas en las primeras horas de la guerra). El SR-71 sólo tenía sentido para sobrevolar la URSS o países igualmente bien definidos. Y en los años 80 la tecnología de imágenes por satélite podía sustituirlo con ventaja.
El problema con los Scud venía más bien del hecho de que las plataformas de lanzamiento son móviles (remolcadas), y que se tarda bien poco en levantar y lanzar uno de esos cacharros (no son nada sofisticados... vienen a ser una V-2 mejorada). Y el desierto es enorme... tenía que darse la casualidad de que un avión de observación pasara por el lugar preciso en el momento adecuado. Si era así, la plataforma estaba condenada.
#9 Va a ser que no. Los misiles usados por Irak en la primera guerra del golfo eran de tipo SCUD-B, de fabricación soviética (denominación R-17 o R-300), "mejorados" localmente. Los franceses y los americanos le vendieron otras cositas, pero no misiles Scud.
#10 Los Satélites no pueden suplir eficazmente a los SR-71. Todos los países saben a qué hora pasa tal o cual satélite espía. Por eso los SR-71 fueron reactivados en el 95.
http://es.wikipedia.org/wiki/Lockheed_SR-71
Respecto a lo del desierto. Un SR-71 es capaz de fotografiar una superficie de 250.000km² cada hora. Creo que es una capacidad suficiente si los despliegan en Arabia Saudí, podrían fotografiar todo Irak en 2 horas y volver a su base en el Reino Unido antes de que a los operarios iraquíes les diese tiempo de montar sus Scud.
#3
el SR-71 servía para tocar las narices a las defensas antiaéreas soviéticas, no para detectar el lanzamiento de misiles. Fueron retirados tras una emboscada tendida por varios Mig-31 (similar a una emboscada israelí a mig-25 sirios años atrás) y vueltos al servicio cuando el colapso económico de la URSS impidió el uso regular de estos aviones. Cuando la URSS volvió a operar los mig-31 de nuevo, USA dijo que eran antieconómicos otra vez y los volvió a retirar. Creo que queda alguno operado por la NASA.
#27 Exactamente, de hecho el SR71 era un avion muy curioso, que volaba tan alto y tan rapido que como bien dices tocaba las narices a las defensas antiaereas. Como curiosidad anadida este avion 'tenia perdidas' de fuel cuando estaba parado que se sellaban por la dilatacion del material a altas velocidades (que ademas era un fuel bastante caro).
Pues a mí me enseñaron que NUNCA se debe comparar con cero, sino calcular una diferencia y compararlo con epsilon (arbitrariamente pequeño según la aplicación). Pero los militares son tan estúpidos como arrogantes (cuando van armados).
#48 Dudo que ese código lo escribiera un militar. Sería un ingeniero de Raytheon.
Por cierto, hay otro "bug" famoso que viene a ser la imagen especular del que estamos comentando:
http://en.wikipedia.org/wiki/Ariane_5_Flight_501
En este caso, se trató de un overflow, no de un error de redondeo. Y las consecuencias fueron realmente espectaculares (y no se tuvo que lamentar muertos, por suerte).
¿Y quién les vendió los misiles a Sadam? Venga, que no es tan difícil.
#7 ¿la URSS?
#8 Pues no, mas bien fueron EEUU y Francia.
Al igual que lo fuera en su dia Pinochet, Sadam era "su hijodeputa"... hasta que les salió rana.
#7 "¿Y quién les vendió los misiles a Irak? Adivinen, es la misma respuesta que con la Guerra del Golfo."
Resulta que fue en la Guerra del Golfo. Y los misiles se los vendió la URSS y Libia, según parece: http://en.wikipedia.org/wiki/Scud_missile#Iran.E2.80.93Iraq_War