R

Conforme se populariza el uso de R, cobran creciente importancia las cuestiones concernientes a su rendimiento, su gestión de la memoria, etc. Hasta el punto que incluso uno de sus creadores, Ross Ihaka, ha expresado últimamente su descontento con las limitaciones de R (el enlace es gentileza de Daniel Castro) sugiriendo que sus componentes puramente estadísticos deberían construirse sobre la base de un lenguaje distinto, posiblemente Lisp.

Dentro de este contexto de preocupación sobre el rendimiento de R, han aflorado algunas cuestiones acerca de la eficiencia del intérprete a la hora de resolver expresiones matemáticas. Por ejemplo, Radford Neal estudió el desigual desempeño de R frente a ciertas expresiones matemáticas equivalentes: en particular, la expresión

Tras escribir el otro día sobre RevoscaleR, he tropezado con un paquete de R, HDF5 que le permite hacer cosas parecidas usando tecnologías libres. Puede encontrarse más información sobre HDF5 en la Wikipedia y en la página del proyecto.

De todos modos, y como dejé escrito como respuesta a un comentario en la entrada que indico más arriba, una solución definitiva al problema del análisis de conjuntos de datos grandes con R podría venir de la mano de una integración adecuada con un gestor de bases de datos orientado a columnas. En efecto, el cuello de botella más notable que existe al usar R junto con, p.e., Postgres (y como Postgres el 99% de los restantes DBMS) es que sus tablas son conjuntos de filas mientras que para R son listas de colunmas. Por tanto, quiérase o no, en algún sitio hay que realizar una trasposición computacionalmente pesada.

En un hilo reciente en la lista de desarrollo de R ha habido una discusión interesante acerca de buenas prácticas a la hora programar con R y concretamente, para desarrollar paquetes que contuviesen llamadas a código desarrollado en C/C++.

En particular, el autor del primer mensaje del hilo criticaba varios usos que consideraba inadecuados a la hora de programar en R:

1. El uso de variables misteriosas surgidas de la nada. En particular, el uso de variables que aparecen en el cuerpo de la función pero que no han pasado como argumentos.
2. El uso de <<-
3. El uso de bucles for cuando el código podía haberse vectorizado.
4. El uso de return al final de una función
5. Código desordenado y antiestético. En particular, el no dejar que respire mediante el uso de espacios.

Al respecto, Hadley Wickham, recomendó leer los consejos que ha recogido en su wiki. Gabor Grothendieck recomendó una discusión en Stackexchange.

Quiero compartir con mis lectores dos enlaces relacionados. Puede que a alguno le interese su sustancia misma. A mí no tanto. A mí me interesan en cuanto que ilustran la emergencia de R y el papel protagónico que está asumiendo en el universo de las cosas analíticas. Tan protagónico que hasta dos viejos dinosaurios pasan voluntariamente por su aro.

Tradicionalmente, para analizar grandes bases de datos empresariales, se realizaba en primer lugar una extracción masiva de datos. Luego se procesaban con herramientas específicas (SAS, por ejemplo). En muchas ocasiones los resultados eran volcados nuevamente en el sistema de partida.

El reto lanzado por Revolution Analytics a SAS está relacionado con el lanzamiento por parte de la primera empresa de un paquete, RevoScaleR, diseñado para permitir el análisis de conjuntos de datos grandes. La lectura más detallada de uno de los pocos documentos técnicos que circulan sobre el paquete me invita a compartir con mis lectores mis impresiones más allá de las primeras y más someras que realicé hace unos días.

La primera es que sigo sin entender claramente cómo es y cómo funciona el nuevo formato de almacenamiento de tablas, XDF. Al menos, no es público. Aunque es un tema de investigación candente (de lo que son prueba esto, esto, esto o el mismo paquete ff de R), no está claro si reaprovecha desarrollos previos o si es una implementación desde cero.

Noticia fresca, recién salida del horno: RStudio acaba de salir a la luz. Se trata de un nuevo editor multiplataforma y de código abierto de R .

Está desarrollado en C++ y corre en Linux, Windows y Mac OS X. Y no puedo decir mucho más de momento. Pero espero los comentarios de todos los entusiastas de R al respecto.

Siguiendo con la serie de artículos sobre programación funcional que comencé hablando de Filter() hace un tiempo, trataré hoy la función Reduce(). El contenido de cuanto sigue debería ser familiar de quienes asistieron al Taller Avanzado de R en las II Jornadas de Usuarios de R.

Reduce es el segundo de los tiempos de una abstracción popularizado por Google y otros pero que tiene sus raíces en los lenguajes funcionales (Lisp y otros): map-reduce. En resumen, map es la transformación

Si el otro día denuncié un gráfico engañabobos (y algún otro me explayaré muy constructivamente sobre el intercambio de correos que mantuve con sus autores), hoy he querido reproducirlo con el paquete googleVis de R.

Habedlo:

[cf]googleViz[/cf]

El código utilizado para generarlo es:

library(googleVis)
library(reshape)

a <- read.csv("http://datanalytics.com/uploads/serie_bde_1.csv")[,1:2]
b <- read.csv("http://datanalytics.com/uploads/serie_bde_2.csv", header = F)[,1:2]

colnames(a) <- c("fecha", "privado")
colnames(b) <- c("fecha", "público")

fechas <- data.frame(fecha = a$fecha, orden = 1:nrow(a))

goo.dat <- merge(merge(a, b), fechas)
goo.dat <- goo.dat[order(goo.dat$orden),]

goo.dat$privado <- goo.dat$privado / 10^9
goo.dat$público <- goo.dat$público / 10^9

goo.dat <- subset(goo.dat, select = c(privado, público))
goo.dat$date <- seq(as.Date("1962-01-01"), by = "month", length = nrow(goo.dat))
goo.dat <- melt(goo.dat, id.vars = "date")


goo.tl <- gvisAnnotatedTimeLine(goo.dat, datevar = "date",
            numvar = "value", idvar = "variable")

Finalmente, hay que advertir que no es inmediato el publicar estas visualizaciones en bitácoras como ésta (que utiliza Wordpress). Los detalles de cómo hacerlo, en este enlace.

He encontrado una página que será, seguro, del gusto de mis lectores. Contiene animaciones en R tales desarrolladas con el paquete animation tales como ésta sobre la optimización por mínimos cuadrados o esta otra sobre k-medias.

¡A disfrutar!

En esta entrada voy a mostrar tres maneras (que vienen a ser la misma) de ordenar los niveles de un factor en R:

1. La básica
2. La sofisticada
3. El atajo

Antes, responderé a una pregunta: ¿por qué reordenar niveles en factores? La mejor respuesta que se me ocurre: si no la sabes, deja de leer ya. Te aseguro que, a poco que trabajes con R, acabarás retomando la lectura.

La forma básica es la siguiente: