Así se fue la 3er Jornada de Python en Santa Fe

Como desde hace 3 años se viene organizando la Jornada de Python e Santa Fe con el objetivo de promocionar este maravillo lenguaje en esta localidad y sus alrededores. Por suerte fue todo un éxito y salió muy bien, estoy muy contento con el resultado.

Esta vez participé como organizador ayudando a los chicos con más experiencia en la organización de este evento intentando colaborar en lo que podía y tirando algunas ideas locas.

La jornada se realizó el pasado Sábado 4 de Octubre con una totalidad de 9 horas de duración en la Universidad Tecnológica Nacional Facultad Regional Santa Fe con una muy buena cantidad de asistentes, en dónde el auditorio estaba casi casi lleno.

Un par de semanas atrás de realizarse la jornada ofrecí mi casa como hosting para los asistentes por la lista de PyAr para los que quieran venir a Santa Fe desde afuera. Como siempre, esto es algo que me gusta hacer, ya que cuando voy a otras ciudades en mi prefencia particular prefiero que me alojen a que me paguen/pagar un hotel, me gusta estar cerca de la comunidad y compartir buenos momentos a que embolarme en un hotel, pero esto va en cada uno.

Tuve la suerte de poder alojar a varios: Karucha (Héctor Sanchez), facundobatista (Facundo Batista) , nubis (Cristian Bruno) y leorockway (Leonardo De Luca) . Nos organizamos como pudimos y creo que todos quedaron cómodos, yo me ofrecí a dormir en una bolsa de dormir porque la cantidad de camas/colchones/sillón eran justo cuatro. Espero que ellos se hallan sentido cómodo en la estadía.

El Viernes por la tarde el primero en llegar fue Leo con quién fuimos a recorrer el centro de Santa Fe y a pasear un rato. Luego vino Karucha y charlamos un rato largo hasta que llegaron Facundo y Nubis, quienes fueron diréctamente a lo de Nicolás César para juntarnos a comer una pizzeada y charlar.

Durante la noche, Nico hizo un monólogo sobre su trabajo y la charla que iba a dar al día siguiente sobre BeautifulSoup y el Gran DT. Un cago de la risa, no paraba de reirme y me hacía recordar varias cosas del mío.

Al día siguiente fuimos lo más temprano que pudimos a las jornadas para registrarnos y preparar todo porque Facundo tenía la primer charla, y yo tenía que colaborar con la organización, que ya me estaba haciendo el chanta llegando tarde y sin haber ido el día anterior a acomodar todo

Luego de llegar, lo primero que hice fue ponerme a doblar mini-tutoriales de Python para que la gente se lleve uno cuando se registre. Por cierto, estaban buenísimos. Después de esto estuve viendo la charla de Facundo Batista y controlando que todo salga bien, manteniéndome cerca por si necesitaba algo, por suerte salió todo bien.

Luego me ocupé del quincho de la facultad que habíamos pedido para almorzar ahí. Fui en busca de las llaves, ordené las sillas y demás. Luego me fui a la registración para estar ahí ayudando en lo que surja y charlando con mucha gente. Pegamos algunos afiches de Santa Fe Libre para ver si la gente se va sumando al proyecto y algunas cositas más.

Antes de ir para el quincho a comer, ví la charla de Nicolás César sobre BeautifulSoup, esta estuvo muy buena, sobre todo muy graciosa ya que a esta librería ya la conocía bastante: no encontré nada nuevo en la charla pero me hizo recordar algunas cosas y reirme mucho. Enseguida después de esta nos fuimos a comer al quincho de arriba con todos los disertantes y algunos amigos de los mismos. Comimos pizzas, empanadas y sandwichitos muy ricos… Por suerte alcanzó justo justo!

Por la tarde, al empezar la primer charla de Daniel Moissete nos enteramos que no había cable para el proyector D’Oh, asique salimos corriendo para todos lados buscando ese maldito cable. Por suerte lo encontramos, aunque no bastante rápido, y Daniel perdió unos cuantos minutos de proyección para su charla.

