R

Pesos de los componentes del QualityScore en Google Ads

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.

offset, porque el coeficiente es 1 necesariamente

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

Sobre el agregador de noticias sobre R en español

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:

vecpart: modelización de moderadores con árboles

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

Modas y fotogenia del código secuencial

R

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.

Una cosa buena, una cosa mala

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.

Sr. Python, muchas gracias por su candidatura; ya le llamaremos cuando... tenga modelos mixtos

Era casi todavía el siglo XX cuando yo, desesperado por hacer cosas que consideraba normales y que SAS no me permitía, pregunté a un profesor por algo como C pero para estadística. Y el profesor me contó que conocía a alguien que conocía a alguien que conocía a alguien que usaba una cosa nueva que se llamaba R y que podía servirme.

Fue amor a primera vista, pero esa es otra historia. La relevante aquí es que volví a hablar con aquel profesor para agradecerle el consejo y, de paso, le pregunté que por qué no lo usaba él. Me contestó que porque en R no había modelos mixtos (aunque nlme es anterior, del 99; ¡a saber en qué estado se encontraba entonces!).

Demasiados colores (para el hijo de un daltónico)

R

Mi padre me enseñó muchas cosas (leer, sumar, etc.). Pero mi infancia fue monocromática porque era daltónico. Siempre dibujé con lápiz (primero) y tinta (después). Las témperas y los rotuladores fueron mi tormento.

R tiene colores. Un montón. Y paletas de colores. Demasiadas. Una búsqueda entre los paquetes disponibles actualmente en CRAN de color proporciona 88 coincidencias, a las que deben sumarse las 35 adicionales de colour. Algunos de esos paquetes se refieren a asuntos tales como “Optimal Block Designs for Two-Colour cDNA Microarray Experiments”, pero los más ofrecen cosas tales como:

¿Hay demasiados paquetes en R?

R

Por su importancia, traigo aquí y resumo una serie de argumentos que he encontrado en otra parte acerca del ecosistema de paquetes en R. Que son:

  • Muchos paquetes no tienen el soporte adecuado a medio plazo.
  • Además, hay demasiados.
  • Pero su calidad es desigual.
  • Y muchos reinventan la rueda (lo manifiesta la escasa interdependencia entre los paquetes).
  • Finalmente, no es para nada sencillo identificar el paquete que puede ser útil para un fin determinado.

Cada cual elige los problemas que quiere tener (y R decidió tener los de un bazar y no los de una catedral).

Evaluación de trucos para multiplicaciones aproximadas

En Street Fighting Mathematics (leedlo) hay un capítulo en el que se discuten trucos para realizar mental y aproximadamente operaciones del tipo 3600 × 4.4 × 10^4 × 32.

La recomendación es la siguiente: contar ceros primero, gestionar las cifras significativas después. En el caso anterior, el autor identifica 8 ceros (tres del 3600, cuatro del 10^4 y uno del 32), quedando como cifras significativas 3.6, 4.4 y 3.2.

Para estas últimas, recomienda aproximarlas a 1, pocos (alrededor de 3) y 10. Pocos es una cifra que vale tres y cuyo cuadrado es 10. Por lo tanto, 3.6 × 4.4 × 3.2 es el cubo de pocos, es decir, treinta. De manera que la aproximación de 3600 × 4.4 × 10^4 × 32 es un tres seguido de nueve ceros (en realidad, es un cinco seguido de nueve ceros).

El discreto encanto de las animaciones

Representando datos, una animación es un gráfico en el que unas facetas (en terminología de ggplot2) ocultan el resto, como en

extraído de aquí y que representa la evolución del tamaño (superficie) de los coches habituales a lo largo del último siglo. Lo mismo pero evitando el indeseado efecto:

El código:

library(ggplot2)

datos <- structure(list(year = c(1930L,
  1950L, 1960L, 1970L,
  1980L, 1990L, 2000L, 2010L, 2018L),
  width = c(1.45, 1.59, 1.54, 1.56, 1.64,
           1.67, 1.75, 1.76, 1.78),
  length = c(3.38, 4.02, 3.96, 3.89, 3.98,
           4, 4.18, 4.12, 4.23)),
  class = "data.frame", row.names = c(NA, -9L))

ggplot(datos, aes(xmin = 0, ymin = 0,
  xmax = length, ymax = width)) +
  geom_rect() +
  coord_fixed() +
  facet_wrap(~ year) +
  xlab("longitud (m)") +
  ylab("anchura (m)") +
  ggtitle("Evolución de la superficie\ndel coche 'promedio'")

data.tree: porque no todos los datos son tabulares

R

De acuerdo, casi todos los datos son tabulares. Digamos que el 90% de ellos. Pero muchos de ellos, no. Y data.tree es un paquete con muy buena pinta para manejar estructuras arborescentes de datos: véanse esta y esta viñeta.

Como no podía ser de otra manera, tiene funciones para recorrer, filtrar y podar los árboles de datos.

La aplicación gracias a la cual di con él es el paquete prof.tree, que es lo mismo que el Rprof de toda la vida… solo que mola más:

Siete años después, dejo la presidencia de la Comunidad R Hispano

R

Eso, que dejo la comunidad de la Comunidad R Hispano. Ocho años después, que ya son. La noticia, en todo caso, no es tanto que abandone la presidencia sino las circunstancias que me condujeron a ella. Noticias viejas, pero noticias al fin y al cabo, que sirven para entender por qué lo fui entonces y por qué dejo de serlo ahora.

La Comunidad R Hispano (por qué se llama así y no, como habría sido natural, Asociación Española de Usuarios de R, es una larga historia que tal vez cuente algún día) se fundó en Madrid hace ocho años en el seno de las III Jornadas de Usuarios de R (a todo esto, esa página la hice yo en html puro y con vi como editor), cuando la comunidad (informal) de usuarios de R ya llevaba un tiempo desarrollando actividades.