R

Aprovechando que el paquete GameTheoryAllocation ha emergido de mi FIFO de pendientes a los pocos días de conocerse los resultados de las [adjetivo superlativizado omitidísimo] elecciones generales, voy a calcular de la manera más naíf que se me ocurre el índice de Shapley de los distintos partidos. Que es:

Al menos, de acuerdo con el siguiente código:

library(GameTheoryAllocation)

partidos <- c(123, 66, 57, 35, 24, 15, 7, 7,
              6, 4, 2, 2, 1, 1)
names(partidos) <- c("psoe", "pp", "cs", "iu",
                      "vox", "erc", "epc", "ciu",
                      "pnv", "hb", "cc", "na",
                      "compr", "prc")

coaliciones <- coalitions(length(partidos))
tmp <- coaliciones$Binary

profit <- tmp %*% partidos
profit <- 1 * (profit > 175)

res <- Shapley_value(profit, game = "profit")

res <- as.vector(res)
names(res) <- names(partidos)
res <- rev(res)

dotchart(res, labels = names(res),
          main = "naive shapley index \n elecciones 2019")

Lo del índice de Shapley, de ignorarlo, lo tendréis que consultar por vuestra cuenta. Al menos, para saber por qué no debería usarse tan frecuentemente (en problemas de atribución, entre otros).

Fueron mis modelos favoritos un tiempo, cuando modelaba visitas y revisitas de usuarios a cierto malhadado portal.

Si las visitas fuesen aleatorias (en cierto sentido), tendrían un aspecto no muy distinto del que se obtiene haciendo

library(IHSEP)

suppressWarnings(set.seed(exp(pi * complex(imaginary = 1))))

tms <- simPois(int = function(x) .1, cens = 1000)
hist(tms, breaks = 100, main = "Proceso homogéneo de Poisson",
      xlab = "", ylab = "frecuencia")

Es decir,

o bien una distribución uniforme en el tiempo. Pero bien puede ocurrir que una visita incremente la probabilidad de otra inmediatamente después, por lo que las visitas tenderían a arracimarse en determinados momentos. Con el paquete [IHSEP](https://cran.r-project.org/package=IHSEP) de R pueden simularse (y ajustarse) este tipo de modelos. Por ejemplo,

suppressWarnings(set.seed(exp(pi * complex(imaginary = 1))))
runif(1)
#[1] 0.4866672
set.seed(-1)
runif(1)
#[1] 0.4866672

Coda: ¿De qué si no creéis que iba esto?

Uno de mis proyectos permanentemente pospuestos es el del análisis de textos muy cortos. Se citarán Twitter y similares, aunque el € está en otros sitios, como los mensajes asociados a transferencias bancarias, reseñas o keywords.

Pero parece que no soy el único interesado en el tema. Otros con más tiempo y talento han desarrollado BTM, que parece ser una versión modificada de LDA para el análisis de textos cortos.

El artículo en el que está basado el paquete también es una buena referencia de técnicas y trucos cuando toca analizar este tipo de conjuntos de datos.

El llamado QualityScore tiene su relevancia en Google Ads. Es un indicador con valores entre 1 y 10 asignado por Google que se basa en tres variables que están descritas por ahí:

• PostClickQualityScore
• SearchPredictedCtr
• CreativeQualityScore

Se trata de variables categóricas con tres niveles: en / por encima de / por debajo de la media.

Haciendo

modelo <- lm(QualityScore ~ PostClickQualityScore +
    SearchPredictedCtr + CreativeQualityScore,
    data = tmp)

summary(modelo)

se obtiene

Call:
lm(formula = QualityScore ~ PostClickQualityScore + SearchPredictedCtr +
    CreativeQualityScore, data = tmp)

Residuals:
        Min       1Q   Median       3Q      Max
-0.25003 -0.07395  0.00775  0.06344  0.86470

Coefficients:
                                    Estimate Std. Error t value Pr(>|t|)
(Intercept)                        1.079603   0.008688   124.3   <2e-16 ***
PostClickQualityScoreAVERAGE       2.114012   0.009037   233.9   <2e-16 ***
PostClickQualityScoreABOVE_AVERAGE 3.856228   0.008448   456.5   <2e-16 ***
SearchPredictedCtrAVERAGE          1.137396   0.003284   346.4   <2e-16 ***
SearchPredictedCtrABOVE_AVERAGE    3.055694   0.004707   649.2   <2e-16 ***
CreativeQualityScoreAVERAGE        0.999580   0.004274   233.9   <2e-16 ***
CreativeQualityScoreABOVE_AVERAGE  2.000725   0.003862   518.1   <2e-16 ***
---
Signif. codes:  0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 0.1574 on 11426 degrees of freedom
Multiple R-squared:  0.9915,	Adjusted R-squared:  0.9915
F-statistic: 2.212e+05 on 6 and 11426 DF,  p-value: < 2.2e-16

Que no merece mayor explicación. Creo.

Estos días me han preguntado sobre un modelo lineal tal que $latex y \sim x_1 + \dots$ donde el coeficiente de $latex x_1$ no se entiende si no es igual a 1. Es como si los datos se creasen de la forma

n <- 100
x1 <- rnorm(n)
x2 <- rnorm(n)
y <- x1 + rnorm(n, .1) + .02 * x2

y se conociese el coeficiente de $latex x_1$ y no el de $latex x_2$. Entonces no tiene sentido plantear el modelo

lm(y ~ x1 + x2)

sino más bien

Aprovecho que acabo de actualizar mi agregador de noticias sobre R en español para escribir este recordatorio.

La cosa es que hace ya un tiempo (¡lo anuncié en 2010!) creé una programita que rastrea una serie de blogs que publican cosas sobre R, extrae los corresondientes RSS, selecciona las entradas que tratan sobre R y:

• Crea un RSS combinado que guarda aquí (para los que aún uséis RSS, claro).
• Publica esas entradas en una cuenta específica de Twitter, @noticiasSobreR.

¿Para qué, pues, este recordatorio? Para dos cosas:

En un GLM (aún más generalizado que la G de las siglas) puede haber coeficientes moderados. Usando una terminología muy ad hoc, en el modelo pueden entrar predictores y moderadores. Lo cual quiere decir que la parte lineal puede ser de la forma

$$\sum_i X_i \beta_i(Z_i),$$

donde las $latex X_i$ son los predictores propiamente dichos y las variables $latex Z_i$ son moderadoras, es decir, que modifican el efecto de los predictores a través de una función arbitraria $latex \beta_i$.

Este tipo de programación se puso de moda en los noventa:

Y yo decía: ¿dónde están mis bucles? ¿Y mis bifurcaciones?

Este tipo de programación está de moda últimamente:

hourly_delay <- flights %>%
  filter(!is.na(dep_delay)) %>%
  group_by(date, hour) %>%
  summarise(
    delay = mean(dep_delay),
    n = n() ) %>%
  filter(n > 10)

Y todo bien, sí, pero sigo sin tener bucles o bifurcaciones.

Tal vez no hagan falta. Al menos, para cosas de andar por casa. Pero, lo confieso, el código de verdad que escribo está lleno de casos especiales, comprobaciones de todo tipo de contingencias, reglas que aplican a unas columnas sí y otras no, objetos complejos (p.e., listas), que se van rellenando de una u otra manera dependiendo de las opciones del usuario y otras enojosas coyunturas muy reñidas con la elegancia.

Que son la misma: esta.

Comienzo por lo malo: ¿realmente necesitamos 17+1 INEs publicando la vistas de la misma información a través de 17+1 APIs, 17+1 paquetes de R y (17+1)*N mantenedores y desarrolladores?

Lo bueno: tiene buena pinta y es encomiable tanto el esfuerzo de los autores como su vocación de servicio público.

Nota: Espero que no enfaden demasiado el 50% de los juicios que he emitido a quien me ha enviado el enlace para su evaluación y posible difusión. Sepa que lo tengo en grande estima y que me consta responsable de mucho de la parte buena y casi nada de la mala.