Si pudieras elegir, si todas las empresas se pegaran por contratarte, ¿en que sector te gustaría trabajar?, ¿quizás en la NASA programando satélites o robots?, ¿quizás programando sistemas de cotización bursátil?, ¿o lo tuyo es la ciberguerra?. Cuéntanos que actividad es en la que te gustaría realizarte como desarrollador:

¿En que sector te gustaría trabajar?

Recuerda que para responder, debéis hacerlo desde nuestra sección de Genbeta Dev Respuestas(sigue el enlace) y en este post los comentarios están cerrados. Gracias.

En la anterior pregunta de la semana, os preguntábamos ¿Qué lenguaje o tecnología de programación te has puesto a aprender últimamente y cómo?. La respuesta ganadora ha estado muy disputada y no ha habido un ganador claro, de hecho, han sido Pablo Herrera y Daniel Esteve quienes han obtenido la mayor puntuación con las respuestas:

Justo en este momento estoy tratando de configurar un buen entorno de desarrollo para Coffescript, que es una verdadera delicia para programar Javascript. Su desventaja: es tan nuevo que los editores aún no lo traen por defecto, hay que configurar bastante. El que mejor lo integra es WebMatrix pero es demasiado lento y trabaja con su propio servidor. Por el momento recomiendo bastante este lenguaje, en especial si ya se ha trabajado lenguajes similares, como python y ruby.

y

Yo soy sencillamente un novato que quiere aprender por su cuenta, en estos momentos estoy en un frustrarte PCPI donde no es que tenga mucho que aprender… por mi propia cuenta estoy aprendiendo PHP para poder mantener,desarrollar y mejorar unos websites y esta siendo una gran aventura me he comprado uno de esos libros de anaya a nivel MEDIO de y eso que yo de PHP se lo justo pero sobre todo lo tengo para consulta de alguna y que otra función,código y consejo. Por suerte tengo unos cuantos amigos programadores y me echan una pequeña mano(no les dejo mas) y por uno de ellos estoy empezando a hacer mis pinitos en csarp sobre mono y como no LinuxMint, también por si te lo estas preguntando tengo 17 Años. Adiós y gracias por dedicar unos minutos a leer estas palabras

Muchas gracias a todos por participar. Nos vemos la semana que viene con las mejores respuestas a la pregunta que os hemos propuesto. Y recordad que la sección de Genbeta Dev Respuestas está a vuestra disposición para resolver todas las dudas que tengáis.

En Genbeta Dev Respuestas | ¿En que sector te gustaría trabajar?

Nos guste o no, vivimos en una sociedad en la que la ley de la oferta y la demanda regula lo que valemos en ella. Todos nosotros compramos aquel producto que, cubriendo lo que pedimos, sea el más barato (si el único que cumple es el más caro, entonces, es también el más barato que podemos comprar).

A nuestro alrededor vemos todos los días a personas que tienen jornadas laborales mucho más duras que las nuestras (hablo en general, tengo pocas dudas de que la jornada de los mineros o de las cajeras [por poner dos ejemplos] es más dura que la nuestra) y sin embargo es bien conocido el malestar de nuestra profesión.

Entonces, ¿si o no tenemos lo que merecemos?, ¿se aprovechan de nosotros porque les dejamos o porque pueden?.

Y lo más importante, si como yo, eres de los que no se rinden,

¿que podemos hacer para cambiar la situación?

Recuerda que para responder, debéis hacerlo desde nuestra sección de Genbeta Dev Respuestas (sigue el enlace) y en este post los comentarios están cerrados. Gracias.

En la anterior pregunta de la semana os preguntábamos ¿Qué eventos para desarrolladores no deberíamos perdernos? en la que se han anotado un buen número de eventos que pueden interesarte. El evento de desarrollo más valorado fue la respuesta de Rubén López García:

Recomiendo el HTML Tour que se va a celebrar dentro de nada en Bilbao, Barcelona, Madrid, Sevilla y Pamplona…

Muchas gracias a todos por participar. Nos vemos la semana que viene con las mejores respuestas a la pregunta que os hemos propuesto. Y recordad que la sección de Genbeta Dev Respuestas está a vuestra disposición para resolver todas las dudas que tengáis.

En Genbeta Dev | ¿Podemos mejorar nuestras condiciones laborales?

A todos nos ocurre alguna vez, que nos asombramos jocosamente al ver algunas soluciones que otros han aplicado; sonreímos con vehemencia (en el mejor de los casos) y comentamos mientras hinchamos pecho, que esa barbaridad se resolvía fácilmente de tal o cual forma.

Yo sigo asombrándome y sonriendo con vehemencia, pero en lugar de sacar pecho, procuro ver y hacer ver, que quizás había una razón para ello, que quizás esa persona (anónima o no) supo encontrar una solución en un campo de batalla, en el que quizás nosotros nos hubiéramos perdido.

Leyendo comentarios sobre el nuevo cambio de IVA, me he vuelto a asombrar y sonreír sobre algunas formas de enfocar el problema y me han venido a la cabeza la gran cantidad de variantes que hay a la hora de tratar con tan peliagudo problema. Un problema, que hace que muchos desarrolladores se conviertan en auténticos “hombre orquesta”. ¿O quizás piensas que es un tema sencillo?.

Advertencia

No soy contable ni nada parecido, lo poco que se del IVA es a fuerza de tener que hacer o trabajar con software que lo incluye en sus procesos, así, no tomes mis requisitos de IVA como una referencia, más bien como situaciones que quizás te encuentres en algún momento. Y si detectas un error u otros requisitos del IVA ¡coméntalo por el bien de todos!.

El IVA

El IVA es muchísimo más complejo de lo que puede parecer a simple vista. Si bien es cierto que el caso habitual es conocido por todos (¿seguro?), existen muchísimas situaciones y variables que lo modifican de una u otra forma. Puedes buscar cualquier libro de contabilidad y repasarte los temas del IVA, verás que de sencillos y concisos no tienen nada (a mi desde luego no me lo parecen).

Como ni puedo, ni debo, ni quiero, ni (probablemente) querrás tú, no entraré en conceptos que difícilmente conozco así, sólo indicaré en general situaciones que se dan o se deben contemplar al trabajar con el IVA.

Requisitos

Sea pues una lista informal (y seguro que incompleta) de requisitos a la hora de trabajar con IVA:

• El IVA de un producto, puede ser diferente según se lo vendas a uno u otro cliente (eg. nacional / extranjero pero hay más casos como ciertas organizaciones que no pagan IVA o lo tienen reducido).
• En caso (por ejemplo) nacional, tu aplicación, quizás deba aplicar el IVA local y descontarlo después, o no aplicarlo o contemplar ambos casos.
• El IVA de un producto, puede ser diferente (además) del tipo de producto de que se trate (eg. productos de primera necesidad / productos de lujo).
• El IVA de un producto, puede ser diferente (además) del IVA de otros productos incluidos en la venta (eg. los gastos de envío).
• El IVA de un producto, puede ser diferente (además) si ha sido manipulado y/o agrupado (eg. packs, ofertas, …).
• El IVA de un producto, puede depender (además) de la fecha de venta, pero resulta, que realmente manda la fecha de facturación ¡pero cuando vendes aún no sabes cuando se realizará la factura!. Por ello, frente a un cambio de IVA, la elección de la fecha en que cambia el IVA puede ser arbitraria (eg. unas empresas querrán facturar al finalizar el mes y otras al empezar, etc… incluso dependiendo del cliente final al que se le factura el día o semana que él decide).
• El IVA de un producto, puede depender (además) de ¡la fecha de disfrute! (eg. una estancia hotelera dentro de un mes), que a su vez depende de la de facturación, etc… (hay hoteles que prefieren facturar al entrar el cliente, otros al salir, otros al terminar el mes de la fecha de salida, etc…)
• El IVA de un producto, puede que ¡no tengas que procesarlo! (pero si el importe). Por ejemplo cuando incluyes en la venta productos o servicios que tú no facturarás (lo hará otra empresa ¡pero tú debes contemplar también su casuística!).

Si ésto aún no es suficiente para ti (auténtico Chuck Norris del IVA), espera, porque hasta ahora únicamente hemos “definido el IVA” (incluyendo el concepto de “desconocido” no lo olvides).

Peticiones “especiales”:

• Se desean cargar los precios de venta con impuestos incluidos, de tal forma que el precio final sea siempre un número prefijado (eg. 100,00 euros). (Cuidadito con este requisito, en general, es una trampa mortal [no tiene solución para algunos casos]).
• Junto con la anterior, se desean tener tarifas netas (cargadas sin impuestos). Es decir, debes procesar simultáneamente importes que llevan o no llevan el IVA (luego totalizar, agrupar impuestos, excepciones, gastos fuera de IVA, etc…).
• Si has sido capaz de componer todas las reglas de negocio, ahora resulta que debes exportar los precios para que otro sistema los procese. (Cuidadito con los decimales, seguramente deberás desnormalizar datos, etc…).
• Múltiples divisas y aquí hay mucho juego, puede ser que el cambio de divisa sea informativo o que se permita al cliente final pagar en la moneda elegida; puede ser que los precios se carguen en una divisa y deban convertirse a otra (manteniendo estrategias como “precios redondos”).
• Pasarela de pago, convirtiendo los importes de una divisa a otra (cuidado decimales).
• Aplíquense reglas adicionales “al gusto” sobre cálculo de comisiones (que se aplican sobre el neto y/o bruto) y el IVA de esas mismas comisiones.

Bueno, seguro que hay muchas otras situaciones, he puesto las que me han venido a la cabeza y con las que de una u otra forma habré tenido que trabajar en algún momento.

Como anécdota diré, que una vez había que pasar ciertas tarifas de netas (sin IVA) a brutas (con IVA); tras comentar que el cambio no era trivial en nuestro sistema, nos comentó alguien de un sistema remoto con quien conectábamos que “sólo es multiplicar los precios de una tabla”, aún se pueden oír las risas de nuestro equipo (el extremo no conocía nada de nuestro sistema para poder hacer tal afirmación).

Problemas fáciles, problemas difíciles

Igual que con el IVA, con otros problemas se producen situaciones similares en todo momento. Problemas aparentemente triviales se convierten en auténticos quebraderos de cabeza, y son éstos, precisamente, de los que se oye recurrentemente la frase “¡pues si es muy fácil!”.