Ví un poquito de la charla de cocos2d también, ya que andaba a las vueltas por ahí, pero ví parte del final y como siempre que veo un poquito de eso me vuela el bocho y me dan ganas de hacer cosas con esa librería. Es genial!

Otra de las charlas que quería ver era la de Nubis, Hacking Django y la verdad que me gustó mucho, aunque se halla quedado corto con el tiempo, estuvo muy buena. Me abrió bastante la cabeza de las cosas que se pueden hacer con la web y con Django, dos terrenos en los cuales no soy muy fuerte. Esta charla tuvo un toque de color… Una pregunta de Gastón Ramos en el medio de la charla haciendo una comparación con Ruby On Rails, Nubis reconoce la voz de él y le contesta sutilmente: “Acá no hablamos de Ruby“. Me hizo reir bastante, porque fue muy cortante y muy graciosa la forma en que se lo dijo

Al cierre de la Jornada estaban las Lighting Talks, una charlas relámpagos de 5 minutos cada una, en la cual cada uno cuenta algo de lo que pueda en este tiempo, intentado hablar lo más rápido que pueda. Estuvieron muy buenas, hubo charlas muy variadas en contenido y algunas no tenían nada que ver con Python, eso estuvo bueno también. Una de las que más me gustó fue la de John Lenton que mostró unas fotos y hablaba sobre el trabajo con el software libre. También estuvo la de Leito Monk, quién tuvo tan buena suerte de que le salte el fsck al momento de bootear la máquina que fue muy gracioso.

Al finalizar las jornadas volvimos cada uno para su correspondiente casa, nos bañamos, hablamos un rato y salimos para Plataforma, el bar de la terminal, a comer y tomar mucha cerveza: a cumplir con el objetivo encubierto de la Jornada de Python. Acá hablé mucho con Pedro, Guille, Nubis y una chica que no recuerdo el nombre… Bah, creo que nunca lo supe. Después de comer mucho y entender poco, con Nubis, Karucha, Leo y Facundo nos fuimos a tomar unas cervezas más a “La S boulevard” en dónde nos engañó el Reggae de la puerta para encontrarnos con Cumbia en el boliche.

Cerca de las 3 am Facundo y Karucha se vuelven para descanzar ya que al otro día Facu tenía que manejar para volverse a Buenos Aires. Nosotros seguimos viaje con los chicos y dimos un par de vueltas más, para volver totalmente liquidado, de mi parte, cerca de las 6 de la mañana.

El domingo a las 12 nos encontrábamos en lo de “Chiquito”, un tenedor libre de pescado ubicado al final de la costanera. Una exquisitez realmente. Comí como un sapo. Para cerrar la tarde nos fuimos a tomar un helado a una heladería de la zona y finalmente organizamos todo como para levantar campamento y que cada uno se vuelva a su respectivo lugar de origen.

Como Leo se quedaba un día más, nosotros volvimos a casa y luego nos fuimos a dar un par de vueltas por el centro y comer algo en “La City” por la noche.

Hoy Lunes, me fui a trabajar totalmente liquidado de un fin de semana agitado intentando hacer todo lo más rápido posible en el trabajo porque había quedado con Leo que me pasaba a buscar para ir a almorzar por la peatonal o ver qué hacíamos al menos. A las 12 en punto me mandó un mensaje, cerré todo y salí. Fuimos nuevamente a “La City” y comimos un lomo completo expectacular, con huevos fritos y papas fritas… Casi exploto!

Caminamos la vuelta hasta mi casa con la panza llena e hicimos fiaca un rato, después hablamos sobre VoIP y probamos distintos programas, entre ellos mumble el cual recomiendo para hacer conferencias de más de dos personas. A eso de las 17 hs lo acompañé a Leo a la terminal para que pegue la vuelta hacia Buenos Aires…

Así se terminó la 3er Jornada de Python en Santa Fe. Gracias a todos por venir y por la buena onda que tuvieron los disertantes, asistentes y en especial a la gente que vino a casa.

Me privan los datos

Es lamentable. Hoy después de hablar lo que publiqué en el post anterior con la profesora, un amigo le preguntó que forma tenía de exportar la base de datos para poder trabajar en su casa (estamos haciendo 2 guías de 20 ejercicios cada una de sentencias SQL). Antes me había preguntado a mí y no tenía ni idea ya que estaban usando Oracle.

