Hoy he escrito last.date <- max(Filter(function(x) format(x, "%m") == "03", all.filled.data$Date)) y he echado mucho de menos Scala. Más sobre Scala: Si yo fuera rey, todos los niños aprenderían Scala. Al tipo que inventó Scala le gustan tanto o más los oneliners que a mí. Todavía me llevo mal con el compilador. La gente viene a Suiza y aprende el alemán malhablado de aquí; yo, ya véis, Scala. Soy así de sociable. Detrás de Scala vendrá Spark.

Me gustaría no tener que hacer más t-tests en la vida, pero no va a ser el caso. El problema al que me refiero le surgió a alguien en una galaxia lejana y, de alguna manera, me salpicó y me involucró. Es, simplificándolo mucho, el siguiente. Tiene una muestra $X = x_1, \dots, x_n$ y quiere ver si la media es o no cero. ¿Solución de libro? El t-test. Pero le salen cosas raras e inesperadas. De ahí lo del salpicón. ...

Avisé en mi entrada del otro día: no me preguntéis por qué (imponer restricciones en un problema de mínimos cuadrados). Pero cuanto más pienso sobre ello, menos claro lo tengo. ¿Por qué restricciones? Primero, el contexto. O el casi contexto. Porque no es exactamente así. Pero sí parecido. Supongamos que queremos predecir algo y construimos, p.e., 4 modelos. Se nos ocurre (y hay buenas razones para ello) combinar los predictores. Uno puede pensar en usar la media de las predicciones. O la mediana. O tratar de usar un peso revelado por los datos. ...

Estoy sin tiempo, así que os suelto el código y me largo a casa a no cenar. Es así: library(parallel) cl <- makeCluster(8) # solo si hay aleatorización # clusterSetRNGStream(cl, 123) clusterEvalQ(cl, { # las librerías necesarias tienen que cargarse # en cada esclavo library(rpart) # en la práctica, hay que cargar los datos # (¿desde fichero?) en cada esclavo my.data <- iris # lo mismo con las funciones necesarias foo <- function(x, dat){ train <- 1:nrow(dat) %% 10 != 1 mod <- rpart(Species ~ ., data = dat[train,]) res <- predict(mod, dat[!train,]) } }) res <- parSapply(cl, 0:9, function(x) foo(x, my.data), simplify = F)

Sí, había restricciones. No me preguntéis por qué, pero los coeficientes tenían que ser positivos y sumar uno. Es decir, buscaba la combinación convexa de cuatro vectores que más se aproximase a y en alguna métrica razonable. Y lo resolví así: # prepare constrained optimization y <- dat.clean$actual x <- t(dat.clean[,2:5]) # target function: L2 first, then other metrics L2 <- function(coef){ sum(abs((y - colSums(x * coef)))^1.5) } # restrictions: coefs > 0, sum(coefs) ~ 1 ui <- rbind(diag(4), c(-1,-1,-1,-1), c(1,1,1,1)) ci <- c(0,0,0,0,-1.000001,0.999999) theta <- rep(0.25, 4) best.coef <- constrOptim(theta, L2, grad = NULL, ui = ui, ci = ci) coefs <- best.coef$par Objetos aparte de x e y, hay: ...

A los estadísticos se nos acusa en ocasiones de contestar preguntas tontas en las que nadie está interesado. (Nota: de alguna manera conseguí el artículo al que se refiere el enlace anterior; pero ahora no veo que exista ninguna copia libre por ahí. Si alguien la consigue, por el bien del resto de los lectores, que me avise o que lo haga saber en los comentarios). A lo que iba. Muchos estadísticos tienen el cerebro reprogramado para tratar de no cometer los llamados errores de tipo I y errores de tipo II (y para ello tratan de estimar una cosa de dudosa utilidad, $P(D|H)$, donde $D$ son los datos y $H$ es cierta hipótesis (que, generalmente, a nadie interesa y que es más difícil de plantear correctamente de lo que parecería). ...

Este verano, la Escuela Complutense de Verano ofrece el curso Big & open data: análisis y programación con R. Lo anuncio por aquí por tres motivos: Por su interés intrínseco. Por si alguno de los lectores de estas páginas estuviese interesado. Porque yo participo/participaría en el programa contando cosas de lo más jugosas.

Las bases de datos son instrumentos magníficos con dos defectos fundamentales: es difícil meter datos en ellas y es difícil sacar datos de ellas. Pero guardarlos… los guardan estupendamente. Estos días me ha tocado subir a una base de datos tablas bastante grandes y las herramientas proporcionadas por RJDBC para ello, esencialmente dbWriteTable han fallado. Internet no se pone de acuerdo sobre si es un bug de RJDBC o si la culpa la tiene el driver de la base de datos que estoy obligado a utilizar. Como fuere, me ha tocado descender un escalón de abstracción y jugar directamente con la API del driver para ejecutar prepared statements. ...

Casi siempre que escribo aquí lo hago para contar algo. Creo que por primera vez creo que voy a usar esta plataforma para pedir consejo a mis lectores. El caso es el siguiente. Tengo un conocido —que me ha pedido que no divulgue su nombre— que estudió en su día la diplomatura de estadística. Lleva años trabajando distintas cosas más o menos próximas al asunto de sus estudios e incluso hizo un máster de algo. Pero el bendito plan Bolonia lo ha desdiplomado: me cuenta que todo lo que cursó de COU en adelante es papel mojado. ...

He recibido hoy un correo sobre plot.ly, que es, según sus autores, una herramienta colaborativa para el análisis y la visualización de datos. Gustará seguramente a los interesados en las APIs: en el fondo, el software reside en la nube. Permite, por ejemplo, integrar gráficos interactivos en IPython. Aunque no he visto ejemplos de cómo integrarlo con knitr. A ver si saco algo de tiempo…