Los días 17 y 18 de enero impartiré una versión extendida (¡siete horas!) de mi taller de R y Hadoop en Zaragoza. Para los interesados:
El temario será el mismo que en las ediciones anteriores aunque en esta ocasión habrá más tiempo para profundizar en algunos conceptos, realizar ejercicios adicionales, etc.
El primero es How to display data badly, de H. Wainer. Es un poco viejo, de 1984; pero, desgraciadamente, tan vigente si no más. Trata, como puede preverse, del mismo y ya algo manido tema: cómo crear gráficos que representen datos clara y eficazmente. Se agradece que el autor, no sin ironía, lo haya planteado a modo de recetario para conseguir justo lo contrario.
El segundo, Visualizing the Law: Using Charts, Diagrams, and Other Images to Improve Legal Briefs, de A. Rosman, es una lectura de evasión para quien comparta mis obsesiones y frustraciones: la vida me ha llevado a tener que leer —y peor aún, necesitar entender— párrafos de los que redactan leguleyos de toda índole y condición. ¿Es necesario que esa gente se explique así? ¿Habría otra manera? Pues la hay: el artículo en cuestión muestra mediante ejemplos cómo determinados pasajes del género legal pueden desenmarañarse trascendiendo la unidimensionalidad del texto corrido y mal empleado si se usan o, al menos, se acompañan de, los gráficos adecuados.
El problema fue sugerido por Eloy Ortiz en un mensaje a r-help-es. Quería saber cómo muestrear aleatoriamente (i.e., uniformemente) puntos sobre una región de la superficie terrestre delimitada por su bounding box (i.e., las coordenadas que definen un rectángulo sobre la esfera).
Obviamente, no vale con muestrear latitud y longitud uniformemente: el área comprendida entre dos meridianos cerca del ecuador es mayor que la comprendida entre otros dos más próximos al polo. Los husos se estrechan lejos del ecuador.
Pues no lo sé. Seguramente, nadie. Pero como he visto esto (que no es otra forma que una representación palabrera de una matriz de transiciones de Markov) y el debate R vs Python para el análisis de datos ha resonado estos últimos días con cierta fuerza, voy a ensayar un pequeño divertimento matemático que me traslada a una clase práctica de Álgebra I en mis años de estudiante.
Es el siguiente:
# creo la matriz de transición
cols <- c("r", "python", "otros")
mt <- c(227, 108, 33, 31, 140, 7, 58, 27, 68 + 73)
mt <- matrix(mt, nrow = 3, byrow = T)
colnames(mt) <- rownames(mt) <- cols
mt <- prop.table(mt, 1)
# la diagonalizo
tmp <- eigen(mt)
# efectivamente, la diagonalización "funciona"
tmp$vectors %*% diag(tmp$values) %*% solve(tmp$vectors)
# y dejo discurrir 1000 años
tmp$vectors %*% diag(tmp$values^10000) %*% solve(tmp$vectors)Como resultado, podemos estimar que el en futuro, el 33% de los data scientists estarán usando R contra el 53% que usará Python y el 13% que se decantará por otras herramientas. O, casi seguro, no.
He construido el mapa
porque, a pesar de sus innegables deméritos gráficos, como la profusión de topos rojigualdas, pudiera resultar de interés. No tanto por lo que representa, la distancia de los puntos de la península Ibérica a una lista obsoleta de aeropuertos (en la que no consta, p.e., el de Logroño), sino por el procedimiento que tal vez alguien pueda en su día reaprovechar para un mejor fin.
Quien haya estudiado estadística o probabilidad en algún tipo de institución que ofrece educación reglada se habrá topado con el problema de estimar el número de peces de un lago.
Esencialmente, lo que puede hacerse (dado que es imposible realizar un censo completo) es lo siguiente:
Con R puede hacerse una estimación (incluso del error), así:
He ejecutado hoy tres ficheros secuencialmente:
#!/bin/bash
wget -nd -r -l1 --accept gz https://stat.ethz.ch/pipermail/r-help-es/
zcat *.gz > all_mails
rm *.gzen sh,
#!/usr/bin/python
import mailbox
from email.utils import parsedate
from time import mktime
for message in mailbox.mbox('all_mails'):
fecha = parsedate(message["date"])
print str(fecha[0]) + "-" + str(fecha[1])en Python y finalmente
#!/usr/bin/Rscript
library(zoo)
meses <- read.table("horas.txt")[,1]
meses <- paste(meses, "-1", sep = "")
meses <- table(meses)
meses <- zoo(meses, order.by = strptime(names(meses), format = "%Y-%m-%d"))
png("uso_r_help_es.png")
plot(meses)
dev.off()en R para construir
y constatar que la lista de correo de ayuda de R en español está en crisis.
El jueves 12 de diciembre impartiré un taller titulado Big data analytics: R + Hadoop en las V Jornadas de Usuarios de R.
Va a ser un taller práctico y eso exige de los asistentes que quieran aprovecharlo disponer de una plataforma (¡no trivial!) sobre la que seguirlo y poder realizar los ejercicios. Además de poder seguir ahondando en el asunto después y por su cuenta.
Los requisitos son los siguientes:
Software:
Óscar Perpiñán es alguien a quien tenéis que conocer necesariamente si os interesan, entre otras cosas, temas como la visualización de datos espaciotemporales. Y tiene un blog muy recomendable.
Recientemente me ha dado permiso para reproducir aquí una respuesta suya en un hilo planteado en r-help-es sobre los distintos mecanismos existentes en R para generar gráficos. Lo hago a continuación con mínimos retoques tipográficos:
La ventaja esencial de los gráficos grid (lattice y ggplot2) frente a los gráficos base es su mayor flexibilidad para añadir o modificar el contenido. Un gráfico grid es un objeto más en R y, como tal, puede ser manipulado con los métodos que cada paquete define. Existen dos librerías fundamentales en el mundo grid, lattice y ggplot2.
El tuit
de John Allen Paulos me indujo a escribir
number.numbers <- function(n){
sum(cumsum(sample(0:n)) < n) + 1
}
res <- replicate(10000, number.numbers(1000))código con el que, efectivamente, puede comprobarse que la media es, efectivamente, e.
Ahora bien, ¿alguien se atreve a explicar por qué?
(No leas esta pista: (s??)?s??).