Así, te animo a ser cauto y/o condescendiente cuando creas ver una barbaridad (chapuza, desastre, etc…) y esperes a tener más datos del problema para crucificar al pobre tipo que, al fin y al cabo, supo solucionar el problema.

Me habrás oído decir en alguna ocasión, que el problema real que debemos solucionar y su solución, no reside en ningún lenguaje de programación concreto, en todo caso, el tener que usar un lenguaje concreto es una más de las restricciones del problema.

Esta forma de pensar y mi afición al juego de la búsqueda de algoritmos me llevó hace unos tres años a encontrar una curiosa solución al esquivo problema NP-completo, al punto de poder resolverlo en tiempo lineal (sí, coste temporal en O(n)); un gran logro sin duda, si no fuera porque el tamaño de la memoria tiene coste exponencial (¡ouch!, O(eⁿ)).

Aún así, fue emocionante analizar esa posibilidad, porque la solución se basa en utilizar las propiedades de las transparencias y una fotocopiadora para codificar la solución. Si sientes curiosidad por ver cómo tan vetusto aparato puede solucionar tamaño problema te animo a leer Programando con una fotocopiadora.

El problema de la suma de subconjuntos

Un problema muy sencillo de plantear y entender pero muy difícil de resolver, es el problema de la suma de subconjuntos. En él, se trata tan sólo de decir si sí o no es posible sumar una cantidad K con los números C = {z1, z2, …zN} que nos dan.

Por ejemplo, si C = {1, 7, 3} y K = 4 es fácil ver que la respuesta es sí.

Para no salirnos del tema, puedes leer sobre NP-complete. Para el caso que nos ocupa, será suficiente con que sepas que si alguien es capaz de resolver el problema anterior de forma eficiente, será capaz de resolver una gran cantidad de problemas muy importantes de forma eficiente, donde eficiente es resolverlos en tiempo polinomial.

Para que te hagas una idea, hoy en día no es posible encontrar la mejor organización de los componentes electrónicos en una placa (si no sabes nada de electrónica, te sonará que esas placas están llenas de pistas de cobre que van y vienen por todos lados), por ello, se utilizan algoritmos que intentan obtener una buena organización, pero no son capaces de asegurar la mejor organización. Otros muchos e importantes problemas prácticos deben ser aproximados (a veces es suficiente pero otras no) o no pueden ser resueltos y nadie sabe todavía si existe un algoritmo eficiente para resolverlos.

Al menos, se sabe que si alguien demuestra que uno de estos algoritmos no puede resolverse eficientemente, entonces se sabrá que no se puede ninguno (y no habrá que seguir buscando) y más interesante, si alguien demuestra que puede resolver eficientemente uno sólo de estos algoritmos, podrá resolver eficientemente todos estos algoritmos.

Por ahora, no existe mejor solución que (básicamente) ir revisando todas las posibilidades del problema e ir verificando una a una si se cumple o no. Bueno, en realidad (no seamos demasiado laxos), cuando se concreta un problema, siempre se puede hacer alguna mejora. Por ejemplo en el caso del conjunto suma, la mejor solución tiene coste O(2^n/2) que es exponencialmente más eficiente que la trivial, pero sigue siendo exponencialmente más costosa que una polinomial.

Algoritmos y ordenadores

Obviamente cuando diseñamos un algoritmo una de las principales restricciones que tenemos es que debe correr en nuestro ordenador; aunque esta restricción sea obvia, no por ello deja de ser una restricción que podemos considerar eliminar del problema.

Los físicos y en particular ingenieros resuelven diariamente multitud de problemas que podrían definirse como “algoritmos”, un ascensor, unas escaleras mecánicas, los procesos para la elaboración de la lejía, etc… son soluciones que, puestas sobre el papel, se asemejan mucho a las soluciones que definimos los programadores. Una receta de cocina, no deja de ser un algoritmo que es ejecutado por un cocinero.

Puedes estar seguro, que si resuelves el problema NP-complete con una patata y un mondadientes, nadie se va a quejar de que no compila con GCC.

La solución eficiente, de ser encontrada, actuaría directamente en nuestros programas (como una API) o indirectamente como un coprocesador matemático. Muchas personas analizan este tipo de alternativas, en las referencias puedes encontrar una forma usando DNA y es un debate caliente en física la posibilidad de encontrar propiedades cuánticas que puedan ser explotadas para resolver problemas NP-complete.

Las transparencias

Una transparencia es como una hoja de papel pero transparente. Antiguamente (eg. cuando yo estaba en la Universidad) se usaba como sustituto de PowerPoint y similares. Al ser transparentes, se podía fácilmente dibujar por capas las partes de un coche, el cuerpo humano, etc… la forma de verlas, era poner una o varias en un proyector de transparencias.

Resolviendo NP-complete con transparencias y una fotocopiadora

Se trata de ver si dado un conjunto de números, algún subconjunto suma una constante dada. El algoritmo ingenuo es ir revisando todas las formas de agrupar los números y ver si alguna agrupación suma dicha constante. Pero claro, combinaciones de N elementos tomados de 0 en 0, tomados de 1 en 1, …, tomados de N en N hace un total de 2^N agrupaciones, por tanto, en el peor caso, tendremos que revisar un número exponencial de agrupaciones.

Por ejemplo, sean los números { 1, 2, 5, 9, 13 } y el valor que deben sumar sea 15, entonces haríamos:

Es decir, a cada paso, obtenemos el doble de números que la vez anterior porque seguimos dejando los números que teníamos y añadimos esos mismos números pero sumando el elemento que procesamos. Si algunos de los nuevos números es el que buscamos, detenemos el proceso.

¿Y si pudiéramos en cada paso sumar ese nuevo elemento a todos los grupos existentes en un sólo paso (simultáneamente)?, en ese caso, el algoritmo tendría coste lineal, pero resulta que con una transparencia podemos hacer precisamente eso, vemos como:

Algoritmo para la fotocopiadora

Como soporte de almacenamiento, necesitamos un máximo de tantas transparencias como números haya en la lista de entrada. Si nos dan 10 números, necesitaremos 10 transparencias como máximo, si nos dan 100 números tan sólo necesitaremos 100 transparencias como máximo. Fácil ¿no?, incluso conseguir 1000 transparencias no parece nada complicado.

El algoritmo para resolver “SubSet sum” en nuestra fotocopiadora es sencillo:

• Todas nuestras transparencias deben tener en la base una línea negra horizontal.
• Tomamos la primera transparencia y la ponemos en la fotocopiadora desplazada una longitud linealmente proporcional al primero número.
• Hacemos una fotocopia en una transparencia nueva.
• Sin quitar la primera transparencia, ponemos la copia realizada desplazándola una longitud linealmente proporcional al segundo número de la lista.
• Hacemos una fotocopia en una transparencia nueva.
• Sin quitar ni la primera ni segunda transparencias, ponemos la copia realizada desplazándola una longitud linealmente proporcional al tercer número de la lista.
• …, y así sucesivamente, repetimos el proceso haciendo tantas copias como números nos hayan dado o bien cuando exista una línea horizontal en la posición linealmente proporcional al valor constante buscado.

El método es tan simple que apenas requiere de explicación. Cada fotocopia que realizamos contiene todos los números anteriores y al desplazarla, estamos sumando todos esos números al del desplazamiento ¡a la vez!.

La solución no es práctica

Probablemente pienses que no es operativo usar unas transparencias y una fotocopiadora, pero ese no es el problema de que el método no sirva en la práctica, los problemas técnicos asociados a la máquina no son tales. Uno puede decir que no es posible hacer una fotocopia cuando en lugar de una hoja tenemos un bloque de (digamos) 30 transparencias, pero este sencillo problema se resuelve haciendo una fotocopia adicional cada pocas (e incluso a cada una, seguiría siendo lineal) fotocopias “desplazadas”. También se puede quejar uno de que no es posible calibrar el desplazamiento que debe hacerse cuando los números son muy grandes (y por tanto el desplazamiento muy pequeño) pero existen elementos para calibrar a nivel atómico. Otros problemas como la dispersión de la luz al atravesar la transparencia o el poder reutilizar el soporte son “sólo” problemas técnicos que de una u otra forma podrían resolverse.

Es obvio que la construcción de la “SubSet Sum Machine” (como yo llamo a la hipotética máquina) distaría de ser la tan sencilla fotocopiadora, sin embargo es notable que su limitación difiere completamente de las limitaciones de los algoritmos actuales (exponenciales en tiempo) pues siempre podrá resolver linealmente cualquier problema en la que la constante K quepa en el dispositivo de almacenamiento (la transparencia).

La limitación real de la máquina consiste en que muchos algoritmos se transforman al problema “subset sum” usando una representación exponencial de K (algo como K = 2^z) y por tanto el tamaño que debe tener la transparencia pasa a ser exponencial. Aunque pudiéramos calibrar nuestra fotocopiadora a nivel atómico y nuestras transparencias fueran una sucesión de átomos de hidrógeno, “sólo” podríamos disponer en cada hoja de aproximadamente 2.970.000.000 átomos, lo que significa que en una hoja sólo podríamos resolver problemas cuya constante K no supere ese valor. Esta limitación hace inútil (o al menos de momento) la solución propuesta.

Conclusión

Además de disfrutar con esta partida en la fascinante búsqueda de algoritmos, han quedado claras las propiedades exponenciales del problema NP-completo analizado. Si estás interesado en profundizar en las propiedades de tamaño problema y el estado del arte del mismo, te sugiero a un gigante en la materia, David Pisinger, con su artículo Where are the hard knapsack problems? (son sólo 14 páginas).

¡Eh! ¿y que pasa si yo lo resuelvo?

Bueno, en otras disciplinas como las matemáticas (en las que tendrías que convencer a gente sesuda que lea tu trabajo) o en física (tendrías que conseguir inversores que te financien el desarrollo) sería complicado hacer valer tu trabajo o tendrías que revelar tu descubrimiento. Afortunadamente, si eres capaz de resolver eficientemente un problema NP-completo, podrás fácilmente colgar una página web en la que cualquiera pueda postear un problema muy difícil para tu algoritmo (elige alguno de entre 3SAT, TSP, Knapsack, etc…) y dile en cuanto tiempo lo tendrá resuelto (antes habrás analizado empíricamente el coste real de tu algoritmo para hacer predicciones precisas). Sin revelar tu poderoso algoritmo, convencerás al mundo de su valía y el dinero empezará a caer sobre tu cabeza.

