Me pasó otra vez...

...Google insiste en confundirme con un bot. No se que es lo que confundirá a sus algoritmos de detección, aunque sospecho de mi tendencia a abrir múltiples pestañas cuando veo una lista de links :-)


Por si fuera poco, el CAPTCHA también me clasificó como "no humano", ya que realmente me resultaba difícil ver que es lo que decía. Tengo la sospecha de que navegar por Internet en el futuro va a ser realmente interesante...

spice3f5 para Visual C++

Acabo de agregar a la página de mi proyecto de Tesis una versión de spice3f5 compilable con Microsoft Visual C++ 2008. Esto permite realizar fácilmente análisis de una netlist cualquiera (aunque no incluye manual de uso :-)

Un problema de probabilidad

En un juego, se presentan a una persona dos sobres. Sabe que uno de ellos contiene una cantidad desconocida de dinero 'A', y que el otro contiene el doble de esa cantidad, pero el jugador desconoce "cuál es cual". Se le dice que puede llevarse solo uno de los sobres y que debe llevarse el último sobre que abra.

La pregunta es: después de haber elegido y abierto un sobre, le conviene cambiarlo por el otro?

La respuesta intuitiva es "no", ya que ver el contenido del sobre no nos permite discriminar entre el caso en que elegimos el sobre con la cantidad A y el caso en que elegimos el sobre con al cantidad 2A. Al no tener evidencia proveniente de ver el contenido del sobre, el intercambio nos sería indiferente.

Ahora supongamos que calculamos el valor esperado del contenido del sobre no abierto, al que denominaremos "sobre 2". Si llamamos B al contenido del sobre abierto, el sobre 2 puede tener contenido B/2 o 2B. Asumiendo la indiferencia mencionada anteriormente, el valor esperado del contenido del sobre 2 sería:

E(contenido sobre 2) = 1/2 B/2 + 1/2 2B = B/4 + B = 5/4 B

Esto implicaría que siempre nos sería conveniente realizar el intercambio!

Más detalles sobre el problema y sus implicaciones en Wikipedia...

Factories en C++

Las implementaciones normales de factories en C++ suelen introducir la necesidad de modificar la clase Factory o su inicialización para cada clase que se agrega. Los intentos de evadir esta centralización utilizando la inicialización estática suelen ser algo como lo que aparece en el ejemplo factory_mal (es claro que hay algo mal :-) .

Este ejemplo utiliza la inicialización de variables globales para realizar el registro de los factory methods. En muchos casos esto parece funcionar, de hecho me acaba de funcionar al probarlo, pero contiene un error grave: asume un orden de inicialización de objetos estáticos entre distintos archivos (bueno, "unidades de traducción").

El problema en que no puede suponerse que los distintos Registrators vayan a inicializarse después que Factory::cm_. Si los Registrators se inicializan primero, Factory::registrate() accederá a un map no inicializado, probablemente llevando a un segmentation fault.

La solución a esto es la misma que la aplicada en el Singleton de Meyers: utilizar una variable estática dentro de un método. De este modo podemos garantizar que el objeto estará inicializado cuando sea utilizado.

Obviamente esta solución no maneja los problemas con múltiples threads, ni arregla mágicamente los problemas de diseño que puedan ser provocados por el uso indebido de singletons, pero soluciona el problema de la inicialización.

Relatividad en 6 minutos

(Vía John Walker)
Sí, un video musical por Max Tegmark! No puedo imaginarme algo así en la FIUBA aunque, en realidad, tampoco lo imaginaba en el MIT :-D



El paper con la letra...

Un robot distinto

BigDog: un robot que parece "útil". Acostumbrado a ver la forma vacilante en que suelen caminar los robots me impresionó mucho la estabilidad y adaptabilidad que despliega BigDog. Tal vez hay razones para el optimismo en la robótica :-)

Muere Arthur Clarke a los 90 años

Probablemente, su idea más conocida es la que apareció en esta tapa de diario, allá por el año 1946 y en una revista en el año 1945 con más detalle. Un anticipo de DirectTV... aunque con tripulaciones yendo a cambiar las válvulas :-)

Probablemente esta mezcla de aciertos y desaciertos sea inherente a tratar de predecir tecnologías futuras; como dice la frase, "es difícil hacer predicciones, sobre todo acerca del futuro". Probablemente allá por el año 2200 se reirán de algunas de las predicciones que se hacen hoy día acerca de la nanotecnología.