Voy a tratar de ser lo más preciso posible en el requerimiento.

Cálculo de la desviación estándar

La desviación estándar se define como la raiz cuadrada de la varianza, una   fórmula para la varianza es esta:

La X con la barrita encima es la media.

El algoritmo típico para calcular la varianza de una lista L de números es el siguiente:


def Varianza(X[], N):

let M = media(X, N)
let S = 0
for x in X:
S = S + (x-M)^2
return S/N

def media(X[], N):

let S = 0
for x in X:
S = S + x
return S/N

Este algoritmo requiere “pasar” dos veces por los datos, una para calcular la media y otra para calcular la varianza.

El desafío de este mes es el siguiente:

Calcular la varianza de una manera más rápida y eficiente.

Desafio extra

El resultado debe ser el más preciso posible.

Con el fin de probar este ejercicio usaré una lista de un millón de números con cuatro dígitos decimales, el resultado se deberá entregar como un número con 8 dígitos decimales. Ganará el programa más rápido y más preciso (proximamente publicaré la lista de números en GitHub y el resultado esperado, así que visiten este post nuevamente para ver estos datos).

Dado el siguiente algoritmo

while (n > 1) do
if (n is even)
n <- n / 2
else
n <- n*3+1
end

Demuestre que este programa se detiene para cualquier número n entero.

Si ustedes resuelven este acertijo entonces, dice Bentley, ¡vayan a la universidad más cercana y reclamen su PhD!

Claro que en el camino se podrían quedar sin amigos, como nos recuerda XKCD:

Este es un problema planteado por Lothar Collatz en 1937, que ha generado bastante investigación. Para los interesados hay una revisión del problema en esta página: http://www.numbertheory.org/keith/george.html.
Lo que sabemos

Este problema es la base del desafío de abril, donde algunos de ustedes participaron.

Mi respuesta al problema es la siguiente (que llamaremos siracusa-1):

No es la más breve, que era una de los requerimientos del desafío. La solución en Ruby de Daniel Torres es la más breve presentada, se me ocurre que podríamos escribir una más breve en perl, pero lamentablemente estas soluciones tienen un mal desempeño, llegando a consumir mucho tiempo de cpu.

Pero si vamos a dedicarnos a obtener nuestro PhD debemos encontrar una solución con buen desempeño y eficiente, después de todo hay que recorrer todos los números enteros.

La solución de Aldrin Martoq usa un bonito método de programación dinámica, con un costo de memoria proporcional al tamaño del problema. Su código usa un arreglo de 10 millones de enteros (de 64bits). En mi mac su solución toma menos de 2 segundos para cualquier parámetro menor o igual a 10.000.000. Cuando empezamos a jugar con parámetros mayores a esa cifra el desempeño empieza a decaer. Claro está que podemos aumentar los requerimientos de memoria del programa y mantener su desempeño para números mayores.

Vamos a intentar romper el record de Aldrin…

Lo primero que vamos a hacer es operar con bits.

La expresión:

n % 2 == 0 ? n / 2 : n * 3 + 1

Se transformará en

n & 0×01 ? ((n << 1)|1)+n : n >> 1

Esto requiere un poco de explicación, verificar que un número es par es equivalente a verificar el bit menos significativo y ver si es un 1. Dividir por 2 es lo mismo que hacer un shift a la derecha en 1.

La expresión n*3+1 es lo mismo que hacer: ((n*2)+1)+n = ((n<<2)|1)+n.

La verdad es que este cambio no impacta en el desempeño. Pero debemos notar que una vez que multiplicamos por 3 y sumamos 1 lo que hacemos es obtener un número par. Así que esto nos da la clave para reformular nuestro función orbita de la siguiente manera:

Esta solución, que llamaremos siracusa-2, tiene una mejora notable en desempeño, estos son los valores de ejecutar la versión de aldrin, siracusa-1 y siracusa-2 en mi pc:


time ./amartoq-2 10000000
8400511

real 0m2.511s
user 0m2.507s
sys 0m0.003s


Probando amartoq-2 y siracusa-2 para n=100.000.000 tenemos estos tiempos:


time ./amartoq-2 100000000
63728127

real 0m27.605s
user 0m27.583s
sys 0m0.015s


Y para 1.000.000.000:


time ./amartoq-2 1000000000
670617279

real 4m59.104s
user 4m58.883s
sys 0m0.160s


Wujuu!! Gané!! Claro que es una victoria pírrica, dado el uso de cpu sostenido durante esos 4 minutos.

Por cierto, el programa de Aldrin siempre puede mejorar para valores mayores de n si aumentamos el tamaño del arreglo saltos.

Ahora les toca a ustedes, les dejo algunos desafíos interesantes, cómo saben si alguno de ustedes encuentra la solución a la Conjetura de Collatz?

Desafíos

1. Modifica el programa de amartoq-2.c para usar las optimizaciones aritméticas usadas en siracusa-2.c y mide el impacto en el desempeño.
2. Fíjate que nuestros programas usan un tipo de datos de 64bits, pero no han sido ejecutados con valores que ocupen todos esos bits, escribe versiones modificadas de los programas usando sólo 32bits y mide el impacto en desempeño.
3. El programa siracusa-3.c imprime los números y el largo de sus secuencias, úsalo para armar una base de datos que permita a los investigadores de este problema consultar rapidamente cual es la secuencia más larga que se genera en un rango de números dados.
4. Para los estudiantes de ciencias de la computación: ¿Se puede calcular la complejidad de los algoritmos usados en este artículo? ¿Cuáles son?
5. ¿Por qué el hacer estos programas no es la forma correcta de ganarse un PhD, qué es lo que falta?

Notas
[1] Este libro es fundamental: Programming Pearls, Jon Bentley ¿en que están que no lo han incorporado a su biblioteca?

Vamos a revisar los resultados del desafío 2012-04: El problema de Siracusa, si no sabe de que hablamos le sugiero leer este post.

Participantes:

• damowe: Daniel Molina en Haskell, con 2 respuestas, aunque la segunda es la que implementa el requerimiento, Daniel incluso escribió un post en su blog e investigó un poco más sobre este problema. A la solución correcta de Daniel la llamaremos damowe-2.hs.
• dtorres: Daniel Torres participó con dos soluciones, una  en ruby dtorres-1.rb (elegí la más corta), y otra en c: dtorres-2.c.
• amartoq: Aldrin Martoq aportó varias soluciones, de hecho varias están en un proyecto en github en que estuvo explorando el tema. Tomaremos dos de sus soluciones para participar, una en ruby: amartoq-1.rb y otra en C: amartoq-2.c.
• chancesman: Michael Chances participó tambien con una solución en C: chancesman-1.c
• umolina: Uriel Molina particpa con una solución en PHP, umolina1.php.

Desempeño:

Para evaluar el ganador vamos a descartar los programas que no cumplen el requerimiento descrito anteriormente:

El desafío de este mes es escribir el programa más breve posible, en el lenguaje que quieran, que encuentre el número base de la secuencia de números más larga, este número debe estar entre 1 y un parámetro de entrada al programa.

Por ejemplo, si le paso como parámetro el número 5 al programa este debería imprimir 3, pues 3 es el número entre 1 y 5 que genera la secuencia más larga:

1: 4, 2, 1.
2: 1.
3: 10, 5, 16, 8, 4, 2, 1 <– esta es la secuencia más larga, por tanto el resultado es 3.
4: 2, 1.
5: 16, 8, 4, 2, 1.

Por lo tanto si ejecuto Siracusa(2) el resultado debe ser 1.

Ronda Número 1:

Ganador

Mención Honrosa

Código Fuente

Vamos por él.

El problema de Siracusa