Como diversión, está bien pensar que quizás lo resuelvas, pero advertido quedas de que se cree que tal solución no existe y por tanto, estarías buscando la piedra filosofal…

Más información | Where are the hard knapsack problems?.
Más información | NP-completo.
Más información | Problema de la suma de subconjuntos.
Más información | Using DNA algorithms to solve NO-complete problems.

Hay cierto tipo de pasatiempos que, siendo pasatiempos, producen en quien los practican gratificantes emociones. Cuando se consigue un equilibrio entre dificultad y éxito es cuando más fuertes son las emociones. Preguntarle la hora a alguien enfrascado en resolver un Sudoku, es como preguntársela a una farola. ¿Cuantas veces os han tenido que repetir vuestras madres la frase “¡a cenaaaaaar!”, mientras repetís (nivel tras nivel) “¡que ya voy!”?. No es casualidad que juegos como el Tetris con suaves curvas de dificultad sean tan populares, mantienen al sujeto en ese preciso equilibrio de dificultad (reto) y éxito (progreso). En la mayoría de los casos da igual si “ganas” o no, de hecho, no “ganar” es un aliciente para intentarlo de nuevo (mientras se mantenga el equilibrio de éxito).

Una de las principales cosas que hacemos los programadores es buscar algoritmos, soluciones eficientes a los problemas del día a día, esa búsqueda de mejorar nuestros procesos es normalmente un aliciente para muchos (y me incluyo). Pero igual que en el Counter-Strike, si el desafío se produce ante otros, toma mayor relevancia (así es el ser humano, que le vamos a hacer).

La fascinante búsqueda de algoritmos

La fascinante búsqueda de algoritmos tiene diferentes y variados modos de juego; podemos conocer la dificultad del problema o no, saber si hay solución, tener una definición estricta o que admite ajustes, en un lenguaje concreto, etc… pero dos de los que a mí más me gustan son:

• Problemas con una definición muy muy sencilla pero que son muy muy difíciles.
• Problemas para los que hay una solución eficiente y encontrar una variante más eficiente todavía.

Del primer tipo, es muy muy (pero que muy) improbable que encontremos una solución (para mí, al menos), pero su sencilla definición permite que le demos muchas vueltas al problema y encontremos montones de estrategias interesantes que luego podemos aplicar en otros algoritmos. Un ejemplo típico sería (nada más y nada menos) que buscar un algoritmo eficiente para un problema NP-completo, si no recuerdas cuales son, aquí tienes dos:

• Dado un conjunto de números C = {n1, n2, …, nM} responder SÍ o NO (nada más) a la pregunta “¿Existe un subconjunto de C que sume K?”. Por ejemplo, si es C = {1, 7, 3} y K = 4 la respuesta es SI.
• Dado un mapa de carreteras y una lista de ciudades, responder SÍ o NO (nada más) a la pregunta “¿Existe una ruta que pase por cada ciudad una sola vez?”. Por ejemplo, en la imagen:
  

Del segundo tipo la dificultad depende de quien haya indicado la solución, es común en foros o en sitios como Solveet que los “participantes” vayan refinando las soluciones (incluso sus propias soluciones) en tal caso será frecuente que podamos aportar soluciones mejores refinando unos las soluciones de otros (en una especie de brainstorm informal). Otras veces sin embargo, las soluciones son “oficialmente las mejores” en cuyo caso será muy difícil que las podamos mejorar, pero siempre queda la posibilidad de mejorar casos concretos.

Quizás un ejemplo representativo de esto último podría ser el problema de triangular un polígono simple (como los que se estudian en el cole), es un problema abierto el obtener un algoritmo más sencillo que el de Bernard Chazelle (de coste lineal). Obtenerlo está (casi seguro) muy lejos de nuestro alcance, pero tomado como un juego, es emocionante darle vueltas y descubrir propiedades y estrategias que no se te habían ocurrido antes.

Así, existen infinidad de problemas de algorítmica de diversos temas y dificultades que podemos resolver (o intentar) con el fin de matar el tiempo, practicar un determinado lenguaje, aprender y pensar en nuevas estrategias, retar a los demás para saciar nuestra innata sed de competitividad, etc…

Lugares donde encontrar desafíos

En mi opinión los mejores sitios para obtener desafíos son la documentación universitaria (y biblioteca técnica y científica asociada), en ella se encuentran desafíos de todo tipo, mostrados con rigor, por personas que saben mucho sobre lo que escriben y cuyas soluciones, hayamos dado o no con ella, seguro que nos aportarán una información valiosa.

No tienen porqué ser libros cargados de teoremas y análisis extensos; muchos se centran en aspectos prácticos como al estilo de “Gráficas por computadora en Basic” que contienen montones de ejemplos. Hay bastantes y muy buenos cuyos títulos suelen ser “Algoritmos de …” que contienen un buen puñado de retos por resolver (con sus soluciones, claro).

En OpenLibra (comentado frecuentemente en GenBeta Dev) hay multitud de libros similares a los que puedes acceder gratuitamente.

Pero si no queremos seguir un método ni horario, también podemos recurrir a Internet por supuesto, aquí una pequeña lista de sitios que se me ocurren (seguro que hay muchísimos más):

• List of algorithm general topics en Wikipedia es un buen punto de partida, podemos navegar por las materias que más nos interesen (IA, gráficas, cálculo numérico, etc…).
• Solveet, que Juan ya nos presentó En su día y que contiene problemas y soluciones en múltiples lenguajes.
• Rosetta Code, que contiene multitud de algoritmos resueltos en multitud de lenguajes.
• Programming praxis, sitio que lleva tiempo presentando periódicamente problemas y que la gente resuelve de manera informal (sin rankings ni nada parecido).
• Project Euler, que se centra en problemas de tipo numérico aunque no de forma estricta (eg. también de combinatoria).
• 4 Clojure, específico para Clojure, guardando las versiones con tus progresos y validación automática sobre los test definidos en cada problema.
• Code Chef, que promueve la cooperación y competitividad.
• Top Coder, sitio muy famoso y con muy elaboradas herramientas que a mí personalmente no me gusta porque tiene demasiado control sobre los programadores (y se trata de pasar un buen rato, no de sentirte observado).

Pero recuerda, se trata de pasar un buen rato, encuentra aquellos problemas que están dentro de tu “zona de juego” (difíciles pero divertidos y asequibles a tu skill) y un consejo, nunca te tomes demasiado en serio los retos con que te encuentres.

Más información | Brainstorming.
Más información | OpenLibra libros técnicos en donde seguro encontrarás retos interesantes.
Más información | Polygon triangulation.

Es muy frecuente al desarrollar aplicaciones que los requisitos no estén completamente definidos desde el principio y/o que éstos sufran cambios a corto y medio plazo, bien porque son descartados, modificados o porque aparecen otros nuevos. Es por ésto que las metodologías ágiles establecen estrategias que se adaptan a dichos precarios escenarios.

Carlos Ble en su post Diseño emergente, también para la base de datos describe una forma de trabajar a nivel de base de datos mediante un enfoque emergente. Si bien muchos programadores llevan utilizando estrategias ágiles (o emergentes) desde hace mucho tiempo, y que lo que Carlos describe también se realiza desde hace mucho tiempo; la clarividencia con la que técnicas concretas (Scrum, Kanban, …) y Carlos en su artículo ponen de manifiesto un determinado aspecto es, a mi juicio, muy interesante y revelador, porque te hace pensar de forma consciente sobre problemas que llevas resolviendo, “inconscientemente”, desde hace mucho tiempo.

Así, con independencia de lo correcto o no de cada solución, del tipo de contexto que cada uno tengamos que resolver (y que serán diferentes), el compartir nuestras estrategias hace que cada cual piense en sus propios problemas y tome de cada uno aquello que le resulta útil.

Por tanto, te propongo un ejemplo práctico de cómo normalmente yo aplico el enfoque de Diseño emergente en la base de datos.

Breve reseña al diseño emergente

Cuando alguien diseña algo (un avión, una casa, un coche, …) es habitual planificar todos y cada uno de los aspectos que finalmente formarán parte del producto. Así, todo es diseñado y planificado de antemano. A modo de ejemplo llevado al extremo, podemos imaginar un sencillo y humilde tornillo ubicado en la parte interna de uno de los motores de los ya obsoletos transbordadores espaciales de la NASA. Es muy probable que dicho tornillo esté presente explícitamente en multitud de planos (no en todos, claro, en algunos estará presente de forma implícita) y que su tamaño, dimensiones y composición química fueran diseñados o elegidos realizando un cálculo concreto. Quien montara el motor, puso ese tornillo y no otro, porque así estaba decidido de antemano.

Un carpintero, puede construir una silla a partir de planos similares a los usados en la NASA, pero será probable que no se le indique el tipo concreto de tachuela que debe usar ni cuantas debe poner. Así, cuando el carpintero tenga que poner las tachuelas a la silla, decidirá en ese mismo momento que tipo de tachuela pondrá y con que separación. Es decir, el diseño final de la silla ha emergido del propio proceso de construcción, en oposición a una cuidadosa planificación previa.

Llevado al extremo, podríamos imaginar a un artista frente a un tronco de madera; el artista no sabe (no ha decidido aún) que figura va a esculpir, empieza observando el material, va esquilmando los trozos de madera agrietados o dañados, golpeando aquí y allá. Al poco vislumbra la imagen de un caballo rampante y comienza a dar grosera forma al material, pero aún no sabe cual será la posición de las patas, la cola, la crin, … todos y cada uno de los golpes del artista son espontáneos no hay absolutamente ningún tipo de diseño previo, cuando termina su obra, podemos decir que el caballo rampante ha emergido del proceso realizado por el artista.

En el diseño de software y concretamente en el agilismo, el diseño emergente se produce al aplazar decisiones, análisis, trabajos y/o requisitos sin que ello impida comenzar a desarrollar y utilizar las aplicaciones y sistemas involucrados. En cierto momento, surge la necesidad de implementar un requisito que ni siquiera se había comentados con anterioridad, este nuevo requisito a emergido del uso y/o desarrollo de la aplicación.

