Estoy leyendo el libro de Papert, Mindstorms, que trata sobre su idea de usar Logo para enseñar matemática.
La verdad que es un libro muy interesante con ideas muy buenas respecto a la educación. Algo que me dí cuenta leyendo este libro es que lo importante no es aprender Logo sino el proceso de aprendizaje por el que se transita, por lo tanto lo más importante es como los docentes lo enseñan, el ambiente en el cual se aprende.
Lo que veo (por ejemplo con mi hija mayor) es que le están enseñando Logo de la manera clásica, sentada en una computadora sin poder pararse y "jugar a ser tortuga" que según Paper es uno de los puntos más importantes de este aprendizaje. Sin embargo luego de hablar con gente del colegio me quedé un poco más tranquilo porque parece que en el resto de las cosas están haciendo las cosas bien.
El otro día me sente con mi hija menor (recién paso a 2 grado) para ver como reaccionaba ella (no lo vió en el colegio todavía) y la verdad me sorprendí por como llegó a la conclusión de que se necesitaba rotar 360/3 cada vez para hacer un triángulo. Lo bueno es que no tuvo que hacer la cuenta, porque no sabe dividir, pero entendió que alcanzaba con decirle a la tortuga que lo haga...
jueves, 28 de febrero de 2008
lunes, 25 de febrero de 2008
Más acerca de Dates, Times, etc.
Estoy leyendo el libro "Developing Time-Oriented Database Applications in SQL" que está disponible para bajarlo en http://www.cs.arizona.edu/people/rts/tdbbook.pdf
Realmente está muy interesante ver como encararon el problema del modelado de calendarios en SQL y tiene muchos comentarios históricos interesantes. Este libro, además de "Calendrical Calculations" nos está ayudando (en realidad a Maxi Taborda) a terminar el trabajo que presentó en Smalltalks 2007
El core del libro trata sobre como modelar aplicaciones temporales, algo similar al problema que encara el paper de Time Travel: A Pattern Language for Values That Change de Kent Beck, sin embargo los primeros capítulos son muy interesantes en lo que respecta al modelado del calendario en SQL. Algunas cosas que recuerdo son:
1) SQL solo modela el calendario gregoriano
2) Ninguna implementación, lo que leyeron, ninguna implementación es complient con el estándar de SQL-92 que es aquél que define como tratar este problema
3) El que más se acerca al estándar es DB/2, el menos similar es Oracle! (El libro fue escrito en 1998)
4) El calendario Gregoriano no tiene el año 0, por que cuando su predecesor, el calendario Juliano, fue creado en occidente todavía no se "conocía" el número 0
5) Hay indicios de que Jesús (de haber existido) nació en el año 4 antes de Cristo, o sea, nació antes de haber existido (otro milagro!! -:) )
6) SQL-92 define abstracciones para Date y DateTime, pero no para Year y DayOfMonth
7) Utilizan una metáfora similar a la nuestra de linea de tiempo, sin embargo no es tan claro en lo que respecta a los puntos de distinta granularidad
8) Posee el concepto de medida de tiempo, aunque lo llama Interval, algo que en Ansi Smalltalk se denomina Duration. Para Chalten un intervalo de tiempo está más relacionado con un intervalo matemático, o sea, algo que posee un inicio y final.
9) El calendario Arabe Hjiri es lunar, con años de 12 meses de 28 días. Por lo tanto un evento puede caer en verano un año y en invierno en otro año. Se sincroniza con el Gregoriano cada 33 años (la edad de Jesús cuando murió... )
10) Entendí por fin que es un segundo bisiesto!!! A partir de la creación del UTC, para mantener correctamente sincronizado los equinoccios y debido a que la traslación y rotación de la tierra no son constantes, se re-acomodan los relojes sumando o restando uno o dos segundos a un minuto particular (generalmente el último minuto de un día). Hasta ahora solo se han agregado segundos. Esto significa que ya no es válido pensar que los minutos tienen 60 segundos puesto que los hay de 61 y 62 segundos. Esta irregularidad agregada al de los "day light savings" (o sea, el cambio de hora para ahorrar energía como sucedió en Argentina esta año) hace que la aritmética de este modelo no sea tan simple. Solamente piense que al sumarle 60 segundos a una hora de un día particular (un DateTime) puede ser que se queden en el mismo día y hora... en pocas palabras, las unidades de minuto y sus derivados no son más intercambiables o derivables de los segundos y sus derivados (como milisegundos)... todo un problema. Todo un problema por tratar de mantener un punto de referencia absoluto...
Espero que hayan tenido tiempo para leer este post! :-)
Realmente está muy interesante ver como encararon el problema del modelado de calendarios en SQL y tiene muchos comentarios históricos interesantes. Este libro, además de "Calendrical Calculations" nos está ayudando (en realidad a Maxi Taborda) a terminar el trabajo que presentó en Smalltalks 2007
El core del libro trata sobre como modelar aplicaciones temporales, algo similar al problema que encara el paper de Time Travel: A Pattern Language for Values That Change de Kent Beck, sin embargo los primeros capítulos son muy interesantes en lo que respecta al modelado del calendario en SQL. Algunas cosas que recuerdo son:
1) SQL solo modela el calendario gregoriano
2) Ninguna implementación, lo que leyeron, ninguna implementación es complient con el estándar de SQL-92 que es aquél que define como tratar este problema
3) El que más se acerca al estándar es DB/2, el menos similar es Oracle! (El libro fue escrito en 1998)
4) El calendario Gregoriano no tiene el año 0, por que cuando su predecesor, el calendario Juliano, fue creado en occidente todavía no se "conocía" el número 0
5) Hay indicios de que Jesús (de haber existido) nació en el año 4 antes de Cristo, o sea, nació antes de haber existido (otro milagro!! -:) )
6) SQL-92 define abstracciones para Date y DateTime, pero no para Year y DayOfMonth
7) Utilizan una metáfora similar a la nuestra de linea de tiempo, sin embargo no es tan claro en lo que respecta a los puntos de distinta granularidad
8) Posee el concepto de medida de tiempo, aunque lo llama Interval, algo que en Ansi Smalltalk se denomina Duration. Para Chalten un intervalo de tiempo está más relacionado con un intervalo matemático, o sea, algo que posee un inicio y final.
9) El calendario Arabe Hjiri es lunar, con años de 12 meses de 28 días. Por lo tanto un evento puede caer en verano un año y en invierno en otro año. Se sincroniza con el Gregoriano cada 33 años (la edad de Jesús cuando murió... )
10) Entendí por fin que es un segundo bisiesto!!! A partir de la creación del UTC, para mantener correctamente sincronizado los equinoccios y debido a que la traslación y rotación de la tierra no son constantes, se re-acomodan los relojes sumando o restando uno o dos segundos a un minuto particular (generalmente el último minuto de un día). Hasta ahora solo se han agregado segundos. Esto significa que ya no es válido pensar que los minutos tienen 60 segundos puesto que los hay de 61 y 62 segundos. Esta irregularidad agregada al de los "day light savings" (o sea, el cambio de hora para ahorrar energía como sucedió en Argentina esta año) hace que la aritmética de este modelo no sea tan simple. Solamente piense que al sumarle 60 segundos a una hora de un día particular (un DateTime) puede ser que se queden en el mismo día y hora... en pocas palabras, las unidades de minuto y sus derivados no son más intercambiables o derivables de los segundos y sus derivados (como milisegundos)... todo un problema. Todo un problema por tratar de mantener un punto de referencia absoluto...
Espero que hayan tenido tiempo para leer este post! :-)
viernes, 1 de febrero de 2008
SUnit, memoria, velocidad y metaprogramación
Uno de los problemas que hemos tenido últimamente con SUnit es la gran cantidad de memoria que consumía al correr los 15.540 test que tenemos en la actualidad. Al correr todos estos test, el proceso de VisualAge crecía en consumo de memoria de 90 megas a 600 megas!. Al crecer dicho proceso a 600 megas, el uso de la pc se hacía insoportable por el trashing que realizaba constantemente puesto que estamos trabajando con máquinas de 1Gb de memoria (los 600 megas sumados al consumo del Firefox, GemStone, etc, rápidamente sobrepasaban el giga).
Lógicamente el problema se debía a que había objetos que quedaban referenciados durante la ejecución de los tests y esto hacía que creciera tanto el consumo de memoria. ¿Qué objetos prodrían ser?. Al principio pensamos que serían los test resource, pero rápidamente nos dimos cuenta que no.
Luego de investigar un poco más me dí cuenta que dichos objetos eran en realidad los mismos test que se ejecutaban y al poseer estos variables de instancias (que en algunos casos referenciaban a instancias completas del sistema) el consumo de memoria crecía de acuerdo a la ejecución de los mismos. Los test son referenciados desde varios lugares, entre ellos el TestResult que posee el resultado de la ejecución de los test y el TestSuite en caso de utilizarse uno.
La solución consistía entonces en lograr que estos objetos no queden referenciados. Lo primero que intenté fue hacer que no queden referenciados desde el TestResult pero el comportamiento de las herramientas de ejecución como el SUnitRunner o el SUnitBrowser no se comportaban bien ante este cambio. Peor aún, no podía lograr fácilmente hacer que el TestSuite dejase de referenciar a los test. Para hacerlo tenía que modificar bastante SUnit, algo que no me atraía demasiado.
Lo que se me ocurrió hacer fue que luego de terminar la ejecución del test y hacer el #tearDown, se pongan todas las variables de instancia con "nil". Hacer esto fue inmediato gracias al metamodelo y la capacidad reflexiba de Smalltalk, simplemente implemente el mensaje #cleanUpIntanceVariables de la siguiente manera:
TestCase>>cleanUpInstanceVariables
(TestCase allInstVarNames size + 1) to: self class allInstVarNames size do: [ :index | self instVarAt: index put: nil ]
Y luego modifique #runCase así:
TestCase>>runCase
[self setUp.
self performTest] sunitEnsure: [self tearDown;cleanUpInstanceVariables]
Con este simple cambio logré que no se consumiera más memoria, durante la ejecución de los 15.540 test la memoria en uso del proceso no aumenta y la mayor sorpresa fue ver que la ejecución de los test bajó en un 50%!! Si, ahora los test corren en la mitad de tiempo de lo que lo hacían antes puesto que Smalltalk no tiene que estar realizando una recolección de basura constantemente, con el scavenging alcanza.
En fin, un buen ejemplo de como un buen metamodelo puede ayudar a resolver problemas que, de no poseerlo, hubiese sido muy costoso hacerlo. Por ejemplo, otra solución sería obligar a cada test a implementar el mensaje #cleanUpInstanceVariables. En nuestro caso hubiese sido necesario implementar este mensaje 2530 veces puesto que esa es la cantidad de subclasses que posee TestCase, teniendo en cuenta que cada una de estas implementaciones deberían modificar a mano las variables de instancia para que referencien a "nil" y luego no olvidarse de mantener dicha implementación cada vez que se agrege una nueva variable de instancia. ¡Impensable!
Lógicamente el problema se debía a que había objetos que quedaban referenciados durante la ejecución de los tests y esto hacía que creciera tanto el consumo de memoria. ¿Qué objetos prodrían ser?. Al principio pensamos que serían los test resource, pero rápidamente nos dimos cuenta que no.
Luego de investigar un poco más me dí cuenta que dichos objetos eran en realidad los mismos test que se ejecutaban y al poseer estos variables de instancias (que en algunos casos referenciaban a instancias completas del sistema) el consumo de memoria crecía de acuerdo a la ejecución de los mismos. Los test son referenciados desde varios lugares, entre ellos el TestResult que posee el resultado de la ejecución de los test y el TestSuite en caso de utilizarse uno.
La solución consistía entonces en lograr que estos objetos no queden referenciados. Lo primero que intenté fue hacer que no queden referenciados desde el TestResult pero el comportamiento de las herramientas de ejecución como el SUnitRunner o el SUnitBrowser no se comportaban bien ante este cambio. Peor aún, no podía lograr fácilmente hacer que el TestSuite dejase de referenciar a los test. Para hacerlo tenía que modificar bastante SUnit, algo que no me atraía demasiado.
Lo que se me ocurrió hacer fue que luego de terminar la ejecución del test y hacer el #tearDown, se pongan todas las variables de instancia con "nil". Hacer esto fue inmediato gracias al metamodelo y la capacidad reflexiba de Smalltalk, simplemente implemente el mensaje #cleanUpIntanceVariables de la siguiente manera:
TestCase>>cleanUpInstanceVariables
(TestCase allInstVarNames size + 1) to: self class allInstVarNames size do: [ :index | self instVarAt: index put: nil ]
Y luego modifique #runCase así:
TestCase>>runCase
[self setUp.
self performTest] sunitEnsure: [self tearDown;cleanUpInstanceVariables]
Con este simple cambio logré que no se consumiera más memoria, durante la ejecución de los 15.540 test la memoria en uso del proceso no aumenta y la mayor sorpresa fue ver que la ejecución de los test bajó en un 50%!! Si, ahora los test corren en la mitad de tiempo de lo que lo hacían antes puesto que Smalltalk no tiene que estar realizando una recolección de basura constantemente, con el scavenging alcanza.
En fin, un buen ejemplo de como un buen metamodelo puede ayudar a resolver problemas que, de no poseerlo, hubiese sido muy costoso hacerlo. Por ejemplo, otra solución sería obligar a cada test a implementar el mensaje #cleanUpInstanceVariables. En nuestro caso hubiese sido necesario implementar este mensaje 2530 veces puesto que esa es la cantidad de subclasses que posee TestCase, teniendo en cuenta que cada una de estas implementaciones deberían modificar a mano las variables de instancia para que referencien a "nil" y luego no olvidarse de mantener dicha implementación cada vez que se agrege una nueva variable de instancia. ¡Impensable!
El código de Arquímedes
Estoy leyendo "El código de Arquímedes" que trata sobre el análisis que se realizó a un palimpsesto que contiene escritos de Arquímedes y los sorprendentes descubrimientos que se hicieron en en este.
Es realmente un libro muy interesante del cual aprendí verías cosas que desconocía, alguna de ellas no muy importantes y otras muy interesantes, cómo:
1) Lo griegos escribían en mayúsculas y sin espacio entre las palabras hasta cerca del nacimiento de Cristo
2) En la matemática que hacían los griegos no existían las ecuaciones. Todas las demostraciones se hacían por medio de gráficos, de dibujos. Las ecuaciones recién surgen en la matemática a partir de la edad media, cuando los escribas empezaron a abreviar las palabras al copiar los libros
3) Los dibujos que usaban los griegos para sus demostraciones no eran exactos. Por ejemplo, si decían que una linea cortaba a otra por la mitad, en el gráfico dicha linea no cortaría por la mitad a la otra. El motivo por el cual no usaban gráficos representativos era para no llegar a conclusiones erróneas puesto que un gráfico muestra una situación concreta y abstracta como el caso de las ecuaciones. Hacer el gráfico de manera incorrecta los obligaba a no utilizar el gráfico para sacar conclusiones sino que tenían que seguir utilizando el pensamiento abstracto para ello.
4) Arquímedes pasaba de la matemática a la física y de esta última a la primera para realizar sus demostraciones. O sea, sacaba conclusiones abstracta en base a comportamientos concretos de la física. Un ejemplo de esto es la demostración que utiliza para demostrar cual es el centro de gravedad de un triángulo, para el cual utiliza una balanza imaginaria para dejar en equilibrio un triángulo y una línea! y a partir de ello concluir su ubicación (muy raro si nos ponemos a pensar que en realidad un triángulo es bidimensional, una linea es unidimensional y ninguno de ellos tiene elementos concretos en la física de nuestra realidad que es tridimensional)
5) Arquímedes no solo manejaba el infinito potencial sino que también llegó a trabajar con la idea de infinito actual, que recién habían empezado a formalizar Newton y Galileo. Arquímedes en su carta a Eratostenes, denominada "El método", cuyo único ejemplar se encuentra en el "palimpsesto" del cual trata este libro, demuestra que dos conjuntos infinitos tienen la misma dimensión creando una relación uno-a-uno entre los elementos de ambos conjuntos, metodología que recién sería utilizada en el siglo XIX para terminar de definir el comportamiento del infinito y por la cual Cantor demuestra la existencia de distintos infinitos (motivo por el cual el resto de los matemáticos contemporáneos lo vuelve literalmente loco)
Un libro muy interesante, aunque la traducción al castellano no es muy buena.
Es realmente un libro muy interesante del cual aprendí verías cosas que desconocía, alguna de ellas no muy importantes y otras muy interesantes, cómo:
1) Lo griegos escribían en mayúsculas y sin espacio entre las palabras hasta cerca del nacimiento de Cristo
2) En la matemática que hacían los griegos no existían las ecuaciones. Todas las demostraciones se hacían por medio de gráficos, de dibujos. Las ecuaciones recién surgen en la matemática a partir de la edad media, cuando los escribas empezaron a abreviar las palabras al copiar los libros
3) Los dibujos que usaban los griegos para sus demostraciones no eran exactos. Por ejemplo, si decían que una linea cortaba a otra por la mitad, en el gráfico dicha linea no cortaría por la mitad a la otra. El motivo por el cual no usaban gráficos representativos era para no llegar a conclusiones erróneas puesto que un gráfico muestra una situación concreta y abstracta como el caso de las ecuaciones. Hacer el gráfico de manera incorrecta los obligaba a no utilizar el gráfico para sacar conclusiones sino que tenían que seguir utilizando el pensamiento abstracto para ello.
4) Arquímedes pasaba de la matemática a la física y de esta última a la primera para realizar sus demostraciones. O sea, sacaba conclusiones abstracta en base a comportamientos concretos de la física. Un ejemplo de esto es la demostración que utiliza para demostrar cual es el centro de gravedad de un triángulo, para el cual utiliza una balanza imaginaria para dejar en equilibrio un triángulo y una línea! y a partir de ello concluir su ubicación (muy raro si nos ponemos a pensar que en realidad un triángulo es bidimensional, una linea es unidimensional y ninguno de ellos tiene elementos concretos en la física de nuestra realidad que es tridimensional)
5) Arquímedes no solo manejaba el infinito potencial sino que también llegó a trabajar con la idea de infinito actual, que recién habían empezado a formalizar Newton y Galileo. Arquímedes en su carta a Eratostenes, denominada "El método", cuyo único ejemplar se encuentra en el "palimpsesto" del cual trata este libro, demuestra que dos conjuntos infinitos tienen la misma dimensión creando una relación uno-a-uno entre los elementos de ambos conjuntos, metodología que recién sería utilizada en el siglo XIX para terminar de definir el comportamiento del infinito y por la cual Cantor demuestra la existencia de distintos infinitos (motivo por el cual el resto de los matemáticos contemporáneos lo vuelve literalmente loco)
Un libro muy interesante, aunque la traducción al castellano no es muy buena.
Suscribirse a:
Entradas (Atom)