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