¿Es necesario el diseño emergente en la base de datos?

El artículo de Carlos me gustó porque puso de manifiesto un aspecto que ha estado presente desde siempre, pero que él ha sabido exponer de forma explícita y no como “un problema menor” con el que nos encontramos a diario. En los siguientes párrafos, intentaré transmitir el tipo de problema que se trata.

Como en cualquier elemento de software, un cambio en una parte afecta a otras y las bases de datos (concretamente relacionales) no son una excepción. Por ejemplo el añadir, quitar o cambiar las propiedades de un campo de una tabla, requiere normalmente ajustar otras partes del sistema. En casos concretos se dispone de herramientas que automatizan ciertos procesos (eg. CRUD), pero en general, cualquier cambio aparentemente nimio, exige un esfuerzo apreciable en otras partes del sistema.

El uso de ORM (Object relational mapping) es hoy muy común y permite automatizar buena parte del trabajo que hace un DBA (DataBase Administrator) tiene bastantes (y ágiles) ventajas. Algunos de los problemas que voy a describir se mitigan o eliminan completamente usando un ORM pero otros se mantienen igualmente. A mi en particular sólo me gusta usar ORM en aplicaciones compactas que hacen uso intensivo de un framework (eg. un portal web), en general, yo me siento muy cómodo teniendo en todo momento control sobre la base de datos, por lo que asumiré en lo siguiente que no se usa un ORM.

Respecto de las bases de datos, algunos ejemplos habituales que me vienen a la cabeza son los “campos zombies”, que serían aquellos que se introducen en el diseño pero que luego nunca se usan o se usan realmente poco, están en la base de datos, pero como si no estuvieran, de forma similar tendríamos las “tablas zombies”; otro ejemplo podrían ser las “tablas tocapelotas” que en diseño se han definido como relaciones “uno a cero o uno” pero cuya partición termina siendo un infierno porque realmente debería ser una única tabla y en todas las consultas se arrastra un horripilante “LEFT OUTER JOIN” que nunca o casi nunca actúa (siempre se hace el JOIN); otros muchos ejemplos provienen de un exceso o falta de normalización, a veces el diseño está muy normalizado penalizando en demasía el rendimiento obligando o bien a desnormalizar el diseño o a crear estructuras adicionales de cacheado; el caso contrario es una falta de normalización (cuando en diseño se piensa que el producto cartesiano en la práctica será pequeño, pero no es así) que produce tablas con ingentes cantidades de registros (innecesarios).

En definitiva, existen muchas situaciones en las que el mejor diseño no está claro (los motivos de que no estén claros son muy variados y pocas veces debidas a cuestiones técnicas) y es sólo cuando la aplicación se pone en marcha que emergen esos fallos dejando patente un mal diseño.

Diseño emergente en la base de datos

Como solución a los problemas mencionados, Carlos propone incluir en las tablas que lo requieran un campo en el que serializar todos aquellos datos cuyo diseño no esté claro aún. Por ejemplo, podemos llamar al campo xdata y serializar a json, xml, … después utiliza esa información en la capa de aplicación.

Yo utilizo ese esquema cuando los datos dentro de xdata no tengo que procesarlos internamente en la base de datos, habitualmente porque hay aplicaciones externas y personalizables que hacen uso de ella. Aun así, rara vez directamente en un campo xdata como tal, yo prefiero normalizar ese campo, veamos como.

La tabla de registro

Muchos conoceréis el “Windows Registry”, realmente no es mas que una gran tabla que asigna un valor a una clave. La estructura arbórea que surge, proviene únicamente de fijar delimitadores en las claves (como una ruta de archivo en /home/josejuan/datos/listado.txt).

Un resumen muy general de mi estrategia preferida sería precisamente esa, tener una tabla que almacena pares de “clave + valor”.

Por poner un ejemplo, los diferentes estados en los que puede estar un semáforo, se podrían codificar como:

De esta forma, no es preciso crear una tabla semáforo para almacenar los posibles estados en que puede estar. Si por ejemplo cuestionamos la necesidad de tener un campo “telephone 3” en la tabla “USER” se podría codificar en la misma tabla anterior como:

Por claridad y rendimiento, suelo tener tablas de registro especiales para conjuntos de datos especiales. Por ejemplo, si nuestro sistema cuenta con entidades “EMPRESA” será habitual tener una tabla de registro especial para esta entidad.

Me consta que este tipo de estrategias de una u otra forma es usada por muchos programadores.

Ejemplo práctico

Por escribir algo de código y clarificar la estrategia anterior, supongamos que estamos creando una aplicación (usando Extreme programming) y que por el momento únicamente necesitamos registrar cuentas de acceso para los usuarios, en tal caso, con la siguiente tabla sería suficiente:

El Product Owner rápidamente empieza a pedir requisitos que si bien están claros, son coherentes y son validables, tenemos serias dudas de su utilidad práctica final (algo subjetivo mientras no se demuestre lo contrario) ¿serán necesarios los cuatro campos de teléfono, dos de fax, el correo principal, el secundario y otros tantos campos “de imperiosa necesidad”?. Tras ver las orejas al lobo, decidimos cumplir con los requisitos usando una tabla de registro, que podría ser ésta:

Por tema de eficiencia, hemos dejado dos campos valor: uno pequeño y con datos en la página de registro y otro blob de acceso lento. Como verás, el campo pequeño es de tipo varbinary porque será capaz de almacenar cualquier tipo de dato que sea necesario (nosotros almacenamos un número como un número, no como una cadena, una fecha como una fecha, etc…).

Para probar el rendimiento de las consultas, vamos a generar 10.000 registros de usuario con aproximadamente unos 100.000 registros de valores en la tabla de registro. Esto se puede hacer con el siguiente script:

Los datos han generado para cada usuario la siguiente información:

• last_access, un campo fecha con la fecha de último acceso del usuario.
• error_count, un campo numérico con el número de errores asociados al usuario.
• message_status, un campo de texto con un mensaje de estado asociado al usuario.
• message list, que es una tabla asociada al usuario con un histórico de mensajes (mensaje 1, mensaje 2, …).

Para acceder a los datos, se puede utilizar una vista que simule una tabla, de forma que se minimizan los cambios a realizar en las consultas (básicamente añadir o quitar campos) en caso de cambios en la estructura. Por ejemplo la siguiente vista permite acceder (indizada adecuadamente, es decir, es eficiente) a los campos de registro de cada usuario:

(Esta consulta es estándar pero puede implementarse mediante PIVOT TABLE que en ciertos escenarios puede tener un mejor rendimiento).

Para acceder al histórico de mensajes, también podemos simular una tabla a partir de la de registro, por ejemplo:

En ambos casos, a partir de una tabla de registro a la que pueden añadirse estructuras adicionales, hemos creado dos “tablas virtuales” sin tener que modificar la estructura de la base de datos.

Por ejemplo, para listar los usuarios con más de 9 errores en los últimos 3 días bastaría escribir:

O bien para saber cual es el número medio de mensajes y longitud media por mensaje de todos los usuarios bastaría con hacer:

Como vemos, podríamos incluso realizar vistas y consultas sobre datos (claves) que ni siquiera existen.

Utilidad de la tabla de registro

La utilidad de la tabla de registro es bastante limitada como medio de evolucionar “emergentemente” una aplicación. En mi opinión, otras técnicas ágiles, usar ORM o refactorizar serán probablemente mejores alternativas que trabajar en el diseño y estructura de la aplicación apoyándose en la tabla de registro.

Además, aunque depende del tipo de aplicación, cambios en la lógica de negocio e interface de usuario son mucho más costosos que en la base de datos, un DBA experimentado no tiene problemas en añadir, eliminar o modificar objetos de la base de datos, quizás son algo molestos, sobre todo si lo usas en combinación con una herramienta CASE y datos en vivo, pero nada que no se pueda hacer en unos minutos.

Sin embargo, la tabla de registro es insustituible como medio para añadir de forma rápida y versátil estructuras que no suponen un coste añadido o a posteriori. Para almacenar valores de informe, de histórico, datos constantes, de configuración, … y en general, datos que no tendrán un coste o cobertura muy alta en la aplicación (si un dato es altamente actualizado, accedido, mapeado, … desde muchos puntos, será preferible que tenga “entidad propia”).

Así, yo la uso indiscriminadamente como forma de disponer de un gestor No-SQL dentro de mi gestor Sí-SQL.

Vía | Diseño emergente, también para la base de datos.
Más información | Emergent Design.
Más información | Windows Registry.
Más información | Extreme programming.
Más información | Object relational mapping. Database Administrator.

En ocasiones anteriores hemos visto que como programadores, podemos escribir el código ingenuo (evidente, fácil, sin pensar, …) o podemos entrenarnos (como los deportistas) para obtener un mejor rendimiento a la hora de escribir nuestro código. Mejor rendimiento es, por supuesto, obtener el resultado más próximo al ideal dentro de las restricciones fijadas por el contexto; por ejemplo, si tenemos un minuto para escribir el algoritmo, alguna optimización podremos hacer, pero no podremos darle demasiadas vueltas (o si prima la legibilidad, etc…).

Una de las cosas que suelo observar, es que muchos programadores se centran en el lenguaje, en el hecho de que están programando una máquina. Sí, eso es evidente, pero si queremos resolver un problema, deberemos comprender en dónde reside su dificultad intrínseca (la que no depende nada más que de ese problema). Y en un algoritmo, su dificultad reside en su complejidad computacional intrínseca (la que no depende de la implementación).

Así pues, ¿dónde está la complejidad de los algoritmos?.

Breve introducción a la complejidad computacional

Cuando en algún sitio lees algo como “tal algoritmo tiene un coste de O(n log n)“, o algo como “la complejidad de ese proceso es O(n²)“, o más rebuscado como que “puede mejorarse a O(|xs| * n + n + n log n)“; lo que te están indicando es algo realmente útil y que no es más, que el número máximo de operaciones necesarias para resolver el problema.

Pongamos algún ejemplo. El siguiente algoritmo para calcular el valor máximo y el valor mínimo de una lista de números tiene por coste O(2n) donde n es la longitud de la lista, veámoslo:

Obviamente puede hacerse en O(n) de esta forma:

(Nota: el algoritmo es sencillo pero, ¿habrías puesto el else?)

Sin embargo, si sabemos que la lista está ordenada, resulta que el coste es O(2). Veamos:

“Si, bueno” te dirás, “¿Pero a que nos referimos con número de operaciones?”. Cierto, en el último algoritmo (con coste O(2)) no se realizan solo dos operaciones, si mirarámos el código que al final tiene que ejecutar la máquina veríamos que realiza muchas operaciones, no solo dos.

En realidad, para no añadir de golpe muchas ideas, arriba he dicho que O(n) (y otros) representa el número de operaciones, pero no es cierto. La complejidad computacional analiza el coste de un algoritmo en todos los sentidos posibles, incluida la cantidad de memoria necesaria para resolverlo, accesos a disco y, en general, cualquier coste que sea digno de tener en cuenta.

Por tanto, si comparamos el primer y segundo algoritmos que hemos escrito, lo que realmente va a marcar una diferencia significativa es la longitud de la lista de entrada y por eso se indica el coste del algoritmo en base a dicha longitud. Por ejemplo, si el número de valores a agregar fueran significativos (máximo, mínimo, promedio, cuadrado, etc…) entonces probablemente, indicaríamos el coste del algoritmo no sólo con la longitud n de la lista, sino también con el número (por ejemplo m) de valores a agregar.

Así, una buena especificación del coste de un algoritmo, tiene que tener en cuenta todas aquellas variables (n, m, …) que de variar, afectarán drásticamente al rendimiento del algoritmo.

Sólo por poner un ejemplo de especificación de rendimiento de algoritmos en base a otra cosa que no sea la velocidad de ejecución (número de operaciones), mostraré la comparativa en cantidad de memoria utilizada. Supongamos que queremos saber, dada una lista de números, que elemento ocupa la posición central tras aplicar una operación a todos los números y ordenar los resultados.

Una forma de hacerlo es usando un array temporal:

Que tiene un coste de memoria O(n) adicionales pues debemos crear un array temporal; sin embargo, en cuanto a velocidad, supuesto que el cómputo con un coste relevante sea funcOperator, sólo requiere O(n) operaciones (estamos suponiendo que el coste de la ordenación puede despreciarse). Sin embargo, es posible hacerlo sin memoria adicional (¿sabrías hacerlo?), veamos como:

En este caso no hace falta memoria adicional, así, el coste de memoria (adicional) es O(0) ¡gratis!; sin embargo, en cuanto a velocidad, en las mismas suposiciones que el de antes, supone un máximo de O(n²) operaciones.

“¿Y saber este tipo de cosas es importante?”, importante no, ¡importantísimo!. Nuestro trabajo consiste en programar y/o utilizar algoritmos para resolver los problemas ¿cómo vamos a elegir los adecuados si no conocemos sus propiedades?. Supón que eres un transportista y que tienes una furgoneta, ¿aceptarías el compromiso de llevar un paquete de Madrid a Barcelona sin conocer previamente el peso y dimensiones del paquete y el peso y dimensiones máximas que soporta tu furgoneta?, si fueras un buen transportista, no lo aceptarías sin conocer esa información y contrastarla.

Muchos programadores “funcionan” escribiendo el código en algún lenguaje y “viendo” por donde “cojea”. Usar un depurador, un profiler, una herramienta de cobertura de código, etc… es muy mala práctica si se usan como el medio a través del cual escribimos nuestro código (son buenas prácticas para prevenir, detectar y corregir los inevitables errores que todos los humanos cometemos). Digamos que todos pondríamos un extintor en la cocina por si se prende fuego ¡pero nadie prende fuego a la cocina para asar un pollo porque tenga un extintor!.

¿Dónde está la complejidad?

Ahora que hemos definido complejidad y hemos visto que es algo a lo que siempre debemos estar atentos para escribir un buen código, ¿cómo la encontramos?, ¿en qué nos tenemos que fijar para saber qué hace que un algoritmo sea más o menos complejo que otros, y encontrar por tanto, las mejores alternativas a nuestros problemas?.

Inevitablemente las herramientas con que contemos para resolver el problema (eg. el lenguaje de programación que debamos usar) serán determinantes (y por tanto debemos conocer las propiedades del lenguaje), sin embargo, habitualmente hablamos de lenguajes de propósito general precisamente, porque en teoría, el lenguaje no impone ninguna limitación a la hora de implementar una estrategia (un algoritmo) determinado (en la práctica si, obviamente).

En los ejemplos anteriores, se han presentado diferentes estrategias (algoritmos) escritos en javascript (implementación), pero cualquier programador puede entender la siguiente estrategia (¡algoritmo!): “ordénese una lista de números; en la primera posición encontraremos el mínimo y en la última posición el máximo”. ¿Hace falta implementar esta estrategia (algoritmo) en algún lenguaje concreto para saber que tiene un coste O(n log n)?, no, claro que no, porque de alguna forma, hemos sintetizado (abstraído) los elementos del problema.

Así, al enfrentarnos a un problema, debemos hacerlo en una primera etapa, pensando únicamente en las propiedades esenciales (abstractas) de los elementos que componen el problema. Luego, en la medida que conocemos esas propiedades, podemos pasar a nuestro “contexto de implementación” y ver cuales de esas propiedades son las más adecuadas para explotar en dicho contexto.

Pero es que además, si tenemos libertad en fijar el contexto de implementación, seremos capaces de elegir el mejor lenguaje en cada situación (o herramientas en general). Por ejemplo, en Solveet propusieron el siguiente problema: “si escribimos consecutivamente todos los números naturales (sin dejar espacios), tendremos algo como 12345678910111213… ¿qué dígito encontraremos en la posición n?”. Sólo tras pensar en el problema, en las propiedades que posee, podemos llegar a soluciones como esta en shell:

(Que no es nada eficiente, pero sí muy concisa). Otros ejemplos son aquellos en los que es posible usar programación lineal, ¡ni siquiera hace falta escribir código para resolver el problema!.

Conclusión

La complejidad de los algoritmos que como programadores nos vemos obligados a escribir y utilizar todos los días, reside únicamente en el problema real que debemos solucionar. Muchas veces creemos que debemos usar tal o cual herramienta, tal o cual lenguaje, tal o cual algoritmo, etc… y no es cierto (si usar un lenguaje es un requisito, entonces forma parte del problema real).

Así, céntrate primero en las propiedades del “enunciado” y juega con ellas mentalmente, la mejor estrategia (algoritmo) te vendrá a la cabeza mientras miras ensimismado por la ventana.

Más información | Teoría de la complejidad computacional.

El Grid computing aprovecha un conjunto heterogéneos de recursos de forma conjunta. Así, una empresa podría utilizar, en segundo plano, todas las CPU de sus empleados para realizar cálculos en lugar de tener un centro de cálculo específico o podría usar el espacio libre en los discos para tener un servidor de datos distribuido y altamente tolerante a fallos. Proyectos como BOINC son ejemplos de computación distribuida heterogénea.

Sin embargo, para utilizar todos estos recursos, normalmente hace falta una planificación e infraestructura. En casos como BOINC es preciso darte de alta, instalar un programa, etc…

Hoy, os propongo un juego (un katta si queréis), ¡aprovecharnos del poder de cómputo de todos los ordenadores de todos nuestros internautas!. El juego se llama Anonymous Grid Computing.

Introducción

Como veremos, en unas pocas líneas de código podemos acceder a una ingente cantidad de potencia de cálculo. El esquema es válido en un entorno real pues el único requisito es tener una conexión a internet. Todo los ordenadores que una empresa internacional posee en todo el mundo, podrían ser usados fácilmente con el mecanismo que propongo. El enfoque “anonymous” que le he dado, es porque a los informáticos nos suele gustar este tipo de juegos (nosotros ser el gato que juega con el ratón), pero en la práctica, un uso “no consentido” tendría implicaciones morales, legales y técnicas que no pretendo analizar. Por eso lo he llamado “juego”.

Computación distribuida

No todos los problemas son adecuados para una computación distribuida, no es mi intención comentar el tema, puedes leer las referencias si quieres profundizar, pero básicamente, aquellos problemas que pueden ser divididos en pequeños problemas, resolverlos de forma independiente y luego juntarlos, son susceptibles de ser abordados mediante computación distribuida. Algunos ejemplos:

• Renderizar las imágenes de una película de animación 3D.
• Simular un experimento muchas veces para contrastar posibilidades (eg. formación de galaxias).
• Búsqueda exhaustiva de soluciones (eg. romper por fuerza bruta claves de datos crifrados).

En nuestro caso, nos da igual lo que calculemos, lo interesante es que podremos lanzar en segundo plano (hipotéticamente sin que se de cuenta el internauta) los cálculos en todas las CPU de nuestros internautas. Sí, si un navegante tiene un ordenador con 8 cores ¡usaremos sus 8 cores!.

Ejemplo de cálculo

Como digo no es importante si no te queda muy claro este punto, solo voy a describir el problema de ejemplo de cálculo que vamos a solucionar. Podría ser cualquier otro, pero aquí, vamos a calcular Pi, además, de una manera muy ineficiente para hacer de forma sencilla, un uso masivo del procesador.

El método de Montecarlo es famoso por permitir, de forma fácil, encontrar soluciones aproximadas a problemas muy complejos. Solo explicaré nuestro problema, en las referencias encontrarás datos concretos sobre el método.

Si tenemos un cuadrado de 1×1 metros e inscrito un círculo (de radio medio metro) al que lanzamos dardos de forma completamente aleatoria, los dardos cubrirán todo nuestro cuadrado, algunos habrán caído dentro del círculo y otro fuera. Una simple regla de tres, nos dirá el valor de Pi. De forma similar, si en lugar de todo un círculo, unicamente inscribimos en nuestro cuadrado un cuarto de círculo, obtendremos la cuarta parte de Pi.

Resumiendo, que si T es el número total de dardos lanzados y H (de hit) es el número de dardos que caen dentro del cuarto de circunferencia, entonces Pi = 4 H / T.

Si X e Y son las posiciones aleatorias dentro de nuestro cuadrado de 1×1 metros, estará dentro del cuarto de circunferencia si es X² + Y² < 1.