Piensa en un número positivo cualquiera, si es par divídelo por 2, si es impar multiplícalo por 3 y súmale 1. Repite el proceso con el resultado. Llegará un momento en que obtendrás el número 1, no importa el número que elijas.

A la secuencia de números que genera este algoritmo la llamamos la secuencia de Hailstone.

Veamos algunos ejemplos:

Supongamos que partimos con el 4, la secuencia que obtendremos será: 4, 2, 1.

Partamos con el 11: 11, 34 (=11*3+1), 17, 52, 26, 13, 40, 20, 10, 5, 16, 8, 4, 2, 1.

A 4 y 11 los llamaremos los números bases. Podrán apreciar que este algoritmo puede generar secuencias muy largas.

El desafío de este mes es escribir el programa más breve posible, en el lenguaje que quieran, que encuentre el número base de la secuencia de números más larga, este número debe estar entre 1 y un parámetro de entrada al programa.

Por ejemplo, si le paso como parámetro el número 5 al programa este debería imprimir 3, pues 3 es el número entre 1 y 5 que genera la secuencia más larga:

1: 4, 2, 1.
2: 1.
3: 10, 5, 16, 8, 4, 2, 1 <-- esta es la secuencia más larga, por tanto el resultado es 3.
4: 2, 1.
5: 16, 8, 4, 2, 1.

Tienen un mes para contestar, el programa más breve gana (es decir, que tenga menos caracteres, no consideraremos los saltos de linea, tabuladores y espacios en blanco porque igual queremos que sea un programa legible).

El bug esencialmente era este:

“Se debe implementar una función que dada una fecha calcule la fecha correspondiente a 10 años antes. Por ejemplo, si la fecha es 3 de marzo de 2012 la fecha de 10 años antes se define como 3 de marzo de 2002. El problema ocurre en los años bisiestos. Cuando llega el 29 de febrero de 2012 la implementación calcula como resultado 29 de febrero de 2002, una fecha que no existe.”

El origen del problema está en la definición del requerimiento y en las condiciones de borde del mismo.

La definición del problema implica que para calcular un desplazamiento de 10 años hacia atrás en el tiempo simplemente se deben restar 10 a la fecha dada. Esa definición es discutible, pero sólo cuando empezamos a considerar los desplazamientos debidos a los años bisiestos. Después de todo un año bisiesto introduce un error de 1 día cada cuatro años, ¿no es verdad?

Pues no. Por que la regla del año bisiesto es:

Un año es bisiesto si es divisible entre 4, a menos que sea divisible entre 100. Sin embargo, si un año es divisible entre 100 y además es divisible entre 400, también resulta bisiesto. Obviamente, esto elimina los años finiseculares (últimos de cada siglo, que ha de terminar en 00) divisibles sólo entre 4 y entre 100.

En código, podemos definir una función bisiesto de esta manera (en C):

Esta función es fundamental para poder implementar la solución correcta de nuestro problema, así que considerenla, todavía quedan días para resolver este desafío.

Pero sigamos analizando el bug. Una técnica que es muy util para desarrollar código de calidad es crear pruebas unitarias, o test unitarios como se les conoce. La idea es definir un conjunto de pruebas que permitan validar el funcionamiento de nuestra implementación.

Supongamos que nuestra función que calcula una fecha previa se define de este modo:

prev_year(cur_day, cur_mon, cur_year, delta_year);

cur_day, cur_mon y cur_year son la fecha que le pasamos como argumento, delta_year es la cantidad de años que queremos que se “retroceda en el tiempo” para calcular la fecha deseada. Esta funcion nos devuelve una estructura que expresa la fecha deseada e en sus tres parámetros día, mes y año.

Ahora usemos seudo código para expresar nuestras pruebas unitarias (lo que sigue parece python, pero no lo es, es un lenguaje inventado para efectos de expresar la idea):

