jarry escribió:es que un programa bien hecho en logico, labura asi, y vos te ahorras todo el quilombo de armar y gestionar el arbol
claro, tal cual! es para eso... pero si lo necesitás para el laburo ponele, es más complicado preparar la interfaz entre Smalltalk y el lenguaje lógico que hace lo que necesitás, que armarte el código directamente en Smalltalk, para mí... (porque pensá que esos datos los puede necesitar para otra cosa después).
Desert69 escribió:
- Off-topic:
- Gente, muchas gracias por reconfirmarme que estudiar ingenieria en sistemas vale la pena... la explicacion de pablo en la pag anterior fue contundente... creo que voy a recuersar discreta.... xD
Jajaja! xD Mientras le pongas pasión a cualquier materia (hasta a las más "feas"
), siempre vas a poder sacar algo útil de ellas que seguro te va a servir más adelante, aunque en el momento que la estudies creas que es una cagada...
LeandroDG escribió:Mmm.. y si el árbol lo armás con las palabras de 3 a 6 letras existentes? Cuántas serán? Serán más que las 1920 totales de combinatoria?
En ese caso armás el árbol completo de palabras existentes y recorrés rama por rama a ver si las letras que tiene cumplen con las posibles.
Ej: Si tenés en el diccionario un nodo raíz y después por ej. un nodo J, del cual se van desprendiendo las palabras JOROBA, JABALI, JETA, vas recorriendo los nodos hijos (c/nodo hijo agrega una letra) y si la letra no está entre las disponibles simplemente no seguís cargando. Lo malo de este método es la velocidad de carga del árbol, pero después para analizar es muy rápido. Y es una manera bastante piola si vas a usar más que palabras de 6 letras, para palabras de 10 letras por ejemplo la otra técnica se va al carajo me parece y esta en cambio agrega más palabras. ¿Cuántas palabras hay? De cualquier manera si considerás que las palabras las vas a tener en un diccionario para andar comparando, usando la técnica que te dije yo lo resolvés bien y usando la menor cantidad de memoria posible
Claro, el tema es que para eso necesitás armar el árbol del diccionario antes, y si cargás tooodo el diccionario en memoria, es un exceso de procesamiento y espacio enorme! Si cargás sólo las palabras que cumplen con las condiciones (que tengan 6 o menos letras que buscás vos), ahí el árbol sería más chico, y lo mejor es que después ya tendrías todas las palabras que necesitás ordenadas en memoria en un árbol (esto, si no me equivoco, sería como un HeapSort). El tema es que controlar palabra a palabra del diccionario si cumple o no tus condiciones, también llevaría procesamiento adicional que del otro modo no necesitabas, porque sólo te posicionabas en la estructura y avanzabas con una cantidad de pasos del orden (log n), mientras que si tenés que lees todas las palabras del diccionario, el orden es (n), por lo tanto mayor tiempo.
Eso sí, yo supongo que el diccionario de alguna forma está ordenado, en algún archivo, por ejemplo. Entonces serían menos lecturas a disco, por ejemplo. Pero si el diccionario está desordenado, habría que ordenarlo primero, y capaz en tal caso conviene ordenarlo como un árbol a ordenarlo como un vector, en ese caso me tiraría más por tu opción.
Igual el estudio de eficiencia es muy sutil y detallista, yo lo estoy viendo a grandes rasgos. Hay algo fundamental, y es si el código este se va a ejecutar una sola vez o varias veces. Si lo hace una sola vez, la eficiencia no es taan importante (claro, a menos que el programa lleve una eternidad), ya que es cuestión de ejecutarlo y esperar un tiempo más grande sólo una vez... y hacerlo más eficiente capaz ya te habría llevado aún más tiempo. Sin embargo, si la idea es ejecutarlo varias veces, los tiempos son importantes y querés tenerlo optimizado.
Hay que ver realmente cuál es el fin del problema... capaz sólo formar una discusión interesante en el foro
(?).