Te contesto por email…

Pedro, por lo que sé, está perfectamente de salud. Cuando lo decida volverá a publicar. O eso esperamos todos…

Hecho mucho de menos sus publicaciones…

Macluskey, buenas ideas, lo de encontrarle problemas reales o plantearle basicos de informatica, ya lo tenia en mente, pero ahroa aún está en fase temprana.

Ryback: Despertar curiosidad, uff, que dificil se me hace eso, por algo “nos” llaman Frikys, porque estamos interesados en cosas raras. Mi mujer es muy Friky, pero de otro estilo(dibujos animados, manga, twitter, juegos,…) pero me cuesta mucho conseguir que se interese por temas, por ejemplo, cientificos. (joder lo que disfruto leyendo el tamiz, pese a no saber casi nada de fisica ni quimica y menos de cuantica) Y para ella(y medio mundo) es un tostón… Y la edad(34) no creo que ayude, aunque no es el mayor de los problemas.

quizá Parezco pesimista con estas respuestas, ni de lejos, solo que lo que uno ya tiene solventado/claro no lo pregunta… jejeje

Respecto a la programación de la solución de cifras y letras, yo también me sorprendí al ver que lo solventabas por fuerza bruta, esperaba algo del estilo de Backtracking como comentas(aunque no he vuelto a programar nada de backtracking desde que dejé la uni….).

aunque por lo que se de Backtracking(poco o nada), al final sería hacer por programación lo que tu ya hiciste mediante formulas, ir cortando todas aquellas ramas que no parecen(en tu caso “que estoy seguro”) llevar a buen termino. Estoy seguro que con backtracking el tiempo de programación hubiera aumentado, pero el tiempo(ciclos) de proceso habría disminuido enormemente para el 95% de los casos y más lento que la fuerza bruta “tuya” en el 5% restante(como siempre % inventados jejeje).

Haría falta hacer un estudio más a fondo de ver cual sería la estrategia que promediaría un mejor rendimiento y cuanto puedes llegar a ganar (en reducción de tiempo) si primero se aplican estrategias “inteligentes” antes de el ataque por fuerza bruta. Así como ver qué estrategias dan una gran reducción de tiempo promedio y cuales no aportan gran cosa

Siguiendo tu símil de la sonda, imagínate que el día de mañana cambiasen el concurso añadiendo más operadores , cambiando los posibles y/o ampliando el rango de posibles resultados a valores de 4 cifras. Tu programa sigue sirviendo (modificando 4 parámetros) pero… ¿El crecimiento del árbol de posibilidades lo haría llegar a un punto de poca eficiencia? Al fin y al cabo el ordenamiento por burbuja es una “maravilla” por sencillez para no tenerte que romper el coco y reduciendo factores de error en el código… Hasta que te enchufan una lista de 100.000 elementos y el usuario se acuerda de los ancestros del programador de turno por lo mucho que tiene que esperar. XD

Saludos

En su día hubo la discusión de cuál sería la mejor estrategia para resolver el problema de cifras (el de letras no tiene mayor problema que tener un diccionario de palabras válidas).

Hay dos estrategias posibles, creo yo.

Una: dado un problema concreto, ver cómo puede resolverse de la mejor forma posible. Es lo que hacen los concursantes, claro está; tienen seis números y un objetivo y allá se las compongan. Y estrategias como la que citas (buscar divisores del objetivo es lo primero que hacemos casi todos) es lo que uno puede hacer ante ese problema concreto. Ya Antonio Villena en su día nos dijo que la solución obvia pasa por hacer un backtracking, y que además se puede optimizar, por ejemplo, teniendo en cuenta si hay números duplicados para no repetir operaciones que sabes que son la misma, etc.

Dos: dar una solución que sirva para TODOS los problemas posibles, es decir, que un único programa con una única estrategia resuelva todos y cada uno de los treinta millones y pico de posibles problemas. Ésa es la que a mí, informático del Achelense, me gusta y me parece más correcta.

