Monthly Archive for marzo, 2005

Page 2 of 3

Problemas abiertos (o “Hay que ver los cerebrines que estudian aquí”)

En las matemáticas existen lo que se llaman problemas abiertos. Son problemas para los que se sabe que hay una solución, aunque nadie haya dado con ella todavía. Quizás el problema abierto (hasta hace poco) más conocido para el público general es el Último Teorema de Fermat:

No hay numeros enteros positivos x, y, z tales que xn + yn=zn, donde n es un número entero mayor que 2.

Desde que Pierre de Fermat enunció este teorema en 1637, nadie fue capaz de demostrarlo hasta 1994, y durante mucho tiempo fue uno de los problemas abiertos más conocidos del mundo de las matemáticas. Curiosamente, el Último Teorema de Fermat es de escaso interes teorico (en el sentido de que tanto si es cierto como si no, el teorema no tiene importantes repercusiones prácticas). Una de las cosas que he aprendido este año es que los matemáticos adoran a Pierre de Fermat no por su último teorema, sino por el Pequeño Teorema de Fermat, un teorema de gran utilidad (por ejemplo, es una de las bases del algoritmo criptográfico RSA).

Pues bien, en informática también hay muchos de estos problemas abiertos. Eso sí, a mi siempre me ha fascinado más el hecho de que hay problemas para los que se ha demostrado que nunca se podrá encontrar una solución. Por ejemplo, está demostrado que es imposible elaborar un algoritmo que, dado cualquier programa P, decida si P entrará en un bucle infinito en algún momento de su ejecución (si crees que te estoy engañando, ya estás leyendote el anexo del artículo Si Turing levantara la cabeza…).

Pero bueno, me desvío del tema: los problemas abiertos. Todo esto lo comento porque nuestro profesor de Algoritmos plantea como desafio a los alumnos la resolución de ciertos problemas abiertos. Lo siento mucho, pero eso es algo por lo que ya no paso. Bastante me atormenta la asignatura de Algoritmos como para además ponerme la capa de Super-Algoritmo-Man para luchar contra problemas en los que durante años han fracasado algunas de las mentes más brillantes de las matemáticas. Eso sí, en nuestra clase hay bastantes cerebrines que sí están por la labor… y resulta que durante la asignatura, dos alumnos han resuelto un problema abierto cada uno. Cagate lorito.

Sin entrar en demasiados detalles, uno de los alumnos ha descubierto la cota inferior de la complejidad de un problema clásico de algoritmia (relacionado con la detección de monedas falsas entre monedas genuinas). Descubrir la ‘cota inferior de la complejidad’ de un problema es un logro acojonante, porque quiere decir que has descubierto que un problema nunca podrá resolverme de manera más eficiente que la dada por la cota inferior. Para que nos enteremos: si un problema tiene como entrada n elementos (p.ej. n números) y la cota inferior es de n3, eso significa que ese problema nunca podrá resolverse en menos de n3 pasos (esta explicación omite muchos detalles, pero es para que me entendais todos… los más entendidos ya sabrán que me estoy refiriendo a la notación Big-Oh).

Otro de los alumnos ha cogido un problema cuyo mejor algoritmo conocido requiere n2 pasos, y ha encontrado un algoritmo que requiere sólo n pasos. También un logro interesante, aunque desde un punto de vista teorico no es tan acojonante como encontrar una cota inferior.

Pues ya veis el tipo de gente que deambula por esta universidad…

Por cierto, si esto de los problemas abiertos ha despertado vuestra curiosidad, os interesará saber cual es (con diferencia) el mayor problema abierto de la informática teorica: ¿P=NP? Esta sencilla formula trae de cabeza a buena parte de la comunidad de la informática teorica. Teneis más detalles aquí.

Mi kernel (y 2)

El viernes entregamos el segundo kernel que había que hacer para la asignatura de Sistemas Operativos. En este caso nos dieron un kernel ya programado (por el profesor), y nosotros teníamos que añadirle toda la funcionalidad de I/O. Leed el artículo sobre el primer kernel para más información sobre la arquitectura simplificada para la que está programada el kernel. En el caso de la capa de I/O, el sistema unicamente tiene cuatro dispositivos: un puerto serie, un lapiz optico, una pantalla, y un chip de memoria flash de 8 MB. Por simplificar, la memoria flash no tiene sistema de ficheros y el kernel presenta el dispositivo como si fuese un único fichero de 8MB.

Nuevamente, para disfrute y deleite de los lectores más frikis, aquí teneis el kernel en cuestión. Os recomiendo que empeceis por el README, pues ahí están listados lo módulos que hemos añadido nosotros. Eso sí, resultan especialmente interesantes los ficheros io_pipe.c (la implementacion de las pipes) y sema.c (la implementación de los semáforos).

¡Ah! Y no olvideis que el fichero está protegido con contraseña fácilmente descrifrable por alumnos/as de ESIDE:

Nombre de usuario: borjanet
Contraseña: “Número del aula de programación” (3 dígitos) + “Nombre de cierta profesora de programación con risa muy contagiosa” (en minúsculas) + “Piso de los profesores” (un dígito)

Nuevamente, si no has estudiado en ESIDE, pideme la contraseña por mail.

Por cierto, hoy he entregado mi proyecto para la asignatura de Grid Computing (impartida por el mismisimo Ian Foster). Ahora ya sólo queda el examen de Algoritmos este viernes. Y por fin habré terminadoooooooo :-D

V Concurso de Programación Obfuscada

A pesar de encontrarme a 6623 kilometros de la Universidad de Deusto (más o menos), este año vuelvo a organizar el Concurso de Programación Obfuscada en el marco de la Semana ESIDE 2005. Este ya es el quinto año que organizo el concurso, y animo a los frikis deustenses a que hagan gala de sus habilidades obfuscadoras. Para los que no esteis en Deusto, el concurso también está abierto a no-deustenses, aunque no optan a premio (sólo a un bonito diploma). De todas maneras, en este concurso uno no se mete por los premios, ¡sino para ganar frikipuntos e infinite bragging rights!

Pues eso. Aunque no vayais a concursar, echadle un vistazo a web del concurso, donde podreis encontrar los programas ganadores de años pasados (algunos de ellos, verdaderas joyas).

Mi kernel

Bueno, para los más frikis, aquí lo teneis para vuestro disfrute y deleite: el kernel que he programado como parte de la asignatura de Sistemas Operativos aquí en la Universidad de Chicago. ¡Ojo! Como el kernel podría ser de gran utilidad para alumnos que hagan la asignatura el año que viene, hace falta nombre de usuario y contraseña para acceder a la URL donde está colgado el kernel. Como me imagino que principalmente interesará a los frikis de ESIDE, la contraseña la podrá deducir facilmente cualquier persona que haya estudiado en ESIDE. Si no has estudiado en ESIDE, mandame un mail y te mando la contraseña.

Nombre de usuario: borjanet
Contraseña: “Número del aula de programación” (3 dígitos) + “Nombre de cierta profesora de programación con risa muy contagiosa” (en minúsculas) + “Piso de los profesores” (un dígito)

En cuanto al kernel, lo primero que tengo que decir es que no lo he programado yo solito, sino en colaboración con Mike Rainey, estimado compañero y excepcional friki. Luego, en vez de cascar un rollo macabeo sobre el kernel, me parece que lo mejor es dar un pequeño resumen y si alguien se pone a mirar el codigo fuente y no entiende algo, que lo plantee en los comentarios.

El kernel está escrito para una arquitectura simplificada llamada Yalnix. Hace falta un emulador para ejecutar el kernel, y por mucho que busco y rebusco, no lo encuentro por ningún lado en la web. Podría pasaros el binario que hemos utilizado nosotros, pero sólo funciona bajo Solaris… En fin, la arquitectura Yalnix es parecida a la que podriamos encontrarnos en un dispositivo movil tipo PDA (de hecho, el emulador de Yalnix te muestra una pantalla tipo PDA e incluye un dispositivo “lapiz” como el que tienen los PDAs). Por lo tanto, implementar un kernel resulta bastante más sencillo que en una arquitectura i386, aunque no por ello deja de ser complicado. A saber, nuestro kernel implementa la siguiente funcionalidad:

  • Gestión de la memoria física (utilizando un algoritmo First-Fit).
  • Gestión de memoria virtual (First-Fit) pero sin swapping al disco. El malloc interno del kernel utiliza un Buddy algorithm (que resulta que es un algoritmo pesimo para reservas de bloques pequeños de memoria, pero que es bastante rapido, y por lo tanto adecuado para una PDA)
  • Gestión de procesos (exec, fork, wait, getpid, delay, yield, …). El scheduler utiliza un algoritmo round robin.

Debo enfatizar que todo esto funciona. Es decir, cuando ejecutamos el kernel en el emulador podemos cargar programas, crear nuevos procesos, y ver como interactuan y se pelean por la CPU. No os podeis imaginar la cara de felicidad que se me puso cuando conseguí que el “Proceso A” y el “Proceso B” conmutasen sin problemas… Trabajar en este proyecto ha sido sinceramente muy revelador. Una cosa es estudiar el funcionamiento de (por ejemplo) la memoria virtual sobre el papel, y otra cosa muy distinta es pelearte tu mismo con la implementación desde cero de un gestor de memoria virtual donde el más mínimo fallo provoca un kernel panic.

