R

El IBEX 35 abre todas las mañanas a un precio y cierra a otro. El precio de apertura de un día no es necesariamente igual al del cierre del siguiente. Por lo tanto, la variación del índice en una jornada completa de 24 horas es igual a la suma de las variaciones dentro y fuera del horario de cotización. Dicho lo cual: Juan compra el IBEX todos los días a primera hora y lo vende en el último minuto. Al otro lado, Pedro lo compra en el último minuto y se lo vende (¡a Juan!) justo al abrir la bolsa al día siguiente. Juan y Pedro llevan operando así desde el 1 de enero de 2000. ¿Cuál de los dos se ha llevado el gato al agua? Veámoslo: ...

En medio del fragor mediático sobre el precio de la electricidad, me ha llegado un ofertón de GasNaturalFenosa: la posibilidad de contratar una tarifa plana para la electricidad. La entrada de hoy es el debido ejercicio acerca de si me conviene o no contratarla. En R, por supuesto. Primero, el código: library(ggplot2) # tramos tarifas planas tarifas <- c("micro", "mini", "media", "maxi", "extra") dat <- data.frame( tarifas = factor(tarifas, levels = tarifas), hasta = c(1500, 2500, 4000, 5500, 7000), tarifa.plana = c(30, 40, 55, 73, 91) ) # precio normal del kWh base <- 0.13 # fijo en función de la potencia contratada # indico el que pago yo aunque varía de # cliente en cliente termino.potencia <- 15 # precio del kWh sobre el límite extra <- 0.23 # consumos posibles consumos <- data.frame(consumo = seq(0, 7000, by=100)) dat <- merge(dat, consumos) dat$precio.normal <- 12 * termino.potencia + dat$consumo * base dat$precio.tarifa.plana <- 12 * dat$tarifa.plana + extra * pmax(0, dat$consumo - dat$hasta) dat$beneficio.oferta <- dat$precio.normal - dat$precio.tarifa.plana dat <- subset(dat, beneficio.oferta > -250) ggplot(dat, aes(x=consumo, y=beneficio.oferta, col = tarifas)) + geom_line() + geom_hline(aes(yintercept=0), col = "red", alpha = 0.5) La salida es este gráfico: ...

El yuyuplot al que me refiero es un gráfico ha circulado por internet y que ha causado cierto pánico, se ve (y de ahí el nombre). En algunos sitios —véase este como ejemplo de los menos acertados— se ha intentado de explicar al público sus deméritos. El mundo de las finanzas debiera ser la envidia de otros ámbitos por el volumen, variedad y velocidad de los datos disponibles en él. Además, desde tiempo atrás, mucho antes de que el siglo nos trajese el big data, la transparencia, el opendetodo y otras concomitancias. A la vez, sin embargo, es inagotable fuente de ejemplos de uso pueril de esos datos. El que nos ocupa es uno de ellos. ...

Pues eso, que me piqué —y parte de la culpa la tiene este sujeto— con el otro problema del cumpleaños y he aquí el código —exacto salvo redondeos, no mediante simulaciones— que he usado para resolverlo: f <- function(n, k = 365, v = NULL){ if(is.null(v)) v <- c(1, rep(NA, k)) res <- 1 for(j in (k-1):1){ v[k-j] <- ifelse( is.na(v[k-j]), f(n, k-j, v), v[k-j]) res <- res - choose(k,j) * ((k-j)/k)^n * v[k-j] } res } f(2287) #0.5003708 f(2286) #0.4994142 Lo que hay al final son los ensayos últimos de mi mecanismo de cutrebúsqueda binaria para acotar la solución usando la función f. Esta función calcula la probabilidad de que una distribución aleatoria de n bolas en k urnas no deje vacía ninguna de ellas. ...

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 Nombres de ficheros: tienen la extensión .R Identificacores: 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. ...