Paquetes

Busco alpha testers para mi paquete rPython. El paquete es la evolución natural de rJython, un paquete de R que permite llamar a Jython, el dialecto de Python que corre sobre la máquina virtual de Java, desde R.

rPython permite llamar al verdadero Python. Funciona perfectamente en mi máquina, pero necesito ver qué problemas de instalación y uso aparecen en otras plataformas. De momento, sólo funcionaría sobre plataformas UNIX o Linux. Me sorprendería lo indecible que funcionase también sobre Windows: sería toda una casualidad.

Me complace anunciar la subida a CRAN de la versión 0.7 del paquete colbycol.

La diferencia esencial con respecto a la anterior es:

• Utiliza el paquete filehash para crear el objeto que almacena los datos en disco.
• Incorpora algunas mejoras de uso sugeridas por los usuarios que facilitan la manipulación de los datos.

Espero poder publicar un estudio comparado del rendimiento en los próximos días.

Parcialmente en agradecimiento a Revolution Analytics por haber concedido una subvención a las III Jornadas de usuarios de R voy a discutir en esta entrada cómo paralelizar bucles usando los paquetes foreach y doMC desarrollados por dicha empresa.

El paquete foreach contiene, esencialmente, una única función, foreach, que, en su forma más básica, permite ejecutar bucles con una sintaxis un tanto peculiar:

foreach( i = 1:3 ) %do% log( i )

Volveré sobre algunas operaciones interesantes y bastante útiles que permite realizar esta función porque, de todas ellas, hoy me ocuparé sólo de una: la que abre la puerta de una manera sencilla a la paralelización de bucles.

Hace unos días subí a CRAN la última versión de mi paquete colbycol. Incluí algunas mejoras sugeridas por uno de sus usuarios así como otras que estaban esperando a que liberase mi agenda. Además, añadí un pequeño tutorial en la página del paquete.

El paquete colbycol está pensado para resolver —aunque sólo sea parcialmente— uno de los problemas más acuciantes de quienes usamos R para el análisis de datos muy grandes: leer ficheros de datos de gran tamaño.

Los amantes de Excel están de enhorabuena. Ahora tienen una alternativa a RExcel, una extensión de Excel que le permite interactuar con R: XLConnect, un paquete multiplataforma de R que permite:

• Trabajar con ficheros de Excel 97 (.xls) y OOXML (.xlsx)
• Crear y eliminar hojas dentro de documentos
• Leer y escribir rangos de valores (ranges)
• Leer y escribir hojas de cálculo
• Añadir gráficos
• Asociar estilos a celdas
• Definir el tamaño de las filas y columnas
• Etc.

Está basado en Apache POI, una colección de librerías de Java que permiten manipular ficheros en los formatos más o menos propietarios de Microsoft. Así no es siquiera necesario tener Excel instalado. ¡Ni siquiera trabajar en Windows!

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.

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.

Hadley Wickman, el autor de plyr, reshape y ggplot2, ha vuelto a la carga en su exitoso empeño por hacernos cambiar de forma de programar en R.

Con su nuevo paquete, stringr, aspira a facilitarnos aún más la vida. En un reciente artículo, enumera sus ventajas:

• Procesa factores y caracteres de la misma manera (de verdad, muy práctico)
• Da a las funciones nombres y argumentos consistentes
• Simplifica las operaciones de procesamiento de cadenas eliminando opciones que apenas se usan
• Produce salidas que pueden ser utilizadas fácilmente como entradas a otras funciones
• Incorpora funciones para procesar texto presentes en otros lenguajes pero no en R

El siempre muy benéfico Banco de Santander me ha proporcionado —onerosamente: veráse el porqué— un conjunto de datos con el que ilustrar a los lectores de este blog en el uso del paquete outliers de R. Los datos son los siguientes:

dia <- 17:26
precio <- 10 + c( 22, 21, 39, 18, 24, 26, 26,26,29, 28 ) / 100

Los días son los discurridos desde que di una orden de adquisición de un fondo de inversión a través de dicha entidad financiera hasta que tuve constancia de que se había completado: el dinero se había adeudado de la cuenta corriente y las participaciones, aparecían listadas en la cuenta de valores. El precio contiene los valores liquidativos diarios del fondo durante tales días. He aquí su representación gráfica:

Tengo acceso a una máquina que, aunque anda un poco corta de memoria, cuenta con ocho CPUs. Tenía unas simulaciones bastante pesadas que correr y quise aprovechar su naturaleza perfectamente paralelizable. Y, de paso, hacer con R lo mismo por lo que he visto a un consultor de SAS cobrar a razón de 3.000 dólares diarios.

En el fondo, es una trivialidad. Supongamos que la función que implementa la simulación se llama foo. Habitualmente, haríamos

Ya está disponible el paquete rJython que permite llamar a Python desde R. Aunque todavía no se ha subido a CRAN, puede instalarse así:

install.packages("rJython", repos="http://R-Forge.R-project.org")

Una vez instalado puede probarse el paquete ejecutando, por ejemplo,

rJython <- rJython()
a <- 1:4
jython.assign(rJython, "a", a)
jython.exec(rJython, "b = len( a )")
jython.get(rJython, "b")
rJython$exec("import math")
jython.get(rJython, "math.pi")
jython.call(rJython, "len", 1:3)
b <- 5:8
rJython$exec("def concat(a,b): return a+b")
jython.call(rJython, "concat", a, b)

Arquitectura: Jython y rJava

El paquete no está basado en el habitual Cpython sino en Jython, un intérprete de Python desarrollado en Java. El motivo es doble:

Prometí el otro día revelar los secretos (pensaba que no lo eran tanto) del gráfico que mostré en esta entrada. Los impacientes tienen aquí todo lo que necesitan. Tienen que ejecutar primero el guión svg2ps.sh que invoca inkscape para transformar los ficheros svg (incluidos en la descarga) de las banderas (obtenidos de la Wikipedia) en ficheros postscript.

El programa src.R genera entonces el gráfico utilizando dos paquetes de R: grImport y lattice. El primero permite convertir postscript en xml y posteriormente en objetos de la clase picture.

No hace mucho me enfrenté con un problema en el trabajo. Quería cruzar dos tablas, una de algunos miles de millones de registros y otra de algunos cientos de miles para, simplemente, contar el número de filas finales que aparecían por fecha.

Cada una de las tablas tenía algunos filtros y agregaciones; el cruce final se realizaba sobre las subconsultas resultantes. El gestor de bases de datos que utilizamos, Teradata (sin comentarios), no podía con el cruce: las decisiones que tomaba internamente el presunto optimizador de consultas conducían inexorablemente a un error de espacio.