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

caRtociudad es esto.

Más noticias habrá.

Las funciones de densidad log-cóncavas son aquellas cuyo logaritmo es una función cóncava. Por ejemplo, la normal: el logaritmo de su función de densidad es, constantes aparte, $-x^2/2$.

El producto de dos funciones de densidad log-cóncavas es log-cóncava: $\log(fg) = \log f + \log g$ (y la suma de cóncavas es cóncava: calcula la segunda derivada). También lo son la suma de dos variables aleatorias cuyas funciones de densidad lo son (la demostración es consecuencia de esta desigualdad).

Voy a constuir unos datos artificiales y un modelo de clasificación binaria,

library(mgcv)
library(ggplot2)
library(pROC)

n <- 10000
dat <- gamSim(1, n=n, dist="binary", scale=.33)

lr.fit <- gam(y ~ s(x0, bs="cr") +
    s(x1, bs="cr") + s(x2, bs="cr") +
    s(x3, bs="cr"),
    family=binomial, data=dat,
    method="REML")

y luego (mal hecho: debería hacerlo sobre un conjunto de validación distinto) a obtener las predicciones para las observaciones

res <- data.frame(real = factor(dat$y),
    prob = predict(lr.fit, type = "response"))

que

ggplot(res, aes(x=prob, fill=real)) +
    geom_density(alpha=.3)

representa así:

Me pregunto si el clasificador construido es bueno. Para lo cual voy a construir la curva ROC con

Imaginemos que queremos muestrear una variable aleatoria cuya función de densidad es (proporcional a) el producto de otras dos (no necesariamente propias). Por ejemplo, la gamma, cuya función de densidad es $K x^{k-1} \exp(-\lambda x)$, el producto de una exponencial y una distribución impropia con densidad $x^{k-1}$.

Supongamos que no sabemos hacer

set.seed(1234)
shape <- 3
rate  <- 3
m0 <- rgamma(1000, shape = shape, rate = rate)

Pero supongamos que sí que sabemos muestrear la distribución exponencial, lo que permite escribir:

Durante la charla de Carlos Ortega del pasado jueves sobre el paquete caret y sus concomitancias, se planteó el asunto de la optimización de los parámetros de un modelo usando rejillas (grids) de búsqueda.

Cuando un determinado algoritmo depende de, p.e., cuatro parámetros, se puede definir una rejilla como en

gbmGrid <-  expand.grid(interaction.depth = c(1, 5, 9),
      n.trees = (1:30)*50,
      shrinkage = 0.1,
      n.minobsinnode = 20)

y caret se encarga de ajustar el modelo bajo todas esas combinaciones de parámetros (90 en el ejemplo) para ver cuál de ellas es, con las debidas salvedades, óptima.

Sí, de drogas de las que mantienen despierto al lumpenazgo. Porque he encontrado (aquí) un conjunto datos muy interesante sobre la valoración que una serie de personas, unas 900, da a una serie de drogas más o menos legales que se llaman —me acabo de enterar— nootrópicos.

El gráfico

extraído de la página enlazada más arriba resume parte de los resultados. No obstante, es sabido entre los que se dedican a los sistemas de recomendación que hay usuarios que tienden a valorar sistemáticamente por encima de la media y otros, por debajo. En los manuales de la cosa suelen recogerse mecanismos más o menos sofisticados para mitigar ese efecto y normalizar las valoraciones entre usuarios. Generalmente, solo exigen matemáticas de bachillerato. Y son meras aproximaciones que no tienen en cuenta circunstancias tales como que puede que un usuario da valoraciones bajas solo porque evalúa productos malos, etc.

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: