Showing posts with label código fuente. Show all posts
Showing posts with label código fuente. Show all posts

Saturday, February 20, 2021

Se libera el código fuente de los FotoMorsaicos



Mi primer acercamiento al tema de los fotomosaicos fue la película The Truman Show, la cual tenía un poster en donde se mostraba el rostro del protagonista hecho con pequeñas fotos, todas ellas sacadas de la película misma.


Era claro que este trabajo se había hecho con algún programa y pronto descubrí que Robert Silvers era el autor de esta imagen. ¿Cómo es que la hacía? Por algún tiempo pensé sobre el algoritmo que estaba detrás de los fotomosaicos. Finalmente descubrí lo que había que hacer y puse manos a la obra. La idea básica es que un programa de fotomosaicos hace un filtro mosaico pero en lugar de usar colores sólidos, usa fotografías cuyo color promedio es parecido al color sólido que debería ir en cada región del mosaico. Escribí entonces un programa en Delphi que hacía un fotomosaico básico. Usaba una colección de unas 6,000 fotografías de alta definición. 

Sin embargo, con el tiempo me di cuenta que un buen programa de fotomosaicos debe contemplar más características: usar diferentes bibliotecas de imágenes, poder decirle al sistema si quiero que haya regiones repetidas o no, es decir, si se debe poner la misma foto o hay que hacer que haya más variedad de las mismas. Igualmente, la idea de fusionar la imagen original en un porcentaje con el mosaico generado “suavizaba” el resultado final, haciéndolo mucho mejor visualmente.

El desarrollo original se publico en la desaparecida revista Dr Dobbs Journal. Un investigador, Thiadmer Riemersma, publicó un artículo estudiando la manera en como los seres humanos ven los colores.( "Colour metric." CompuPhase. May 26, 2008. http://www.compuphase.com/cmetric.htm). Usé su aproximación y el software mejoró más visualmente. Fue de hecho el mismo T. Riemersma quien me escribió al respecto después de leer mi artículo.


Hoy el software permite: 1.Usar diversas colecciones de imágenes (hasta 100,000 fotografías); 2. Hacer blending entre la foto original y el mosaico generado de manera que ambas se fusionen en un porcentaje determinado; 3. Permitir repetir imágenes consecutivas o no. Un fotomosaico con imágenes no repetidas es mucho más aceptable visualmente.



Primer FotoMorsaico hecho con mi software (Ilse, la cantante de Flans)

En https://sourceforge.net/projects/fotomorsaicos/ se encuentra todo el código fuente y la documentación completa del proyecto, escrito totalmente en Delphi y poniéndose de manera pública en el cumpleaños 26 de Delphi.

El Fotomorsaico de David I, gurú de Delphi





Wednesday, February 17, 2021

El código fuente del programa que hace fotos con dados



En mayo del 2020, escribí sobre una imagen hecha con dados, creada por la ciberartista Barbara Lynn Helman. Aparentemente la creadora puso los dados de acuerdo al tono de gris que visualmente hallaba en cada pedacito de la imagen. Las fotografías que presentó parecen indicar esto. Sin embargo, hacer visualmente así un cuadro hecho con dados hubiese sido una labor demasiado complicada y probablemente muy fácil para cometer errores. Yo quiero suponer que Barbara usó algún programa que le indicaba qué dado poner en qué posición. Esta sería, en todo caso, la manera inteligente de hacer esta tarea.

Por ello, escribí un programa que precisamente genera imágenes con dados, como las que hace la señorita Lynn Herman. Y en realidad lo que hice fue modificar un programa que ya tenía que hacía semitonos. En consecuencia, hechas las modificaciones, obtuve rápidamente un programa que generaba las imágenes finales, poniendo dados virtuales (imágenes de dados), en lugar de poner dados reales en una superficie plana.


Quien quiera el software, escríbame a morsa@la-morsa.com para enviárselo de forma gratuita a su correo. En esta ocasión incluye el código fuente de todo el sistema.

El código fuente, aquí y el instalador, aquí.

@EmbarcaderoTech with #Delphi26th

Tuesday, November 04, 2014

De los libros de programación con CD incluido


Hoy en día muchos libros de programación tienen incluido un disco compacto (CD), o bien, dan acceso al código fuente de todo el libro directamente en una página web. En alguna ocasión, tenía en la cama un libro sobre graficación en OpenGL con Delphi, me apoyé sobre él y se dañó el disco, lo rompí. El disco aún estaba en su sobre cerrado. Decidí escribir al correo de contacto de Wordware, mandando una foto del accidente que había tenido. Un par de semanas después me sorprendí con la llegada de un CD (normal, de los que se pueden comprar en las tiendas, con una copia de la información que supuestamente traería el disco dañado).

Y la realidad es que cuando uno está aprendiendo algún tema de programación, resulta siempre muy ilustrativo cargar el código del libro que estemos usando, compilarlo y ver qué hace. En general, el código ejecutable funciona como dice el libro. En otras ocasiones pudiese ser que estemos usando una nueva (o vieja) versión del compilador y haya que hacer algunas modificaciones menores. Esto del código fuente en disco compatco (o página web) ahorra problemas y tiempo.

Pero en términos de enseñanza, estoy empezando a dudar que sea tan útil esto. Miren ustedes: cuando estoy aprendiendo alguna técnica particular en programación y el autor del libro de texto me indica un programa ejemplo, que bien puede tener dos o tres cuartillas, quizás lo más razonable sea escribir el código directamente, es decir, copiarlo del libro al editor del compilador. La razon de esto es que al menos leemos una vez el código fuente (en general más, pues los errores de dedo los hallará fácilmente el compilador y habrá que hacer correcciones al respecto). En este acto de copiar el codigo fuente, probablemente entenderems más qué está haciendo el autor para ilustrar algo sobre el tema de interés. Vamos, que en el fondo, copiar el código "a mano" no necesariamente es una pérdida de tiempo porque no se hace mecánicamente.

Aprender requiere de esfuerzo. No hay manera de aprender si el alumno no se involucra y trabaja para que logre comprender eventualmente lo que puede hacer con toda esta nueva información. Por eso, para sacar mejor provecho de estos discos con el código fuente en los libros de programación, quizás lo mejor sea tener a alguien que nos guíe en ese camino, y que nos dé las cosas tal vez, parcialmente digeridas, para que quien aprende haga la otra parte. Porque no es tan fácil hacerse de la disciplina de empezar a escribir el código cuando éste ya se encuentra en formato electrónico. Es como perder el tiempo tecleando algo que ya alguien hizo por nosotros. Pero tal vez no estemos perdiendo el tiempo... ¿Qué piensan ustedes, lectores?

Sunday, June 22, 2014

Ganadores del reto del gato


Sorprendido alegremente por la respuesta de los programadores que visitan unocero, a escasas horas de empezar el reto, a eso de las 10 de la noche del sábado -cuando se publicó el artículo- recibí a la 1:30 am del domingo la primera respuesta. Dos más llegaron a eso de las 2:15 am y 4:40 am. En el transcurso de hoy llegaron un par más.

 El ganador fue Adán Enrique Aguilar, que escribió un programa en Java, el cual pongo a consideración de todos: Enrique es de Xalapa, Veracruz y en un par de días le mando su memoria USB de 16 GBytes, ¡Felicidades!

Debido al interés que presentaron los siguientes dos programas, se dan dos premios más, uno fue para Manuel Alcántara Juárez. Él me mandó, además, los siguientes datos: El programa genera 255168 posiciones donde 131,184 juegos los gana X, 77,904 los gana O y 46080 terminan en empate. El programa inicia con las "o" pero como dice mi tocayo, es isomorfo.

Finalmente, Charles López resolvió el problema. Su código llegó a eso de las 4 40 am. El ganador se lleva la memoria USB y los otros dos se llevan una taza con el logotipo de La_Morsa.

De izquierda a derecha: Adán Enrique, Manuel Alcántara y Charles López   


Es importante decir que aún no me queda claro cuántas son las posibles posiciones legales. Muchos sitios web dan cifras pero en todos los casos no coinciden. Cuando tenga un rato verificaré esto.

Agradezco realmente el esfuerzo realizado. No pensé que iba a tener estas respuestas y tan rápido. Quien quiera los archivos zipeados de los ganadores, con el respectivo código fuente, escríbame a morsa@la-morsa.com y se los mando de inmediato. (No los puse aquí porque tuve problemas en el formateo).

Wednesday, March 20, 2013

Nuevo reto de programación lúdica: Óleo digital



Una característica de las imágenes en la computadora es que son digitales, es decir, hechas de dígitos, de números, pues. Cada dígito representa un punto en la pantalla, y normalmente el valor que vemos corresponde al color que ese punto tiene en la imagen. De esta manera, las fotografías digitales (ya sean escaneadas o tomadas con alguna cámara digital), son en realidad una matriz cuadrada de pixeles (puntos en la pantalla), que bien puede ser en color o en blanco y negro.

En la medida en que la tecnología ha progresado, hemos pasado de imágenes de 256 colores a las que nos pueden mostrar alrededor 16 millones de colores. Actualmente, cualquier tarjeta de video que se precie de serlo muestra los tres componentes de color R(ed – rojo), G(reen – verde) y B(lue – azul) en cada pixel (o punto), el cual puede ser un valor entre 0 y 255. De esta manera, 256 x 256 x 256 nos da 16,777,216 posibles colores. Cabe señalar que el ojo humano no puede ver semejante espectro de colores, pero es un hecho que la computadora puede desplegarlos.

Ahora bien, cada fotografía digital es en realidad una aproximación sobre lo que se fotografía tomando una cámara analógica, es decir, una que tenga filme. Por ello mismo, “el grano” de la cámara digital es la precisión con la cual puede distinguir los detalles. Por ello vemos que hay cámaras digitales de 4, 8, 10 o más megapixeles. De hecho, tampoco ya el ojo humano no distingue entre, digamos, 8 y 10 megapixeles. De esta manera, la resolución de las imágenes ha crecido y con ello la necesidad de usar cada vez más bytes en los archivos y memorias donde se guarda.

Con el advenimiento de la tecnología digital de imágenes y su gran aceptación en el mercado, estamos viendo desaparecer las cámaras analógicas y los filmes. Se acabó el revelado y los costos asociados a esto. Además, con la generación de imágenes digitales, también nació la posibilidad de post procesarlas para generar efectos en ellas. Photoshop, por ejemplo, es uno de los programas más populares para manipulación digital de imágenes.

Filtros Digitales


La manipulación de una imagen digital se denomina genéricamente como un “filtro”, el cual convierte una imagen en alguna otra cosa. Existen filtros que son reversibles, mientras que también los hay aquellos que no lo son. De acuerdo a las necesidades, se pueden tener diversos filtros o transformaciones que pueden aplicarse a una imagen incluso ya filtrada. Los resultados suelen ser sorprendentes.

Muchos filtros gráficos, sino es que todos, se consideran transformaciones gráficas basadas en una matriz llamada también “convolución” (no se asuste por la palabra, es sólo un término que da precisión a todo esto). Estas convoluciones es el procesar segmentos de la imagen a partir de una submatriz (que puede ser de 3×3, 4×4, 5×5, etc.) de pixeles, que va recorriendo la imagen completa. El resultado final convierte la imagen original en alguna otra cosa. Existen filtros para reconocer bordes, para quitar ruido, para meter ruido, para hacer más precisa una imagen, para hacerla más borrosa, para deformarla, etc. Las aplicaciones son infinitas.

El filtro Oleo Digital (en tonos de grises)


En el libro Beyond Photography (The Digital Darkroom), de Gerard J. Holzmann, que trabajó algunos años en los Laboratorios Bell, el autor nos habla de cómo alterar imágenes. Ahí presenta la fotografía de Dennis Ritchie (uno de los inventores del lenguaje C), y al procesarla la convierte en la misma imagen, pero como si fuese pintada al óleo. De acuerdo al autor, lo que hace es esto: “Para cada punto en la imagen, un programa calcula el histograma de los 36 bordes del derredor [del punto de interés], en la vecindad del punto de interés, y se asigna el valor [al propio punto que estamos procesando] el valor que contenga la mayor frecuencia. El resultado es casi una pintura al óleo”.

Cuando intenté escribir mi propio programa que hiciese este filtro “al óleo”, decidí, sin embargo, no usar 36 puntos, sino 49, para que así mi matriz (llamada: de convolución), mi cuadrícula, tenga un punto central en [4,4]. Con una convolución par no se puede tener un punto central. Igualmente, generé un arreglo de 256 números (de 0 a 255), para colocar la frecuencia de los 49 valores de la matriz de 7×7, que voy recorriendo en la imagen, pixel a pixel. Así, saco los primeros 49 valores y encuentro la frecuencia de los mismos. En el punto de interés pongo el que tenga la mayor frecuencia. ¿Qué pasa si hay más de uno valor con la mayor frecuencia? ¿Cuál pongo? Cualquiera de ellos. Da lo mismo.


La imagen de la izquierda es la de Dennis Ritchie (el creador del lenguaje C), como aparece en el libro de Holzmann. A la derecha aparece mi propia versión del algoritmo descrito. ¿Cuál le gusta más a usted? Este programa funcionaba originalmente sólo con imágenes en blanco y negro (tonos de grises), pues en imágenes de tonos de gris hay nada más 256 tonos y además, las componentes RGB de cada pixel tienen el mismo valor, es decir, R=B=G, lo cual hace sencillo el encontrar el histograma de frecuencias de color. La diferencia en resultados es que Holzmann usa una matriz par y yo uso matrices impares.

El filtro Oleo Digital (en color)

Para poder generar imágenes al mejor estilo óleo, en color, se necesita hacer una modificación que parece trivial, pero que no lo es. La dificultad es que al querer pasar a color, tenemos que las imágenes pueden contener poco más de 16 millones de colores. Esto, obviamente hace el problema un poco más difícil, pues no podemos generar un arreglo de 16 millones (para seguir con la técnica usada en la parte en tonos de gris), pues es totalmente ineficiente y absurdo. Así, aquí hay que contar y crear el histograma de frecuencias de manera más sencilla. Después de dos semanas de darle la vuelta al problema, finalmente hallé una solución simple. La implementé y de pronto ya tenía mi programa que generaba el óleo digital en color. (¿Cómo le hice?… es parte del reto)

Al poder hacer el histograma y hallar cuál es el valor de mayor frecuencia, simplemente lo pinto para cada punto en la pantalla. Es claro que el filtro hace una imagen que pierde precisión contra una fotografía real, pero se asemeja, sin duda, a un cuadro hecho al óleo.

El reto es pues el siguiente: hágase el filtro óleo en color siguiendo la técnica: “Para cada punto en la imagen, un programa calcula el histograma de los 36 bordes del derredor [del punto de interés] y se asigna el valor [al propio punto de interés] el valor que contenga la mayor frecuencia. El resultado es casi una pintura al óleo”.




He aquí las bases adicionales del reto:

  • Ganará el programa que transforme la imagen de Lena (que aparece más abajo), en el menor tiempo posible. El segundo mejor tiempo obtendrá el segundo lugar.
  • Habrá dos lugares: Ambos se llevarán una taza con el logotipo de La_Morsa. Mi intención es que al imprimir esas tazas aparezca una leyenda con el título de la misma y el lugar obtenido, para que quede constancia por el tiempo de vida de la taza.
  • Los programas pueden hacerse en cualquier lenguaje de propósito general y no se vale usar en éste particularmente, bibliotecas que hagan filtros gráficos. Los programadores tienen que resolver el problema por sí mismo, sin ayuda de bibliotecas externas. (Desde luego, se vale usar alguna biblioteca para cargar/guardar la imagen de Lena para procesarla, la cual es un JPG, pero nada más). Así pues, C, C++, C#, Pascal (Delphi), Javascript, Python, Ruby, Visual BASIC, Visual C, Java, etcétera, son idóneos para esta labor.
  • Los autores de los programas deberán mandar el código fuente y el archivo ejecutable en Windows 7.
  • Un autor puede mandar versiones mejoradas de su propio software dentro del tiempo del concurso. No se tomarán en cuenta las que se salgan del tiempo establecido.
  • En la medida de lo posible, el programa debe indicar el tiempo total del proceso realizado para crear la imagen al óleo de Lena.
  • El autor debe enviar el código fuente y quienes ganen aceptan que su código quede accesible para quien lo quiera ver.
  • Los programas deben poderse ejecutar en el sistema operativo Windows 7 de 64 bits. Se correrán en una máquina AMD con 6 núcleos y los resultados obtenidos son inapelables y definitivos. De nuevo aclaro: este es un reto de buena fe y no un concurso estrictamente. Los premios son meramente un estímulo extra para que se animen a entrarle al reto. Evidentemente asumo que el código de cada concursante es creación del mismo y que no andan copiando el código de otras partes, foros, sitios en Internet, etcétera. En caso de hallar que el código fue copiado, el programador queda descalificado.
  • El reto dura una semana a partir del día de la publicación del artículo. Por ejemplo, si éste se publica un 10 de mayo a las 3 de la tarde, el reto se cierra el 17 de mayo a esa misma hora.
  • Cuando reciba algún programa participante en el reto, le enviaré un acuse de recibo para asegurarnos que están todos los que son y son todos los que están.
  • El concurso es para quienes viven en la República Mexicana. Si alguien de otro país quiere participar es bienvenido, pero no podrá acceder a los premios.
  • Los programas deben ser enviados a morsa@la-morsa.com o en su defecto a lopem@hotmail.com, por si alguna de las direcciones no funciona.

Así que queridos y entusiastas programadores, a entrarle al reto. Afilen sus herramientas de programación y que gane el mejor.

Imagen a procesar (512 x 512 pixeles):


Monday, March 12, 2012

Los efectos del software libre


Quienes usamos y compartimos la idea del software libre y abierto, nos topamos con quienes simplemente no entienden cómo es que uno "regala" su trabajo. La realidad es que es una cuestión de creer en que la idea es correcta y "regalar" el trabajo (asunto que estrictamente pudiese ser cierto), no es tan lamentable ni grave como a más de uno le pudiese parecer. De hecho, Donald Knuth, una de las vacas sagradas del cómputo ha dicho ya en alguna ocasión que todos estamos obligados a hacer algo por nuestras comunidades, por el lugar donde vivimos. Los programadores pueden donar su código y eso es una manera de agradecer los beneficios recibidos en nuestras existencias. Cada quien, desde su reducto, está obligado a hacer de este mundo algo mejor.

Knuth es el primero en aplicar esta idea y su sistema de tipografía TeX, es libre y gratuito. Es de código abierto y hoy por hoy es el estándar en sistemas de tipografía para libros de matemáticas. TeX tiene ya sus años y se ha desarrollado extraordinariamente con una serie de herramientas para quienes tienen que formar libros científicos. Así pues, aparte de la obra maestra de Knuth (The Art of Computer Programming - una serie de libros sobre cómputo), tenemos a TeX, entre tantas cosas que ha hecho este personaje por el cómputo mundial.

En el software libre, abierto, en donde en general incluso se entrega el código fuente, tenemos la posibilidad de aprender de lo que otros ya han hecho. Esto me hace pensar en el ajedrez: gracias a quienes escriben de las partidas de otros, que las analizan, que hacen colecciones de posiciones de táctica, de ejercicios para mejorar en nuestra comprensión ajedrecística, entonces aprendemos. No tiene sentido pretender inventar el hilo negro, aprender todo desde cero, sin ayuda. No nos alcanzaría una vida en ese sentido. Hay que sacar ventaja de que otros ya han hecho el trabajo y se han tomado la molestia de explicarnos muchas cosas que nos permiten avanzar más rápidamente.

Y todo esto viene a cuento porque leo a Frederic Friedel, de Chessbase, que en una entrevista dice que los programas de ajedrez de código abierto han arruinado el negocio del ajedrez computarizado. El problema es que hay una serie de motores de ajedrez, "engines", los cuales juegan tan bien como que Fritz, Rybka, Shredder, etc. Por ello en la versión 13 de Fritz, Chessbase ha añadido el que se pueda interactuar con análisis de otros a través de la "nube", es decir, a través de análisis realizados por otros y guardado en los servidores públicos de Chessbase. Para ello, cabe decirlo, se necesita comprar Fritz 13 para tener acceso a esta opción.

El problema es que Robbolito, Houdini y StockFish, son programas que juegan ya tan bien como Rybka (que de acuerdo a Kasparov a finales del 2010, decía, era el programa que mejor entendía de ajedrez). Ahora simplemente se puede descargar cualquiera de los programas mencionados y si comparamos análisis contra los motores comerciales, no veremos prácticamente diferencia. Quizás Friedel tiene razón: vender motores y programas de ajedrez ya no parece ser un buen negocio.

Pero pensemos en Chessbase, el producto estrella de dicha empresa, el manejador de partidas de ajedrez el cual es un estándar. Hay varios productos de la competencia, algunos comerciales y otros de software libre y abierto. Chess Assistant, que es la competencia comercial de Chessbase, hace estrictamente lo mismo que Chessbase (y viceversa), y es cuestión de gustos y de tiempo el preferir uno u otro programa. Sin embargo, tenemos "José" (por José Raúl Capablanca) y Scid (Shane's Chess Information Database), que son programas que en términos generales hacen lo mismo que Chessbase o Chess Assistant, pero sin embargo, no tienen el éxito de los programas comerciales. ¿Por qué?

Puede haber muchas razones, pero quizás la más común es que Chessbase y Chess Assistant también entregan una serie de programas de apoyo para sus manejadores de partidas. Tienen servicios de recolección de partidas que se juegan en los torneos y sus bases de información están actualizadas al día. Los programas públicos, libres y gratuitos tienen eso en contra y no pueden competir con esta parte de los programas comerciales. Otra razón es que sus bases de partidas están en general en un formato optimizado para búsquedas, el cual es propietario, mientras que los programas abiertos usan el formato PGN, que probablemente sea mucho más lento de manipular cuando se tienen unos cinco millones de partidas con todo el ajedrez registrado.

Así pues, he aquí lo que hay que hacer para mantener un negocio de software a flote: hay que dar mucho más que solamente un programa funcional. Por eso Chessbase y Chess Assistant se mantienen en el gusto de los ajedrecistas. Con ese mismo criterio el negocio de los programas que juegan ajedrez debe buscar dar más que sólo un programa que juegue al ajedrez. Como se mencionó antes, Fritz 13 es un primer paso en ese derrotero, pero es claro que hay que apurarse porque los programas abiertos y gratuitos hacen tanto como los comerciales. ¿Por qué pagar por algo que se puede conseguir gratis?

Monday, January 09, 2012

Errores y solución al concurso de programadores reales

En el artículo pasado puse mi programa en prolog, el cual sacaba la solución al problema propuesto, que tomar los 100 primeros enteros y descomponerlos como la suma de dos enteros al cuadrado (también del 0 al 100). El programa que puse era defectuoso, pero fue a "ojo de buen cubero" (que no resulté tan buen cubero). Ya con calma me senté a resolver el asunto y éste es el código que sí funciona:


predicates
   num(integer)
   cuenta(integer,integer,integer).
   checa(integer)


clauses
    num(0).
    num(1).
    num(2).
    num(3).
    num(4).
    num(5).
    num(6).
    num(7).
    num(8).
    num(9).
    num(10).
    num(11).
    num(12).
    num(13).
    num(14).
    num(15).
    num(16).
    num(17).
    num(18).
    num(19).
    num(20).
    num(21).
    num(22).
    num(23).
    num(24).
    num(25).
    num(26).
    num(27).
    num(28).
    num(29).
    num(30).
    num(31).
    num(32).
    num(33).
    num(34).
    num(35).
    num(36).
    num(37).
    num(38).
    num(39).
    num(40).
    num(41).
    num(42).
    num(43).
    num(44).
    num(45).
    num(46).
    num(47).
    num(48).
    num(49).
    num(50).
    num(51).
    num(52).
    num(53).
    num(54).
    num(55).
    num(56).
    num(57).
    num(58).
    num(59).
    num(60).
    num(61).
    num(62).
    num(63).
    num(64).
    num(65).
    num(66).
    num(67).
    num(68).
    num(69).
    num(70).
    num(71).
    num(72).
    num(73).
    num(74).
    num(75).
    num(76).
    num(77).
    num(78).
    num(79).
    num(80).
    num(81).
    num(82).
    num(83).
    num(84).
    num(85).
    num(86).
    num(87).
    num(88).
    num(89).
    num(90).
    num(91).
    num(92).
    num(93).
    num(94).
    num(95).
    num(96).
    num(97).
    num(98).
    num(99).
    num(100).
    
    checa(101) :- !,fail.
    checa(_).
          
    cuenta(X,A,B) :- 
               num(A),
               num(B),
               X = (A*A) + (B*B),
               write(X," = ", A,"^2 + ",B,"^2"), nl,
               X1 = X + 1, !,
               checa(X1),
               cuenta(X1,A1,B1).


    cuenta(X,A,B) :- X1 = X + 1,
                     checa(X1),
                     cuenta(X1,A,B).


La solución completa la dio en Mathematica Emmanuel Garcés, la cual realmente es elegante, mucho mejor que mi código en prolog. se ve que mi tocayo conoce bastante bine el programa de Wolfram

Monday, July 18, 2011

Las respuestas de Vasik


Vasik Rajlich es el creador de Rybka, el programa más fuerte de ajedrez actualmente y el que el mismo Kasparov me dijera en una entrevista, que es el engine que mejor entiende ajedrez hoy por hoy. Pues bien, como se informó en su momento, Rybka fue descalificado por la ICGA, que es un organismo encargado de realizar los campeonatos mundiales de computadoras de diversos juegos, incluído el ajedrez. Durante mucho tiermpo se sospechó que Rybka no era un trabajo original y en las reglas de la competencia se especifica que si se usa el trabajo de otros, debe anotarse. Vasik jamás ha concedido esto. Sin embargo, las indagatorias de una comisión de expertos parecen haber llegado a conclusiones contrarias al respecto de que Rybka es un programa original. Aparentemente la versión desensamblada del software (porque Rajlich no ha dado jamás el código fuente), parecen indicar que hay partes de código copiadas 100% de programas como Fruit y Rybka.

Vasik Rajlich no había hecho comentario alguno sobre la descalificación de su programa, así como la petición de la ICGA para que regrese los trofeos y los premios en metálico (que a decir de Vasik, en la entrevista -ver más abajo- no entiende de qué se está hablando, porque no ha habido nunca premio monetario por ganar el campeonato mundial de computadoras de ajedrez).

Cabe también señalar que muchos de los investigadores que se aplicaron a ver si Rybka era un plagio o no, son programadores dedicados al ajedrez pro computadora. Ergo, son "rivales" en los torneos de computadoras contra el propio Rybka y uno bien podría pensar: ¿es legítimo armar un conjunto de programadores para probar si un programa es original o plagio, estando esos investigadores como parte de otros equipos de programación de ajedrez por computadora? ¿No es esto ser juez y parte?

Mientras se dilucidan estas puntillosas cuestiones, he aquí la entrevista que hiciese Nelson Hernández al creador de Rybka. Dura una media hora. En mi opinión, no me convence lo que dice Vasik en general, pero desde luego: que cada quien saque sus conclusiones.

Wednesday, June 29, 2011

Rybka es un tramposo

Ayer salió un muy interesante artículo sobre Rybka, quizás el programa más fuerte de ajedrez, que había dominado hasta hace pocos el ajedrez por computadora. El artículo completo, con las referencias y análisis sobre todo este asunto puede verse aquí.

La cuestión simple es que por mucho tiempo se sospechó que Rybka era un clon -ciertamente modificado- de un programa de código abierto, llamado Fruit. David Levy, uno de los jerarcas de la Federación de ajedrez por computadora (entre otros juegos), escribió un extenso artículo sobre este tema, del cual hablé también en este blog (puede consultarse aquí al respecto).

Y la pregunta seguía en el aire: ¿Era Rybka un clon de algún otro programa? Algunas conclusiones de Levy así lo hacían ver. Sin embargo, nada era conclusivo hasta que una serie de expertos en el tema tomaron el toro por los cuernos y comenzaron a analizar a Rybka, a partir de que éste empezó a jugar de manera notable.

Así entonces, la International Computer Games Association (ICGA), ha descalificado y bloqueado a Rybka y a su programador, el MI Vasik Rajlich, de jugar en futuros campeonatos mundiales por computadoras, amén de exigirle a Rajlich que regrese los trofeos y premios en metálico que hubiese recibido cuando ganó los torneos mundiales de los años pasados (2007, 2008, 2009 y 2010).

La ICGA acusa a Rajlich de plagio de dos programas, Crafty y Fruit, después de haber conformado un panel de investigación que analizó Rybka desensamblado el código ejecutable (pues Rajlich no ha dado acceso al código fuente).

Los miembros del panel fueron:

Secretariado:
  • Robert Hyatt - (Crafty, Cray Blitz, World Computer Chess Champion in 1983 and 1986)
  • Mark Lefler (author of Now)
  • Harvey Williamson (part of Hiarcs Team)

Miembros:
  • Albert Silver (software designer for Chess Assistant (1999-2002); currently editor of Chessbase News (2010-present))
  • Amir Ban (author of Junior: World Champion 2002, 2004, 2006, World microcomputer Champion 1997, 2001)
  • Charles Roberson (author of NoonianChess)
  • Christophe Theron (author of Chess Tiger)
  • Dariusz Czechowski (author of Darmenios)
  • Don Dailey (author of Cilkchess, Star Socrates, Rex, Komodo)
  • Eric Hallsworth (part of Hiarcs Team, Publisher of Selective Search magazine)
  • Fabien Letousky (author of Fruit)
  • Frederic Friedel (Chessbase.com)
  • Gerd Isenberg (author of IsiChess)
  • Gyula Horvath (author of Pandix, Brainstorm)
  • Ingo Bauer (Shredder team)
  • Jan Krabbenbos (Tournament Director of Leiden tournaments)
  • Kai Himstedt (author of Gridchess and Cluster Toga)
  • Ken Thompson (creator of Belle Chess Machine, World Computer Chess Champion 1980, Turing Award winner 1983, creator of B and C programming languages, Unix and Plan 9 developer). More Information about Ken can be found here http://en.wikipedia.org/wiki/Ken_Thompson
  • Marcel van Kervinck (author of Rookie)
  • Maciej Szmit (assistant professor at Technical University of Lodz)
  • Mark Watkins (MAGMA Computer Algebra Group, School of Mathematics and
  • Statistics, University of Sydney)
  • Mark Uniacke (Hiarcs, World Microcomputer Champion 1993)
  • Mincho Georgiev (Pawny)
  • Olivier Deville (Tournament Director of ChessWars)
  • Omid David (author of Falcon)
  • Peter Skinner (Tournament Director of CCT--the major annual online computer chess tournament)
  • Ralf Schäfer (author of Spike)
  • Richard Vida (author of Critter)
  • Richard Pijl (author of The Baron)
  • Stefan Meyer-Kahlen (author of Shredder, multiple world champions from 1996-2007)
  • Thomas Mayer (author of Quark)
  • Tord Romstad (author of Stockfish, Glaurung)
  • Tom Pronk (ProChess, Much)
  • Vladan Vuckovic (Axon, Achilles)
  • Wylie Garvin (game Programmer at Ubisoft Montreal)
  • Yngvi Björnsson (The Turk)
  • Zach Wegner (author of ZCT and Rondo, an upgraded version of Anthony Cozzie’s Zappa program, which was world champion in 2005).

Esta noticia sin duda es casi tan importante en el mundo del ajedrez como lo fue la descalificación del canadiense Ben Johnson en las Olimpiadas de 1988 después de que dio positivo en las pruebas antidoping. Aparentemente la resolución es definitiva y es claro que Rybka y Rajlich habrán caído en el desprestigio, quedando fuera de este tema del ajedrez por computadora.



Yo quisiera imaginar que el MI Rajlich debe salir en defensa de su programa. Si es un trabajo original debe poder mostrarlo y además, así evitaría, además de las sanciones, el desprestigio en el que en este momento se encuentra. Habrá que ver qué reacciones hay.

En el mientras, es muy lamentable que estas cosas pasen, pero es claro que los programadores que se esfuerzan porque sus programas cada día jueguen mejor y además, contribuyan a la resolución de los problemas con ideas originales, sean finalmente sobrepasados por alguien que copia código de manera "inteligente" y que logra éxitos sorprendentes basándose en trabajos de terceros, a los cuales, desde luego, no les da ni siquiera crédito.