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.

Estos días he estado haciendo de campaña promoviendo el uso de nuevas técnicas de análisis de datos en ámbitos como, p.e., el riesgo de crédito, uno de esos campos sujetos al parecer de un regulador (el Banco de España, en este caso).

La gente con la que he debatido al respecto tiende a aplicar esa forma cuasiperfecta de censura que es la autocensura previa. La autocensura previa ni siquiera requiere la acción explícita del censor: es el potencial censurado el que la aplica de mejor o peor gana automáticamente… por si las moscas.

Imaginemos un banco que construye modelos para determinar si se concede o no un crédito. Este banco tiene varias opciones para crear el modelo. Sin embargo, en algunos países el regulador exige que el banco pueda explicar el motivo de la denegación de un crédito cuando un cliente lo solicite.

Esa restricción impediría potencialmente usar modelos de caja negra como el que construyo a continuación:

library(randomForest)

raw <- read.table("http://archive.ics.uci.edu/ml/machine-learning-databases/credit-screening/crx.data",
    sep = ",", na.strings = "?")

dat <- raw
dat$V14 <- dat$V6 <- NULL    # me da igual
dat <- na.omit(dat)          # ídem

modelo <- randomForest(V16 ~ ., data = dat)

Fijémonos en el sujeto 100, a quien se le deniega el crédito (suponiendo, ¡mal hecho!, que el punto de corte de la probabilidad para concederlo es el 50%), y la variable $V8$. Podemos ver cuál sería el score del cliente modificando esa variable entre su valor real y el máximo del rango dejando las demás tal cual:

El telón de Aquiles del big data es el sesgo. Me gustaría hablar más de ello, pero me agarra de la pluma uno de esos NDAs. Así que hablaré de otra cosa.

Si le preguntas a la gente cuántos hermanos son en la familia, el promedio del resultado tenderá a ser superior al número medio de hijos por familia. Esencialmente, porque no estás muestreando familias sino hijos. El tautológico hecho de que las familias con más hijos tengan más hijos hace que estén sobrerrepresentadas en la muestra.

Es

$$ \sum_i \Phi(y_i, f_1(x_i)) > \sum_i \Phi(y_i, f_1(x_i) - \lambda \nabla \Phi(y_i, f_1(x_i)) \sim$$ $$ \sim \sum_i \Phi(y_i, f_1(x_i) - \lambda f_2(x_i))$$

Por supuesto, el lector se preguntará muchas cosas, entre las que destaco:

• ¿Qué representa cada uno de los elementos que aparecen en la línea anterior?
• ¿Qué parte de ella es solo casi siempre cierta?
• ¿Qué tiene todo eso que ver con GBM?

… (por motivos que importan pero no debo revelar a mis lectores) aprovecho para criticar a esos tipos que, vistiendo como yo, insisten reiteradamente a sus analistas en que les proporcionen un número. Un número que tiene que ser cerrado, indiscutible, pivotal.

A esos que gastan traje y corbata como yo hoy les horroriza la varianza. Le espantan, seguro, esos punticos que tan opotunamente coloca Kiko Llaneras alrededor de las medias de este estupendo

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

Que es una manera de matizar

Porque, recordemos,

• no solo con datos tomamos decisiones informadas: las prioris (experiencia cuantificada) tienen su importancia
• no podemos obtener datos que justifiquen todas, todas, todas las decisiones.

Leyendo por ahí, he encontrado un comentario sobre el paquete RJSONIO de R en el que se recomendaba no usarlo por no ser libre.

El paquete, aparentemente, está liberado bajo una licencia BSD. Pero su pecado es que dentro de uno de los ficheros que contiene, src/JSON_parser.c, dice

The Software shall be used for Good, not Evil.

Más información, aquí.

No sé qué pensar sobre toda esta historia.

En varias de las ediciones de las Jornadas de Usuarios de R he formado parte del comité organizador, que se encarga, fundamentalmente, de la logística de la cosa. Este año, para variar, estoy en el comité científico.

Como integrante del cual, es labor mía tratar de animaros a que enviéis alguna propuesta de participación, que puede tener alguno de los siguientes formatos:

• Una presentación de unos 20 minutos, mostrando alguna aplicación de R. Y no necesariamente en el mundo académico. Son también bienvenidas y apreciadas las aplicaciones en empresas e instituciones de  todo tipo. De hecho, una de las presentaciones más recordadas del año pasado, la de Antonio Sánchez Chinchón, trató de aplicaciones ludicomatemáticas de R.
• Un taller (típicamente de 2 horas) para enseñar a utilizar alguna herramienta particular de R. En el pasado las ha habido de mapas, de gráficos, de Spark… ¡y recuerdo uno sobre plyr y reshape2 que impartí en 2010 cuando esos paquetes eran una novedad y una rareza!

Hay tiempo hasta el primero de mayo para realizar las propuestas. Los detalles pueden consultarse aquí.