A: Le preguntaba si no hay una forma de exportar la base de datos o algo para poder llevármela a mi casa y poder trabajar ahí.

P: No porque el profesor no la puso disponible a la base de datos.

A: Ah, ¿No está disponible?, yo le decía porque no llegamos a hacer todos los ejercicios.

P: Mmm… No, la única opción que tienen es venir a trabajar acá al laboratorio

También está en OGG, y es patético. Asique bueno, mi amigo se puso a hacer SELECT * FROM tabla; de las 8 tablas que había y copiaba eso a un “.txt” para que yo me lleve a mi casa y luego haga un script que levante eso y lo vuelque en una base de datos.

Recién lo termino, aunque no está muy bien hecho, ya que algunos atributos estaban separados por 2 espacios y otros por N, quedó más o menos… A veces tuve que agregarle campos vacíos (le puse ** para identificar cuales eran).

Igualmente, no entiendo muy bien todavía, y no tengo ganas de ponerme a ver cómo son tampoco, son las claves foráneas y las claves primarias. Aunque tengo el diagrama, este se entiende bastante poco.

… dentro de poco no voy a poder compartir con nadie lo que aprendo en la facultad, espero realmente que esto cambie …

Una “discusión” sobre un parcial

Primero como para ponernos en órbita, explico de qué se trata esto. Ayer (Martes) rendí el primer y único parcial de Gestión de datos. No pude estudiar mucho por algunas cuestiones personales en cuanto a discrepancia con los docentes de la materia y no tenía mucho ánimo. Por suerte algo de SQL sabía porque lo había estudiado por mi cuenta en otra oportunidad.

Luego de salir del parcial, me fui contento a mi casa porque me había ido, a mi modo de ver las cosas: bastante bien. Como siempre, esto no quiere decir que apruebe ni nada por el estilo, y mucho menos si considero la bronca que me tienen los docentes por hacer preguntas en clases.

Dejando de lado todo esto, hoy tuve clase de práctica y un amigo me preguntó algo sobre un ejercicio que me hizo poner en duda. Aproveché y le pregunté a la profesora sobre esto. Escribo abajo el diálogo completo (transcripción que realicé desde un OGG).

Pero antes, explico más o menos como era el enunciado del problema. Había un diagrama entidad-relación el cuál nosotros teníamos que pasar a tablas SQL pero sin escribir las sentencias CREATE TABLE y demás. Sino que con algunos dibujos y explicando cuales eran claves primarias y foráneas estaba bien. El diagrama era como este (lo único que le falta son algunos atributos a foto que no recuerdo, pero es para mostrar la idea):

El enunciado decía más o menos así: “Un usuario puede tener 0 o n fotos y una foto puede tener como máximo un dueño. Además un usuario puede tener n cuentas de email. NOTA: cant_fotos es un atributo calculable.”

Yo hice tres tablas, una para Usuario, otra para Foto y otra Usuario_Email en la que indicaba el email y el usuario, de modo que pueda tener muchos emails un mismo usuario. En ningún lado puse cant_fotos ya que en el enunciado decía que era un atributo calculable. Aunque antes de leerlo igualmente pensaba que no debería estar ya que sale con un SELECT COUNT. Asique no lo puse en ningún lado. Ahora viene lo que hablamos con la profesora hoy. El primero que hablar (”A”) es un amigo, y luego paso a ser yo (”M”). “P” es la profesora:

A: En la que teníamos que armar las tablas: a mí me quedaron tres, Usuario, Correo y Foto. Además había un atributo que era calculable.

P: Si, eso es porque estaba en el modelo.

A: Claro, yo no lo puse en ninguna tabla.

P: No, pero eso tiene que estar en la tabla Usuario.

A: ¿Tiene que estar?

P: Si obvio.

A: Pero si se puede calcular.

P: El contenido después lo verán, se supone que si lo estás haciendo en la vida real el contenido lo calcularás por código o lo que sea. ¿Pero dónde lo vas a almacenar? Tenés que tener creado el campo dentro de la tabla.

