Stan

1. Ahora se pueden correr Stan en el navegador (vía WebAssembly) aquí.
2. En este artículo relacionado se preguntan sobre la problemática relación entre MCMC y las GPUs. La respuesta es, esencialmente, que no: el MCMC es iterativo y no se presta al paradigma SIMD (single instruction, multiple data). Los únicos casos en los que he visto alguna ganancia son esos —rarísimos— en los que el modelo involucra algún tipo de red neuronal que sí que puede aprovechar el paralelismo.
3. En este artículo, John D. Cook se suma los críticos del BMI —que no es novedad— y sugiere reemplazarlo —esto sí— por algún tipo de índice de redondez (del cuerpo del sujeto).
4. Un problema de los LEFTs es que la volatilidad diaria socava gravemente su rentabilidad. Para evitar ese problema, se han lanzado LEFTs que cierran semanal o mensualmente.
5. Una recomendación habitual es evitar la sobreprecisión en los números publicados (p.e., $p = 0.0421942). Sin embargo, en Please, show lots of digits argumenta en contra: esos números no redondeados aportan información adicional que puede permitir realizar ingeniería inversa y revelar cifras y procedimientos no explícitamente mostrados en los artículos.

1. Últimamente, casi siempre que se usan las palabras tecnología y enseñanza en una misma frase es para denunciar los perniciosos efectos de la primera en la segunda. No obstante, aquí_ se señala una de sus potenciales atractivos: adecuadamente usada, podría permitir gestionar la varianza (por no usar el término tabú, desigualdad), en el desempeño escolar.
2. En Stan’s autodiff is 4x faster than JAX on CPU but 5x slower on GPU (in one eval) se ponen en cuestión “leyes de la naturaleza/informática” que no son otra cosa que generalizaciones. Va por casos. Doy fe.
3. Uno de los problemas de las licencias de abiertas es que, por diseño, olvidan una dimensión muy importante del desarrollo de código: hay gente que vive de eso (véase, por ejemplo, Free as in Do as Your Told). Un nuevo tipo de licencia, la fair source, quiere remediar el problema. En resumen, es un tipo de licencia privativa que deviene automáticamente abierta al cabo de un tiempo razonable.
4. Otro de los problemas que ocurren (a veces) al desarrollar software libre: que tus dependencias pueden quedar huérfanas, como aquí
5. Xata ofrece alojamiento para instancias de Postgres que cuenta con un segmento gratuito (free tier). Aquí describen la solución tecnológica y el impacto económico de ese servicio (en concreto, de cómo usan lo uno para minimizar lo otro).

El otro día publiqué un minihilo en Twitter que terminaba con una encuesta. Proponía el siguiente problema:

1. Quiero, abusando del lenguaje, estimar el efecto de $x$ sobre $y$ usando el modelo lineal clásico $y = a_0 + a_1 x + \epsilon_1$.
2. Pero no puedo medir $x$ con precisión. Solo tengo una medida ruidosa/aproximada de $x$, $z = x + \eta$, donde $\eta$ es normal, independiente de $\epsilon_1$, etc.
3. Uso el modelo $y = b_0 + b_1 z + \epsilon_2$.

La pregunta que planteé consistía en elegir entre las siguientes tres opciones:

He subido un nuevo vídeo a mi canal,

Es una charla de casi una hora con José Luis Cañadas. Comienza con Stan y luego deriva hacia otros temas de interés estadístico. Como digo en el resumen del vídeo, solo los últimos 3-4 minutos son prescindibles.

Me he entretenido estos días en crear un modelo que represente la siguiente hipótesis de trabajo:

Los encuestadores electorales combinan tres fuentes de información: sus propios datos, el consenso de los restantes encuestadores y la voz de su amo, es decir, el interés de quien paga la encuesta.

Es un modelo en el que se introduce (y se mide) el sesgo que introduce cada casa en los resultados. De momento (¡no fiarse!, léase lo que viene después) he obtenido cosas como estas (para el PP):

[El título de esta entrada tiene un + delante porque ya escribí sobre el asunto tiempo atrás.]

Con la excusa de la reciente publicación del paquete ivreg (para el ajuste de modelos con variables instrumentales, por si el contexto no lo hace evidente), he mirado a ver quién estaba construyendo y ajustando modelos generativos menos triviales que los míos (véase el enlace anterior) para que quede más claro de qué va la cosa. Porque la explicación típica, que adopta formas no muy distintas de

