Programación

En el artículo Large-Scale Parallel Statistical Forecasting Computations in R encontrarán los interesados información sobre cómo está usando Google R para realizar predicciones de series temporales a gran escala usando cálculos en paralelo.

El artículo tiene dos partes diferenciadas. Por un lado está la que describe los métodos que usan para realizar predicciones sobre series temporales. Parecen sentir cierto desdén por la teoría clásica, comprensible dado el gran número de series temporales que tratan de predecir y el mimo —entiéndase como uso de materia gris— que exige aquella. Prefieren un proceso en el que el coste sea esencialmente computacional: construir predicciones usando gran número de modelos distintos y promediándolos después para obtener resultados que, aunque lejos del óptimo para cada caso particular, resultan adecuados para su fin.

El algoritmo PSLQ se usa para resolver aproximadamente ecuaciones con coeficientes enteros $latex a_i$ de la forma

$$ \sum_i a_i x_i = 0$$

donde, obviamente, no todos los $latex a_i$ son cero. Aproximadamente significa que la solución se busca dentro de un cierto nivel de tolerancia.

No existe, que yo sepa, una implementación en R. Pero sí en Python, usando librerías que permiten utilizar números de precisión arbitraria, como [mpmath](https://code.google.com/p/mpmath/). Veamos un ejemplo:

Permítanme mis lectores matar dos pájaros con una misma entrada. La primera es anunciar que se está organizando una conferencia sobre Grandes Datos en Madrid este invierno. Tendrá lugar los días 14, 15 y 16 de noviembre. Los organizadores la anuncian así:

Un grupo informal de universidades, grupos de desarrolladores y empresas tienen el honor de organizar un congreso sobre Grandes Datos en Madrid, España. El congreso introducirá formalmente la disciplina de los Grandes Datos en España a través de una completa revisión de todas las áreas que incluye, desde la minería de datos y su limpieza hasta el análisis, la modelación y la distribución.

Sin darnos cuenta, abusamos de ciertos términos. Uno de ellos es el de la varianza explicada. Después de años utilizándolo como por inercia, he venido a darme cuenta por dos vías distintas de su impropiedad: una de mis recientes lecturas y una experiencia profesional.

Tal vez sea más sencillo comenzar exponiendo la crítica realizada en esa página. Parte del análisis de la serie de muertes en Chicago entre 1987 y el 2000:

A las entradas que he hecho sobre Julia estos últimos días, quiero añadir esta en la que publico mi primer programa en dicho lenguaje.

Me ha dado por reimplementar el programa para realizar un muestreo de Gibbs que aparece en Gibbs sampler in various languages.

Lo primero ha sido instalar Julia, para lo que basta con seguir las instrucciones que aparecen en su página de github. Y aviso: tarda bastante en descargar y compilar todas sus dependencias.

Unos días después de la primera noticia acerca de Julia en esta bitácora me llegan, como suele ser habitual en estos casos, otras.

En primer lugar, hay una discusión interesante sobre R en la lista de desarrolladores de Julia. Y hay un vídeo de Jeff Bezanson sobre Julia de un seminario en Stanford que podría estar pronto disponible en el canal de Youtube de dicha universidad (y que, de momento, puede verse yendo a la bitácora de Julia y después, navegando a Stanford Talk Video y available here).

Yo creo que es un bug, vamos. Y tengo tres motivos para creerlo:

1. Teradata no hace lo que se espera que haga.
2. No he encontrado por ahí motivo técnico alguno que proscriba razonadamente lo que intento hacer.
3. He hablado con un señor empleado de Teradata, le he enviado el ejemplo y en lugar de explicarme mi error (de haberlo) ha hecho el avestruz (ya hablé de lo que pasa cuando uno encuentra _bugs _en software propietario).

He aquí cómo reproducir el bug. Primero creo una tabla muy simple e inserto una única fila en ella.

Hace no mucho escribí una entrada en este blog sobre, bromas aparte, cómo no escribir código SAS. Habría respondido in situ a uno de los comentarios que hicieron mis lectores pero, abusando de mi condición de dueño del blog, lo voy a hacer desde más encumbrado púlpito: una entrada ad hoc. Conste que escribo para discrepar. Pero conste también que lo hago desde la más genuina cordialidad y con la esperanza de generar un debate que a todos nos enriquezca.

Y, para el caso, Postgres y OpenOffice.

Pues en que quienes los diseñan piensan que los usuarios finales son, somos, abuelitas. Y por tanto, toman decisiones por nosotros (usar mayúsculas donde no se debe, cruzar tablas como les da la gana, empeñarse en que incoar se escribe con hache intercalada, etc.). En particular, mi queja de hoy se refiere a lo estúpidos que pueden llegar a ser los presuntos optimizadores de consultas en bases de datos y en un pequeño —aunque universal— método para doblegarlos a nuestra voluntad soberana.

Yo siempre he creído que eso de los portátiles tiene algo de fálico. Ya no gastamos puñal ni espada. Ni escribimos con tachuelas Biba mi dueño en el mango de navajas de valleinclanianas. Pero salimos a la calle con portátiles y los celamos (yo, al menos) como antaño se guardaban de la sucia mano ajena los afilados depositarios de la virilidad carpetovetónica.

He comprado un portátil nuevo y, llevado de fálico exhibicionismo, he decidido que amerita una entrada en la que proclamar que el mío es más pequeño que el de casi todos mis lectores.

No es éste foro para opinar sobre si nos interesa la Madre Teresa o si los patriotas son idiotas, pero sí para mostrar nuestro desacuerdo con la canción (por abreviar, acá está su letra) y dejar claro que las jerarquías no son una porquería. Si no que se lo digan a un indirecto cliente mío que consume lo que no nos devuelve a los accionistas como dividendo en pagar hordas de consultores poco avisados de lo que acá cuento. Y lo cuento y dejo públicamente escrito para que tengan todavía menos excusa.