brunodiaz escribió:

pablo escribió:Pero LeaTex, justamente lo que puse es una solución alternativa a combinatoria... o sea, aplicar combinatoria es algo MUY FEO xD.

Fijate el código que te di en verde... sólo necesitás pasar eso a Smalltalk, y no es dificil. No lo hago porque no me acuerdo casi la sintaxis, pero creo que si lo lees no se te complica pasarlo. Igual, para entender bien como funciona eso capaz necesites haber cursado Gestión de Datos, ya que mucho de lo que puse en el post está tomado de ahí e intercalado con Discreta/Proba.

Suerte!

por lo que lei algo me dice que cursaste la parte de algoritmos con reinosa xP
habia momentos que me parecia estar escuchandolo al chabon

Jaja sí, cursé con él... no digo que sea la mejor cursada que puede ser, ya que era 0 teoría casi, pero bueno, los temas que se dieron dentro de todo los aprendí .

pablo escribió:Pero LeaTex, justamente lo que puse es una solución alternativa a combinatoria... o sea, aplicar combinatoria es algo MUY FEO xD.

Fijate el código que te di en verde... sólo necesitás pasar eso a Smalltalk, y no es dificil. No lo hago porque no me acuerdo casi la sintaxis, pero creo que si lo lees no se te complica pasarlo. Igual, para entender bien como funciona eso capaz necesites haber cursado Gestión de Datos, ya que mucho de lo que puse en el post está tomado de ahí e intercalado con Discreta/Proba.

Suerte!

Sí, entiendo todo. Es que puse mi respuesta antes de que editaras tu post (o no lo vi). Y ya cursé este cuatrimestre Gestión de Datos (con Reinosa) así que entiendo lo de árboles y demás.

Bueno, voy a ver si puedo implementarlo, y después les cuento cómo me fue.
Gracias de nuevo.

por como lo planteas, parece ser algo que se resuelve muy facil con programacion logica, ahora no me acuerdo muy bien, pero deberias tener un archivo diccionario con todas las palabras cargadas como reglas, y armar un par de predicados que te devuelvan cantidades, no es dificil, y el prolog implementa un motor de combinatoria muy bueno

jarry escribió:por como lo planteas, parece ser algo que se resuelve muy facil con programacion logica, ahora no me acuerdo muy bien, pero deberias tener un archivo diccionario con todas las palabras cargadas como reglas, y armar un par de predicados que te devuelvan cantidades, no es dificil, y el prolog implementa un motor de combinatoria muy bueno

Justamente por eso él aclaro que necesita implementarlo en Smalltalk xD.

Si el tema es procedural / objetos no hay drama, es relativamente fácil convertirlo, pero con lógico no tanto, ya que, por ejemplo, los lenguajes incluyen mecanismos de backtracking embebidos que en procedural / objetos hay que generarlos manualmente (como el ejemplo que puse).

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

Lean, pensá que las palabras de 2 o 1 letras son re pocas, o sea.. tenes 6*5 de 2 letras y 6 de 1 letra... o sea, 36 palabras de más. La idea del árbol es porque vas a tener que volver a tomar otra letra en algún momento, y entonces lo que haces es volver a un nodo padre (con menos letras) y elegir otra letra hija para intentar formar otra palabra. Las palabras de 3 letras no están en las hojas eh, en las hojas sólo están las de 6. Las de 3 las vas agarrando a medida que descendés, así como las de 4 o 5.

Como dije antes, el árbol físicamente no existe... no lo armás. Es conceptual, es una forma de recorrer el diccionario. Por eso, es irrelevante el caso para cuantas letras se usen en las palabras, porque lo único que hacés al agregar una letra es descender conceptualmente en una rama del árbol y moverte en el diccionario (o sea, afinar la búsqueda, como hace uno cuando busca una palabra).

De hecho, así muy parecido funciona el texto predictivo de los celulares. No es igual porque hay varias palabras por cada combinación, pero es bastante similar. ^^

pablo escribió:Lean, pensá que las palabras de 2 o 1 letras son re pocas, o sea.. tenes 6*5 de 2 letras y 6 de 1 letra... o sea, 36 palabras de más. La idea del árbol es porque vas a tener que volver a tomar otra letra en algún momento, y entonces lo que haces es volver a un nodo padre (con menos letras) y elegir otra letra hija para intentar formar otra palabra. Las palabras de 3 letras no están en las hojas eh, en las hojas sólo están las de 6. Las de 3 las vas agarrando a medida que descendés, así como las de 4 o 5.

Como dije antes, el árbol físicamente no existe... no lo armás. Es conceptual, es una forma de recorrer el diccionario. Por eso, es irrelevante el caso para cuantas letras se usen en las palabras, porque lo único que hacés al agregar una letra es descender conceptualmente en una rama del árbol y moverte en el diccionario (o sea, afinar la búsqueda, como hace uno cuando busca una palabra).