Solución

La solución consistirá en la parte del servidor que acumulará los datos generados por los ingenuos internautas (que están pensando en comprarse un ordenador más potente porque las páginas web van un poco lentas; risas). Luego mostraremos la página web que realiza el trabajo en paralelo.

Servidor

En un escenario real, la carga de datos debería ser transaccional, por simplificar usaré un sencillo archivo de texto que almacenará e irá sumando los valores T y H que nos envían los clientes. Además, devolverá al cliente el valor actual de Pi aproximado, ésto no hace falta, pero así nosotros vemos como evoluciona el cálculo.

Bueno, el código es un sencillo script en Perl que no requiere de explicación (para cualquier duda usa los comentarios):

Cliente

Para conseguir la paralelización en el navegador, usaremos la API Web Workers que ya está disponible en Firefox, Safari, Chrome y como no en IE no.

Obviamente, si queremos que nuestro proceso sea transparente, ni pediremos al usuario que nos entregue hilos de ejecución ni le mostraremos la evolución del proceso, pero así nosotros podemos verlo. La página siguiente tampoco tiene mucha miga y tampoco requiere explicación (para cualquier duda usa los comentarios):

El script que realiza el trabajo y del que se crean tantos hilos como sea preciso, también es sumamente sencillo, aquí está:

Ejemplo de uso

Para verlo en acción puedes ir a la página anonymousGridComputing.html que he dejado funcionando. Allí, le puedes indicar cuantos hilos quieres dejar funcionando. En la imagen, puedes ver un ejemplo:

Estimación de la capacidad

La mejor forma de estimar la carga es conociendo el número de usuarios únicos que visitan nuestros sitios y el tiempo medio que permanecen en ellos. Por ejemplo, la página de El Corte Inglés tiene unas 270.000 visitas al día con una permanencia media de 5 minutos, eso hacen 1.350.000 minutos de computación por día. Es decir, el equivalente a 1.350.000 / 1440 = 937 equipos. Como centro de cálculo, no está nada mal. Lo más difícil sería estimar la capacidad media de cada equipo, pero podemos tener un factor aproximado incluso con las pocas líneas que hemos escrito, porque cada 5 minutos nos envían el número de eventos generados (en el valor T) así, el mismo valor T es un indicador de la potencia de cálculo de cada máquina en el momento que nos envía cada resultado. De ahí, a guardar una cookie para identificar cada equipo hay un paso.

Conclusión

De una forma muy sencilla, podemos utilizar toda una heterogénea infraestructura para realizar cálculos de algún tipo sin necesidad de realizar ninguna configuración ni preparación previa (nada más que un navegador funcionando). La naturaleza de JavaScript además permite realizar prototipos de forma rápida y cómoda. Las mejoras en los intérpretes también hacen que usar JavaScript no conlleve un rendimiento desastroso aunque en casos reales, la utilización de un applet con código Java optimizado puede ser recomendable (ver comparativa en las referencias).

En todo caso, ¡un ejercicio muy divertido!.

Más información | Grid computing, BOINC, Computación distribuida.
Método de Montecarlo.
Más información | W3C Web Workers.
Más información | Comparativa rendimiento JavaScript frente a Java.

El término Impossible Programming no existe (aunque la vivamos a diario), pero es el nombre que se me ha ocurrido para presentar un sencillo ejercicio sobre Programación dirigida por eventos.

Hay algunos problemas, que si bien en si mismos no son complicados, la gran cantidad de elementos involucrados hacen que resolverlos con éxito, sea una empresa arriesgada. Por ejemplo, todos los aquí presentes sabemos sumar pero… ¿estaríamos seguros del resultado tras sumar dos números con 230 dígitos?.

Al menos con la suma sabemos como tenemos que proceder pero, ¿y si además de haber muchos elementos involucrados, no estamos seguros de tener una estrategia óptima?, ¿y si resulta que tras deshacer el nudo gordiano y dedicar mucho tiempo a poner orden (por ejemplo con cuidadosas pruebas unitarias y TDD) la estrategia no es correcta?, ¿y si nos cambian los requisitos, la información es errónea o las condiciones varían con el tiempo?, ¿y si (muy a nuestro pesar) efectivamente el problema supera nuestros conocimientos?, …

Bueno, bueno, una vez encomendados a San Isidoro de Sevilla (patrono oficial de los programadores), ¿hay algo más que podamos hacer?. Claro, existen un buen número de herramientas útiles que los programadores podemos usar cuando (seamos sinceros) no tenemos ni idea de por donde tirar. Hoy, te propongo jugar con la Programación dirigida por eventos, ¿estás preparado?.

Brevísima introducción a la Programación dirigida por eventos

Cuando escribimos un programa, habitualmente esperamos unos datos de entrada pactados de antemano (eg. una lista de nombres, los datos de registro de la centralita telefónica, etc…) y por eso podemos escribir un procedimiento que procese los datos de forma prefijada. Insisto, establecemos un procedimiento concreto de antemano, que describe como deben procesarse esos datos.

Sin embargo, si los datos nos llegan en cualquier orden y forma (ahora un nombre, luego un teléfono, después algo que hay que procesar, etc…), fijar un único procedimiento concreto será, normalmente, más complicado que si nos centramos en procesar individualmente cada bloque de datos por separado. El siguiente ejemplo puede aclarar la idea, en lugar de tener todo mezclado:

Puede quedar más claro si separamos las diferentes formas en las que nos llegan los datos:

En general, la programación dirigida por eventos está orientada a situaciones en las que la naturaleza del problema es, precisamente, un conjunto de eventos pero, podemos aprovechar la forma de organizar los eventos para simplificar un problema, veamos como.

El problema: la situación

Hoy tenemos un problema “empresarial” (no “matemático”), por eso deberás hacer un pequeño esfuerzo para no dormirte entre requisito y requisito.

Supongamos que una empresa dispone de diversas factorías para fabricar productos de repostería (toman las materias primas y producen ya embalados diversos tipos de dulces). Como son factorías muy viejas y que llevan funcionando mucho tiempo, se han convertido en auténticas máquinas de Rube Goldberg, como la de la imagen que encabeza el post.

La cuestión es que si bien su mecánico es bastante bueno y sabe hacer funcionar todos los sistemas, no hay nadie capaz de entender cómo y para qué sirven todos los mecanismos que componen las factorías, ni siquiera el mecánico tiene una idea general de cómo funciona todo, él simplemente va arreglando las cosas que dejan de funcionar.

Cada día se producen averías con mayor frecuencia y el Caos empieza a ser lo habitual en el funcionamiento de las factorías. Además, debido a que no es evidente el flujo de procesos, una máquina puede dejar de funcionar debido a que a mucha distancia, otra máquina ha dejado de tener materia prima y a la empresa le resulta muy difícil proveer un suministro constante de materia prima para maximizar la producción. De pronto se quedan sin harina, y deben salir corriendo a buscar más para que todo vuelva a funcionar.

En definitiva, he descrito el tipo de empresa en el que todos querríamos trabajar.

Así pues, en la empresa piensan que como los ordenadores ordenan cosas, a ellos igual les viene bien tener uno para que ponga orden en sus factorías (si este argumento te parece descabellado, debes saber que es “El argumento” del que es imposible sacar a los clientes; piensan que no son ellos los que deben poner orden ¡para eso están los ordenadores y los informáticos!) y te llaman a ti, que de fabricar pasteles sabes lo mismo que un caracol de tocar el Ukelele.

El problema: lo que hay que hacer

Obviamente todos sabemos que la mejor solución es construir nuevas y flamantes factorías que dispongan de la última tecnología pero claro, la empresa dice que “ya lo habíamos pensado pero como nuestro mecánico es muy bueno (que lo arregla todo), a ver si se podía poner orden en los recursos que debemos tener disponibles en cada momento”.

Así, los requisitos serían más o menos los siguientes:

• Se pide diseñar un sistema que indique la cantidad de recursos necesarios para maximizar la producción de pasteles. Obviamente debe poder decirlo con la antelación suficiente (días o semanas).
• El sistema debe servir para diferentes factorías, cada cual con sus particularidades.
• El sistema debe ser capaz de adaptarse a situaciones inesperadas como caída, eliminación, adición y/o cambios en el comportamiento de los subsistemas de cada factoría.

Soluciones “formales”

Todo el mundo sabe que en un escenario como este las redes de Petri son una herramienta que nos permite analizar, comprender y optimizar el flujo de procesos, es probable que exista algún software que nos permita modelar el Caos de estas factorías pero, ¿y si no sabemos qué son esas redes?, ¿y si existen procesos estocásticos que dificultan el modelo?, ¿y si no sabemos usar ese software? (deberíamos aprender).

Todo el mundo sabe también, que la complejidad de los procesos puede ser rodeada usando la estadística (para obtener datos) y el cálculo de probabilidades (para predecir comportamientos). Podríamos realizar un cuidadoso estudio estadístico de, únicamente, el flujo de materias prima de entrada y la producción de salida, ignorando toda la complejidad interna de las factorías. Obtendríamos así (probablemente) un modelo ajustado sobre la probabilidad de que nos quedemos sin materia prima que nos permitiría minimizar la probabilidad de parada. Sin embargo, aplicar esta solución requiere tomar muchos datos y, además, con el tiempo habría que ir ajustando el modelo.

Solución “a la torera”

Como Joselito con su capote, vamos nosotros capear el problema, sino con inteligencia, esperemos que con gracia. Porque en realidad lo que vamos a hacer es una mezcla “informal” de las dos anteriores. Pues en lugar de modelar la red de Petri, únicamente vamos a simular nuestras factorías, y en lugar de minimizar la probabilidad de parada, sólo vamos a obtener los datos del funcionamiento de las partes (estadística).

Es decir, vamos a construir un simulador de factorías para poder predecir que recursos se van a agotar primero y en tan sólo 99 líneas de código. ¿Empezamos?.

Lo que vamos a hacer

La solución que proponemos a la empresa es, ya que no va a cambiar las factorías y que el funcionamiento va a seguir cambiando de un día para otro, la siguiente:

• Nuestro sistema se podrá reconfigurar instantáneamente, bastará con cambiar el archivo de entrada. Así, si un nuevo subsistema cambia su comportamiento, es añadido o eliminado, ajustamos el archivo de configuración y listo.
• Nuestro sistema podrá funcionar con independencia entre las diferentes factorías, un cambio en unas, no afectan en nada a las otras.
• Nuestro sistema responderá instantáneamente a las entradas de material, así, podremos pedir un report que instantáneamente nos indique el estado que tendrán todos los subsistemas (por ejemplo, para poder ver que la máquina de amasado se bloqueará porque necesitará más harina).

El generador de simuladores

La primera estrategia consiste en abstraer el problema. En lugar de intentar modelar directamente las factorías, vamos a crear un generador de simuladores. Con ello conseguimos por un lado no tener que pensar en el tremendo lío que hay en cada factoría y por otro, que la configuración y reconfiguración pueda hacerse muy fácilmente (desde el archivo de configuración).

El simulador

La segunda estrategia consiste en identificar las partes de la factoría que sean posibles, si una parte es completamente incomprensible no pasa nada, la trataremos como un todo, pero el identificar las más partes posibles nos permitirá actuar fácilmente allí donde se produzca el problema.

La forma más fácil de ver como funciona el simulador es ver su archivo de configuración:

Vemos que hemos identificado las diferentes materias primas con el número de elementos que nos llegan en cada envío (eg. 30 manzanas por envío) y los procesos internos (eg. para hornear hacen falta cinco montajes ya listos y una unidad de energía). Si mañana se añade un proceso, sólo es añadir una línea, si desaparece, eliminarla, si la máquina de recortes empieza a fallar y desperdicia una de cada seis manzanas sólo es ajustar el número de manzanas necesarias (eg. en lugar de 15 poner 19), etc…

El control

Para controlar el simulador, además del archivo de configuración, querremos disponer de algunos comandos como levantar todo el sistema, detener el sistema, simular la caída de un subsistema, añadir recursos de algún tipo, de otro tipo, pedir un estatus a todos los sistemas, etc…

La implementación

Para implementar nuestro sistema vamos a utilizar Inter-process communication que aunque suena muy técnico, es tan sencillo como que unos procesos se envían “correos electrónicos” (es un símil) unos a otros. Como en mi ejemplo los procesos son sencillos scripts (en bash) utilizaré un sencillo comando msgtool que puedes encontrar en las referencias.

Bien, el código que nos permite generar los simuladores a partir del archivo de configuración es:

Que no hace otra cosa, más que generar automáticamente una serie de scripts que mandan y reciben mensajes simulando las relaciones existentes en las factorías. Después veremos algún script autogenerado por este código en Perl.

El despliegue

Para poner en marcha los simuladores, crearemos una carpeta para cada factoría con su archivo de configuración, por comodidad podemos poner nuestro script generador de simuladores y la utilidad msgtool. El proceso de generación es trivial, pongo un ejemplo completo con el listado de archivos (que es lo que ocupa espacio):

Para levantar todos los subsistemas de nuestro simulador, basta hacer:

Obviamente si solicitamos a los subsistemas que emitan su estado, estarán todos a cero:

Por comodidad, podemos lanzar el siguiente comando en otro terminal para tener actualizado en tiempo real el estado del simulador:

El simulador también nos ha generado automáticamente scripts para cada uno de los recursos que tenemos disponibles, así, podríamos lanzar por ejemplo la siguiente carga de recursos (eg. según llegan a los almacenes):

Vemos que con las manzanas y operarios que han entrado se han producido seis recortes y hay disponibles las guindas, pero no puede continuar el proceso, además, operarios tenemos tres parados y no hay más manzanas.

Si continuamos añadiendo recursos, vemos la evolución:

Así, podemos predecir fácilmente las necesidades de recursos que vamos a tener a corto plazo y pedirlas antes de que se agoten, sin necesidad de tener almacenadas grandes cantidades.

Los scripts autogenerados

Cuando hemos generado el simulador a partir del archivo de configuración, se nos ha listado los identificadores asociados a cada variable (manzana, horneado, …) algunos no se usarán para nada (eg. manzana) pero otros serán los identificadores de las colas de mensajes.

El script que levanta todo el sistema contiene lo siguiente:

Que como ves, únicamente pone en segundo plano cada uno de los subsistemas que hemos definido.

Cada uno de los subsistemas intermedios (masa, montaje, …) son muy parecidos, contabilizan los recursos que tienen disponibles y cuando son suficientes para producir el resultado, lo notifican al subsistema siguiente. Por ejemplo, el subsistema del montaje es:

Que como ves, únicamente consiste en esperar a que llegue un mensaje a su número de cola asociada y en caso de que sea alguna materia prima, incrementa la cantidad disponible. Si es un comando de sistema (poweroff o report) efectúa lo propio y en cualquier caso, mira a ver si puede producir el resultado con el material disponible, en cuyo caso, lo notifica a la cola de destino.

El subsistema final es un caso especial, pues cuando se termina una tarta, no hay nada que hacer, así, únicamente se notifica, pero es esencialmente igual que los demás.

El último script que genera el generador de simuladores es el sendToAllSystems, que sirve para notificar a todos los subsistemas alguna cosa como que se apaguen o que reporten su estado:

Conclusión

Por un lado, vemos que existen estrategias que nos permiten abstraer la dificultad intrínseca de los problemas. Obviamente no las podemos aplicar siempre, sólo en aquellos problemas que las admitan (como en este caso). Conocerlas y practicar con ellas nos permite enfrentarnos a situaciones que a priori pueden parecer intratables o que superan nuestros conocimientos.

Por otro lado, vemos que no hace falta dedicar mucho tiempo ni recursos para modelar adecuadamente un problema a priori complejo. Subestimar o ignorar herramientas como el shell hará que perdamos la oportunidad de utilizarlas en innumerables ocasiones.

Nota sobre la implementación

La Programación dirigida por eventos no impone mayor restricción que el que se pueda “disparar” un cómputo cuando se producen ciertas condiciones, es por ello que existen otros paradigmas en los que puede hacerse una traslación casi directa cuando la usamos en la forma presentada en el post. Por ejemplo, es trivial definir en POO una clase denominada Subsistema que disponga de algún método recibirRecurso y la referencia al subsistema receptor de su producto. También es trivial crear un sencillo programa que únicamente mantenga una lista completa de todas las variables, si introducen una materia prima, incrementa la variable y revisa hasta que no se pueda todas las transformaciones en subproductos.

Que la implementación utilizada sea distribuida (cada subsistema puede correr en máquinas distantes) no es relevante (aunque interesante) pero enfatiza el sentido de “disparo de evento” que se produce entre los subsistemas y muestra que es muy sencillo utilizar colas de mensajes (semáforos, mutex, …) en un shell.

Más información | Programación dirigida por eventos.
Más información | Inter-process communication, msgtool.
Más información | Isidore of Seville, Rube Goldberg device (o incredible machine), Redes de Petri.

Lo deseable cuando escribimos cualquier algoritmo, es que este sea tan rápido como sea posible. Desafortunadamente, no siempre es lo más indicado, bien porque no se disponga de tiempo para codificarlo o bien porque supondría una complejidad adicional en el despliegue (ej. precálculos, caché, librerías) y/o en el propio código por cuestiones de legibilidad y mantenimiento.

Sin embargo, no cabe duda de que no sólo en aplicaciones con marcado carácter computacional (financieras, simulación física, graficación, juegos, etc…) es deseable la máxima optimización. Páginas web dinámicas, un fluido interface de usuario (Tablet, PC o navegador), procesos en segundo plano en nuestro servidor y en otras tantas situaciones podemos obtener múltiples beneficios (mejor experiencia de usuario, menor consumo de cloud contratado, no necesitar hardware adicional, etc…) si procuramos escribir un código eficiente.

Así, te invito a practicar conmigo en la optimización del código con un sencillo ejemplo. ¿Te animas?.

Breve introducción

Existen muchos tipos de optimización en los algoritmos. Éstos pueden ser de índoles muy diferentes. La optimización puede estar orientada al hardware como por ejemplo, el instalar un segundo disco para minimizar los bloqueos entre procesos que escriben y leen. Otras optimizaciones se centran en el lenguaje concreto sobre el que trabajamos, cambiando una “palabra” por otra, podemos obtener un mejor desempeño (eg. en Haskell, cambiando concat $ map por concatMap o en otros haciendo el cambio String por StringBuilder). Otras consisten en un cambio en la estrategia basada en una combinación de las anteriores (una típica es aquella que consiste en cambiar un tipo genérico Integer por uno concreto y más eficiente a nivel de compilador y hardware como Int32).

Pero sin duda, la mejor forma de optimizar un algoritmo es mejorándolo, reemplazándolo por otro en el que el número de operaciones requeridas para hacer el trabajo, sea menor que en el anterior.

Sin embargo, ésto último no siempre es cierto, “¿cómo?” te dirás, “¿usar un algoritmo más eficiente es peor que usar otro menos eficiente?”. Pues sí, la cuestión es que un algoritmo no siempre se comporta igual. Hay algoritmos que (es solo un ejemplo) funcionan igual de bien (o mal) con independencia de que deban procesar uno o miles de datos, otros sin embargo, funcionan bien para pocos datos pero con muchos se vuelven penosos, etc…

La eficiencia de los algoritmos es la materia de estudio de la Complejidad computacional, sin embargo, como es verano y hace calor, comentaré implícitamente algunos aspectos de dicha teoría revisando cuatro soluciones diferentes a un mismo problema.

El problema

Como es habitual, lo más fácil es plantear un problema “matemático”, esto es así porque de forma sencilla y concisa, se puede poner un problema que condense toda la dificultad que queremos mostrar sin tener que poner un ejemplo “empresarial” que sería largo y aburrido (recuerda el ejemplo de mi post de Microcódigo en mi código).

De todos modos, si se te ocurren problemas “cotidianos” que no tengan un enunciado demasiado largo, puedes postearlo en los comentarios o en Solveet.

El problema propuesto consiste en calcular todos los factoriones que existen, por simplificar un poco, vamos a suponer que nos indican que no existen factoriones mayores que un N dado. Bien, ¿qué es un factorión?:

Un factorión es un número natural (1, 2, 3, …) tal que, si tomamos todos sus dígitos decimales y sumamos sus factoriales, volvemos a obtener ese mismo número.

