programación

Extingámonos con dignidad: generaciones actuales y futuras, no incurramos en los errores de las anteriores

Participé el otro día en una cena con gente friqui. Constaté con cierto desasosiego cómo han virado los sujetos pasivos de nuestra indignación profesional a lo largo de los años. Antaño, fueron los viejos que seguían apegados a la paleoinformática. Hogaño, los primíparos que usan Python y desdeñan R. Tengo sentimientos encontrados y no sé qué más añadir.

Windows Subsystem for Linux

Igual todo el mundo conoce ya WSL. Pero por si acaso queda entre la audiencia algún otro despistado, pues, eso: que existe en Windows 10 (¿solo?) un subsistema Linux que permite correr comandos de consola, instalar paquetes (p.e., con apt-get), etc. Incluso R. Me queda solo la duda del entorno gráfico, sobre el que no he visto nada. En su día, Windows fue un programa de MS-DOS que arrancaba al escribir win en la consola.

Efectos secundarios (nota: que existan no significa que debas usarlos)

Una función no debería cambiar nada de cuanto la rodea. Debería devolver algo y ya. Se acepta barco como animal acuático cuando hay funciones que escriben en logs, guardan datos en disco o crean gráficos. R deja que los usuarios se disparen en el pie permitiendo hacer cosas tan peligrosas como: a <- new.env() a$1 # error foo <- function(){ a$a <- 1 } foo() a$a # [1] 1 De la misma manera, si le enseñas un cuchillo a una vieja, es posible que te dé su bolso con todo lo que contiene.

Todo lo que sucede en R es una llamada a una función

En serio, es así. ¿También if? Pues también. De hecho, `if`(1 == 3, print("a"), print("b")) Y eso permite, por ejemplo, que funcionen expresiones tales como a <- if (1 == 3) 4 else 5 tan útiles como poco empleadas en general. También son funciones (, { y otras que aparecen en la sección .Internal vs .Primitive del documento R Internals.

Una fina, tenue, somera capa de sintaxis

Estuve el otro día en una charla de José Luis Cañadas en el grupo de usuarios de R de Madrid sobre sparklyr. Hoy en otra de Juan Luis Rivero sobre, esencialmente, lo mismo, pero esta vez con Python. Y podría escribir “etc.”. Me centraré en la de José Luis, aunque podría decir lo mismo de cualquiera de las otras. No había trabajado con sparklyr. No soy siquiera fan de dplyr (aunque no es que no se lo recomiende a otros; es simplemente, como tantas cosas, que soluciona problemas que no tengo).

Un curso de 15 horas de introducción a la programación

Hoy comienzo a enseñar un curso de introducción a la programación para recién graduados que comenzarán un máster de matemáticas aplicadas con incursiones en la llamada ciencia de datos. Serán 4 sesiones con el siguiente contenido: Sesión 1, programación imperativa: variables, condicionales y bucles. Sesión 2, programación orientada a objetos. Sesión 3, colecciones: listas, tuplas, conjuntos, diccionarios, etc. Sesión 4, programación funcional: map, reduce, fold, foldLeft, scan, filter, etc. Los lenguajes a utilizar serán R y Python (via Jupyter).

R es un vago

Si creo la función foo <- function(a,b) a*a + b y la llamo mediante foo(1 + 1,3) pueden ocurrir dos cosas: o bien que R precalcule 1+1 y la función ejecute 2 * 2 + 3 o bien que la función ejecute directamente (1+1)*(1+1)+3. Pero, ¿qué es lo que hace realmente? Si escribimos f1 <- function(x){ print("Soy f1") x } f2 <- function(x){ print("Soy f2") x } foo(f1(2), f2(3)) obtenemos

Metropolis-Hastings en Scala

Tengo la sensación de que un lenguaje funcional (como Scala) está particularmente bien adaptado al tipo de operaciones que exige MCMC. Juzguen Vds. Primero, genero datos en R: datos <- rnorm(500, 0.7, 1) writeLines(as.character(datos), "/tmp/datos.txt") Son de una normal con media 0.7. En el modelo que vamos a crear, suponemos conocida (e igual a 1) la varianza de la normal y trataremos de estimar la media suponiéndole una distribución a priori normal estándar.

R sobre el EC2 de Amazon hace casi siete años: una concesión a la melancolía

Corría el año 2009 cuando comencé mi segunda aventura bloguera (nadie, yo incluido, quiere rememorar la segunda) cuando Raúl Vaquerizo tuvo la caridad de aceptarme como colaborador en Análisis y Decisión. En diciembre de aquel año escribí cómo utilizar R en una cosa que entonces comenzaba a sonar: la nube y, en concreto, el servicio EC2 de Amazon. El resultado, probablemente totalmente desfasado, fue este. Material de hemeroteca, alimento de melancolías.

Rmd2R: un conversor de lo que su propio nombre indica

Mis clases de/con R suelen consistir en un guión que es un programa en R con muchos comentarios y ejercicios. Con el tiempo, estos últimos tienden a crecer hasta el punto de que se convierte casi en un fichero de texto comentado con aspersión —en su acepción no-DRAE de efecto— de líneas de código. Mejor, me he dicho recientemente, usar Rmarkdown. Pero Rmarkdown sirve para lo que sirve: como fuente para compilar ficheros pensados para ser leídos por seres humanos.

¿Tanto ha llovido (en términos de precisión numérica) desde 2008?

Acabo de ejecutar set.seed(1234) x <- runif(1e6) x.shift <- 1e9 + x sd(x) sd(x.shift) sqrt(sum((x - mean(x))^2) / (length(x - 1))) sqrt(sum((x.shift - mean(x.shift))^2) / (length(x - 1))) sd.sum.squares <- function(x){ n <- length(x) suma <- sum(x) suma.cuadrados <- sum(x^2) sqrt((n * suma.cuadrados - suma^2) / (n * (n-1))) } sd.sum.squares(x) sd.sum.squares(x.shift) inspirado por esto y me pregunto: ¿tanto ha llovido en términos de precisión numérica desde 2008?