Por azares, me ha tocado lidiar con eso de la detección de anomalías. Que es un problema que tiene que ver con dónde colocar las marcas azules en

El anterior es el gráfico construido con los datos de ejemplo del paquete AnomalyDetection. De hecho, así:

library(AnomalyDetection)

data(raw_data)
res <- AnomalyDetectionTs(raw_data,
    max_anoms=0.02,
    direction='both', plot=TRUE)
res$plot

Aparentemente, AnomalyDetectionTs hace lo que cabría sospechar. Primero, una descomposición de la serie temporal, tal como

Estuve el otro día en una charla de José Luis Cañadas en el grupo de usuarios de R de Madrid sobre sparklyr. Hoy en otra de Juan Luis Rivero sobre, esencialmente, lo mismo, pero esta vez con Python. Y podría escribir “etc.”.

Me centraré en la de José Luis, aunque podría decir lo mismo de cualquiera de las otras. No había trabajado con sparklyr. No soy siquiera fan de dplyr (aunque no es que no se lo recomiende a otros; es simplemente, como tantas cosas, que soluciona problemas que no tengo). Pero la seguí sin mayores problemas. Lo que tenía de nuevo era una fina, somera capa de sintaxis que enlazaba fundamentos con fundamentos.

Los amigos de Descifrando Emprendedores han tenido la gentileza de entrevistarme. Nuestra charla puede escucharse aquí.

Es:

library(future)

plan(multiprocess, workers = 4)

system.time({
  a1 <- future({Sys.sleep(7); 1})
  a2 <- future({Sys.sleep(1); 1})
  a3 <- future({Sys.sleep(1); 1})
  a4 <- future({Sys.sleep(1); 1})
  a5 <- future({Sys.sleep(1); 1})
  a6 <- future({Sys.sleep(1); 1})
  a7 <- future({Sys.sleep(1); 1})

  res <- sapply(list(a1, a2, a3, a4, a5, a6, a5), value)
})

Piensa antes las posibles opciones:

• ~8 segundos: ejecuta primero a1-a4 en 7 segundos y luego a5-a7 en un segundo adicional.
• ~7 segundos: ejecuta primero a1-a4, pero cuando acaban a2-a4, lanza a5-a7, que terminan antes que a1
• ¿Otras?

Vosotros mismos.

Hoy escribo afectado por un derrame de pesadumbre. Pero esa es solo una opinión que igual no importa nadie.

Estas del 8 de noviembre han sido las elecciones en que menos y que más caso he hecho de las encuestas electorales. Cansado del cada vez más monótono ciclo de que

• se publican encuestas electorales
• llegan las elecciones y el resultado no se parece en nada a lo dibujado por ellas y
• se reitera el mismo blablablá (en latín se dice excusatio non petita) que unos meses antes

he decidido esta vez dejar de prestar atención a algo que, se ha visto, no ha sido sino ruido. Les he hecho caso, sin embargo, al inclinarme a comprar con ánimo 100% especulativo unas accioncillas que hoy valen el 4% menos que ayer y el 2% menos que cuando las compré. ¡Contento me tienen los científicos de opinión pública y sus benditas batas blancas!

El día 16 de noviembre (de 2016) daré una de esas minicharlas de seis minutos en el Databeers que tendrá lugar en el HUB del Campus de Alcobendas de la Universidad Europea. Comenzaré hablando de por qué no necesitamos a Newton para agarrar al vuelo una pelota de tenis que nos alcanza un cuñado y acabaré Dios sabe dónde y cómo.

El cartel lo completan Antonio Chinchón (no os perdáis su blog), Luz Frías y otros que me expongo a que me riñan por no mencionar.

Seis sigma es un conjunto de métodos y prácticas para mejorar la calidad de los procesos industriales. Su nombre está inspirado por la distribución normal: aspira a que la tasa de errores (por ejemplo, piezas defectuosas producidas por una planta) sea pnorm(-6).

Pero pnorm(-6) es 9.8e-10 (uno por millardo, aproximadamente), mientras que, según la Wikipedia, que siempre tiene la razón, la aspiración del Seis Sigma es la de alcanzar 3.4 defective features per million opportunities. Que es bastante (trescientas veces) superior.

En 2012 mencioné de pasada ese artículo de Breiman al que hace referencia el título. Estaba bien, tenía su gracia.

Lo he visto utilizar recientemente como punto de partida en discusiones sobre lo distinto o no que puedan ser la ciencia de datos y la estadística. Y espero que, efectivamente, se haya usado como punto de partida y no como otra cosa porque el artículo tiene 15 años (cerrad los ojos y pensad dónde estabais en 2001 y cómo era el mundo entonces).

Esta entrada extiende y mejora una homónima de 2014.

El problema de entonces consistía en calcular por separado y en paralelo objetos A, B y C para combinarlos después. Cuando, por supuesto, el cálculo de A, B y C es pesado.

El muy reciente paquete future incorpora a R un mecanismo disponible en otros lenguajes de programación: un cierto tipo de datos, los futuros, que contienen promesas de valores que se calculan fuera del hilo principal del programa. Se usan, por ejemplo, para realizar llamadas a APIs, operaciones de IO o (y esto es más pertinente para usuarios de R) cálculos que llevan su tiempico.

Me mandan un whatsapp. Es de alguien que está en una charla de ciencia de datos. Acaba de oír decir al ponente que en una de esas competiciones de Kaggle le ha servido optimizar a lo largo del conjunto de semillas aleatorias. Sí, del set.seed().

Supongo que al ponente le funcionaría.

El éxito de la ciencia de datos parece tener aparejada una plaga de homeopatía de datos. Algo habrá que hacer. Por lo pronto, emplear el escepticismo para algo más que para asestar grandes lanzadas a moros muertos.