Programación

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?

Sí, mi viejo ordenador había cumplido 6 años y comenzaba a quedarse corto. La puntilla fueron problemas de compatibilidad de la tarjeta gráfica con el nuevo Xubuntu (más precisamente, con los nuevos núcleos de Linux que trae). Así que lo que hace no tanto habría parecido ciencia ficción, es ahora realidad bajo mi mesa: 64GB de RAM para mí solo. Y eso que no me he querido gastar dinero; además que, como autónomo y siendo la nueva máquina herramienta de trabajo, viene a salirme como en la mitad que a un civil.

Son lenguajes de programación diseñados para describir odelos probabilísticos y realizar inferencias sobre dichos modelos.

El resto de la entrada de la Wikipedia sobre este apasionante (y lo uso sin retintín) tema, aquí (y puede que también quieras visitar esto).

Existe una breve obrita, Unix for Poets, que utiliza el análisis cuantitativo de texto como excusa para aprender a manejar una serie de comandos inexcusables de Unix y sus derivados: wc, grep, etc.

Se la recomiendo particularmente a aquellos que se compraron una Mac y no saben que cuentan con una terminal decente oculta en alguna parte de su sistema (en serio, los hay: el otro día se la descubrí a una maquera).

Frans van Dunné me ha hecho llegar su guía de estilo de programación en R. Abunda en otra creada por Google hace un tiempo y que traduje y adapté aquí.

Tiene como novedad, dice, su adaptación a las formas y maneras de Hadley Wickham, aún no tan conocido entonces. Coinciden, no obstante, en lo más.

Ninguna de las dos trata el uso las tuberías (operador %>%). Pero es un asunto que se nos puede ir de las manos: de hecho, hoy he conocido el paquete [backpipe](https://github.com/decisionpatterns/backpipe), que implementa %<% y que nos augura largas y desesperantes sesiones de depuración de código.

Los que estéis por allí o tengáis la posibilidad de acudir, sabed: la semana que viene (5, 6 y 7 de mayo de 2015) se celebra una nueva edición de APIdays Mediterránea en Barcelona.

Quienes tengáis pensado acudir, podéis beneficiaros de un 30% de descuento si os registráis desde este enlace.

Participé en la edición de 2013 en Madrid y me duele no poder asistir este año. Entre otras cosas, por esto. Y me displace perdérmelo porque mi nuevo stealth project tiene mucho que ver con APIs…

Suelo trabajar un servidor con ocho CPUs. Cuando quiero paralelizar código en R, suelo utilizar [parallel::mclapply](https://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html) (como aquí). Pero no tengo una máquina. Tengo varias. Y antes, de hecho, muchas.

¿Cómo paralelizar en distintas máquinas?

Se puede usar Spark (y SparkR), por ejemplo. Pero una ruta que no había ensayado jamás es la de la vieja escuela, i.e., MPI, snow y demás.

Pero si

• tienes varios servidores corriendo un sistema operativo decente,
• instalas R y snow (y todo lo que necesites) en todos ellos y
• configuras los servidores para poder acceder a través de ssh sin contraseña desde uno central,

y, entonces, ejecutas

Muchos cuidamos de nuestro ordenador casi como una mascota: le ponemos un nombre (a menudo escribo desde tiramisu), le hacemos algo de mantenimiento, etc. Hay quienes, incluso, decoran sus máquinas con pegatinas.

Pero llega un momento en que hay que comenzar a tratar a las máquinas no tanto como mascotas sino como rebaños. Desde una pantalla aneja a esta en la que escribo estoy manejando un clúster de más de 200 GB y 50 núcleos distribuido en varias máquinas que ni sé dónde están. Además, solo espero que crezca. Ya no cuido de una mascota; cuido de un rebaño.

Rescato aquí para mis lectores dos citas de un artículo de 1983, Computer Intensive Methods in Statistics, de Efron y Diaconis, por dos motivos: su valor intrínseco y que consideren leer el resto, particularmente el principio y el final.

La primera es (con mi traducción):

[…] el ordenador está cambiando la teoría de la estadística. Arriba hemos examinado nuevas teorías que han surgido a causa del ordenador. Otro cambio evidente es de los conjuntos de datos enormes que están disponibles a causa de la memoria de los ordenadores. Además, el ordenador permite usar métodos tradicionales para resolver problemas más grandes. El análisis de componentes principales es un buen ejemplo: fue inventado antes de que fuese realmente práctico.

No sé si imagen y magia comparten la misma raíz. Lo que me consta es que la gente que procesa imágenes hace algo que me parece casi mágico. De mayor quiero ser como ellos.

Traigo aquí un ejemplo sobre técnicas para completar imágenes:

El artículo completo, Scene Completion Using Millions of Photographs, y mucho material auxiliar puede revisarse aquí.

Trabajo sobre una máquina de 8 núcleos y 24 GB de RAM. Y que conste que se me ha llegado a quedar chica.

Algunos programas que ejecuto tienen (o contienen pedazos de) la forma

1. calcula A
2. calcula B
3. calcula C
4. combina A, B y C

Obviamente, se me ocurre ejecutarlos así:

1. calcula A, B y C en paralelo
2. cuando acabe el paso anterior, combina A, B y C

Y aún me sobrarían 5 núcleos y bastante RAM. La pregunta es: ¿cómo?

Copio aquí unas líneas:

R is a dynamic language for statistical computing that combines lazy functional features and object-oriented programming. This rather unlikely linguistic cocktail would probably never have been prepared by computer scientists, yet the language has become surprisingly popular.

Pertenecen al resumen de un artículo que enlazo aquí por si a alguien le intrigan el nudo y el desenlaza de ese planteamiento.

Sí, hay gente que pasa cinco años en una de esas instituciones encopetadas que son las universidades y sale de ellas sin saber programar.

Aquí va un ejemplo. Es un fragmento de un currículo que me ha llegado recientemente. El tipo es economista, graduado en uno de los departamentos de la materia más reconocidos de Madrid. Dice así:

Eso es todo lo que el tipo reconoce saber sobre algo parecido a la programación.