Python

DataSynthesizer (véase también el correspondiente artículo) es un programa en Python que:

1. Toma una tabla de datos (microdatos, de hecho) que contiene información confidencial.
2. Genera otra aleatoria pero que conserva (¿los conservará?) la estructura básica de la información subyacente (conteos, correlaciones, etc.).

Está pensado para poder realizar el análisis estadístico de (determinados) datos sin verlos propiamente.

Particularmente interesante es el algoritmo para preservar la correlación entre columnas.

[Nota: he aprovechado la entrada para acuñar el neologismo microdatado para referirme a quien figura en un fichero de microdatos.]

El título, no el de esta entrada sino el de A Comparison of Programming Languages in Economics, es una sinécdoque confusa.

Que nadie busque en él consejo sobre qué lenguaje estudiar si le interesa el mundo de la economía (en general). O fuera de ella (también en general).

Encontrará más bien la implementación de la solución a un único problema dentro de los muchos que supongo comprende esa disciplina. Uno, además, con el que no he visto (en persona) a economista alguno ganarse el pan ni en la academia ni fuera de ella.

Hoy he visto

aquí y he escrito

m <- matrix(c(74, 15, 10, 1, 11, 50, 38, 1,
            5, 4, 90, 1, 17, 4, 19, 60),
            4, 4, byrow = TRUE)
m <- m / 100

luego

m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m%*% m%*% m%*% m%*% m%*% m%*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m %*% m%*% m%*% m%*% m%*% m%*% m%*% m
#          [,1]      [,2]      [,3]       [,4]
#[1,] 0.1926676 0.1133218 0.6696203 0.02439024
#[2,] 0.1926647 0.1133206 0.6696245 0.02439024
#[3,] 0.1926638 0.1133202 0.6696258 0.02439024
#[4,] 0.1926675 0.1133218 0.6696205 0.02439025

y finalmente

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.

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.

Supongo que a estas alturas todos conoceréis feather y rPython. Hoy los vais a ver trabajar juntos.

Primero solo en R:

library(feather)
path <- "/tmp/my_data.feather"
write_feather(cars, path)
my_cars <- read_feather(path)

Ahora, para pasarle datos a Python:

library(rPython)
python.exec("import feather")
python.exec("a = feather.read_dataframe('/tmp/my_data.feather')")
python.exec("print a")

Y, finalmente, para crear datos grandes en Python y devolvéselos a R:

python.exec("import numpy as np")
python.exec("import pandas as pd")
python.exec("arr = np.random.randn(10000000)")
python.exec("arr[::10] = np.nan")
python.exec("df = pd.DataFrame({'column_{0}'.format(i): arr for i in range(10)})")
python.exec("feather.write_dataframe(df, '/tmp/test.feather')")

python.data <- read_feather("/tmp/test.feather")
dim(python.data)
#[1] 10000000       10

Los tiempos, que los mida cada cual.

Ayer, después de mucho tiempo, perdí horas de sueño enredando con Jupyter. Y mi sensación fue la misma que hace un año: está bien para presentaciones, cursos y en definitiva, contenido cerrado y estructurado que para el cacharreo diario. ¡Echo en falta un lugar en el que equivocarme reiteradamente!

En RStudio, al menos, dispongo de la consola y de algún programa que uso como espacio de borrador. En Jupyter me siento como obligado a comportarme como esos niños repelentes que tomaban apuntes directamente a limpio.

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,…

Un usuario de rPython, David González Knowles, me ha facilitado su código para pasar una tabla, iris en este caso, de R a una tabla de pandas en Python usando mi paquete.

En R hay tablas de serie. En Python no. La librería pandas de Python implementa algo parecido a los data.frames. Solo que nada garantiza que un usuario de Python la tenga instalada. Por eso no hay un formato de destino claro y universal para las tablas de R a través de rPython. Y por eso, en Python, si se tiene pandas instalado, el usuario tiene que hacer algo, lo siguiente:

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

Nota: publico hoy en inglés en atención al público potencial de la entrada.

rPython lets R users call Python code. Anaconda is a completely free enterprise-ready Python distribution for large-scale data processing, predictive analytics, and scientific computing. Not surprisingly, some users want to call Anaconda Python rather than their system’s default Python.

However, Anaconda is a very particular package: unlike most other packages, whose files are scattered in a diversity of locations, it is self contained in a single directory. This helps Anaconda solve some problems, like the library hell. It is intended to provide the same experience regardless of the specifics of the host system.

Quien escribió Call matplotlib from R podía haberse ahorrado bastante trabajo de la peor especie (programación de bajo nivel con C++) leyendo los benditos manuales (de rPython, en este caso).

Le bastaba hacer

library(rPython)

x <- seq(0, 2*pi, length = 100)
sx <- sin(x)
cx <- cos(x)

python.assign("x", x)
python.assign("sx", sx)
python.assign("cx", cx)

python.exec("import matplotlib.pyplot as plt")

python.exec("plt.rcParams.update({'figure.figsize' : (7,4)})")
python.exec("plt.plot(x, sx)")
python.exec("plt.plot(x, cx, '--r', linewidth=2) ")
python.exec("plt.legend(('sin(x)', 'cos(x)'))")
python.exec("plt.savefig('2015-04-02-pyplot.png')")

para obtener

con una fracción del esfuerzo y sin reinventar la rueda.

Acabo de subir a Github una nueva versión de rPython-win, que soluciona uno de mis bugs históricos: ha pasado tanto tiempo en estado “pendiente” que casi le cojo cariño. Tiene (o tenía) que ver con particularidades no documentadas de las APIs para C de Python en distintas versiones de Windows y creo que no afecta al paquete en otras plataformas.

Y aprovechando que el Pisuerga pasa por Valladolid, un enlace: Calling Python from R with rPython.