Por ejemplo, el número 1024 tiene por dígitos decimales a {1, 0, 2, 4}, los factoriales (recuerda que el factorial de n se denota n! y es igual al producto de los n primeros números naturales, es decir, n! = 1 × 2 x … x n) de esos dígitos son {1, 1, 2, 24} cuya suma total hace 28, y como no nos ha dado 1024, resulta que 1024 no es un factorión.

Por otro lado, el número 145 tiene por dígitos {1, 4, 5} cuyos factoriales son {1, 24, 120} y su suma es precisamente 145, luego 145 sí es un factorión.

Solución ingenua

Se suele llamar “solución ingenua” a la solución evidente, la que se escribe sin pensar. Es un término común en ciencias de la computación, no pienses que lo he puesto yo. Dicha solución, consiste en usar la potencia del ordenador para que revise, uno a uno, todos los números, aplicando directamente la definición sin pensar, ¡a veces es la mejor solución posible!.

Si usamos Python, una forma de escribir directamente una solución sería así:

¿Cómo se optimiza?

La forma de optimizar cualquier algoritmo, consiste en conocer y entender sus propiedades y las del problema a resolver, “¿propiedades?”, sí, sólo vamos a poder actuar sobre aquellas propiedades que conozcamos, por ejemplo, viendo el algoritmo en Python, se puede ver que para cada i estamos calculando una y otra vez los factoriales de los mismos dígitos (sólo hay 10 dígitos decimales, del 0 al 9), aunque sea una propiedad evidente, es una propiedad bien conocida que el factorial de 9 es siempre 362.880, si siempre es 362.880, nos podemos ahorrar las 8 multiplicaciones que requiere obtenerlo si lo dejamos precalculado en una matriz. Es decir, dejar en una matriz los 10 factoriales de los 10 dígitos posibles.

La propiedad de que el factorial de un número n no cambia es conocida e interesante. Una propiedad de la función rand() es justo la contraria, el valor devuelto puede tomar (o no) un nuevo valor diferente cada vez. Si no conocemos las propiedades de las cosas, no podremos controlarlas eficientemente.

Optimizar el código

Como decía en la introducción, una forma de optimizar la ejecución, es mejorando el código, aunque el algoritmo sea el mismo (técnicamente el algoritmo será diferente, pero el proceso teórico, el algoritmo teórico seguirá siendo el mismo). En nuestro ejemplo, una forma evidente es precalcular los factoriales de cada dígito, pero hay otra cosa que se puede hacer que creo te va a gustar.

Una propiedad que tiene la definición de factorión es que, si tengo calculada la suma de los factoriales de los dígitos del número n, para calcular la suma de los factoriales de los dígitos del número n + 1 sólo tengo que sumar y restar aquellos dígitos que sean diferentes ¡a que es genial! (esta propiedad ya no es tan evidente ¿eh?). Probablemente lo veas mejor con un ejemplo (es sencillo, ya verás):

Para n = 10321041, tenemos que hacer 1 + 1 + 1 * 2 * 3 + 1 * 2 + 1 + 1 + 1 * 2 * 3 * 4 + 1 = 37.

Para n = 10321042, tenemos que hacer 1 + 1 + 1 * 2 * 3 + 1 * 2 + 1 + 1 + 1 * 2 * 3 * 4 + 2 = 38.

¿En que se diferencian?, ¡únicamente en el dígito que cambia!, es decir, si tenemos calculada la definición para n = 10321041, para saber cuanto vale la de n = 10321042, únicamente tenemos que restar el factorial del dígito que sale (1) y sumar el factorial del dígito que entra (1 * 2 = 2).

“¿Y esta propiedad es interesante?”, mucho, porque significa que en 9 de cada 10 números de los millones que tengamos que revisar sólo tendremos que hacer una resta y una suma ¿no es genial un ahorro del 90%?. Nota: cuando el primer dígito pase del 0 al 1, del 1 al 2, …, del 8 al 9, podemos aplicar la propiedad anterior, cuando del 9 pase al 0 no, porque pasará a las centenas, pero en éstas, sólo serán 2 restas y 2 sumas y no será ¡hasta los miles! que deberemos calcular 3 restas y 3 sumas, etc… desde luego, un ahorro impresionante.

En la práctica, el código siguiente lo único que hace es contar de 0 a N, pero en lugar de usar el operador suma (n = n + 1), lo hace como en el cole, mantiene un array con dígitos que inicialmente valen 0 y va sumando “llevando una”. No detallaré el algoritmo por no aburrir demasiado, pero puedes usar los comentarios si quieres que aclare algo.

Aún se puede optimizar más el código, por ejemplo, una propiedad interesante del procedimiento que hemos establecido, es que siempre se resta y suman los mismos factoriales, por ejemplo, del dígito 0 siempre se pasa al 1, del dígito 1 siempre se pasa al 2, etc… en lugar de restar y sumar ¿porque no precalculamos esa resta y suma y así sólo hacemos una suma? ¡acabamos de reducir a la mitad el número de sumas (y restas)!.

No obstante, no merece la pena ahondar más aquí, ahora veremos una forma mejor.

Optimizar reescribiendo el algoritmo

Entre nuestro primer algoritmo ingenuo y el segundo, realmente no hay ninguna diferencia, son el mismo algoritmo, lo único que el segundo corre muchísimo más rápido. Digamos que tenemos que seguir yendo de Madrid a Barcelona, pero en lugar de a 50 Km/h lo hacemos a 1540 Km/h. Lo que vamos a hacer ahora es ¡un agujero de gusano para atravesar el espacio tiempo y teletransportarnos de Madrid a Barcelona! “¿cómo?”, conociendo las propiedades de los factoriones y aprovechándonos de ellas por supuesto.

Si volvemos a mirar como se calcula la definición que deben cumplir los factoriones:

Para n = 10321041, tenemos que hacer 1 + 1 + 1 * 2 * 3 + 1 * 2 + 1 + 1 + 1 * 2 * 3 * 4 + 1 = 37.

Nos fijamos que la suma tiene la propiedad conmutativa, ¿porqué es importante saber eso?, porque en cualquier objeto que cumpla dicha propiedad, podemos cambiar el orden de los elementos sin que afecte al resultado final, es decir, el número anterior, lo podemos reescribir como: 00111234. Es decir, todos los números que pueden escribirse con los mismos dígitos podemos calcularlos una única vez.

Si por ejemplo nos dicen que busquemos factoriones de 1 a 10.000.000, con los algoritmos anteriores tendríamos que revisar todos y cada uno de los 10 millones de números, sin embargo, si usamos la nueva propiedad únicamente tendremos que revisar 11.440 ¡hemos reducido el problema un 99,8856%! (ojo, antes reducíamos las operaciones en un 90% pero sólo de cada uno de los millones de números a revisar, es decir, teníamos que seguir revisando millones de números, ¡pero es que ahora hemos reducido el problema a sólo revisar unos pocos números!).

“¿Y como se usa esta propiedad?”, bueno, sólo tenemos que generar las combinaciones con repetición de los dígitos involucrados. Tampoco explicaré el código siguiente, cualquier aclaración por favor, siéntete libre de indicarla en los comentarios:

Éste código sin embargo, no es más rápido que el anterior en C para valores de N inferiores a unos tres millones, a partir de ahí, este último código en Haskell deja en pañales al de C.

Optimizando a lo Agente Smith

“¿Aún podemos optimizar más?”. ¡Claro!, igual que el Agente Smith en la pelicula Matrix, no sólo vamos a teletransportarnos instantáneamente de Madrid a Barcelona, además, ¡nos vamos a clonar para ser muchos simultáneamente!.

En general, no siempre podemos paralelizar nuestros algoritmos pero, una propiedad muy interesante de nuestro último algoritmo, es que el cálculo de las combinaciones con repetición se hace recursivamente y de forma independiente (en los algoritmos de Python y C, las variables y matrices eran compartidas para cada número a revisar), es decir, lo podemos paralelizar muy fácilmente añadiendo un simple parMap:

De todos modos, para números tan pequeños (decenas de millones) no merece la pena, porque hemos optimizado tanto y tan bien, que incluso en mi humilde Atom D510 sólo le lleva unos pocos milisegundos.

¿Se puede mejorar al Agente Smith

Pues sí, existen propiedades adicionales que no hemos explotado como por ejemplo, que la suma parcial de la definición debe ser menor o igual que el número que revisamos (algo evidente, claro). Es decir, si estamos verificando el número 999.999, vemos que cuando llevamos sumados los factoriales de tres dígitos ya nos da 1.088.640, por lo que no hace falta que sigamos sumando para saber que no es un factorión.

¿Sabías que el estudio de las propiedades (y relaciones) de las cosas es el objetivo de las matemáticas?.

Curiosidades sobre los algoritmos escritos

• El código Python tiene un coste O(n) y es lento y aburrido.
• El código C tiene un coste O(n) y es muy rápido ¡sólo unos 10 ciclos de reloj para cada número!.
• El código Haskell sin paralelizar tiene un coste O(log n) y aunque no es rápido en ejecución, efectúa muchísimas menos operaciones que los anteriores.
• El código Haskell paralelizado, tiene un coste O((log n) / c) donde ‘c’ es el número de hilos que le dejamos para ejecutar; si tenemos un AMD Phenom II X6 con seis cores, tardará seis veces menos que el Haskell anterior.

Conclusión

Como programadores debemos ser capaces de escribir un código eficiente, utilizar el algoritmo ingenuo es cómodo y tentador, pero hay muchas situaciones en las que un programador bien entrenado (no acomodado en que simplemente, funcione) puede fácilmente optimizar un código y obtener un producto mejor. Ni las mejoras son mínimas si las hemos ido realizando desde el principio del desarrollo, ni el código se complica innecesariamente si las hacemos de forma inteligente. A veces únicamente será cambiar la forma de aplicar una instrucción, otras declarar una pequeña matriz para precalcular algún resultado e incluso otras, complicaremos conscientemente el algoritmo asumiendo el coste de mantenimiento.

Si no hay una razón para no escribir un buen código, ¿porqué no hacerlo?.

En Genbeta Dev | Solveet.

Más información | Combinaciones con repetición.

Más información | Problema factorión.

Más información | Complejidad computacional.