M: Pero eso se calcula desde la tabla de fotos. Hacés un SELECT COUNT de la tabla de fotos y sabés cuantas fotos tiene ese usuario. No es necesario guardarlo.

P: Bueno, está bien. Lo óptimo sería no guardarlo, sino que ir calculando e ir mostrándolo. Sino que así como estaba en el modelo se necesitaba tener ese atributo en la tabla.

M: ¿Porqué? No entiendo…

P: Y porque es un atributo de Usuario. Después el contenido lo vas calculando y, osea, lo que se entiende es que si está en el modelo es porque se necesita tenerlo almacenado en algún lado, entonces lo almacenás como un atributo en la tabla de Usuario. Igual, si no lo pusieron se les bajará unos puntitos nada más. Osea, sólo por no haber puesto el atributo N-Fotos no van a salir mal.

M: No, está bien, no es la cuestión salir bien o salir mal. El tema es que no entiendo porqué está mal no ponerlo, a eso me refiero. Si justamente el enunciado decía “el atributo es calculable”

P: Si, en realidad en el enunciado estaba como una aclaración para que no pregunten “¿Qué es ese atributo que esta con líneas puntadas?” Puede ser que eso los confundió digamos y que pensaban que había que hacer algo o no almacenarlos.

M: Es que está almacenado, porque si vos sabés cuantas fotos hay en la base de datos, ese
atributo ya lo tenés. A eso es lo que voy yo.

P: Sí, pero cuando vos hacés el cálculo lo obtenés.

M: Claro, de hecho si lo guardás puede quedar inconsistente la base de datos porque te quedan 5 fotos y tiene 10.

P: Está bien, y es así como vos me decís. De hecho puede ser que no esté el atributo en
la vida real y no lo tengas que guardar, pero en este caso del modelo sí porque aparecía. Si
no fuese necesario diréctamente no aparece en el modelo y por código lo obtenés. Y listo.

M: Bueno, entonces que sea calculable y que no sea calculable es indistinto.

P: Si, en este caso es lo mismo.

M: No puede ser.

P: ¿Cómo que no? Cuando nosotros hicimos la guía había cosas que te pedía la guia y que en modelo no se reflejaban. Bueno en este caso es al revés, si estaba en el modelo era porque después al transformarlo lo ponías como un atributo en tu tabla. Igualmente todo es discutible, cuando después vos empieces a trabajar podés ir a preguntarle al usuario que te está mandando hacer el trabajo si lo va a querer tener almacenado o no. Y le vas a decir que no hace falta porque lo vas a poder calcular y lo podés hacer por código, etc etc… Y seguramente no lo vas a tener. En este caso del modelo si.

… me imagino preguntándole al cliente: “Señor, ¿Quiere que guarde el atributo X o lo calculamos al momento de mostrarlo? ¿Usted que opina?”…

Caso de estudio: “Dependencia Funcional”

Hoy fui a la facultad a la materia Gestión de Datos e hicimos un ejercicio de la guía de actividades prácticas. Estamos dando el tema “Dependencia funcional y normalización”. El enunciado es este:

Se desea construir una BD para gestionar la información de los electores en un censo electoral con los siguientes supuestos semánticos:

• Un elector es identificado por su DNI (D). Todos los electores tienen DNI. Un elector tiene un nombre (N), fecha de nacimiento (F) y sexo (S)
• Un municipio se identifica por la provincia a la que pertenece (P) y su código de municipio (C). No pueden existir dos municipios con igual código en la misma provincia.
• Dos municipios pueden tener el mismo nombre (B) pero sólo si pertenecen a provincias diferentes
• Una mesa está identificada por su municipio, número de distrito (T), número de sección (NS) y número de mesa (M). Los números de distrito se pueden repetir para municipios diferentes pero no dentro del mismo municipio. Igual ocurre con los números de sección respecto de los distritos y con los números de mesa respecto de las secciones.
• Un elector está inscrito en una mesa, incluida en una sección, a su vez incluida en un distrito, que a su vez pertenece a un municipio.
• Un elector tiene una dirección, es decir, una calle (L) y un número de calle (E).
• Todos los electores que residen en la misma calle del mismo municipio están inscritos en la misma sección, aunque pueden estar en mesas diferentes según el número de la calle.

