Programación

Una de las cosas que menos me canso de repetir es que R no es (solo) un lenguaje de programación. R es un entorno para el análisis de datos. Los informáticos se horrorizan con él: no entienden por qué es como es. Pero, fundamentalmente, su problema es que no conciben que pueda haber sido diseñado para el REPL y no (solamente) para crear programas.

Casi todo el tiempo que paso con R abierto lo consumo trabajando interactivamente, no programando. R está pensado para facilitar ese tipo de trabajo, no para crear programas complejos. Está optimizado para el usuario, no para la máquina. De ahí se sigue una cascada de corolarios que no ha lugar plantear aquí.

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).

Recibí recientemente este correo (con los enlaces que aparecen en él; solo he eliminado el apellido de la remitente):

Subject: Carlos - Scala resource

Hi Carlos,

I was doing some research for our students here at Udemy on people using Scala resources and when I came across your site, saw you were using the tutorial from Wikipedia.

We really like that resource, and actually created our own that we think is a perfect supplement! This Scala tutorial is text-and image based, easy to search for quick answers, and super helpful for anyone: as a base for learning or as a reference guide.

El problema es sencillo: se cuentan y ya.

Pero hay quienes tienen cantidades ingentes de elementos que contar. Tantos que por razones de memoria, etc., es inviable hacer lo obvio, es decir, guardar una lista de claves (elementos distintos) y valores (el número de ocurrencias) sumando uno a los últimos cada vez que ocurra una de las primeras.

Por ese motivo, existen algoritmos que aproximan el número de elementos distintos de una lista. Existe, de hecho, toda una industria dedicada a crear tal tipo de algoritmos.

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…

Tengo un fichero .bak. Un fichero .bak (el mío, al menos) es una copia de seguridad de SQL Server y no hay forma humana de acceder a sus contenidos sin otro SQL Server (que yo sepa). No me preguntéis de dónde lo he sacado. La cuestión es que contiene datos que tengo que leer.

Requisito imprescindible para tener un SQL Server es disponer de una máquina con Windows. Pero yo no tengo ninguna. Cuando tuve, instalé la versión de evaluación gratuita de SQL Server (¿Express?) y me ahorré parte de la pena que describo a continuación. Lo hago por referencia mía, por referencia de otros y por si alguien conoce algún atajo.

Telegram es un sistema de mensajería por internet similar a Whatsapp, aunque con algunas diferencias notables:

• No es de Facebook
• Una vez tienes una cuenta, puedes usarla desde distintos dispositivos (Linux incluido)
• Tiene menos usuarios
• Es programable

De lo último es ilustración esta “conversación” que tuve con la cuenta @TeleR:

Los detalles, aquí. Y el crédito, para Rubén Tobalina.

Abres una aplicación en tu móvil que diseñó un programador búlgaro. Ipso facto aparece un insidioso banner de, p.e., Jazztel. ¿Cuáles son los mecanismos que ponen en contacto al búlgaro con Jazztel? ¿De qué manera recibe aquél una compensación de esta?

Tradicionalmente, el desarrollador habría hablado con, p.e., Google. Le habría dicho: yo voy a generar “espacios” donde tú vas a poder colgar propaganda a cambio de una cantidad (fija o variable). El intermediario, por otra parte, capta anunciantes (Jazztel en nuestro ejemplo), almacena un inventario de ellos y decide cuál de ellos mostrar. Hay teoría aplicable en estos contextos, como la que describe Real-Time Bidding Algorithms for Performance-Based Display Ad Allocation.

Tengo por delante otro proyecto que tiene mucho de análisis exploratorio de datos. Sospecho que más de un árbol construiré. Los árboles son como la Wikipedia: prácticamente nunca el último pero casi siempre el primer recurso.

Esta vez, además, por entretenerme un poco, probaré el paquete [evtree](http://cran.r-project.org/web/packages/evtree/index.html). Aunque no porque espere sorprendentes mejoras con respecto a los tradicionales, ctree y rpart.

¿Qué tiene aquél que los diferencie de los otros dos? Que la optimización es global. Tanto ctree como rpart utilizan algoritmos recursivos: al definir un nuevo corte del espacio, el algoritmo solo tiene en cuenta la región definida por los cortes anteriores. La optimización es local. evtree utiliza un algoritmo global de la familia de los evolucionarios (¡qué tufillo a lentorro!). Los detalles están aquí.

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

Esta de hoy es una entrada muy friqui que se sirve de la casi excusa de que los creadores de Apache Spark han ganado la competición Gray Sort de 2014 para recomendar a sus lectores a estar alerta a las novedades que llegan.

Todavía colea el siglo XX y todavía pagan dinero por cosas que algún día consideraremos tan entrañables como el ZX Spectrum de 48kB tales como:

• Colorear casillas en Excel.
• Escribir pasos data en SAS.
• Tener reuniones de dos horas.
• Guardar todos los archivos en el disco duro de un portátil.
• Y otras cosas que igual un día me suelto y cuento.

Pero el futuro está a la vuelta de la esquina y los pájaros tempraneros de hoy en día, que ya saben R (porque son, como digo, pájaros tempraneros), aprenden Spark y Scala.

Uno de mis últimos pet projects tiene que ver con el análisis de las componentes conexas de unos grafos muy grandes. Como aquí pero con datos de un tamaño muchos órdenes de magnitud mayores. Usando Spark, claro. Y ya que lo cito, aprovecho la ocasión para regalar un consejo a mis lectores más jóvenes: no esperéis a los cuarenta para aprender Scala y Spark.

Voy a limitarme a copiar el código para referencia mía y de otros. Creo que se autoexplica:

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.