R

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:

gplot2 es, sin duda, el paquete gráfico de moda en R. Hay quien lo ama, hay quien lo odia, pero cada vez son menos los que lo ignoran. Lo que igual no es tan sabido por los usuarios de R es el contexto en el que nació ggplot2, su relación con el motor gráfico de R y su relación con otros mecanismos de representación gráfica existentes en otros paquetes estadísticos.

Revolution Analytics ha disparado un torpedo apuntando bajo la línea de flotación de SAS. Se trata del SAS to R challenge, una muy inteligente campaña de publicidad por la que se compromete a reescribir en R gratuitamente código SAS de clientes potenciales si el primero es más eficaz que el segundo.

Más allá de lo que la campaña parece ser, se esconde lo que realmente es: la constatación de que el premio gordo en el mundo de análisis empresarial es la actual base instalada de SAS y de que Revolution va a por todas.

Puede que a alguien le resulte sencillo, pero jamás ameno: trabajar con fechas y horas es, cuando menos, una molestia con cualquier lenguaje de programación. Y como mi compañero Raúl ofreció en su bitácora una pequeña guía de cómo operar con ellas usando SAS/WPS, me dispongo yo a hacer lo propio con R.

Leyendo fechas y horas: strptime

El primer encontronazo con el insidioso problema de las fechas y las horas suele ser el tener que leerlas de algún fichero de texto. En tales casos la función strptime siempre es útil:

Acabo de tener noticia de R-node, una interfaz web para R. Permite abrir una sesión de R remota (o local) a través del navegador e interactuar con R como a través de la consola habitual.

Los interesados deberían visitar esta demo y, tal vez, el código fuente en Gitorious.