Nunca he entendido eso de los odds. Me refiero a eso que mencionan las películas: ocho contra uno a favor de tal, cinco contra tres a favor de cual. Y no creo que sea el único al que le son ajenos. De hecho, la página de la Wikipedia en español correspondiente a la inglesa para odds se refiere a ellas como cuotas, término que jamás hasta hoy había visto así usado. Tampoco lo han visto, se concoce, los lexicógrafos de la RAE.
R es un lenguaje de programación de alto nivel que se usa principalmente en aplicaciones estadísticas y para la generación de gráficos. El objetivo de esta guía de estilo es que nuestro código sea más fácil de leer, compartir y analizar. Las reglas de esta guía fueron consensuadas con la comunidad de usuarios de R en Google.
Resumen de las reglas de estilo
.Rvariable.name, FunctionName, kConstantName<-, no =# seguido de un espacio; los comentarios dentro del código necesitan dos espacios delante de #TODO(username)Resumen de las reglas de programación
Creo que muchos hemos tropezado con las macros alguna vez. Yo conocía las del preprocesador de C o el tinglado que tiene SAS. Y nunca fui muy amigo de ellas.
Pero el otro día leí Stop Writing JavaScript Compilers! Make Macros Instead y se me alargaron los dientes. Así que he buscado información adicional hasta hacerme una idea de la diferencia entre una macro que se limita a reemplazar texto, una macro procedural —como las del lenguaje PL/I, antecesor e inspirador de SAS— y las sintácticas, como las que tiene Lisp (¿cuándo tendré tiempo para aprenderlo en condiciones?).
Los profesores Hastie y Tibshirani, coautores de Elements of Statistical Learning, de muchas técnicas predictivas y, todo hay que decirlo, ídolos intelectuales míos, organizan un MOOC gratuito, Statistical Learning entre el 21 de enero y el 22 de marzo.
Si estás leyendo esto (es decir, si has aterrizado en mi bitácora), te interesa. Si no te apuntas, te aviso, te arrepentirás.
Dicho lo cual, yo estaré ahí. Y se cuenta que podrían organizarse grupos locales de participantes —p.e., en Madrid— para resolver dudas y problemas.
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.
