Accion farmacologica

"el pantopazol inhibe selectivamente la bomba de protones localizada en la membrana apical de las celulas parietales de la mucosa gastrica. Este bloqueo irreversible provoca una inhibicion mas pronunciada de la secrecion acida en comparacion con los antagonistas de los receptores histaminergicos H2.
En el interior de la celula parietal el pantoprazol alcanza su forma activa, una sulfenamida ciclica cationica, que luego se une a los residuos de cisteina de la bomba protonica, inhibiendo asi la accion de la misma"
y esto se puede conseguir en cualquier farmacia...

finance google no funciona tan bien

disclaimer: Este no es un post computronico

Y eso me pone contento :)

Le estaba mostrando a un amigo (juan pablo) finance.google.com, y el descubrio un pequeño bug.

Por curiosidad, quizimos ver como andaba tenaris ( http://finance.google.com/finance?q=NYSE%3ATS ), y al ver el Market Cap, me dijo: "che, eso no esta bien. el numero es 111.56B, pero esta mal", de hecho, en http://finance.yahoo.com/q?s=ts, el Market Cap era 22.31B, es decir, una pequeña diferencia de 89.25B, casi nada, digamos :)

El me dijo que no estaban teniendo e cuena que tenaris era un ADR, pero no pude encontrar otro titulo donde el error sea tan grosero.

Realmente me alegra que a la gente de google no le salgan siempre tan perfecto las cosas (si, es envidia :) )

Por si no se entiende, donde dice B se lee Billions, que es mil millon dollars (mucha mucha plata)

kmeans y c++ template metaprogramming

Estoy haciendo una implementacion de kmeans tratando de hacer la maxima cantidad de cosas posibles con templates metaprogramming, para transferir en el codigo el conocimiento que ya tengo en tiempo de compilacion.
Me aparecio este petit problema (gracias g++, sos lindo... por suerte ya lo resolvi):
iChing:~/.../code/kmeans jb$ make maing++ main.cpp -o maini686-apple-darwin8-g++-4.0.1: Internal error: Illegal instruction(program cc1plus)Please submit a full bug report.See <URL:http://developer.apple.com/bugreporter> for instructions.make: *** [main] Error 1

Information Entropy y k-means

Hace un par de semanas me encontre con la medida de la entropia de Shannon. Es simplemente esta formula:

I = -∑p_i*ln₂(p_i) donde p_i = N_i / N

N es la cantidad de elementos en todo el conjunto, y N_i es la cantidad de elementos en cada uno de los k i-subconjuntos

Parece una formula simple, pero en realidad, simplemente mirandola, no podia entender su significado.

En principio parece una esperanza, en particular, la -E(ln₂p_i), esto seria algo asi como la cantidad de bits necesarios para representar, en promedio, los elementos existentes en cada uno de los i grupos.

Pero seguia sin decirme demasiado, asi que gracias a la ayuda de Manuk, empezamos a destripar esta formula.

Partimos de:

I = -∑p_i*ln₂(p_i) 

= -∑p_i*ln₂(N_i/N)

= -∑p_i*[ln₂(N_i) - ln₂(N)]

= ∑p_iln₂(N) - ∑p_iln₂(N_i)

como ln₂(N) no depende de i, es una constante, y puede ser extraido de la suma.

= ln₂(N)*∑p_i - ∑p_i*ln₂(N_i)

como ∑p_i = 1, y el segundo termino es una esperanza, nos queda:

=ln₂(N) - E(ln₂(N_i))

El primer termino es constante, siemre que se mantengan constantes las cantidades de elementos del conjunto, entonces, si queremos maximizar o minimizar la entropia, tenemos que modificar el segundo termino (la distribucion de los elementos dentro de los conjuntos).

De hecho, la entropia va a ser maxima cuando cada conjunto tenga exactamente la misma cantidad de elementos. Es decir, cuando los N elementos esten distribuidos entre los k conjuntos. 

Cuando eso ocurra vamos a tener que N_i = N / k

