R

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 $latex 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.

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:

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.

He recibido hoy un correo sobre plot.ly, que es, según sus autores, una herramienta colaborativa para en 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](http://nbviewer.ipython.org/gist/msund/61cdbd5b22c103fffb84). Aunque no he visto ejemplos de cómo integrarlo con [knitr](http://yihui.name/knitr/). A ver si saco algo de tiempo…

Los días 16 y 17 de junio tendrán lugar en Madrid las V Jornadas de la Enseñanza y Aprendizaje de la Estadística y la Investigación Operativa. Cosa de la que tal vez no hubiese llegado a tener constancia de no haber sido por la gentileza de la organización, que me ha invitado a impartir un taller introductorio al big data.

Serán cuatro horas y media en la mañana del 17 organizadas de la siguiente manera:

Trabajo sobre una máquina de 8 núcleos y 24 GB de RAM. Y que conste que se me ha llegado a quedar chica.

Algunos programas que ejecuto tienen (o contienen pedazos de) la forma

1. calcula A
2. calcula B
3. calcula C
4. combina A, B y C

Obviamente, se me ocurre ejecutarlos así:

1. calcula A, B y C en paralelo
2. cuando acabe el paso anterior, combina A, B y C

Y aún me sobrarían 5 núcleos y bastante RAM. La pregunta es: ¿cómo?

Copio aquí unas líneas:

R is a dynamic language for statistical computing that combines lazy functional features and object-oriented programming. This rather unlikely linguistic cocktail would probably never have been prepared by computer scientists, yet the language has become surprisingly popular.

Pertenecen al resumen de un artículo que enlazo aquí por si a alguien le intrigan el nudo y el desenlaza de ese planteamiento.

Ayer odié mucho a José Luis Cañadas —que sigue no obstante siendo amigo: véase más abajo— por esto:

Nueva versión en CRAN de MicroDatosEs de @gilbellosta. Permite leer con #rstats entre otros, los microdatos los de la EPA del INE.

– Jose Luis Cañadas (@joscani) May 13, 2014

Hubiera preferido reservarme la primicia para todos sus usuarios y simpatizantes de la nueva versión del paquete MicroDatosEs recién subida a CRAN pero… en fin.

De todos modos José Luis no es el villano de la historia. El villano es el INE, que parió en la mañana del 29 de abril los nuevos resultados de la EPA con un cambio retroactivo de formato en los ficheros de microdatos que rompió mis funciones justo cuando más falta hacían. ¡Contento me tiene el INE! ¡Apañaos dejó a los usuarios mi paquete! ¿Sabéis cuántos correos desesperados recibí esa mañana?