Se pide:

1. Realizar un modelo de tablas que represente la BD a ser utilizada por el sistema tratando de minimizar la cantidad de tablas.
2. Llevar el modelo anterior a la tercera forma normal (3FN).

Sinceramente yo no tenía ni idea como arrancar, esto lo dimos en la clase de teoría hace dos semanas creo y no me acordaba nada, asique agarré el libro y me puse a leer. Termino de leer la primer forma normal, comienzo a hacerlo, y la profesora explica como resolverlo. Escuho, atiendo, y me pongo a resolverlo de la forma que explicó. Me quedó así:

• DNI(D) ->Nombre(N), Fecha de nacimiento(F), Sexo(S)
• Calle(L), Provincia(P), Código(C) -> Número de sección(NS)
• Provincia(P), Código(C), Calle(L), Número de calle(E), Número de sección(NS), Número de distrito(T) -> Número de mesa(M)
• Provincia(P), Código(C) -> Nombre(B)
• DNI(D) ->Número de sección(NS)
• DNI(D) ->Calle(L), Número de calle(E)

Justo cuando terminamos de hacer esto, la profesora empieza a desarrollarlo en el pizarrón y agrega una dependencia funcional que nosotros no teníamos:

• DNI(D) -> Nombre(N), Fecha de nacimiento(F), Sexo(S), Calle(L), Provincia(P), Código(C), Número de sección(NS), Número de calle(E), Número de distrito(T), Número de mesa(M), Nombre(B)

Resumiendo, el DNI determina todos los otros campos. Con los chicos que lo estaba haciendo empezamos buscar a ver si se nos había pasado un axioma en dónde podía llegar a estar dicha relación, aunque sin éxito, no la encontramos. Uno de nosotros pregunta:

• Alumno: “¿Porqué DNI determina Provincia(P) y Código(C)? Por ejemplo”
• Profesora: “Mmm… No sé como explicártelo, creo que se deduce del enunciado, es como en la vida, vos sabés dónde votas con tu DNI. Osea, podés saber todos los datos de tu mesa”

En ese momento, sinceramente, no podía creer lo que nos estaba diciendo: “No sé como explicártelo” y además, “Creo que se deduce del enunciado”. Supongo que si hay un enunciado de un problema es para que lo respetemos y que no queden cosas que se sobre entienden, porque justamente esto es lo que trae consigo muchos problemas a la hora de interpretar algo.

Igualmente, me quedó picando y capaz que tenga razón, que se deduzca del enunciado porque existen las reglas de Armstrong con las cuales se pueden inferir en otras dependencias funcionales. Asique cuando llegué a mi casa me puse a leer éstas reglas y a ver si llegaba a la respuesta de la profesora. Estas son las reglas:

• Reflexividad: si B es subconjunto de A, entonces A->B
• Aumento: si A->B, entonces AC->BC
• Transitividad: si A->B y B->C, entonces A->C

De estas tres reglas se pueden deducir otras tres más:

• Descomposición o proyección: si A->BC, entonces A->B y A->C
• Unión o adición: si A->B y B->C, entonces A->BC
• Pseudo-Transitividad: A->B y DB->E, entonces AD->E

La que acabo de encontrar (es la primera vez que lo hago realmente) es esta:

• Por Unión: DNI(D) -> Nombre(N), Fecha de nacimiento(F), Sexo(S), Calle(L), Número de calle(E), Número de sección(NS).

En ningún lado veo que exista la dependecia de Provincia(P) y Código(C) con DNI(D). Por lo tanto no entiendo de dónde está sacando que sabiendo el DNI de un persona se puede saber la Mesa(M) en cuál vota o la Provincia(P) en la cual vive. Por lo tanto el resto del ejercicio por supuesto que lo tenía todo mal hecho ya que yo trabajé sobre la base de datos del enunciado y ella trabajó sobre la de la vida misma

Python más rápido que Java

Con un título de post robado de la charla de Facundo Batista y Lucio Torre (”Python más rápido que C“) empiezo un post para comentar los resultados que fui obteniendo a lo largo de la implementación de un árbol de búsqueda trie, para el desarrollo de un trabajo práctico de la facultad.