prueba_1: assert prev_year(2012, 3, 1, 10) == (2002, 3, 1);
prueba_2: assert prev_year(2012, 2, 29, 10) == (2002, 3, 1);

assert es una primitiva que intenta ejecutar una expresión booleana, si la expresión se cumple entonces assert indica que todo está bien, si no se cumple assert nos informa de un error. El modo específico de como funciona esto depende de cada lenguaje de programación.

La idea importante que quiero expresarles es que cuando nos enfrentamos a un problema de este tipo, sobretodo cuando hay que depurar algún error, el uso de pruebas unitarias es de gran ayuda. Así que si quieren responder el desafío que les he planteado en el post anterior les sugiero implementar esto tests unitarios, y de esta forma estarán validando si cumplen con el requerimiento.

Así, si la fecha es 28 de febrero de 2012, entonces 10 años antes se calcula restando 10 a 2012, es decir, la fecha buscada es 28 de febrero de 2002. Por supuesto aplicando ese criterio para el día de hoy genera la imaginaria fecha del 29 de febrero de 2002.

Esa no es la manera correcta de calcular la fecha para 10 años atrás, así que este es el desafío de esta oportunidad ¿cuál es la mejor manera de calcular la fecha correspondiente a 10 años atrás en el tiempo?

Más sobre bugs del bisiesto en la naturaleza del software.

Elaborados con la ayuda de la gente de StackExchange, los videos dan algunas recomendaciones para las personas que están interesadas en ser desarrolladores de software.

Estos son los enlaces a los videos:

• Parte 1
• Parte 2

En general estoy de acuerdo con lo expuesto en los videos, pero tengo mis comentarios.

En el video un desarrollador se define básicamente como una persona analítica con la capacidad de resolver problemas. Bueno, eso coincide curiosamente con la descripción de ingeniero

Una mente analitica y capacidad para resolver problemas

Pero sí, un desarrollador debe tener las mismas habilidades cognitivas de un ingeniero, por eso que en Chile al menos, tenemos la carrera de ingeniería en informática, computación o software (no hay mucho consenso al respecto).

De todas maneras aparecen mencionadas en la segunda parte algunas habilidades y características que un desarrollador debe tener.

La primera, y estoy de acuerdo que es una de las más importantes, es la habilidad para comunicarse. La idea del programador como una persona aislada, solitaria encerrada en una sala oscura llena de pantallas es inadecuada, después de todo, hoy en día el software apoya a muchas industrias y disciplinas, lo que obliga a trabajar en equipos con gente con distintas profesiones y oficios. Es importante saber escuchar y trabajar en conjunto en pos del objetivo de la empresa o institución. Un buen programador debe ser empático y colaborador, ser un aporte y no un estorbo a la organización. Desarrollar las habilidades sociales y de comunicación es un requisito mínimo para el desarrollador. Cuando no hay comunicación se resuelven los problemas equivocados, se asumen cosas incorrectas, se generan errores, los proyectos se retrasan.

Luego hay una serie de habilidades más concretas:

• Matemáticas: fundamental. Probablemente no necesitas ser un genio de las matemáticas, pero es básico saber álgebra, geometría y probabilidades. Yo agregaría matemáticas discretas, es fundamental saber contar,  hablaremos sobre matemáticas más adelante en este blog.
• Estimación: Hay que saber estimar, ese es uno de los mayores defectos de los programadores, y algo que deben aprender a mejorar rápidamente en su carrera. Una buena manera es dividir el problema en partes más pequeñas, estimar el esfuerzo de cada una, llevar un registro de las estimaciones, y después revisar que fue lo que estuvo mal con la estimación, y corregir. Aprender en retrospectiva, para ir mejorando las estimaciones.
• Micro economía: en esto estoy totalmente de acuerdo, se deben entender los fundamentos de la economía, oferta, demanda, costo de oportunidad, etc. Muchos programadores ignoran el aspecto económico o no se preocupan del impacto que su perfeccionismo pueda tener sobre el negocio. Muchas decisiones en un proyecto van a estar influenciada por el dinero. Se debe entender la diferencia entre lo perfecto y lo que es relevante para el valor del negocio.
• Diseño de Interfaces de Usuario: finalmente otra persona será la que use tu programa, y hay una manera adecuada de desplegar la información y definir las interacciones. Muchas interfaces malas son creadas por programadores, que no se preocupan de la importancia de la usabilidad y la accesibilidad.No se trata de que se vea lindo, se trata de que sea usable, entendible. Hay que aprender el lenguaje de los controles en pantalla y saber cuando usar cada control para cada uso específico.
• Lenguajes de Bajo Nivel: C o Assembler. En algún momento aparecen los problemas de desempeño, y hay que entender cómo un lenguaje de alto nivel nos abstrae de detalles de bajo nivel como punteros, uso de memoria, branching, aritmética, representación de la información en bits, etc. Cuando uno entiende esto puede llegar a optimizar el código de mejor manera.
• Arquitectura de Computadores, o cómo funciona un computador internamente. Esto incluye el conocimiento de hardware, redes, sistemas operativos. En algún momento se encontrarán con problemas de paginamiento, pérdida de paquetes, falla a nivel de hardware, y hay que saber como enfrentar esos problemas.
• Programar, programar, programar. Escribir código, leer código. Participar en algún proyecto opensource, escribir tu propio código, realizar algún code kata (ya veremos que es eso). Leer blogs sobre programación donde enseñen alguna técnica, o leer tutoriales sobre un framework, y probarlos por ti mismo.

Estas son las sugerencias de StackExchange y Penny Arcade sobre las habilidades para ser un buen programador/desarrollador de software, ¿qué opinan ustedes?

Con respecto a este blog, voy a imponerme una meta de escribir al menos un post semanal, esto incluirá un desafío de programación al mes, así que atentos. Pero voy a orientar este blog a que significa ser un buen programador, contar algunas historias, personales o que he presenciado, probablemente invitar a otros programadores. El objetivo de este blog será enseñar y transmitir experiencia. Hay una gran necesidad de contar con buenos programadores, y espero con este blog motivar a más gente a dedicarse a este hermoso oficio.

Hay muchos lugares donde se pueden aprender técnicas, lenguajes de programación, etc. Este blog pretende orientarlos en la búsqueda, también pretende acortar una brecha que existe respecto al idioma. Hay mucho material, pero está en inglés. Si quieren dedicarse seriamente a la programación deben aprender inglés, pero mientras tanto, hay que ayudar con algo de material en nuestra lengua.

Esos son los planes para este blog durante este año, espero verlos más seguido y me comprometo a cumplir con estas metas, y espero vuestro apoyo.

[1] Acá hay nota introductoria sobre GitHub en mi otro blog: http://www.lnds.net/blog/2012/02/el-senor-de-los-archivos.html

GitHub permite arrendar espacio en sus servidores para alojar nuestros repositorios, y hay otros servicios por ahí. Pero una alternativa bastante ingeniosa es usar DropBox, alojar nuestros repositorios en la carpeta compartida de Dropbox, crear repositorios limpios (bare repositories) y hacer git pull/pull localmente sobre esa carpeta compartida. La idea aparece en este post (en inglés), y es bastante simple y potente.

Supongo que esto también puede servir con otros gestores de control de versiones, como Mercurial o Bzr, pero incluso es una buena idea que se podría aplicar con gestores más tradicionales como Subversion. Si alguien lo implementa con esos sistemas lo invito a comentar y compartir la experiencia.

http://www.programando.org/aprende-a-programar/segunda-parte/arquitectura-de-computadores/dispositivos.html

Este capítulo cierra la parte dedicada a la arquitectura de computadores. A continuación retomaremos el objetivo de la segunda parte del curso, que es construir una versión gráfica de nuestro juego.