Entonces,

I = ln₂(N) - ∑N/k*ln₂(N / k))

= ln₂(N) - ∑N/k*[ln₂(N) - ln₂ (k))]

= ln₂(N) - [ln₂(N) - ln₂ (k))]

= ln₂(N) - ln₂(N) + ln₂ (k))

=ln₂(k)

es decir, a la cantidad de bits necesarios para representar a todos los conjuntos

Todo esto con respecto a la entropia, ahora vayamos a k-means.

k-means , es un algoritmo para agrupar un conjunto de datos en k subconjuntos, minimizando alguna distancia (en general, la distancia euclidea).

la funcion a minimizar es la siguiente

V = ∑_i∑_jdist(x_ij;c_i)

donde c_i es el centro del subconjunto.

Si utilizamos el error cuadratico medio, lo que vamos a estar minimizando es esperanza de la varianza intragrupos (es decir, dentro de los grupos)

Esto de encontrar grupos que tengan algun sentido (minimizen alguna distancia), parecia que tenia bastante que ver con la teoria de la informacion, asi que empezamos a pensar un poco al respecto (aca vortex y tenuki me ayudaron un poco).

Como la funcion distancia, puede ser cualquier funcion distancia, que cumpla con las condiciones de una funcion distancia, utilize la distancia discreta multiplicada por ln(N_i)

dist(x_ij;c_i) = 0 sii x_ij = c_i

dist(x_ij;c_i) = ln₂(N_i) sii x_ij != c_i

como ninguno de los N_i elementos es c_i,  (si alguno fuese, multiplicamos y dividimos la distancia por algun valor, y el problema se resuelve), entonces,

∑dist(x_ij;c_i) = N_i*ln(N_i)

reemplazando en V, tenemos

V = ∑_iN_i*ln(N_i)

dividiendo m. a m. por N, tenemos

V / N =∑_iN_i*ln(N_i)/N

como N_i = p_i, entonces

V / N =∑_ip_i*ln(N_i)

