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). No me he atrevido a añadir Scala (como ejemplo de cómo deben hacerse las cosas, además de ser un lenguaje, para variar, tipado y no interpretado) por falta de tiempo.

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

> foo(f1(2), f2(3))
[1] "Soy f1"
[1] "Soy f2"
[1] 7

lo que significa que f1 ha sido llamada una única vez. Es decir, R resuelve sus argumentos antes de aplicar la función. Pero hay más:

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. Y con Scala, así:

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.

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. Contiene demasiada información irrelevante —formato, etc.— para un guió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.

Trabajar con Spark usando Scala implica renunciar a ese paraíso que son las funciones melt y (d)cast de reshape2.

¿O no?

import org.apache.spark.sql.types.StructField;
import org.apache.spark.sql.types.StructType;
import org.apache.spark.sql.types.StringType;
import org.apache.spark.sql.types.DoubleType;
import org.apache.spark.sql.Row;

/** Create some data **/

val nrows = 20
val origDF = sc.parallelize(1.to(nrows).map(x => (x, math.pow(x,2), math.pow(x,3)))).toDF("id", "cuadrado", "cubo")

/** Melt **/

val ids  = Map("id" -> 0)
val cols = Map("cuadrado" -> 1, "cubo" -> 2)

def melt(x:Row, ids:Map[String, Int] , cols:Map[String, Int]) = {
        var tmp = ids.mapValues(y => x(y))
        for((k,v) <- cols) yield tmp + ("var" -> k, "value" -> x(v))
}

val df = origDF.flatMap(x => melt(x, ids, cols))

val newStructure = StructType( ids.values.map(x => origDF.schema(x)).toList ::: List(StructField("var", StringType), StructField("value", DoubleType)) )
val meltDF = sqlContext.applySchema(df.map(x => Row.fromSeq(x.values.toList)), newStructure)

/** cast **/

val castDF = meltDF.groupBy("id").pivot("var").sum("value")

… rigen los siguientes términos de servicio (que traduzco, porque el original vienen en inglés):

Usuarios autorizados: usuarios afiliados a una institución educativa de investigación o sin ánimo de lucro.

Supongo que ese es el fin de la historia: estoy expulsado de ella, salvo que retuerza el hilo de la casuística, relaje el perímetro de las acepciones y me considere afiliado a alguna de las instituciones educativas donde imparto alguna clase; y justifique, claro está, que no tienen ánimo de lucro.

La solución que presenté el otro día para resolver el problema en cuestión, tal como indicó Iñaki Úcar, es demasiado aparatosa. La alternativa a mi propuesta

ssh -ND 2001 miusuario@datanalytics.com

y todo lo que sigue es crear un túnel ssh mediante

ssh -NL 2001:localhost:8787 miusuario@datanalytics.com

y conectarse a la sesión remota de RStudio apuntando en cualquier navegador a http://localhost:2001.

El comando anterior exige la debida exégesis, que nunca había tenido del todo clara. Lo que hace es, primero, crear una conexión entre mi ssh local, el ordenador en el que lanzo el comando, y mi ssh remoto (el servidor con nombre datanalytics.com). Eso es lo que verán los terceros: una conexión ssh entre dos máquinas.

Finalmente, instalé RStudio Server en la máquina que está sirviéndote esta página. Pero no dejo abierto el puerto 8787 al exterior ni jarto de vino.

(De hecho, veréis que desde hace un tiempo a este blog escucha en el puerto 443 y, aunque esa es otra historia, utiliza HTTP/2).

Así que lo he configurado para que solo se pueda acceder a él desde localhost, i.e., que no admita conexiones remotas, añadiendo la línea

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

Me llegan noticias de PyData Madrid 2016, que tendrá lugar en abril de este año en Madrid:

Os pongo un poco en contexto. Las PyData empezaron como conferencias de desarrolladores y usuarios de herramientas Python para trabajar con datos. Las primeras se hicieron en Silicon Valley, Nueva York, Londres,… Actualmente hay conferencias en NY, SV, Dallas, Seattle, Boston, Londres, Berlín, Amsterdam, París, Colonia, Tokio, Singapur,…, y Madrid. Como he comentado, empezaron un poco enfocadas en Python pero ahora están mucho más abiertas y se habla de Julia, Python, R, Scala,…