Programación

Echadle un vistazo a Syberia (y me contáis qué tal os va). Tiene muy buena pinta y puede ser útil para produccionalizar código.

[Esto es casi todo; lo que sigue es omitible.]

Sin embargo y sin que necesariamente haga desmerecer a Syberia como tal, en la página arriba enlazada se lee:

In the viewpoint of the author, R is syntactic sugar around LISP, which enables arbitrary computation; Syberia is an attempt to support this conjecture by allowing the construction of arbitrary software projects within the R programming language, thereby finally outgrowing its long-overdue misconception as a statistical tool.

Tuve ocasión el pasado jueves, en Barcelona y gracias a la invitación de KSchool, de lo que llamo el stack analítico. Es decir, de aquellas herramientas tecnológicas necesarias para poder hacer ciencia de datos hoy en día.

Las diapositivas de la charla están aquí.

El tema es viejo pero no por ello menos urgente: existen herramientas (y, desgraciadamente, me he visto a incluir el saber leer documentación técnica en inglés) cuyo conocimiento es imperativo para poder trabajar de manera efectiva en ciencia de datos. Incluidos están sistemas operativos (dencentes), editores de texto (decentes) e IDEs y, como poco, un lenguaje de programación.

En serio, es así. ¿También if? Pues también. De hecho,

`if`(1 == 3, print("a"), print("b"))

Y eso permite, por ejemplo, que funcionen expresiones tales como

a <- if (1 == 3) 4 else 5

tan útiles como poco empleadas en general. También son funciones (, { y otras que aparecen en la sección .Internal vs .Primitive del documento R Internals.

Nunca me he visto en la tesitura de tener que usar callbacks porque no son mi guerra. Pero por lo que he oído de la gente que sabe mucho más que yo, son uno de esos infiernos de los que hay que huir con el mismo pavor que de los fors, los ifs, los elses (¡argggg! ¡he escrito else!) y los whiles.

Una pequeña maravilla teórica que me ha hecho replantearme la absoluta inutilidad de aquello que estudié en Álgebra III (funtores y demás) son las mónadas.

Estuve el otro día en una charla de José Luis Cañadas en el grupo de usuarios de R de Madrid sobre sparklyr. Hoy en otra de Juan Luis Rivero sobre, esencialmente, lo mismo, pero esta vez con Python. Y podría escribir “etc.”.

Me centraré en la de José Luis, aunque podría decir lo mismo de cualquiera de las otras. No había trabajado con sparklyr. No soy siquiera fan de dplyr (aunque no es que no se lo recomiende a otros; es simplemente, como tantas cosas, que soluciona problemas que no tengo). Pero la seguí sin mayores problemas. Lo que tenía de nuevo era una fina, somera capa de sintaxis que enlazaba fundamentos con fundamentos.

Es:

• Nivel 1: Realizan la mayor parte de su trabajo con herramientas ofimáticas (fundamentalmente Excel), aunque pueden utilizar puntualmente Eviews, Stata, R o Matlab.
• Nivel 2: Los que realizan la mayor parte de su trabajo con R, Python, SAS o SQL pero cuyo sistema de control de versiones es el de ficheros con determinadas convenciones de nombres.
• Nivel 3: Como el anterior, pero usando control de versiones, estilos de código, y revisión por pares (peer review).
• Nivel 4: Como el anterior, pero incorporando métodos propios de la ingeniería de software como el unit testing, documentación integrada, release cycles, etc.

Lo anterior está traducido de Why you need version control, que habla de eso y más. Léelo.

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:

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