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.
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.
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.
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.
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
calcula A calcula B calcula C combina A, B y C Obviamente, se me ocurre ejecutarlos así:
calcula A, B y C en paralelo cuando acabe el paso anterior, combina A, B y C Y aún me sobrarían 5 núcleos y bastante RAM.
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.
En el siguiente vídeo Wolfram habla del lenguaje de Wolfram. Siento repetirme, pero quiero dejar claro que puede haber un sesgo. Porque como no lo haya, el Sr. Wolfram me va a tener como admirador (y puede que hasta como cliente).
Mirad lo que cuenta:
¿Es o no casi increíble?
Hoy viernes vuelvo a traer a mis páginas cuatro enlaces interesantes. El primero de ellos es como las malas películas: un arranque espléndido, un planteamiento prometedor y, al final, humo. Pero no trata de chico-conoce-chica sino de qué hacer con esas variables que tienen una varianza casi nula (a la hora de crear modelos estadísticos, se entiende). Me llegó tan oportunamente que pensé que alguien que vela por mí desde lo alto me lo enviaba para sacarme de mi semanal atolladero.