De hecho, así muy parecido funciona el texto predictivo de los celulares. No es igual porque hay varias palabras por cada combinación, pero es bastante similar. ^^

El de los celulares es similar pero en lugar de descender por letra descenderías por número me imagino.

Igualmente, no terminé de entender tu idea... Donde estaría el diccionario? En algún lado físicamente tiene que elegir. Vas combinando y fijándote si cada palabra está o cómo vas desarrollando la búsqueda? :O

El diccionario estaría almacenado en alguna estructura ordenada, pero éste posee todas las palabras que existen (o sea, es un diccionario, literalmente, sólo que sin las definiciones en principio ).
La forma de acceder a él a fines teóricos es irrelevante... se sobreentiende que hay alguna función o método para leer la palabra de una posición X, y con eso alcanza para buscar en él una palabra particular siguiendo una búsqueda binaria y determinar así si está o no está esa palabra. Llamemos a esta función/método "Buscar(palabra)".
Sin embargo, para los fines del ejercicio, necesitaríamos también determinar si "hay palabras que empiecen con...", ya que esto sirve para saber si podar ramas o no (por ejemplo, podemos tener la subcadena "ape", que si bien no es una palabra, sabemos que en el diccionario va a haber palabras que empiecen así, como "apellido" o "apelar". Claro que, también hay que tener en cuenta que la primera palabra nunca se tomará, y la segunda sólo se tomará cuando las letras usadas inicialmente coincidan con ellas. Creo que el algoritmo base que hice antes no tendría problemas con estos casos. A esta/e función/método llamémosla/lo -malditos paradigmas xD- "BuscarEmpezandoCon(subcadena)".

Entonces, lo que hacés es, luego de concatenar cada letra nueva, volver a buscar en el diccionario si existen palabras que empiecen con esa nueva subcadena. Asì sabés si seguir profundizando en esa cadena de letras o intentar con otra. De eso se encarga el algoritmo, por lo cual no necesitás tener el árbol, si no que recorrés al diccionario como un árbol.

Supongo que en IA habrán dado "árboles de decisión". Esto es algo similar... lo que hacés es ir descartando posibles decciones a medida que recorrés el diccionario, y volver para atrás a tratar otras decisiones una vez que trataste las actuales.

Espero que quede claro! =D

Claro, yo apunto a cargar ese diccionario que vos decís en un árbol

Vos decís de tenerlo en alguna estructura ordenada, yo te digo que esa estructura debería ser un árbol Entonces agarras una letra de las posibles, te fijas si esta como nodo de nivel 2 del arbol, si no es agarras otra letra, si es agarras otra letra y te fijas si esta como nodo de nivel 3 (hijo del nodo anterior) en el arbol, etc etc.

es que un programa bien hecho en logico, labura asi, y vos te ahorras todo el quilombo de armar y gestionar el arbol

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

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 (?).

Cita: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.

Para solucionar el problema del exceso de procesamiento y uso de memória podés sacar estadisticas (como los que nombraste en el posts anterior) para determinar un diccionario de palabras "más usadas" (teniendo en cuenta la ley del 80-20).

Dependiendo el uso que se le dé se podría a) crear un sub-set de palabras ya predefinidas como palabras "más usadas" y guardarlas en memória, o b) hacer un módulo de "accounting" y otro que use la información para gestionar una "caché virtual" de palabras (aunque es medio dificil lograr que séa eficiente)

Esto independientemente del método de busqueda en el diccionario.

No me tome el trabajo de leer todo, pero unos profesores me tiraron un ejercicio bastante copado para hacer.

Un programa que imprima siempre su propio codigo, sin usar Archivos....

alguna idea?

Maclein escribió:No me tome el trabajo de leer todo, pero unos profesores me tiraron un ejercicio bastante copado para hacer.

Un programa que imprima siempre su propio codigo, sin usar Archivos....

alguna idea?

sin usar archivos? quién te planteó este problema? algún profe de paradigmas?
digo, porque si no tenés archivos, dónde está el código fuente? aunque si trabajás con objetos vivos no tenés archivos fuentes, entonces ahí sería posible hacerlo "sin archivos", pero imposible imprimir el código fuente porque estaríamos hablando de métodos, clases, etc.

por cierto, cuando decís "su propio código", te referís al código fuente, no?

en fin, al margen del lenguaje utilizado, hacés que el programa encuentre su archivo fuente, lo lea y lo imprima como si fuera cualquier otro archivo. pero para eso, ya te digo, tenés que tener un archivo fuente.

no se me ocurre otra cosa. tal vez con un poco más de datos se me ocurre algo más.