Data.table

El ayuntamiento de Madrid publica información (desde 2015) de los avisos recibidos por los ciudadanos a través de los distintos canales puestos a su disposición (010, LineaMadrid, la app, etc.). He bajado los datos y he pintado que es la suma acumulada de la diferencia entre los avisos entrantes y los resueltos día a día usando library(data.table) library(xts) recibidos <- rbindlist(lapply(dir(pattern = "recibi"), fread)) resueltos <- rbindlist(lapply(dir(pattern = "resu"), fread)) recibidos.fecha <- recibidos[, .(n.recibidos = .N), by = "FECHA_DE_RECEPCION"] resueltos.fecha <- resueltos[, .(n.resueltos = .N), by = "FECHA_DE_RECEPCION"] ambos <- merge(recibidos.fecha, resueltos.fecha) ambos$fecha <- as.Date(ambos$FECHA_DE_RECEPCION, format = "%d/%m/%Y") ambos$FECHA_DE_RECEPCION <- NULL ambos <- ambos[order(ambos$fecha),] ambos$pendientes <- cumsum(ambos$n.recibidos - ambos$n.resueltos) tmp <- xts(ambos$pendientes, order.by = ambos$fecha) plot(tmp, main = "Avisos pendientes en Avisa Madrid (010, etc.)" , ylab = "cola de pendientes") Comentarios: ...

Los productos de Apple, aun admitiendo su calidad, resuelven problemas que yo hace años que no tenía. Tanto data.table como dplyr vinieron a resolver problemas a los que muchos nos enfrentábamos con sudor y lágrimas. Ha aparecido recientemente una serie de tutoriales sobre ambos paquetes que recomiendo: El de data.table El de dplyr (parte I, parte II) Y mis comentarios: Para el 99% de mis problemas de manipulación de datos, me sobra con, además de R base, reshape2 y plyr. Para datos más grandes, me decanto por data.table. En gran medida, porque es previo a dplyr. No obstante, tengo la sensación de que dplyr acabará llevándose el gato al agua: tengo suficientes años como para haber presenciado sin que me las cuenten batallas anteriores: Beta vs VHS, WordPerfect vs Word, etc.

Jan Gorecki ha resumido las soluciones a las cincuenta preguntas más populares sobre el paquete data.table de R en Stack Overflow y las ha resumido en forma de tutorial aquí. Muy recomendable. Muy recomendable también data.table. Aunque me temo que el hadleyverse, y por razones que nada tienen que ver con la calidad de la cosa, no van a dejar de él, a medio plazo, ni las raspas.

Se me ha ido pasando y nunca he llegado a escribir aquí que seré uno de los profesores del Experto en Data Science de la U-tad que comienza… de hecho este viernes. El escribir tan tarde me permite, al menos, presumir de que todo lo bueno que tengo que decir sobre el programa y el claustro no tiene finalidad comercial/propagandística. Y sí, lo habéis adivinado: la parte del programa que me corresponde tiene que ver con R y algunos de los paquetes que me sacan de apuros a diario (p.e., data.table). Y la otra sobre motores de recomendación. Tema en el que hasta no hace mucho no creía (y tampoco me atraía) pero en el que estoy descubriendo extensiones muy interesantes. Como por ejemplo, esta.

Fui un pájaro mañanero con [plyr](http://cran.r-project.org/web/packages/plyr/index.html). Probé una vez [data.table](http://cran.r-project.org/web/packages/data.table/index.html) y no me convenció. Volví a él cuando realmente lo necesitaba y ahora es la prolongación de mis dedos. Aún no me he puesto con [dplyr](http://cran.r-project.org/web/packages/dplyr/index.html) aunque he visto el suficiente código escrito con él que no creo que me cueste mucho comenzar a usarlo. Pero tengo la sensación de que tenemos un cisma como el de vi contra emacs en ciernes. Comienza a haber, parece, partidarios acérrimos de tirios y troyanos. Así que abro la sección de comentarios para que opines sobre estos paquetes. A mí y a muchos otros lectores nos gustaría conocer tu opinión al respecto. ¿Cuál utilizas? ¿Qué te gusta de cada cual? ¿Cuál recomendarías?

En ocasiones uno quiere añadir un total calculado en ciertos bloques a una tabla. Por ejemplo, en la tabla set.seed(1234) ventas.orig <- data.frame( cliente = rep(1:10, each = 5), producto = rep(letters[1:5], times = 10), importe = rlnorm(50)) tenemos clientes, productos e importes. Y nos preguntamos por el porcentaje en términos de importe que cada producto supone para cada cliente. Una manera natural pero torpe de realizar este cálculo consiste en usar un objeto intermedio y merge: library(plyr) tmp <- ddply(ventas.orig, .(cliente), summarize, total = sum(importe)) ventas <- merge(ventas.orig, tmp) ventas$pct.producto <- 100 * ventas$importe / ventas$total No os asustéis, se puede hacer aún peor (p.e., usando sqldf). Pero existen dos maneras, cuando menos, de hacerlo mejor. La primera es usando data.table. ...

Sigo con mi lacónica serie sobre data.table. La protagonista: frases[sample(1:nrow(frases), 3),] #pos.es pos.en length.es length.en en es frase tfe qjilm num #1: 15 43 72 72 i de 2632 4.881416e-02 0.01369863 6.686871e-04 #2: 33 48 46 48 X países 5321 2.726146e-06 0.02040816 5.563563e-08 #3: 2 35 53 66 in preguntar 4582 2.424379e-08 0.01492537 3.618476e-10 dim(frases) #[1] 6340091 10 El tiempo: system.time({ setkey(frases, "frase", "es") denominadores <- frases[, sum(num), by = key(frases)] setnames(denominadores, c("frase", "es", "den") ) frases <- merge(frases, denominadores) frases$delta <- frases$num / frases$den }) #user system elapsed #5.628 0.208 5.841 En particular, ...

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