Paquetes

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

Nunca he sido muy partidario de esas técnicas a medio camino entre lo descriptivo (con descripciones que apenas nadie entiende) y lo inferencial (con inferencias que pocos se creen). Entre ellas, MDS (multidimensional scaling). Pero este fin de semana y por exigencias del guión (¿se acentúa guión aún?) he tenido que replicar unos análisis en que se usaba NMDS a la vegan.

Seré breve y me limitaré a definir el problema, enlazar una referencia con código y una discusión mejor que la mía y a mostrar una de las representaciones que uno podría llegar a construir.

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:

Son paquetes que marcado como potencialmente relevantes pero que aún no he revisado como debiera. Tal vez alguien tenga algo más que decir sobre ellos. Tiene los comentarios, por supuesto, abiertos.

longRPart2: Particionamiento recursivo para modelos longitudinales. Extiende ctree y, por supuesto, mob del paquete party a datos de tipo longitudinal.

radiant: Más que un paquete, es un conjunto de paquetes para business analytics usando R y Shiny. Ni idea de para qué parte de ese amplio campo del business analytics puede resultar útil, pero si resulta que es precisamente el tuyo, ¡enhorabuena!

Escribiendo la entrada del otro día sobre embeddings, no se me pasó por alto que la fórmula

$$ \frac{P(W_i,C_i)}{P(W_i)P(C_i)}$$

que escribí en ella es análoga al llamado lift (¿es el lift?) del llamado análisis del carrito de la compra, i.e., el estudio de productos que tienden a comprarse juntos (véase, por ejemplo, esto).

Lo cual me lleva a sugerir mas no escribir una entrada en la que se rehagan este tipo de análisis usando embeddings: los ítems como palabras, los carritos como textos, etc. Si alguien tiene tiempo y le sale algo potable, que avise y lo enlazo aquí.

Existe un paquete muy curioso en CRAN, rSARP para diseñar, optimizar y comunicar la evolución de planes de búsqueda y/o rescate (p.e., de un niño desaparecido en un monte).

Es particularmente interesante porque este tipo de problemas lo tienen todo: desde distribuciones a priori (sobre dónde es más probable encontrar lo que se busca) hasta la decisión final (explórese tanto aquí y tanto allá) teniendo en cuenta restricciones de tiempo y recursos.

Hace un tiempo quise hacer cosas malísimas con datos fiscales de España y Dinamarca. Pero los datos estaban histogramizados:

Gracias a Freakonometrics di con binequality. Adaptando su código, escribo

library(rvest)
library(plyr)

dk <- read_html("http://www.skm.dk/english/facts-and-figures/progression-in-the-income-tax-system")
tmp <- html_nodes(dk, "table")
tmp <- html_table(tmp[[2]])

header <- tmp[1,]
tmp <- tmp[-c(1, 2),]
colnames(tmp) <- header

# elimino declaraciones negativas
tmp <- tmp[-1,]

# elimino el total
tmp <- tmp[-(nrow(tmp)),]

colnames(tmp) <- c("rango", "contribuyentes",
    "X1", "income", "tax1", "tax2", "pct")

irpf_dk <- tmp[, c("rango", "contribuyentes",
    "income", "tax1", "tax2")]

irpf_dk$contribuyentes <- as.numeric(irpf_dk$contribuyentes)
irpf_dk$income <- as.numeric(irpf_dk$income)
irpf_dk$tax1 <- as.numeric(irpf_dk$tax1)
irpf_dk$tax2 <- as.numeric(irpf_dk$tax2)

irpf_dk$tax <- irpf_dk$tax1 + irpf_dk$tax2
irpf_dk$tax1 <- irpf_dk$tax2 <- NULL
irpf_dk$pct <- irpf_dk$tax / irpf_dk$income


irpf_dk$desde <- c(0, 25, 50, 75, 100, 125, 150,
    200, 250, 300, 350, 400, 500, 750, 1000)
irpf_dk$hasta <- c(irpf_dk$desde[-1], Inf)

irpf_dk$desde <- irpf_dk$desde / 7.44
irpf_dk$hasta <- irpf_dk$hasta / 7.44
irpf_dk$income <- irpf_dk$income / 7.44
irpf_dk$tax    <- irpf_dk$tax / 7.44

irpf_dk$mean_income <- irpf_dk$income /
        irpf_dk$contribuyentes * 1000

irpf_dk$rango <- NULL

para bajar y preprocesar los datos y después

Hace un par de días hablé de la falacia del fiscal y granos de arroz. La entrada iba acompañada de

y la lección era: es raro no encontrar ningún clúster cuando se tiran al azar granos de arroz sobre una superficie. De lo que se derivaban más cosas que es ocioso repetir aquí.

Pero el gráfico no es desconocido para los viejos del lugar: se parece mucho al de la página 319 de ESL. Para los que no lo tengáis a mano, la parte donde se habla de un algoritmo que se llama igual que un general de Reus con calle en Méjico DF: PRIM.

Un motif es un patrón que se repite en una serie temporal:

Para saber más sobre ellos, p.e., Finding Motif Sets in Time Series. Y para identificarlos con R, STMotif.

La función stl (véase aquí un ejemplo de uso). Pero tiene sus limitaciones.

El paquete stR la extiende y permite, entre otras cosas, introducir distintos tipos de estacionalidades (p.e., anuales y semanales).

La codificación de las variables categóricas en problemas de clústering es la fuente de la mayor parte de los problemas con que se encuentran los desdichados que se ven forzados a aplicar este tipo de técnicas.

Existen algoritmos que tratan de resolver el problema sin necesidad de realizar codificaciones numéricas. kamila es un paquete de R que implementa uno de ellos. El artículo que lo acompaña, A semiparametric method for clustering mixed data aporta los detalles, que en resumen son:

Mi paquete MicroDatosEs ya forma parte de rOpenSpain. Sin embargo, está falto de ciertas mejoras a las que aspiran los paquetes que forman parte de dicho repositorio.

Una de ellas es la de migrar la documentación del paquete a roxigen2. Lo podría hacer yo, pero es muy aburrido. Sin embargo, entiendo que puede ser entretenido (además de sencillo) para alguien que:

• No sepa de qué va eso de roxigen2 pero me tome la palabra en eso de que es importante.
• No sepa mucho de cómo va git, GitHub, etc. pero me tome la palabra en eso de que es importante.
• Quiera disfrutar de una oportunidad real y significativa de aprender practicando.
• Quiera aparecer en la lista de contribuyentes a dicho paquete.

Así que si alguien está dispuesto a pasar unas cuantas horas aprendiendo, que avise y le cuento cómo proceder. Eso sí, por simplificar, va a ser uno y no más.

Uno de los modelos más útiles potencialmente y que menos atención recibe es el de los modelos de conteos autoexcitados. Es decir, aquellos en los que un evento incrementa durante cierto tiempo la probabilidad de que ocurra otro. Creedme, ocurre así muy a menudo en muchas aplicaciones.

Por eso se pone uno muy contento cuando descubre paquetes de R como este.

Pero el hecho de que unos académicos lo hayan creado y puesto ahí por mor de las neonormas (administrativas, morales o de señalamiento) de reproducibilidad, no significa que lo hayan desarrollado para los usuarios finales. O pensando en ellos.