Una parte del trabajo consiste en crear una función de autocompletado, esto es, a medida que el usuario vaya tipeando letras en un editor de texto, se despliegue una lista con todas las sugerencias que coinciden con la cadena de teclas tipeadas. Por ejemplo, si el usuario va tipeando “automovi”, el programa sugiere las palabras ["automovilístico", "automovilismo", "automovilista"] (la lista de todas las palabras son previamente cargadas desde un archivo de texto plano).

Con mi equipo intuíamos que esto se hacía con un árbol, ni idea porqué, pero pensábamos que era mejor que hacer una lista con todas las ocurrencias y filtrar por “startswith()” (empieza con), ya que de esta forma estamos recorriendo toda la lista, y el proceso se alentecería bastante. Asique opción descartada definitivamente… Aunque… ¡Aunque nada, y listo

Luego seguimos leyendo el trabajo, y decía: “La cantidad de palabras en los diccionarios puede ser grande, por lo cual se recomienda que la selección de la palabra actual se realice mediante una referencia a una estructura arbórea, y que no se cree una lista con todas las palabras posibles, ya que la ineficiencia de esta opción puede notarse en una aplicación interactiva como la que se pretende desarrollar”. Por lo que no descubrimos nada con lo que intuíamos, pero por lo menos nos dimos cuenta que no estábamos equivocados…

El primer día que nos juntamos con Guille, mi compañero de grupo junto a Iván, aunque éste último se encontraba ausente debido a que estaba en su ciudad (¿natal?), nos pusimos las pilas pensando cómo iba a ser la estructura de datos que queríamos crear y cómo podíamos luego buscar las coincidencias con respecto a lo que tipeaba el usuario.

Sin ningún tipo de estupefaciente encima, ni siquiera cerca, empezamos a delirar varias ideas, árboles, listas, diccionarios, pilas, colas, mates y música volaban por todos lados. Pero ninguna de todas las ideas nos convencía.

A todo esto estábamos en la tarde del Miércoles de esta semana en la pileta de mi casa pensando estas cuestiones con un infiltrado en el grupo (Nico). Aunque ya habíamos trabajado a la mañana corrigiendo algunas cosas del trabajo anterior, que pensábamos que podían llegar a estar mal. La idea que fue más acertada por los tres, fue la de tener en cada nodo una lista con todos sus hijos, además de un caracter (que componía una de las letras de la palabra), y una marca indicando si en ese nodo terminaba una palabra o no.

Según algunos comentarios de Nico en su computadora la carga del diccionario.txt de unos 800Kb aproximadamente en una estructura le llevaba algo así como 5min, ¡Una guasada! Lo que en gran parte fue el comienzo de esta investigación.

Hicimos algunas cosas más (perdimos un poco de tiempo), y nos pusimos a codificar algo con el Guille. No llegamos a nada concreto, ni siquiera pudimos terminar de pulir la idea que teníamos. Él se fue y yo me quedé con la espina en el ojo de que cómo no podíamos implementar un árbol, si ya lo había hecho en ocasiones anteriores… Bueno, pasó y me fui a dormir.

Al otro día cuando me levanto, me voy derecho al canal IRC de PyAr, sabiendo de ante mano que tienen muy buena onda y que seguro alguno me iba a tirar alguna pista de cómo implementar un árbol de este tipo, por lo menos en Python. Lo que más necesitaba era saber si la idea que teníamos estaba más o menos acertada, sobre todo para no empezarme a pelear con Java sin saber si lo que estoy haciendo va a funcionar o no.

Me tiraron varias ideas teóricas, conceptos, material para investigar (que busque en google ) y demás, hasta que Facundo mandó una implementación de esa estructura arbórea que yo necesitaba en Python. Él implementó algo muy parecido a lo que teníamos pensado pero cambiando algunas cosas, por ejemplo, en vez de listas utilizó diccionarios y algunas otras cuestiones que permite Python. La cuestión es que me hizo entender muy bien el funcionamiento de éstos árboles y lo rápido, fácil y útil que es Python para crear prototipos de cualquier cosa.