En la segunda parte del proyecto (la que entregamos este viernes), tenemos que añadir lo siguiente al kernel:

  • Gestión de E/S a bajo nivel (llamadas del sistema para interactuar directamente con los dispositivos fisicos). Esto supone escribir código bastante obfuscado para gestionar (entre otras cosas) un puerto serie.
  • Gestión de E/S a alto nivel, tipo UNIX. Es decir, interactuar con los dispositivos de bajo nivel a través de ficheros como “/dev/serial”, “/dev/display”, etc. y con las llamadas típicas de UNIX (open, close, read, write, pipe, etc.)
  • Exclusión mutua mediante semáforos.

La segunda parte ya la tenemos 99.9% terminada (hemos llegado al punto en que nuestra principal preocupación es conseguir que los comentarios queden bonitos…). De la segunda parte me ha encantado implementar todo el sistema de pipes. Escribir el caracter de la barra vertical en la shell nunca volverá a ser lo mismo…

En fin, ahi lo teneis. Si os sentís especialmente frikis hoy, bajaros el kernel y echadle un vistazo (os sugiero que empeceis por kernel.c). Si teneis preguntas, planteadlas en los comentarios. ¡Ah! E intentaré colgar el segundo kernel la semana que viene.

P.D.- El kernel incluye varios comentarios en plan de cachondeo. A ver si podeis encontrarlos todos…

Llegando a la linea de meta…

Hoy ha sido el último día de clase del trimestre de invierno. Después de duras batallas en Algoritmos y en Sistemas Operativos, ya sólo queda semana y media para que esto termine definitivamente. Este viernes entregamos el segundo proyecto de SO, y el 18 de marzo tenemos el examen final de Algoritmos. Me siento como si estuviese corriendo un maratón, y estuviese a punto de entrar al estadio para la vuelta final…

De momento parece que todo va viento en popa. El lunes tuvimos el segundo parcial de Algoritmos y hoy nos han dado las notas. Afortunadamente, me sigo manteniendo a flote en el “cuartil superior” (top 25% de la clase). Debo enfatizar que aquí lo importante no es tu nota sino dónde te situas con respecto a tus compañeros, porque la nota final se hace mediante campanazo de Gauss. Para que os hagais una idea del nivel de exigencia de la asignatura, yo estoy en el cuartil superior a pesar de que mi nota media (sin ajustes) es un 6 :-O

Hoy, además, nos han dado las notas del primer proyecto de SO (el kernel que implementamos). Me agrada poder anunciar que mi kernel ha sacado la segunda nota más alta de la clase (después de unos megafrikis que al parecer se pegaron atracones de 72 horas seguidas de programación -sin dormir- para currarse un kernel acojonante… lo siento, pero yo por eso ya no paso). En fin, que he dejado en buen lugar la honra Deustense… Que se enteren estos zafios yankis que dónde esté un ingeniero de Deusto, que se quite el resto (lo digo con un ligero tono de coña… así que si alguien está pensando en dejar un comentario tipo “¡Eres un pretencioso soplapollas!” que por favor se abstenga :-P)

Y hablando del proyecto de SO, no, no me he olvidado de que tengo que colgarlo. De hecho, hoy mismo lo colgaré por fin.

Ah, y aunque no haya escrito sobre el tema (como han hecho muchos otros blogs Deustenses, como el de Lady Pain y Paradise City), que sepais que sí he seguido con sumo interes el progresivo agilipollamiento del Consejo Europeo en lo referente a las patentes del software. No sé por qué, yo me imaginaba que aquí en Europa tendriamos un nivel de trapicheo menor, por lo menos por el simple hecho de que hay que alcanzar un consenso entre tantos paises. Pero parece que no… incluso en Europa nos la pueden meter doblada porque se le pone en la punta de las narices a una minoría interesada. No voy a repetir aquí en mi blog todos los argumentos en contra de la patentabilidad del software. Sí diré que estos argumentos a mi, por lo menos, me parecen muy solidos, tanto en el fondo de la cuestión como en lo referente en la forma en la que se ha aprobado la directiva Europea (pasandose los procedimientos y cauces legales for el arco del triunfo). Os refiero para más detalles a la web del GHOST: http://www.e-ghost.deusto.es/patentesfuera.