R

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 Nombres de ficheros: tienen la extensión .R Identificadores: variable.name, FunctionName, kConstantName Longitud de línea: no más de 80 caracteres Indentación: dos espacios, no tabuladores Espacios Llaves: el primero en la misma línea; el último, solo Asignaciones: usar <-, no = Puntos y comas: no usarlos Distribución general y ordenación Comentarios: todos los comentarios comienzan con # seguido de un espacio; los comentarios dentro del código necesitan dos espacios delante de # Definiciones y llamadas a funciones Documentación de funciones Ejemplo de función Estilo para los TODO: 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: Información adicional (fechas, horas, lugar) Requisitos de hardware y software para el taller 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 en el 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: Pescar cierto número de peces, $p_1$, marcarlos y devolverlos al lago. Pescar cierto número de peces, $p_2$, y contar cuántos de ellos fueron marcados el día anterior, $n$. Estimar el número de peces como $p_1 p_2 / n$ (dado que la proporción de peces marcados en el lago, $p_1 / x$ debiera ser similar a la de pescados el segundo día, $n / p_2$). 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 *.gz en 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. (Nota para quienes entienden mejor las explicaciones textuales que el siempre unívoco código: los programas anteriores descargan los correos enviados a r-help-es desde sus orígenes, extraen sus fechas de envío y representan gráficamente su número por mes). ...