Lo primero que probé fue cargar todo este archivo con la implementación que hizo Facu (en el link anterior ya tiene las modificaciones que le hice yo). Lo cargó enseguida, demoró 5.12 segundo, que comparado con los 5 minutos de los que veníamos manejando con Nico, no era nada. Hice una búsqueda y funcionó. Pero pasaron algunas cosas, por ejemplo el programa en memoria estaba ocupando 185Mb de ram y 100Mb de memoria virtual, lo que es ¡Una locura!. Igualmente no molesté más a la gente de PyAr hasta que implemente mi versión en Java y podamos comparar tiempos de ejecución, de carga, de búsqueda y demás porque quizás esto era ¿aceptable?.

Luego de hacerlo en Java después de algunas peleas con los tipos de datos, partiendo de que no encontraba cuál era la clase de diccionarios ya que está Dictionary, pero esta es abstracta, por lo tanto no puedo tener instancias de estas. Así seguí bajando por el árbol de herencia hasta llegar a la clase Properties. Ni idea si esto es un diccionario o no, pero lo hice con esta clase y funcionó por lo menos…

Terminé de codificarlo todo, el código resultante quedó así (la implementación en Java) y los tiempos para “cargar las palabras del diccionario al árbol” y “cargar el árbol y realizar una búsqueda” son estos. El comando time está ejecutado tres veces por cada operación. Una vez que el programa carga todo el árbol en memoria, este ocupa 108Mb de memoria ram física y al rededor de 180Mb de memoria de intercambio algo similar a lo que ocupaba el programa hecho en Python. Asique estaba conforme con ambas implemenetaciones hasta el momento.

“La primera versión que había hecho del programa en Java ocupaba sólo 20Mb en memoria, lo cual me sorprendió mucho cuando ví. Pero que luego de unas correcciones pasó a parecerse a la implementación hecha en Python”

En este momento dejé un comentario en el foro de la materia explicando esta situación, comentando de que habíamos creado esta estructura y que seguro que el programa iba a ser muy lento a la hora de mostrar las sugerencias en la lista de posibilidades. Pero hasta el día de hoy no he tenido ninguna respuesta .

Comenté en el canal de PyAr que me parecía raro que el programa ocupara tanto en memoria en comparación con la incorrecta implementación del mío (que en este momento desconocía) y Facundo mejoró su código agregando __slots__ para que la clase sepa cuanta memoria reservar de ante-mano. Y el programa pasó a ocupar como 80Mb menos en memoria, lo cual es bastante menos. Interesante.

Hoy, tres días después de haber pensado que era una locura meter todas las palabras y hacer startswith, me puse a implementar esta forma de encarar el problema, para luego llevarme una sorpresa gigante.

El programa para la carga y búsqueda lo hice en Python, ya que quería ver resultados rápidos, y Python para esto viene al pelo. Ni bien terminé de hacerlo corrí la aplicación cargando el árbol y nada más, en dónde veo que esta carga estaba demorando solamente 0.13 segundos como mucho, lo que no se compara con la carga del árbol que era 5.12 segundos con el algoritmo de Facundo también hecho en Python y 2.6 segundo que demoraba el mío hecho en Java. Entonces ¿es mejor utilizar listas que árboles para esto? El programa en Python con una lista en vez de un árbol es este.

Por ahora estoy bastante mareado con todos los resultados que obtuve. En el canal de PyAr me dijeron que quizás no importe tanto el tiempo que demore en cargar el diccionario ya que esto se hace una sola vez, lo que más importa es el tiempo de búsqueda de concordancias… Pero el resultado promedio que obtuve con esta implementación buscando 100 palabras aleatoreas:

[manuel] [~/blog/python-mas-rapido-que-java]$ python lista.py
En cargar: 0.07 seg
Cantidad de palabras a buscar: 100
Busq x palabra: 41.96 mseg
[manuel] [~/blog/python-mas-rapido-que-java]$

Cuanto tenga menos dudas o esté seguro al menos de cómo lo voy a desarrollar y qué estructura de datos voy a usar para hacer esto escribo cómo y qué hice