R

Hace unos días se publicaron los resultado de la cuarta encuesta anual de minería de datos realizada por Rexer Analytics en la que 735 participantes de 60 países completaron sus 50 preguntas. Los hechos más relevantes que contiene son:

• La principal aplicación de la minería de datos (siempre pienso que desgraciadamente) es en el campo de la gestión (o inteligencia) de clientes, lo que por ahí denominan CRM.
• Los algoritmos más usados por los encuestados han sido árboles de decisión, regresión y análisis de conglomerados.
• En cuanto a las herramientas, la más utilizada es R. El 43% de los encuestados afirmaron haberlo usado. Sin embargo, como herramienta básica de trabajo, la más usada parece ser STATISTICA, usada por un 18% de los encuestados. Las herramientas mejor valoradas fueron STATISTICA, IBM SPSS Modeller y R.
• La mayor parte del análisis siguie realizándose en ordenadores personales, con los datos almacenados en local. Lo mismo ocurre a la hora de realizar el scoring. Los usuarios que más utilizan PMML son quienes emplean STATISTICA.

Y más detalles pueden descargarse de la página de la encuesta.

Me llegó el otro día información acerca de un curso sobre métodos para afrontar el problema planteado por los valores no informados (missing observations) que su autor agrupaba bajo etiquetas bastante simpáticas: el bueno, el malo y el impensable. Tal vez faltaba el feo, tal vez porque lo son todos ellos, igual que el bendito problema que suponen. Añadía, sin mayores abundamientos, que

• explicaría cómo la solución común es en general la peor;
• mostraría por qué cierta solución sencilla, relativamente común y con mala fama no es habitualmente tan mala, explicando, además, cuáles son las situaciones en las que funciona y no funciona e
• indicaría dos soluciones que proporcionan resultados insesgados, una de las cuales es sencilla de implementar pero sólo funciona en ciertas circunstancias y la otra, aunque más complicada, funciona siempre.

Es un planteamiento un tanto comercial y no exento de gancho. Sin embargo, para el interesado en estos temas, traigo a colación dos artículos que ofrecen dos perspectivas algo distintas sobre este problema. El primero es una panorámica de procedimientos y herramientas existentes para encarar el problema de los valores no informados (en el contexto del análisis de la regresión, pero fácilmente extrapolables a otros similares), _Much Ado About Nothing: A Comparison of Missing Data Methods and Software to Fit Incomplete Data Regression Models _. El segundo es un informe de la Agencia Europea del Medicamento, Guideline on Missing Data in Confirmatory Clinical Trials, que sostiene una postura razonablemente paranoica al respecto (resumidamente: en caso de duda, siempre la solución más conservadora).

Busco alpha testers para mi paquete rPython. El paquete es la evolución natural de rJython, un paquete de R que permite llamar a Jython, el dialecto de Python que corre sobre la máquina virtual de Java, desde R.

rPython permite llamar al verdadero Python. Funciona perfectamente en mi máquina, pero necesito ver qué problemas de instalación y uso aparecen en otras plataformas. De momento, sólo funcionaría sobre plataformas UNIX o Linux. Me sorprendería lo indecible que funcionase también sobre Windows: sería toda una casualidad.

Me complace anunciar la subida a CRAN de la versión 0.7 del paquete colbycol.

La diferencia esencial con respecto a la anterior es:

• Utiliza el paquete filehash para crear el objeto que almacena los datos en disco.
• Incorpora algunas mejoras de uso sugeridas por los usuarios que facilitan la manipulación de los datos.

Espero poder publicar un estudio comparado del rendimiento en los próximos días.

Desde esta bitácora hemos seguido atentamente el a veces espinoso asunto del rendimiento de R. De ello es muestra entradas como ésta. Por eso retomamos el asunto para comentar desde una óptica distinta un análisis publicado hace un mes cuyo autor estudia la ineficiencia de funciones básicas como la media y otras similares.

Y llega a conclusiones que no es necesario manifestar explícitamente a quien ejecute esto en R:

x <- rnorm(50000)

foo.mean <- function(){ mean(x) }
foo.mean.int <- function(){ .Internal(mean(x)) }
foo.sum  <- function(){ sum(x) / length(x) }