Claro que también se puede programar esta segunda opción a base de ir probando trucos o estrategias traídas de la alternativa uno: Primero vemos si hay duplicados, luego si el objetivo es divisible por algún argumento, luego si lo es por la suma de dos, de tres, luego tal y luego cual… Se puede, claro. Pero ésa no es una solución nada efectiva, por una razón: cuando todas las estrategias que se nos ocurran fallan, si queremos agotar todas las posibilidades, entonces ¡sólo queda la fuerza bruta!

Y digo yo: si de todos modos hay que programar el ataque por fuerza bruta cuando todos los IF’s fallan, cuando ninguna estrategia “humana” conocida funciona… pues ¡limitémonos a programar el ataque por fuerza bruta, y yastá! Se ahorra una barbaridad de tiempo y esfuerzo al hacerlo así.

Eso sí, hacerlo a lo bruto-bruto es terriblemente ineficiente, como ya vimos en los artículos de hace cinco años, y entonces es cuando entra el divertido proceso de optimización que permite que probando sólo 600.000 fórmulas se pueda determinar la solución (si tiene) de cualquier problema.

Por ejemplo: Si tuviéramos que enviar una sonda a Marte, podríamos programar una solución que llevase la sonda exclusivamente hasta Marte, teniendo en cuenta la posición relativa de ambos planetas, el momento del lanzamiento, etc. O bien podíamos programar una solución que fuera capaz de llevar una sonde desde cualquier planeta hasta cualquier otro y en cualquier momento temporal. En esta segunda solución los parámetros de entrada serían, más o menos: desde dónde sale la sonda, a dónde tiene que ir, y cuándo se produce la salida. Y valdría no sólo para ir a Marte, sino a Venus, a Neptuno o a donde fuera. Costaría más realizarlo que en el primer caso, pero estaría hecho para siempre.

Esta forma de pensar, es decir, buscar la solución para resolver un tipo de problemas, no un problema concreto, es lo que, desde mi punto de vista, distingue a un buen informático de uno mejor todavía.

Un saludo

El caso es que nunca estuve muy de acuerdo con plantearlo por “pseudo-fuerza bruta” como hiciste tú. Es una forma tan válida como obvia de hacerlo y sin duda el análisis para “podar” y dejar bien limpio el árbol de posibles operaciones tiene un gran mérito y es muy didáctico a los profanos (ley del buen programador: no basta con que el programa funcione, tiene que funcionar de forma óptima).

Pero si cualquiera de nosotros nos pusiésemos a resolver uno de esos problemas del cifras (con nuestra materia gris); nuestra forma de abordarlo sería completamente distinta. Por ejemplo, yo cuando veía el programa solía empezar por buscar divisores enteros del resultado entre los números disponibles (y en caso de no haberlos, ver cuan cerca me quedaba). Algo que a mi entender simplificaba muchísimo el problema. Cuando leí tus artículos me quedó el gusanillo de no ser capaz de plasmar sobre código muchas de esas “estrategias de ataque” del problema que me salían de forma casi instintiva (y no quiero ni pensar en las que conocen verdaderos cracs en lo de operar de coco). Por algo será que terminé en sistemas, peleado con las abstracciones a código. XD

Ahora reviviendo el tema has vuelto a lograr que me pique y por ello te odio un poquito más (pero de buen rollo)

Saludos!

PD: Isanagi, si tuviera que darte un consejo, te diría que le inculcases el don (a veces malsano) de la curiosidad. Todos los que hemos terminando “trasteando cachivaches” empezamos sin darnos cuenta de pequeños. Cuando nuestros colegas jugaban con los juguetes de reyes y nosotros LOS DESMONTÁBAMOS para ver como funcionaban, aunque luego no pudiésemos montarlos de nuevo. Esa clase de curiosidad te hace ser mejor ingeniero, querer saber no sólo el “como” sino también “el porqué” de las máquinas y construcciones que nos rodean. Eso y aprender a ser metódico (solucionar problemas complejos por división o por eliminación de posibilidades) son para mi las dos herramientas básicas.

PD2: Yo sí recuerdo haber visto en la tele algún (escaso) ejemplo de concursantes incluyendo operaciones con fracciones en sus respuestas (y dejando ojipláticos al personal en el proceso)