R

Frans van Dunné me ha hecho llegar su guía de estilo de programación en R. Abunda en otra creada por Google hace un tiempo y que traduje y adapté aquí.

Tiene como novedad, dice, su adaptación a las formas y maneras de Hadley Wickham, aún no tan conocido entonces. Coinciden, no obstante, en lo más.

Ninguna de las dos trata el uso las tuberías (operador %>%). Pero es un asunto que se nos puede ir de las manos: de hecho, hoy he conocido el paquete [backpipe](https://github.com/decisionpatterns/backpipe), que implementa %<% y que nos augura largas y desesperantes sesiones de depuración de código.

Suponemos que observamos rachas de longitud 2 + rpois(1, 10) de un juego en el que se tiene éxito (1) o se fracasa (0) con probabilidad 1/2. Nos interesa saber si existe eso de las rachas de suerte, es decir, si es más probable que a un éxito le suceda otro o lo contrario.

El observador ve rachas y calcula el número de veces que a un éxito le sigue un éxito y el número de veces que a un éxito le sigue un fracaso así:

En ocasiones, el conjunto de datos sobre el que se ajusta una regresión logística está desequilibrado con respecto a la población subyacente. Por ejemplo, puede suceder que la tasa de casos positivos en los datos sea del 20% mientras que en la población general es del 5%.

Esto puede suceder por varios motivos. El sobremuestreo es uno de ellos: se sobremuestrea cuando se toman, por ejemplo, todos los casos positivos y solo un subconjunto de los negativos.

Recomiendo leer Scalable Strategies for Computing with Massive Data, un artículo que trata dos de los problemas de escalabilidad con que tropezamos los usuarios de R:

• Los de memoria, para los que proponen e ilustran el uso del paquete bigmemory.
• Los de velocidad de ejecución, a los que se enfrentan paralelizando el código, tanto en una única máquina como en un clúster, con foreach.

En el artículo no solo discute los dos paquetes por separado sino que ilustra además cómo usarlos conjuntamente en su propuesta de estrategia escalable con R.

Vuelvo a lo de Casillas inspirándome en el primer ejemplo de este artículo de Gelman et al.

El planteamiento es el siguiente: el número de paradas, $n_i$, que realiza el $i$-ésimo portero tiene una distribución binomial

$$ n_i \sim B(N_i, p_i)$$

donde $N_i$ es el número de disparos entre los palos y $p_i$ es la habilidad innata del portero. Estas habilidades innatas siguen una distribución dada, la de habilidades innatas de los porteros de primera división, que podemos suponer que sigue una distribución beta

Rescato y reconvierto un comentario de mi buen amigo José Luis Cañadas en una entrada mía reciente en la de hoy.

Sugiere José Luis el uso del paquete effects de R para estudiar el efecto de (que el caso concreto de interés, aunque hay otros) las variables de un modelo logístico.

Nos copia el código

library(effects)
mod.cowles <- glm(volunteer ~ sex + neuroticism*extraversion,
    data = Cowles, family = binomial)
eff.cowles <- allEffects(mod.cowles,
    xlevels = list(extraversion = seq(0, 24, 6)),
    given.values = c(sexmale = 0.5))
plot(eff.cowles, type = "response")

que genera

Diríase que sí. La altura de un individuo está sujeta a multitud de factores que suman y restan. Está la genética (que es el resultado de la suma y resta del impacto de muchos genes individuales). Está la dieta, está… Diríase, insisto, que la altura es el promedio de muchos efectos pequeños y no demasiado dependientes entre ellos.

Y en efecto, (una vez descargados los microdatos de la Encuesta Nacional de Salud de 2011),

Los coeficientes de la regresión logística tienen una interpretación recta en términos de odds ratio. Que es un concepto sobre el que puede que alguien tenga algún tipo de intuición. Pero yo no.

¿Cómo podemos interpretar, aunque sea de manera rápida y grosera, los coeficientes? En términos de la variación de la probabilidad cuando la variable correspondiente cambia de valor (p.e., en una unidad). El problema es que la probabilidad depende del valor del resto de las variables: la relación no es lineal. No obstante, esa intuición es posible (en algunos casos: véase la nota).

Acaba de nacer el R Consortium con no sé qué objetivos. Los declarados son

trabajar con y dar soporte a la R Foundation y a las organizaciones clave que desarrollan, mantienen, distribuyen y usan R a través de la identificación, desarrollo e implementación de proyectos de infraestructura.

Vamos, nada que la R Foundation no viniese haciendo ya de oficio.

Solo que es probable que lo quieran hacer de otra manera. R se está volviendo demasiado importante, pensarán, como para que su desarrollo siga en manos de unos amateurs. Uso aquí el término en el sentido literal y no despectivo del término: estos amateurs son académicos de reconocido prestigio que hacen en su tiempo libre y con equipos informáticos que vete tú a saber a quién pertenecerán y dónde se alojarán las cosas que pretende hacer el consorcio.

foo <- function(df, column.name){
    if (!column.name %in% colnames(df))
      stop("Column ", column.name, " not found in ", deparse(substitute(df)))

    mean(df$column.name)  # por ejemplo
  }

  foo(iris, "petal.area")

Lanza el error

Error in foo(iris, "petal.area") : Column petal.area not found in iris

mucho más informativo gracias a deparse + substitute.