V / N = E(ln(N_i)

Que es el segundo termino de la medida de la entropia.

Por lo tanto, en el espacio metrico definido por esta funcion distancia, es equivalente minimizar la distancia, a maximizar la informacion (No hay que olvidarse que en la formula de la informacion, el segundo termino aparece restando). Y es ahi donde las dos cosas tienen algo que ver.

Pero sin embargo, este resultado no me dejo completamente contento.

Por un lado, no refleja lo que yo queria (que era mostrar la cantidad de informacion que se concentra en los c_i; de hecho, estos ni siquiera se utilizan).

Ademas, quise utilizar otra funcion de distancia, como por ejemplo, la distancia de Hamming, pero no pude obtener el resultado que queria.

Espero que a alguien que lea este post se el ocurra alguna funcion distancia mas entretenida

saludos

/jb

ps: Tambien tengo que agradecer a tomas, que desde el mas alla (mas alla del meridiano de greenwich), siempre me da una mano con estas cosas

Acoplamiento y No Convexidad

Disclaimer:

• Este articulo tenia ganas de escribirlo hace un tiempo, pero habia un par de cosas que no me cerraban del todo, y queria esperar a que tenga el concepto cerradito y monono. Eso no paso, pero lo que si paso fue que me canse.
  
• Este es un articulo computronico

Lo que queria hacer era relacionar funciones, metodos, clases,  y namespaces con conjuntos.

Supongamos que tenemos una clase que sea una estacion climatica. Esta estacion climatica tiene sensores, como por ejemplo, termometros. 

Nosotros somos consumidores exernos de informacion, y solamente nos interesa lo

 que la estacion climatica nos puede ofrecer.

La imagen anterior vendria a ser una representacion de nuestro mundo.

A travez de los metodos, se producen relaciones entre los objetos.

Por ejemplo, si el consumidor externo quiere saber la temperatura, le pregunta a la estacion climatica la temperatura, se produce una relacion entre el consumidor y la estacion climatica.

Como la clase que define el consumidor tiene como variable de instancia una estacion climatica, la relacion ya esta establecida en la propia clase, por lo tanto, la relacion que genera el metodo es una relacion que va de la clase a la clase. 

A pesar de que por claridad yo dibuje las flechitas como saliendo de las clases, cuando estos nos encontramos con estos metodos, en realidad lo que ocurre es que todas las relaciones se producen dentro del conjunto que define la clase. Lo que se parece bastante al concepto de convexidad.

Por otro lado, puede ocurrir que el consumidor externo, en vez de preguntarle a la estacion climatica la temperatura, le pida su sensor de temperatura, y a la vez a este le pida la temperatura actual.

Esto es lo que vemos en este grafico:

En este caso, la relacion que generaria el metodo para obtener la informacion de la temperatura, iria mas alla de lo que define el conjunto de la clase consumidor externo (aunque volveria al consumidor externo, "salio por un rato" para buscar la temperatura).

Si trazacemos las flechas que define las relaciones producidas por este metodo, veriamos que pasa por la clase "sensor de temperatura", el cual no es conocido por el consumidor externo.

En este caso, las relaciones son relaciones no convexas, y por otro lado, este es un buen ejemplo de alto acoplamiento entre clases.

En que sentido esto no esta piola? 

Bueno, si por ejemplo cambiamos el sensor de temperatura por uno construido en el imperio, con las temperaturas medidas en grados farengein, en vez de en grados celcios, tendriamos un gran problema, ya que el consumidor externo no sabria nada sobre eso (problema que seguro estaria resuelto por la estacion climatica).

Por otro lado, hay algo interesante. A pesar de que estas tres clase estan acopladas entre si, las relaciones que producen sus metodos se mantienen dentro del conjunto definido por esas tres clases.

Si quisieramos definir un namespace que englobe esas tres clases, podriamos hacerlo, y tendriamos las caracteristicas de convexidad para ese namespace. 

Por lo que estariamos encapsulando este micromundo en ese namespace. Y maravillosamente, el minimo conjunto convexo que contiene a una serie de puntos se llama capsula convexa (o clausura convexa), por lo que el nombre de encapsulamiento parece tener aun mas sentido :)

Bueno, espero que a alguien le guste este post, a mi realmente no me gusta, pero ya no queria pensar mas en esto, y esta es la mejor manera de sacar un tema de la cabeza :)

saludos

/jb 

Feedback Positivo y crisis financieras

Ultimamente estuve pensando bastante sobre retroalimentacion positiva y negativa. Los sistemas con retroalimentacion negativa (autoregulados), son particularmente interesantes, y por el otro lado los sistemas con retroalimentacion positiva son los que se ven generalmente en los modelos caoticos y con soluciones fuera del equilibrio. (se van se van se van...)

Con respecto a los modelos financerios, estuve pensando un poco en esto:
Muchos operadores financieros utilizan modelos que suponen eficiencia de los mercardos, para la toma de deciciones.
Supongamos que el mercado es levemente no eficiente, es decir, algunas de las condiciones de eficiencia no se esta cumpliendo (esto es mas facil que suponer que el mercado es eficiente ;) ).
Entonces, los modelos, aplicados sobre este tipo de mercados, van a ser una aproximacion (quizas muy buena, es verdad), pero solo una aproximacion a la realidad.
Como estos modelos son una aproximacion, pueden producir una solucion que no sea la optima. Esto implicaria que haya agentes que esten tomando deciciones suboptimas, y creando ineficiencias en el mercado.
Ahora, estas ineficiencias, se agregan a las que ya existian, generando un sistema aun mas ineficiente, y la solucion de los modelos seria aun mas equivocada, y el sistema se retroalimentaria, divergiendo completamente, hasta llegar a una crisis, u otra solucion de equilibrio (Hysteresis). En esta crisis, los modelos se re ajustan, y tomo comienza de cero...
Ahora, a pregunta es, por que no es que todo el tiempo no estamos llendo vertiginosamente hacia una crisis?
Bueno, creo que parte de las respuestas bienen por varios lados:
a) Puede ser que las ineficiencias del mercado produscan deciciones equivocadas en los modelos, pero la direccion del error puede ser contraria a los errores anteriores, y neutralizar el efecto divergente
b) Animal spirits: Hay agentes que "no utilizan modelos", salvo el de "obtener el mayor resultado". Al no hacer "asumpciones formals" sobre el comportamiento del mercado, aprobechan las deciciones suboptimas de los agentes mas "racionales", y neutralizan esas deciciones
c) Distintos modelos internos producen respuestas contrarias, donde las fuerzas de esas respuestas se neutralizan, y se mantiene un equilibro.

Bueno, ahora, con la existencia de a, b, y c, pasamos de un modelo de crisis permanente, a un modelo de no crisis (que tampoco es cierto). La pregunta es, por que la realidad es algo intermedia?
Bueno, creo que a, b, y c explican un poco el modelo gaussiano-browniano.
El modelo gaussiano, supone, que si hay una cantidad suficientemente grande de errores, todos independientes, y con la misma distribucion (y si, variancia finita), vamos a estar en presencia de una variable distribuida Normalmente (de aca surgen los teoremas centrales en el limite)
El modelo browniano tiene como finalidad, representar el movimiento de una particula que es afectada por la interecaccion sobre esta particula, de una cantidad suficientemente grande (si es infinita, mejor), de particulas aleatorias (tambien, independientes, identicamente distribuidas). El ejemplo tipico, es una pelota, y un monton de focas pegandole a la pelota.. :P (bueno, si, no era el tipico).
Este modelo, parece que cierra bastante con la idea del mercado, donde hay miles de agentes empujando cada uno para un lado particular, y donde cada uno de estos agentes son "independientes", pero (y aca hay un gran pero).
Como vimos, la divergencia producida por los errores de los modelos estan neutralizadas, salvo que aparesca la sincronizacion. Cuando la masa de agentes se sincronizan (por ejemplo, por que todos usan modelos que ante un estimulo en particular, responden en la misma direccion -y ademas, es una decicion suboptima-), la fuerza que pueden hacer el resto de los agentes no llega a neutralizarla, y permite que el sistema salga del equilibrio. Una vez fuera del equilibrio, mas modelos van a ser parte de la sincronizacion (ya no necesitan el estimulo comun, ya que van a responder de forma erronea por la situacion de no equilibrio del mercado). Esto produce el famoso efecto bola de nieve (que lindo ejemplo de retroalimentacion positiva), desencadenando una crisis. Lo interesante, es que por esta sincronizacion, se rompe la idea de modelo browniano, y de normalidad. Ya que ocurren eventos que tendrian una probabilidad de ocurrencia casi nula segun esos supuestos. Es por eso que se utilizan los modelos de colas pesadas (donde los eventos raros, en realidad no son tan raros como parecen)

Bueno, creo que este post me termina de cerrar un par de cavos sueltos
pongo un par de links para expandir el post (si, me dio paja poner href):
http://en.wikipedia.org/wiki/Positive_feedback
http://en.wikipedia.org/wiki/Negative_feedback
http://en.wikipedia.org/wiki/Brownian_motion
http://en.wikipedia.org/wiki/Carl_Friedrich_Gauss (que grande este tipo :) )
http://en.wikipedia.org/wiki/Synchronization_of_chaos

saludos
/jb

Jerarquias (Object Based)

Disclaimer:

Este post es (particularmente) computronico, si quieren no lo lean :)

Historia previa:

El otro dia (asi empiezan todas las historias), con mat y despues con tenuki estabamos pensando sobre el concepto de classe en la programacion basada en objetos. No se si ellos estaban de acuerdo con lo que voy a escribir, pero ayudaron mucho a que estas cosas se organizen asi en mi cabeza :P.

Idea:

Basicamente, pensamos que existen dos tipos distintos de penzar el concepto de clase cuando se programa pensando en objetos.
La primer forma de penzar las clases (y la jerarquia de clases) es desde un punto de vista conceptual. Una clase representa un concepto, y sus subclases representan particularidades de este concepto (la idea de especie y subespecies). Este es un approach Top-Down, ya que primero hacemos el circulo grande donde definimos a la clase, y adentro de este circulo grande hacemos los circulos pequeños que definen a las subespecies. El consumidor de este concepto es un consumidor externo al objeto que es de la clase (o subclase).
Ejemplo: a un mamifero le podemos preguntar la cantidad de tetas que tiene. Eso lo podemos hacer, por que independientemente del mamifero que sea, el concepto de mamifero implica tener tetas.
Como el consumidor es externo, y el concepto es un concepto que se presenta al mundo, tiene sentido que los metodos (los mensajes) de las instancias de esta clase sean publicos, ya que esperamos que desde afuera se utilize este objeto a travez de la representacion conceptual que esta jerarquia esta ofreciendo. Mas aun, desde este punto de vista, tiene todo el sentido del mundo el concepto de classes abstractas (pure concept), y estas clases definen una interface para ofrecer al mundo, pero los elementos que estan en niveles mas particulares (inferiores ?) de la jerarquia tienen que definir como es el comportamiento puntual. Volviendo al ejemplo, sabemos que los mamiferos tienen tetas, pero dependiendo de cada especie la cantidad de tetas que (mas o menos) tienen.
Una de las principales ventajas que tiene esta forma de pensar las clases es la facilidad del uso, yo no necesito saber de que subespecie es tal objeto en particular, ya que puedo utilizar los conceptos que me brinda la especie. Ademas, permite programar comportamiento utilizando metaforas, que es una forma comoda para nuestro cerebro de manejar unos y ceros de forma compleja.


Por otro lado, existe otra forma de pensar el concepto de clases, que es desde un punto de vista mas matematico o funcional. Tenemos un par de objetos (que corresponden a clases distintas), y podemos pensar que puede existir alguna relacion entre estas clases cuando comparten algun tipo de comportamiento. Entonces vamos a agrupar a estas clases en una clase que va a ser "comparten tal comportamiento". Aca el approach es Bottom-Up, ya que primero tenemos los circulitos chiquitos con las clases particulares, y despues armamos un circulo mas grande en donde las agrupamos gracias a este comportamiento compartido. Los usuarios de esta jerarquia son las mismas subclasses, cuando se pretende reusar comportamiento, y agruparlo en un mismo lugar. Me parece que desde este punto de vista, tiene todo el sentido del mundo la existencia de mensajes o herencia "protected", ya que esta jerarquia no ayuda a trabajar con las clases a los consumidores externos, pero permite la reutilizacion de codigo.
Para que este tipo de jerarquia funcione bien, creo que los metodos que se comparten deberian ser metodos donde existe pure behaviour, que esta mas relacionado con el paradigma funcional que con el de Basado en Objetos.
Una de las desventajas de esta forma de ver las clases (me parece), es poder identificar una forma univoca de crear las superclases (un nombre), pero quizas si se pienza como el comportamiento compartido, y no como un concepto compartido, sea mas facil de encontrarlo (al nombre).

Hace un tiempo tenuki me paso un paper sobre la implementacion de traits en smalltalk, y encontre este link: http://www.iam.unibe.ch/~scg/Research/Traits/ Creo que esto tiene mucho que ver con la segunda forma de ver a las clases.
En particular, creo que la implementacion de traits en smalltalk, puede producir un cambio en la dimension del paradigma. Si pensamos a los paradigmas como un especio, smalltalk esta claramente sobre la recta de Object Based. El poder generar una jerarquia de clases en base a comportamiento compartido desplaza un poco el lenguaje sobre el espacio Object Based-funncional.
Bueno, espero opiniones, por que esto me interesa :) (y ademas espero que no haya sido un lio)

saludos
/jb