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