system.time(tmp <- replicate(10000, foo.mean()))
system.time(tmp <- replicate(10000, foo.mean.int()))
system.time(tmp <- replicate(10000, foo.sum()))

Efectivamente, la media es lenta: pierde mucho tiempo en comprobaciones, revisando opciones y casos particulares. Además, es una función genérica que tiene que encontrar el método adecuado. Todo eso supone, efectivamente, un sobrecoste.

El otro día di con una entrada en una bitácora con cinco consejos para utilizar R en producción. Cuatro de ellos son razonables:

• Crear un sistema de validación, monitorización y alertas. Y, en particular, desarrollar un mecanismo para que R notifique los problemas encontrados por correo electrónico. En la entrada original hay código que puede utilizarse para tal fin.
• Usar la función sink para facilitar la detección y corrección de los errores.
• Usar Linux de 64 bits con mucha, mucha memoria. Aunque el autor de la entrada que comenta no lo diga, añado yo de mi cosecha que es conveniente utilizar rm y gc explícitamente cuando dejen de utilizarse objetos voluminosos para eliminarlos más satisfactoriamente y facilitar labor del recolector de basura.
• Usar sentencias tryCatch.

El último de los consejos del autor es más cuestionable: utilizar —más bien se refiere a reescribir— tus propias funciones. Pone como ejemplo la función glm, que no tiene mucho éxito de crítica, al parecer.

Imagine que le proponen participar reiteradamente en un juego de azar. Dispone de una cantidad de dinero inicial, $latex a$ euros, y puede apostar en un juego en el que o gana con probabilidad $latex p$ $latex b$ veces la apuesta o la pierde enteramente. Puede repetir el juego cuantas veces quiera  y apostar el porcentaje que desee de su dinero.

¿Cuánto se apostaría? ¿Qué porcentaje de su capital inicial se jugaría?

Sin ir más lejos, cojamos el primer ejemplo que aparece en ?ls, es decir,

ctl <- c(4.17,5.58,5.18,6.11,4.50,4.61,5.17,4.53,5.33,5.14)
trt <- c(4.81,4.17,4.41,3.59,5.87,3.83,6.03,4.89,4.32,4.69)
group <- gl(2,10,20, labels=c("Ctl","Trt"))
weight <- c(ctl, trt)
lm.D9 <- lm(weight ~ group)
summary( lm.D9 )

y hagamos

cor( weight, predict( lm.D9 ) )**2

¿Qué obtenemos? Precisamente la R2 del modelo lm.D9. Esta relación abre la puerta a varias extensiones de esta medida de la bondad de ajuste a contextos en los que las expresiones suma de cuadrados de… carecen de sentido.

Como parte de mis atribuciones dentro del comité organizador de las III Jornadas de Usuarios de R estoy tratando de conseguir la participación (y tal vez la financiación) de empresas e instituciones. Me ha parecido oportuno invitar a tomar parte en ellas a Teradata, empresa que, según la Wikipedia,

[está] especializada en herramientas de data warehousing y herramientas analíticas empresariales.

Teradata no se postula como un vendedor de herramientas de almacenamiento: quiere ir más allá. Su mercado es el de las empresas que aspiran a algo más que a que sus datos permanezcan varados en discos duros esperando, como mucho, a ser exportados a aplicaciones externas. Teradata dice ser capaz de realizar el análisis estadístico de los datos dentro de su propio sistema, eso que se ha dado en llamar in database analytics.

Parcialmente en agradecimiento a Revolution Analytics por haber concedido una subvención a las III Jornadas de usuarios de R voy a discutir en esta entrada cómo paralelizar bucles usando los paquetes foreach y doMC desarrollados por dicha empresa.

El paquete foreach contiene, esencialmente, una única función, foreach, que, en su forma más básica, permite ejecutar bucles con una sintaxis un tanto peculiar:

foreach( i = 1:3 ) %do% log( i )

Volveré sobre algunas operaciones interesantes y bastante útiles que permite realizar esta función porque, de todas ellas, hoy me ocuparé sólo de una: la que abre la puerta de una manera sencilla a la paralelización de bucles.