Una de los proyectos en los que estoy trabajando últimamente está relacionado con un problema de optimización no lineal: tengo un modelo (o una familia de modelos) no lineales con una serie de parámetros, unos datos y se trata de lo que no mercería más explicación: encontrar los que minimizan cierta función de error.

Tengo implementadas dos vías:

• La nls, que usa un optimizador numérico genérico para encontrar esos mínimos. (Nótese que uso nls y no nls porque esa función me queda muy corta).
• La stan, donde especifico el modelo, introduzco una serie de prioris más o menos informativas según lo que sepa de mi problema y estimo la distribución a posteriori de mis parámetros.

Ambas tienen sus ventajas y desventajas. La una es rápida y la otra no; la una me da poca información sobre los parámetros y la otra, mucha; una me permite introducir mucha información a priori y la otra casi nada, etc.

El modelo SIR es deductivo: dados una serie de parámetros, plantea una ecuación diferencial cuya solución es perfectamente limpia y determinista, tal como gusta a matemáticos y físicos:

Pero, ¿quién y cómo le pone al gato el cascabel de determinar los parámetros más adecuados para el modelo? Los parámetros son inciertos, ruidosos y producto de los datos que el modelo mismo quiere representar. Lo suyo sería enlazar la ecuación diferencial

[Nota: el código relevante sigue estando en GitHub. No es EL código sino UN código que sugiere todos los cambios que se te puedan ocurrir. Entre otras cosas, ilustra cómo de dependientes son los resultados de la formulación del modelo, cosa muchas veces obviada.]

Continúo con la entrada de ayer, que contenía más errores que información útil respecto a objetivos y métodos.

Los objetivos del análisis son los de obtener una estimación del número de casos activos de coronavirus en la provincia de Madrid. La de los casos oficiales tiene muchos sesgos por culpa de los distintos criterios seguidos para determinarlos a lo largo del tiempo. Sin embargo, es posible que los fallecimientos debidos al coronavirus, antes al menos de que se extienda el triaje de guerra, son más fiables. Eso sí, la conexión entre unos (casos) y otros (defunciones) depende de una tasa de letalidad desconocida. El objetivo del modelo es complementar la información de los casos notificados con la de defunciones.

[Nota: si no sabes interpretar las hipótesis embebidas en el código que publico, que operan como enormes caveats, no hagas caso en absoluto a los resultados. He publicado esto para ver si otros que saben más que yo lo pulen y consiguen un modelo más razonable usándolo tal vez, ojalá, como núcleo.]

[Edición: He subido el código a GitHub.]

[El código de esta sección y los resultados contienen errores de bulto; consúltese el código de GitHub.]

Escribe Gelman en términos irónicocelebratorios:

OK, we can now officially say that Stan, as an open-source software, has recouped its societal investment.

Apostilla Terry (en los comentarios), por si alguien se lo había tomado literalmente:

Came here to say this.

Review saved $20-$50 billion. Stan was involved in the Review. Therefore, Stan saved $20-$50 billion.

AWOOOOOOOGAH!!!

The economic Klaxon is deafening.

Nope, nope, nope, nope.

Porque siempre hay alguien sin sentido del humor.

Porque, aunque la intención sea buena, el DSL (que ni siquiera llega a serlo) es muy, muy feo. Que en este contexto, además, quiere decir antinatural.

La demostración, aquí, aquí o aquí.

Leyendo sobre si dizque PyTorch le siega la hierba debajo de los pies a TensorFlow, averigué la existencia de Pyro.

Pyro se autopresenta como Deep Universal Probabilistic Programming, pero aplicando métodos porfirianos (ya sabéis: género próximo y diferencia específica), es, o pretende ser, Stan en Python y a escala.

Aquí van mis dos primeras impresiones, basadas en una inspección superficial de los tutoriales.

En primer lugar, aunque Pyro permite usar (distintas versiones de) MCMC, parece que su especialidad es la inferencia variacional estocástica. Que parece funcionar de la siguiente manera. En el MCMC tradicional uno obtiene una muestra de la distribución (a posteriori, para los amigos) de los parámetros de interés. Eso es todo: vectores de puntos. En la inferencia variacional estocástica, uno preespecifica la forma paramétrica de la posteriori y el algoritmo calcula sus parámetros a partir de los valores simulados. Por ejemplo, uno va y dice: me da que la distribución del término independiente de mi regresión lineal va a ser normal. Entonces, Pyro responde: si es normal, la mejor media y desviación estándar que encuentro son tal y cual.