Blog personal de Aitor Iriarte.
Intento ayudar en lo que queda de una comunidad con personas que se respetan unas a otras. Si esto sigue adelante sólo es por comentarios positivos o alentadores. Si ves que este blog permanece congelado, el nulo feedback es el único motivo.
Antes de ejecutar los comandos en sistemas en producción, asegurate leyendo la ayuda o en sitios especializados, de que son adecuados para el fin que pretendes.
Esto es una pregunta con trampa porque no existe el mejor GNU/Linux a secas. Para la elección de tu distribución favorita hay que tener en cuenta un montón de factores que no voy a enumerar.
Ahora bien, el trabajo realizado por eWeek nos puede ayudar un poco si lo que buscamos es "la mejor alternativa a Windows y Mac OSX".
En este lugar (eWeek) después de un gran esfuerzo en laboratorio han resuelto que Ubuntu sigue siendo el mejor Linux para sobremesa. Por supuesto hay decenas de comentarios en contra de los cuales también se pueden extraer conclusiones.
Sin embargo, fruto del mismo trabajo, han llegado a la conclusión de que si hablamos de servidores hay otros mejor capacitados como Red Hat Enterprise Server y su primo-hermano libre CentOS.
Me imagino que como todos, tienes un buscador preferido. Lo que ocurre es que a veces te gustaría probar la búsqueda en varios a la vez.
En http://www.mysearchoff.com/podemos consultar con los tres buscadores más utilizados a la vez: google, livesearch y yahoo. También se puede votar al mejor buscador y ver los resultados de la encuesta, donde por cierto machacan google y live search.
Ayer tuve una jornada de reencuentro con viejos amigos a los que saludos desde aquí (por si acaso a alguno le da por leer esto). :-) Estuvo muy bien, sobre todo la sesión maratoniana de mus donde Castrol y yo arrasamos a la vieja usanza de nuestros años universitarios.
Os dejo esta foto de Castrol en Shanghai donde trabaja. Si queréis saber más hacer clic en el enlace de Castrol el loco. La foto la he bajado de su blog.
Bueno, entremos en materia...
¿Qué son los metadatos en el ámbito de documentos como el word, excel, etc? Pues son datos que se almacenan en el propio documento y que se refieren a características del mismo, el autor, la red, el sistema operativo, las impresoras, etc.
Desde hace unos meses Chema Alonso ha dedicado varios post a este tema donde se pueden ver los datos y como leerlos. Han creado incluso una herramienta llamada FOCA que facilita la labor de lectura de metadatos de diferentes archivos de diferente formato (Office, openoffice, ...).
Yo sólo quiero transmitir que existen los metadatos en todo tipo de ficheros y no sólo word.
Y también que importantes organizaciones han metido la pata por no haberlos tenido en cuenta.
EL DODGY DOSSIER
En el año 2003, el ministro británico de asuntos exteriores tuvo que comparecer ante una Comisión Parlamentaria encargada de investigar si el Gobierno manipuló el informe sobre las armas de destrucción masiva en Iraq.
El Gobierno había hecho público un informe (dodgy dossier) en un momento delicado, ya que en aquel momento era dudoso que la ONU fuera a respaldar una resolución para la invasión.
En EEUU Colin Powell presentó el informe como prueba ante el Consejo de Seguridad. Y días más tarde la prensa británica informó de que atendiendo a los metadatos del informe gran parte de él era una copia de una tesis de postgrado de un universitario estadounidense escrito 12 años antes.
El Ministro trató de quitar hierro, dijo que no era un informe sino un comunicado de prensa y que se había producido un error debido a la presión que ejercían los periodistas que querían comunicados diarios.
Aunque no he escrito nada en dos días, no he dejado de aprender informática.
El olentzero ha dejado en casa un MacMini y me he pasado unos buenos ratos jugando con el aparatito, aunque realmente no es mío.
Ahí va un pantallazo. No había manejado nunca un MaxOSX pero la verdad es muy sencillo y tiene una buena ayuda.
De precio no se puede decir que sea excesivamente caro, y más aún teniendo en cuenta el software que trae de serie. El hardware me lo ha reconocido sin problemas por lo que compartirá discos externos, monitor, teclado y ratón con el PCKubuntu.
Hay cosas que llaman mucho la atención. Por ejemplo que sacas el cacharro de la caja, lo enciendes, y con un par de preguntas ya estás navegando. La fecha, la hora las coge por su cuenta. El arranque y el apagado es increíblemente rápido.
Bonito, ¿eh? No me van las guerras entre PC y Mac. Si utilizara habitualmente un Mac me gustaría jugar con un PC y viceversa. El mac tiene especial interés por ser un UNIX (sí, ya se que es discutible) con su comandos, editor vi, etc.
Este es un divertido vídeo sobre la pelea entre Bill y Steve.
Los scripts en general suelen ser lenguajes interpretados. Algunos son sencillos y limitados, aunque también muy efectivos como el los viejos .bat del ms-dos que sobreviven en los últimos Windows.
Tenemos potentes lenguajes como Perl, Python que se utilizan también como lenguajes de propósito general.
En windows hay un interprete poco conocido que nos puede facilitar mucho la administración de una gran de red de PC-s Windows. Quiero centrarme un poco en este potente lenguaje Windows para intentar sacarle provecho en el trabajo después de las vacaciones.
En Windows utilizaremos el notepad o el viejo Edit para editar un fichero de texto. Por ejemplo:
WScript.Echo "Hola mundo"
Guardamos el fichero con nombre hola.vbs, abrimos una sesión de línea de comandos y...
cscript hola.vbs
La ventaja de utilizar Windows Script Host es que si nuestra red es Windows todos nuestros clientes lo tienen por defecto. Además tiene "objetos" preparados para Windows: acceso al registro, a la configuración del explorer, al controlador del dominio, etc. etc.
Ahora no puedo probar los scripts sobre los clientes de una red, pero pondremos este script que podemos utilizar para guardar la información del sistema de un PC:
strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colCSes = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystem") For Each objCS In colCSes WScript.Echo "Computer Name: " & objCS.Name WScript.Echo "System Type: " & objCS.SystemType WScript.Echo "Number Of Processors: " & objCS.NumberOfProcessors Next Set colProcessors = objWMIService.ExecQuery("Select * from Win32_Processor") For Each objProcessor in colProcessors WScript.Echo "Manufacturer: " & objProcessor.Manufacturer WScript.Echo "Name: " & objProcessor.Name WScript.Echo "Description: " & objProcessor.Description WScript.Echo "Processor ID: " & objProcessor.ProcessorID WScript.Echo "Address Width: " & objProcessor.AddressWidth WScript.Echo "Data Width: " & objProcessor.DataWidth WScript.Echo "Family: " & objProcessor.Family WScript.Echo "Maximum Clock Speed: " & objProcessor.MaxClockSpeed Next
La última conclusión si estaba perfectamente escrita. Los puntos interiores en una circunferencia de radio 1, son los que cumplen X^2 + Y^2 < 1. Si incluimos los puntos del borde cambiamos el "menor" por "menor o igual".
El lenguaje maltratado por los grandes gurús, Visual Basic, esta vez es más rápido que C#.
El miércoles anunciaba cómo en el cálculo de pi por el método de Montecarlo el programa C# sobre XP se comportaba mejor que el mismo programa en FORTRAN sobre Kubuntu.
En agosto ocurrió que un mismo programa Visual Basic corría más rápido que el equivalente C++. En aquellas fechas busqué referencias en Internet y publiqué que "A veces VB es más rápido que C++"
Tiempos de ejecución:
KUBUNTU + FORTRAN (GCC-F77): 1 minuto 37 segundos. XP + C#: 50 segundos. XP + VB.NET: 39 segundos.
Ya se sabe que errar es de humanos, no voy a comentar el caso en detalle porque es como para comerse a alguien. Sólo diré que yo no he cometido el error. Aunque como responsable de la instalación he tenido que arreglarlo.
Buenos, el caso es que he ido al trabajo tan tranquilo, he entrado algo más tarde que las 8:00 a.m. y he salido algo antes que las 22:40.
Quiero documentar lo realizado porque hay cosas que no vienen en ningún sitio y sólo te lo puede explicar alguien a quien le ha ocurrido antes. Empecemos por Tru64.
DEC (Digital EquipmentCorporation) era una gran compañía creada en 1957. Os sonarán sus servidores PDP y VAX. El PDP-8 se suele considerar como el primer mini-ordenador. Se les denomina mini por comparación con los mainframes de la época pero eran auténticos cacharros.
En 1978 se lanza el VAX que fue una mejora consistente en una arquitectura de 32 bits. Se podía utilizar UNIX, aunque lo suyo era el super sistema operativo que todavía sigue vivito y coleando: VMS. Yo conocí el VAX/VMS en la Universidad y era robusto de verdad.
En 1992 lanzan los nuevos servidores Alpha que tenían arquitectura RISC (juego de caracteres reducido y ejecuciones en menos ciclos de reloj). En aquel momento había grandes debates y era la arquitectura que se iba a comer el mercado. La gran novedad era la arquitectura de 64 bits que también se considera como la primera del mercado. Funcionaban con UNIX (Digital-UNIX), VMS (lo ideal) o WindowsNT. Yo he trabajado con un Alpha 4100 con VMS y era lo más duro que he visto en mi vida. A prueba de balas. Un día pongo las fotos. ¡Sniff!
En 1997, DEC demanda a Intel por violación de patente en sus nuevos microsPentium. Su RDB (base de datos relacional super-robusta) lo compra Oracle (OracleRDB).
En 1998 Compaq compró DEC. Y Compaq cambió el nombre del sistema operativo. Lo que hasta entonces era Digital UNIX pasa a llamarse Tru64 (sí, el 64 es para remarcar que es de 64 bits).
Se da la circunstancia de que HP compra-fusiona Compaq en 2001-2002 por lo que aunque todavía hoy (2008) le da soporte se puede considerar que muere ese año. Desde el momento de la fusión HP deja de lado el Tru64 en favor de su propio UNIX HP-UX. Muchos técnicos que han trabajado con ambos sistemas operativos (por venir de Digital) defienden la superioridad de Tru64 frente a HP-UX, pero lo comentaremos otro día.
Ya me he enrollado otra vez. Lo que quería decir es que el servidor con el problema es un CompaqAlphaServer ES40 y su sistema operativo es...Tru64. Mañana entro en detalles.
Como os decía el otro día quiero hacer un programa en Fortran-Linux y el mismo en XP-C# y comparar los tiempos de ejecución.
Lo primero es encontrar un algoritmo matemático en Fortran con cierto interés.
He pensado en el cálculo de PI. Ya sabéis, ese número irracional (y por lo tanto con infinitos decimales).
Hay un bonito método llamado "Método de Montecarlo" que paso a resumir. Se llama montecarlo por su relación con juegos de azar como la ruleta.
Advertencia: He encontrado varias web donde se confunde este método de Montecarlo con otro llamado de las agujas propuesto por el naturalista francésconde de Buffon.
Supongamos que tenemos una diana que consiste en un círculo dentro de un cuadrado de 2x2 (me recuerda la cuadratura del círculo, pero eso es otra historia).El área total del cuadrado es 4, y el del círculo pi x r cuadrado. Al ser el radio del círculo 1, su área es pi. Si tiráramos los dardos de forma totalmente aleatoria, la probabilidad de que los dardos se clavaran dentro del círculo sería pi / 4 porque el área total es 4 y el área del círculo pi.
Entonces lo único que hace falta es un programa que calcule valores de x,y aleatorios para un montón de tiradas. Multiplicamos el número de aciertos por 4 y dividimos entre el número total de tiradas. El resultado es una aproximación a pi.
probabilidad de acierto = pi / 4
pi = 4 x probabilidad de acierto
pi = 4 x (aciertos / tiradas)
En mi Kubuntu me he encontrado un bonito editor llamado Kate que reconoce perfectamente la sintaxis del Fortran:
Con 1.000 intentos me ha estimado un valor de pi = 3,176 (bastante malo) :-( Con 10.000 intentos sale pi = 3,1444 (sigue siendo una ruina).
Podéis hacer unos cuantos intentos del método en este sitio, pero he probamos con 10.000 intentos por ejemplo y me da pi = 3,1248.
Ya vemos que esto no va a funcionar. Conseguir series de números realmente aleatorios no es fácil.
La importancia de este tipo de métodos (agujas, Montecarlo, etc.) es que abrió la posibilidad de utilizar el azar para cálculos analíticos. Algo que se puede utilizar en la práctica con los ordenadores.
Saludos.
Actualización del 5/2/2012:
A raiz del comentario de Miguel, me ha entrado la curiosidad. ¿Se conseguirá una precisión de 3 decimales con 1 millón de iteraciones?
El resultado que sí, con el millón se llega a pi=3,142. Exactamente lo que ha predicho Miguel.
He venido hace poco del cine donde he visto una película de esas que no te deja tranquilo después de verla. Sobre todo en estos momentos de crisis globalizado.
No voy a desvelar nada. Creo que es mejor que no leáis sobre ella hasta después de verla.
Simplemente decir que es alemana, se llama "La ola" y que está basada en hechos reales ocurridos en Palo Alto en 1967.
Jeje, he perdido la forma. Hoy tenía comida con antiguos compañeros de trabajo y prácticamente sin beber nada ya tengo dolorcito de cabeza...No sé que va a ser de mi en la quedada que voy a tener el día 27 con mi amigo Castrol (ver el loco Castrol en la sección de enlaces que tiene un blog mucho más interesante que este).
Vayamos con el post...
Sí, Fortran es un lenguaje venido a menos como lenguaje de propósito general, pero en el ámbito científico creo que sigue con vigencia.
Tengo tres libros de Fortran y quiero hacer algo. Por ejemplo una comparativa de algún programa corto comparado con C#.
Para que haya cierta polémica no lo voy a hacer en condiciones iguales. Utilizaré mi viejo PC sobremesa con Linux y Fortran, contra el viejo portátil XP con Visual Studio 2005. Y que gane el mejor.
Lo primero la instalación del compilador de Fortran en el Kubuntu.
sudo aptitudeinstall g77
De esta forma conseguimos:
/usr/share/doc/g77 /usr/bin/g77
Vamos al home del usuario y editamos (con el VI por ejemplo) el primer programita "Hola mundo".
c Nuestro primer programa Fortran77 programhw write (*,*) 'Hola mundo' stop end
Ahora compilamos el programa objeto así:
g77 hw.f -o hw
Para ejecutar:
./hw
En la imagen una muestra del programa fuente, la compilación y la ejecución:
Hoy espero aclarar las dudas que pueda haber sobre el tema de las excepciones.
En Visual Basic.NET tenemos unas cuantas funciones de conversión:
En el siguiente código visual basic se hace una conversión como la que pudo ocurrir en el momento previo de la explosión del cohete.
Tenemos una variable entera llamada i. Y una variable doble llamada z.
Dim i As Integer Dim z As Double z = 4.354354387594386E+25 i = CInt(z)
En Visual Basic, igual que en Ada (lenguaje utilizado en el Ariane-5) la variable z contiene un valor demasiado grande para que pueda convertirse al tipo entero. Lógicamente esto provocará un error.
Igual que en el caso del cohete Ariane, hemos introducido captura de excepciones, lo que ocurre es que no se capturan todas.
Try
Dim i As Integer Dim z As Double DimstreamEscritura As New System.IO.StreamWriter("c:\temp\dato.txt")
Catchioe As System.IO.IOException MsgBox("c:\temp no existe")
Catch se As System.Security.SecurityException MsgBox("Acceso denegado.")
EndTry
El programita después de la conversión imposible va a intentar escribir el resultado en un fichero de texto. Hemos capturado la excepción de "Error de Entrada/Salida" y la de "Seguridad". Veamos lo que ocurre:
Se ha producido un error "Overflow Exception" y la ejecución del programa se ha interrumpido. Esto es lo que ocurrió en el cohete.
La solución es evidente. Hay que capturar TODAS LAS EXCEPCIONES para que nunca se interrumpa de esa forma la captura de datos de los sensores. Si un valor es demasiado grande no debería ocurrir nada, se desecha el valor y el sensor ya nos enviará un nuevo dato.
En Visual Basic esto se hace con una captura de excepción genérica:
Catchex As System.Exception EndTry
Bueno, la lección es la siguiente: Hay que pensar que siempre puede haber excepciones no previstas. Pensar la mejor forma de salir del error e implementarla en el lugar adecuado.
También es importante recordar que las conversiones de tipos suelen ser especialmente problemáticas.
El Ariane-5 era algo más que la continuación de los anteriores. El diseño prácticamente era nuevo. La nueva lanzadera tiene dos secciones. La de abajo es la parte común para todas las misiones y la superior depende de la carga que se va a poner en órbita.
El 4 de junio de 1996, en su primer vuelo, la expectación fue enorme. Todo el mundo estaba observando. Despegó y a los 40 segundos, empieza a girar sobre si mismo hasta que explota.
A los pocos días se nombró una comisión de investigación formada por técnicos de diferentes países. Y esto fue lo que encontraron:
Datos de vuelo:
Hasta el segundo 42 tenían datos telemétricos remitidos a tierra, señales de radar e imágenes visuales.
1-Antes del despegue, todo normal. 2-Despegue, todo normal. 3-Hasta el segundo 36, todo normal. 4-Fallo del sistema de referencia inercial de reserva. 5-Fallo del sistema de referencia intercial activo. 6-La posición de las bocas de los propulsores y del motor van a la posición más extrema. 7-Autodestrucción de la lanzadera.
Con estos datos, ya vieron lo que falló: el sistema de referencia inercial.
Recogida de más datos:
La zona de despegue (Kourou, Guayana Francesa) estaba rodeada de árboles. La explosión fue sobre los 4.000 m. Los fragmentos se dispersaron a lo largo de 12 km cuadrados. Patearon toda la zona y encontraron los dos sistemas de referencia inerciales los cuales tenían datos valiosísimos que no se habían remitido a tierra. De esta forma se supo que primero falló el sistema de reserva y luego el principal.
El diseño
Lógicamente, lo primero que tenemos que saber es qué es eso del sistema de referencia inercial. Para decirlo con cuatro palabras. Parece un montón sensores (giroscopios láser y acelerómetros) conectados a un procesador. De esta forma se mide en todo momento el movimiento, orientación, velocidad, aceleración de la lanzadera.
Este sistema de referencia inercial provee de datos a la computadora de a bordo (sí, como los coches de ahora) a través de un bus de datos.
Esa computadora central tiene el programa de vuelo y va accionando las bocas de los propulsores, el motor, etc. por medio de elementos hidráulicos.
El hecho de que hubiera dos sistemas de referencia inerciales era para evitar el desastre en caso de que fallara el principal. El hardware y el software eran iguales. Como se suele decir ahora eran un activo pasivo y encargado de "switchear" es el computador de a bordo en caso de detectar algún fallo.
El computador de a bordo también estaba duplicado.
El fallo
La secuencia "marcha atrás" fue la siguiente:
A la velocidad que va el cohete y con una inclinación del 20 grados (y subiendo), los propulsores se separan. Eso hace que se active la autodestrucción.
Ese giro no planeado se produce porque las bocas de los propulsores y del motor se encuentran "a tope".
Estaban "a tope" porque así lo había ordenado la computadora de a bordo.
Los datos que cogió de referencia la computadora de a bordo eran los del sistema de referencia principal. No eran datos "buenos" pero los tomó como si lo fueran.
El sistema de referencia principal no enviaba datos "buenos" porque se había producido una excepción en el software.
Aunque había una excepción, el ordenador de a bordo no cambió al sistema de referencia secundario porque este había fallado antes que el principal. En el secundario se había producido la misma excepción.
La excepción se produjo en una conversión de datos de coma flotante (64 bits) a entero con signo (16 bits). Resulta que el número en coma flotante que se intentaba convertir no cabía en los 16 bits del entero. La excepción era un "Error de Operando". El código era Ada, y en esta parte del programa se habían tenido en cuenta otro tipo de errores de conversión, pero no el "Error de Operando".
Ya vemos el cariz que esta tomando esto, pero la realidad supera siempre a la ficción y lo que viene es flipante...
El módulo en el que ocurre el error es para una función de alineamiento que sólo es necesaria antes del despegue. Después del despegue ya no sirve para nada.
O sea, todo se fue al garete sin necesidad. Se trataba de un código que no debería estar ejecutándose.
La cosa es algo más complicada que eso. El Ariane-4 si que necesitaba esa función durante 50 segundos desde la activación del "modo de vuelo" de los sistemas de referencia inerciales. Esos 50 segundos se terminan sobre el segundo 40 desde el despegue. El Ariane-5 no necesitaba esa función en vuelo.
El Error de operando se produjo porque la función se encontró con un valor más alto de lo esperado. La variable está relacionada con la velocidad horizontal de la plataforma.
Era más alto que lo normal porque la trayectoria del Ariane-5 es diferente del Ariane-4 y lo que no era normal en el anterior sí era normal en el nuevo cohete.
00:30 a.m. Hora de dormir. Mañana continuo, porque en el informe se intenta justificar el motivo por el cual no se hicieron todas las comprobaciones necesarias. Decían que no se quería llegar al 80% de la capacidad de proceso del sistema de referencia inercial, pero algo huele mal si realmente estaban ejecutando código innecesario.
Es mucho más conocido lo ocurrido en 1986 con el Challenger. Por un lado, a diferencia del Ariane, éste era un vuelo tripulado. Además recuerdo que en aquel vuelo iba una civil (la primera civil en el espacio). Por si eso fuera poco, muchos vieron las imágenes en directo.
En la wikipedia hay un resumen y las posibles causas del accidente, así como detalles más o menos escabrosos como la posibilidad de que la causa de la muerte de los astronautas fuera el impacto con el océano. La falta de un sistema de eyección así como de paracaídas fue muy criticada y tuvo consecuencias para la NASA.
Hoy quiero hablar del Ariane ya que desde el principio se achacó el desastre a un "problema" informático.
En muchos sitios se habla del Ariane, al fin y al cabo es un cohete europeo con muchos años de vida, pero parece que se ha olvidado lo ocurrido en 1996. En la Wikipedia una simple oración lo recuerda, y en muchos sitios especializados ni mencionan aquel problema informático que originó una pérdida de millones de euros.
Ariane es una familia de cohetes europeos construidos por la Agencia Espacial Europea (ESA). Esta agencia está formada por varios países. Entre otras misiones los Arianes se encargan de poner en órbita satélites.
El primer Ariane se lanzó en 1979. Tenía 47 metros de longitud y podía poner en órbita un satélite de unos 2.500 kg. En 1980 se encarga la construcción a la empresa Arianespace cuyo accionista mayoritario es el estado francés. Las diferentes series se van mejorando y se utilizan según necesidades. La serie 4 podía poner en órbita 4.400 kg.
En estas estamos cuando se llega a la serie 5. La decisión de una lanzadera-cohete más competitiva, con menores costes y mayor fiabilidad, la tomaron en 1987 los ministros de los estados miembros. El Ariane 5 podía poner en órbita 2 satélites de 3.000 kg cada uno, o uno solo de 6.800 kg. Puede transportar incluso vehículos tripulados.
Para el año 1996 se preparan los primeros dos vuelos de prueba: el ariane-501 (en mayo) y el ariane-502 (en otoño). Al final el vuelo 501 se lanza en junio y ocurre el gran desastre.
Al tratarse de un proyecto compartido entre varios países había que iniciar una investigación y hacer públicos los errores. El resultado muy sorprendente. Uno de los mayores fallos software de la historia en un sistema diseñado para que nada falle.
Este post ha resultado demasiado largo. Son las 00:43. Mañana el informe.
Ha muerto mi fiel amigo Gorri. Después de 15 años (105 años perrunos) ha llegado su hora.
Murió el sábado 6-12-2008. Es el motivo de que no haya escrito nada estos días.
A pesar de que tenía muchos años, y tenía los achaques y manías propios de la edad, qué pena da pensar que no voy a verlo más. Un amigo excepcional, gran olfato, inteligente, sensible, deportista que nos ha acompañado en todo tipo de marchas de montaña..., siempre haciendo compañía, alegre la mayoría de las veces, triste cuando notaba que algo no iba bien. No habrá otro igual.
El cohete europeo que explotó en el aire era un proyecto en el que colaboraban numerosos países y había que clarificar quien había metido la pata. Los resultados de la investigación eran públicos y al menos el año pasado estaba en Internet.
Imprimí lo que encontré del tema y lo guardé para cuando hiciera falta. Ahora no encuentro nada. Ni mis apuntes, ni el informe de lo ocurrido en la red.
En cuanto encuentre el material, lo analice y lo resuma lo publico en el blog.
Por el momento, sólo os diré que hubo un problema clásico que no se habría producido en caso de haber seguido las nociones más elementales de ingeniería del software.
Por otra parte se produjo un problema de redondeo que tiene relación con lo que hablábamos de las limitaciones en informática y por último, el sistema entero estaba duplicado pero el error de redondeo también se produjo en el sistema secundario con lo que no sirvió de nada.
La lección: por mucho dinero que metas en el proyecto, si te saltas a la torera la documentación de proyectos y das por hecho cosas que no son ciertas el fracaso te perseguirá. Además, luego todo el mundo te dirá a ver por qué no leíste la documentación, y por qué no hiciste las pruebas necesarias.
Saludos.
jueves, diciembre 04, 2008
Ya vimos ayer lo que le pasó a Hipaso por divulgar un descubrimiento secreto que hoy en día es inofensivo. De todas formas, desde el punto de vista de los pitagóricos la muerte de Hipaso no era tan grave. Ellos pensaban que al morir su alma se mudaría de cuerpo, sin más.
Probablemente mudaría a un cuerpo que no conocería el secreto, así que asunto arreglado.
Las consecuencias para la matemáticas griegas fueron que el descubrimiento se trató como un obstáculo infranqueable. Los griegos se centraron en el estudio de la geometría y dejaron de lado los números relacionados con áreas y longitudes.
El siguiente gran impulso relacionado con los números naturales se da con Euclides (sobre el 300 a.c.), pero esto es otra historia.
La verdad es que hoy en día el impacto sigue siendo fuerte aunque no tenga consecuencias prácticas.
En el triángulo de arriba si el cateto EA mide 1 metro y el cateto AB también mide 1, la hipotenusa mide 1,4142135623730950488... hasta el infinito.
O sea, que no puede existir un triángulo así.
Acabo de poner que no tiene consecuencias prácticas, pero ya me estoy arrepintiendo...
La informática, la electrónica, sirve para solucionar problemas, descubrir cosas nuevas,..., pero siempre tienen ciertas limitaciones como la memoria disponible, la longitud de los registros, la memoria máxima que se puede direccionar, los MIPS, la frecuencia máxima de reloj, la longitud máxima de cada tipo, etc. etc.
Hay cálculos que requieren gran precisión, y por otra parte hemos visto que en este universo (da igual lo avanzada que esté una civilización) surgen números indomables que requieren memoria infinita para ser almacenada.
Esto nos lleva inevitablemente al fracaso de grandes proyectos, especialmente con magnitudes increíblemente grandes, o increíblemente pequeñas.
En los próximos días pongo unos cuantos casos.
Pista: Observar estas imágenes e imaginaros lo lejos que pueden estar esas maravillas:
Comentaba ayer que hace 2.500 años se hizo un descubrimiento sorprendente en las matemáticas. Es algo totalmente superado hoy en día, pero en aquel momento causo una gran conmoción.
Pitágoras (582 a.c.-507 a.c.) fue un gran viajero que aprendió matemáticas de Egipto, Mesopotamia, etc. Al regresar de sus viajes a Samos (lugar de nacimiento) fundó una escuela. Huyo de la tiranía y fundó una segunda escuela en Italia. También fueron expulsados de Crotona y fundo la tercera escuela en Tarento (también Italia).
En sus escuelas impartir conocimientos a los no iniciados estaba prohibido. Recibían el nombre de los Pitagóricos y consideraban que la base de todo el universo eran las matemáticas (aritmética y geometría).
Más que matemáticos o filósofos era una especie de religión con sus teorías de transmigración de las almas, un Dios con forma de esfera etc. etc.
El teorema de Pitágoras era conocido por otros pueblos (en Babilonia e India probablemente), pero se atribuye la demostración a los pitagóricos.
No sabemos la demostración exacta aunque hay varias que pudieron haber encontrado.
Ya se ve que esta gente SI pensaba que las matemáticas eran la realidad y todo se podía explicar por ellas.
En los tiempos de los pitagóricos ya habían descubierto los números racionales. Estos números tienen la particularidad de que se pueden mostrar como relación entre dos números naturales. O sea, que si "r" es racional r= p / q siendo p y q naturales. Racional se refiere a que es parte de otro número.
Para explicarlo de otra forma, los números racionales son aquellas soluciones de la ecuación a = bx cuando a y b son enteros.
Realmente el teorema de pitágoras y otras muchas de sus demostraciones se basaban en establecer relaciones entre ángulos, longitudes y áreas.
En esas estamos cuando un pitagórico llamado Hipaso, que se cree que fue maestro de Heráclito, encuentra la siguiente demostración:
Nota: la función sqr() es el cuadrado y sqrt() la raiz cuadrada.
Supongamos que tenemos un cuadrado cuyo lado mide 1. Entonces la hipotenusa mide raiz de dos (sqrt(2)).
Como todos los números son racionales, sqrt(2) = p / q siendo p y q enteros.
Empezamos quitando todos los factores comunes entre p y q. Si los dos son pares sacamos el 2 como factor común y simplificamos. Se tiene que quedar uno de ellos como par y el otro impar, o los dos impares. No pueden ser los dos pares.
2 = sqr(p) / sqr(q)
O sea sqr(p) = 2 sqr(q)
Entonces sqr(p) es par.
Si sqr(p) es par entonces p es par.
Como p es par entonces habrá un número natural r tal que p = 2r
Como hemos dicho antes sqr(p) = 2 sqr(q)
Y eso lleva a sqr(2r) = 2 sqr(q)
4 sqr(r) = 2 sqr(q)
2 sqr(r) = sqr(q)
Esto quiere decir que sqr(q) es par por lo que q es par.
Pero es que como hemos dicho al principio no pueden ser los dos números pares por lo que hay una contradicción. Por eso sabemos que los números naturales p y q no existen.
Así son los números irracionales. No son parte de ningún otro número racional.
Para verlo más gráficamente, (y esto lo pongo de mi cosecha), así como no existe el círculo perfecto, tampoco existe el cuadrado perfecto, ya que raíz de 2 es irracional y eso implica que tiene infinitos decimales. Si tuviéramos que medir su longitud con una regla no terminaríamos nunca.
Esto lógicamente causó una gran conmoción entre los pitagóricos. Hay varias teorías sobre lo que le pasó a Hipaso. Algunos creen que fue ejecutado por orden de Pitágoras. Otros que fue expulsado de la orden. Parece que hay algún documento de la época que habla de un naufragio en extrañas circunstancias.
Aunque la matemática sea la supuesta "Reina de las Ciencias", algunos matemáticos no la consideran una ciencia natural. No, no es una ciencia natural. Se basa en conceptos abstractos que muchas veces no tienen reflejo en el resto de ciencias. Por ejemplo no hay ningún problema para representar un espacio vectorial con 1.384 millones de dimensiones. Dudo que el mundo físico en el que vivimos tenga justo justo esa cantidad de dimensiones.
Incluso cuando tratamos conceptos que se pueden extrapolar a la física, las matemáticas expresan cuestiones que sólo pueden existir en nuestra cabeza.
Por ejemplo un punto 0-dimensional.
¿Y algo que tenga que ver con la informática?
Pongamos un sencillo ejemplo. El siguiente programa en pseudocódigo calcula la circunferencia de un círculo con radio r.
Programa circunferencia contante pi = 3,141592 variable radio: real
Escribe("Introduce el radio") Leer(radio)
Devolver 2 x pi x radio
Observa el programa. Hemos puesto un pi con 6 decimales. Podíamos haber puesto un número pi todo lo preciso que queramos pero el programa nunca devolverá el valor exacto.
Esto sólo demuestra una cosa. Podemos acotar el error pero es imposible eliminarlo. Esto es lo que le pasó al cohete europeo Ariane Vpor un error de redondeo (un día de estos publicaré detalles técnicos recopilados desde hace tiempo).
Lo que hemos visto en el video anterior es el problema de la informática por basarse en la realidad física en lugar de en las matemáticas puras.
Pero hay más:
PI es un número irracional. Significa que no expresarse como una fracción p/q donde "p" y "q" sean enteros. Se caracterizan por tener infinitos decimales que no siguen un periodo definido. Efectos prácticos: Imaginemos que encontramos un circulo perfecto en el mundo. Nos inventamos una unidad de media nueva de forma que el radio del círculo sea la unidad.
Entonces el diámetro es 2 x pi x r, y como pi es irracional y r es la unidad... Tenemos que el diámetro es 2 x pi. Y si pi tiene infinitos decimales, pi x 2 también. Por lo tanto, no hay circulo perfecto en el mundo simplemente porque no podría haber una circunferencia con "longitud finita" que cumpliera la igualdad.
El circulo perfecto es una idea en nuestra cabeza nada más. Por eso decía que la informática se basa en la realidad física más que en las matemáticas.
Mañana os cuento lo que le ocurrió hace 2.500 años al matemático (entonces filósofo) que intentó que las matemáticas avanzaran admitiendo la existencia de esos números tan "irracionales" que no podían ser de este mundo.
Sin embargo si hubo una reflexión interesante en forma de comentario por parte de Pokemon kamikaze. Decía algo así:
"la informática está basada en la matemática. Y la matemática es infalible. Otra cosa es que los componentes materiales (hard) o el soporte humano (human) no sean capaces de dar soporte a la necesidad matemática." En aquel momento dije que "Este tema que has sacado merece un post." y ha llegado el momento adecuado.
Empieza el post...
La informática está basada en la realidad física de este mundo. Creo que esto es obvio y no admite discusión. Si esto no es así, yo también podría decir como Pedro Calderón de la Barca: "La vida es sueño" y debate terminado.
La matemáticas son algo más difícil de explicar. Como dijo el matemático Leopold Kronecker, "Dios hizo los naturales; el resto es obra del hombre".
Hay que entender el estado de las matemáticas en la segunda mitad del XIX. Los matemáticos debatían qué cosas debían ser consideradas como válidas y cuales no tenían sentido.
Los intuicionistas consideraban que conceptos abstractos como el infinito, conjuntos, etc. no tenían sentido. El intuicionismo es un tipo de constructivismo que son matemáticos que no reconocen la reducción al absurdo.
Sin embargo las matemáticas avanzaron por estos caminos aunque con algunos problemas. Uno de los problemas más graves fue la paradoja de Cantor y la paradoja de Russel. Durante esta semana explicaré estas paradojas que son muy sencillas de entender pero que tienen difícil solución.
Ha habido otras ocasiones en las que matemáticos se han escandalizado al descubrir/inventar algunos resultados como los Pitagóricos y los números irracionales.
Son casi las 00:05. Tengo que dormir que estoy reventado.Mañana continuo, pero aviso, lo que voy a contar es interesante y hará pensar.
Al mediodía os proponía una forma de empezar a resolver el problema.
He seguido colocando damas y ha ocurrido lo siguiente:
O sea, que nos hemos encontrado sin salida. Hemos colocado 5 damas y ya no podemos continuar porque la sexta la pongas donde la pongas estará amenazada.
Os preguntaba como continuar y no ha habido respuesta. Así que lo continuo como se me ocurra a mi.
Este algoritmo que hemos seguido se parece mucho a una búsqueda en un árbol. Para el que no haya estudiado esto de grafos y árboles os lo explico:
Ante un callejón sin salida, volvemos atrás y miramos si la última dama colocada se puede poner en otra casilla.
Llegamos al punto en el que colocamos la dama en E4. La siguiente dama no la podemos poner. Volvemos atrás y buscamos otra opción. Encontramos la casilla E8 donde podemos colocar dama. Continuamos como siempre y vemos que se puede colocar una dama en F4.
Con esta técnica hemos podido poner una dama más aunque no nos ha servido demasiado por encontrarnos en otro callejón sin salida.
Como no podemos continuar más, hay que retroceder hasta ir agotando todas las posibilidades.
El grafo es un diagrama de líneas y el árbol es un tipo de grafo especial en el que un padre tiene 1 o varios hijos, pero un hijo sólo tiene un padre. El dibujo que hemos elaborado es un árbol.
Cuando nuestros programas tengan que recorrer un árbol hay dos estrategias diferentes:
La búsqueda que hemos visto se llama búsqueda en profundidad porque avanzamos todo lo que podemos por una rama hasta el callejón sin salida. Si hay que retroceder retrocedemos lo mínimo necesario para encontrar una rama lo más profunda posible. Esta es una buena estrategia cuando la profundidad máxima está controlada (en nuestro problema hay 8 niveles) y nuestro algoritmo no se va a perder por esos caminos.
Con grandes profundidades, si no queremos ver nuestro programa perdido en una rama profundísima podemos emplear la búsqueda en anchura. Se trata de retroceder hasta el nivel superior y empezar por otra rama antes de empezar a indagar en las profundidades.
