En más de una conversación de café he sacado el comentario sobre lo vacíos que últimamente están los contenedores de basura. Por no hablar del metro y otros transportes públicos.  Son claros indicadores de la crisis, contrapuestos a la retórica de los macroindicadores.

Hay un caso especial en todas esas fuentes de datos: las que nadie (o pocos) más ven. Esos detalles, en los que pocos reparan y muchos rehuyen de observar, son los que más nos pueden explicar cómo está nuestro entorno, si entrenas esa mirada para escuchar lo que te explican.

Y he aquí que me veo ante un contenedor de basura. ¿Qué hago mirando en los contenedores de basura? Escuchar la realidad de un modo que pocos lo hacen.  No es que vaya metiendo la cabeza en todo contenedor abierto, pero tampoco es necesario.  Es fácil pensar que un estadístico sólo tiene en mente las cifras. Y desde luego trabajamos con datos... Pero para conectar la realidad con esos datos, a veces es necesario encontrarlos... en los contenedores. Esa frase que nos repitieron los padres: "El dinero no crece de los árboles", pues bien, los datos no crecen en las hojas de cálculo.

Es en estos detalles en el que están los ojos estadísticos: en detectar una fuente de datos, integrada en un proceso. Descubrir un indicador cuya obtención apenas modifica el proceso que lo genera: fragmentos de realidad que chisporrotean datos. Trocitos de realidad, como una rama del árbol que empieza a surgir del tronco.

Y aunque sí es cierto que frente a sus ojos el paisaje puede estar plagado de ellos, la visión que requiere el análisis de datos nos lleva a dar un paso más allá. La doble visión de arte y ciencia aporta valor a la narrativa del análisis. Nos recuerda qué preguntas tratamos de reponder, y por qué nos las formulamos.

Y volviendo al indicador en cuestión: no soy el único que se ha dado cuenta. A mí, lo vacía que está la basura últimamente, me explica hasta qué punto la cosa está jodida. Para qué negarlo.

</p>

Entrevista a Susan George en CNN+ from ATTAC.TV on Vimeo.

School of Data ha publicado un artículo interesante sobre bibliotecas de código y utilidades que se basan en D3 y que pueden simplificar las tareas más repetitivas.

Es un artículo interesante, y realmente toca un punto clave de D3: ¿necesitamos siempre una herramienta tan compleja para generar un gráfico? La mayoría de las veces no, pero si quieremos aplicar la gramática de los gráficos con total libertad, D3 es ideal. Y por otro lado, el hecho que D3 sea un punto de partida para generar gráficos, da margen de movimiento para modificaciones futuras.

En el articulo se diferencian tres niveles/tipologias:

• Facilitadores y gráficos prefabricados.
• Gráficos compuestos y utilidades enfocadas a visualizar conjuntos más complejos.
• Aplicaciones que se basan en un lenguaje de entorno de servidor (python, etc.) o entorno (R).

También dejaría a un lado Vega, porque creo que queda a cierta distancia del resto de propuestas, aunque no he usado la herramienta y no puedo valorarlo.

Bueno, y ahora, os toca probar las propuestas.

Parece que el ciclo en el análisis y la representación de los datos también está cambiando. Como ya sucedió en IT con las metodologías ágiles, quizá la reducción en el precio de los recursos (en este caso, el acceso a más datos por un coste bajo o nulo), ha conducido a cambios en el ciclo de trabajo. Así, en una entrevista a Jer Thorp, leía:

We have a research based practice which can be summed up in two words: “Data first”. Let’s look at the data and let it tell us where we are going to.

Pero ¿acaso necesitamos sólo los datos? No, esos datos deben ser reales. No valen datos de prueba, e incluso datos simulados.  La exploración de datos, que nos permite detectar patrones visuales, es lo que acaba determinando la visualización. Por eso vale la pena pedir los datos:

Clients are not always good at coming up with real data, he said, but you have to try to get it. Without it, the prototypes don’t make sense and people find them confusing because there’s no context. “They need to see themselves in the data,” he said. If he doesn’t have it, he makes very rough prototypes in D3 or relies on paper sketches.

• Entender la fuente (de los datos).
• Identificar la narrativa.
• Definir la experiencia de uso (cómo interactúa el usuario en esa narrativa base).
• Evitar la reinvención de la rueda (ergo sé al menos un poco original).

La distribución de Poisson es la otra cara de la moneda de la distribución Exponencial.  Mientras que la distribución exponencial nos sirve para modelizar el tiempo que transcurre entre dos sucesos independientes, la distribución de Poisson modeliza el número de sucesos que tienen lugar en una unidad de tiempo.

Por ejemplo:

• Si queremos saber cuántas llamadas entrarán en un Call Center cada hora, modelizaremos en base a Poisson.
• Si lo que queremos saber es cuánto tiempo transcurrirá entre dos llamadas a ese Call Center, modelizaremos con una distribución Exponencial.

• Se simula un primer valor E utilizando el generador de valores exponenciales. Esto nos indicará el tiempo que ha tardado en entrar la primera llamada.
• Si la llamada ha tardado más de un minuto en entrar, significa que durante el primer minuto han entrado cero llamadas. Por lo tanto, ese valor de Poisson vale cero.
• En caso contrario, ya ha entrado una llamada, y quizá entre una segunda. Simularemos valores exponenciales mientras las sumas de estos valores no superen la unidad de medida (en este caso, un minuto).
• Cada vez que simulamos un valor exponencial, sumamos 1 a P.

Suena un poco complicado, pero en el fondo lo puedes pensar así: arrancamos el cronómetro y lo paramos al minuto. Contamos el total de llamadas que han entrado en ese minuto por una línea. En el momento que entre una llamada después de ese minuto, ya está fuera del contador.

La distribución de Poisson, como la Exponencial, toma un solo parámetro λ, pero ojo porque el valor es el inverso. Es decir, que si en la Exponencial consideramos que cada llamada tarda 30 segundos en entrar, la Poisson indicará que hay 2 llamadas por minuto. En resumen: el parámetro tiene el mismo nombre pero toma el valor inverso. En la Exponencial sería 0,5 y en la Poisson sería 1/0,5 = 2. En el fondo es más intuitivo, aunque de buenas a primeras suena a chino, hay que reconocerlo.

[d3-link]

[/d3-link]

Pues bien, hecha la explicación, vamos a por la simulación de los datos con D3:

[d3-source canvas="chart"]
var
svg  = null,
bars = null,

generator = function() {
var 
lambda = 5,
simulations = 500,
barWidth    = 16.3,
barsScale = d3.scale.linear()
.domain([0, 3 * lambda])
.range([0,29]);
barXScale = d3.scale.linear()
.domain([0, 3 * lambda])
.range([0,270]);
var dataset = poissonGen(lambda, simulations, barsScale),

barYScale = d3.scale.linear()
.domain([0, d3.max(dataset, function(d) { return d;})])
.range([270, 0]),

yAxis = d3.svg.axis()
.scale(barYScale)
.orient("left")
.ticks(5),

xAxis = d3.svg.axis()
.scale(barXScale)
.orient("bottom")
.ticks(4);

if (svg !== null) {
bars = svg.selectAll("rect")
.data(dataset);

bars.enter();
} else {
svg = d3.select(".chart")
.append("svg")
.attr("width", 400)
.attr("height", 300);

bars = svg.selectAll("rect")
.data(dataset)
.enter()
.append("rect");
}

svg.selectAll("g.axis").remove();

svg.append("g")
.attr("class", "axis")
.attr("transform", "translate(30,0)")
.call(yAxis);

svg.append("g")
.attr("class", "axis")
.attr("transform", "translate(30,270)")
.call(xAxis);

bars.attr("x", function(d,i) {
  return 32 + i * (barWidth + 1);
 })
 .attr("y", function(d) {
  return 270-d;
 })
 .attr("width", barWidth)
 .attr("height", function(d) {
  return d;
 })
 .attr("fill", "blue");
},

poissonGen = function(lambda, simulations, barXScale) {
var datum = [];
  for(var row = 0; row < 30; row++) {
  datum.push(0);
  }

  for(var i = 0; i < simulations; i++) {
  var total = 0, poisson = -1;
  do {
  var u = Math.random();
  total += (-Math.log(u)/lambda);
  poisson++;
  } while(total < 1);

  datum[poisson]++;
  }
  return datum;
};
generator();
[/d3-source]

Se puede ver que en general su forma es acampanada. En realidad a partir de valores λ superiores a 30, las formas de la distribución de Poisson y de la distribución normal son casi indistinguibles (salvo, claro, porque la primera toma valores discretos y la segunda, continuos).

Agradable sorpresa descubrir reveal.js, una biblioteca Javascript que permite crear presentaciones (tipo powerpoint, para entendernos) en HTML5, por lo que se pueden ver en el navegador. Entre las funcionalidades que incluye están la posibilidad de navegar por las diapositivas en las cuatro direcciones, exportar la presentación a PDF, y poner la presentación en modo pausa (se queda la pantalla a oscuras y la gente no se distrae).

Por si fuera poco, tiene licencia MIT, y su código fuente está en Github, donde también se puede encontrar (entre otros muchos datos) el grado de soporte a navegadores (que no está nada mal, aunque supongo que mejorará progresivamente). La utilidad se basa en CSS 3D y habrá que esperar a ver su potencial cuando los navegadores implanten estas especificaciones. Pero hoy por hoy, no es tan descabellado empezar a usarlo.

El hecho que sea HTML5 implica... pues poder incrustar infinidad de cosas en esa presentación. En mi caso, se me pasa por la cabeza incrustar visualizaciones interactivas, simplificando la creación de un discurso a partir de la visualización. Pero cada cual se puede imaginar lo que sería tener una herramienta de presentaciones dentro de una web... O una web que se muestra como una presentación. ¿Por qué no?

Aquí tenéis una presentación del propio autor para ir abriendo el apetito.

No tienes ni idea de programar? Pues aquí tienes slid.es, un sitio donde probar y utilizar reveal.js.

Hace tiempo que tengo ganas de comentar (¡y usar!) la biblioteca D3.js.  En realidad, poco después de hablar de protovis, Mike Bostock comentó que discontinuaba protovis y que empezaba con D3.

Y lo cierto es que me la había estado mirando.  Desde la lectura de The Grammar of Graphics, D3 era una asignatura pendiente.  Ahora, poniéndome al día, he encontrado este tutorial realizado por Scott Murray, con mucho sentido pedagógico, ideal para los que se introducen en este tema.

Quizá para quien no haya utilizado jQuery o similares, el tutorial les resulte algo complejo en lo relativo a los selectores. Pero sólo es cuestión de práctica.

La distribución exponencial es una distribución especialmente importante en estadística.  Sirve para modelizar el tiempo que transcurre entre dos eventos independientes, y durante los cuales transcurren, por término medio, el mismo tiempo. También se la reconoce por ser la otra cara de la moneda de los procesos de Poisson, de los que hablaré en otro momento.

La distribución exponencial es una distribución continua (digámoslo rápido: el tiempo que transcurre entre dos eventos es un número real, con potencialmente infinitos decimales), que se define por la fórmula (vía wikipedia):

Esto básicamente quiere decir que la distribución exponencial empieza a operar a partir de cero (los tiempos negativos tampoco tienen sentido aquí), y su forma es:

Para los diferentes valores, vemos que a medida que el valor de λ aumenta, la función de densidad se hace más picuda, lo cual significa que la probabilidad se concentra en los primeros intervalos de tiempo. En realidad, el valor de λ determina la media y varianza de esta distribución.

Por su lado, la función de distribución (es decir, el acumulado anterior, que se obtiene calculando la integral de la fórmula anterior), es:

Y su fórmula:

Lo cual puedes comprobar si integras la función anterior.

Simular el valor a partir de la función de distribución

• El rango de valores de la probabilidad (eje vertical) oscila entre 0 y 1.
• Para cada valor entre 0 y 1, sólo hay una correspondencia con el valor a simular.

• Simular un valor u entre cero y uno, utilizando un generador aleatorio (cualquier hoja de cálculo, lenguaje de programación y paquete estadístico tiene esa función).
• Obtener el valor de x a partir de u.

[math]x=\frac{-ln(u)}{\lambda}[/math]

[d3-link]

[/d3-link]

[d3-source canvas="chart"]
var
svg = null,
bars = null,

generator = function() {
var
lambda = 0.5,

simulations = 500,

barWidth = 9,

barsScale = d3.scale.linear()
.domain([0, 10 / lambda])
.range([0,29]);

barXScale = d3.scale.linear()
.domain([0, 10 / lambda])
.range([0,270]);

var dataset = exponentialGen(lambda, simulations, barsScale),

barYScale = d3.scale.linear()
.domain([0, d3.max(dataset, function(d) { return d;})])
.range([270, 0]),

yAxis = d3.svg.axis()
.scale(barYScale)
.orient("left")
.ticks(5),

xAxis = d3.svg.axis()
.scale(barXScale)
.orient("bottom")
.ticks(4);

if (svg !== null) {
bars = svg.selectAll("rect")
.data(dataset);

bars.enter();
} else {
svg = d3.select(".chart")
.append("svg")
.attr("width", 400)
.attr("height", 300);

bars = svg.selectAll("rect")
.data(dataset)
.enter()
.append("rect");
}

svg.selectAll("g.axis").remove();

svg.append("g")
.attr("class", "axis")
.attr("transform", "translate(30,0)")
.call(yAxis);

svg.append("g")
.attr("class", "axis")
.attr("transform", "translate(30,270)")
.call(xAxis);

bars.attr("x", function(d,i) {
return 32 + i * (barWidth + 1);
})
.attr("y", function(d) {
return 270-d;
})
.attr("width", barWidth)
.attr("height", function(d) {
return d;
})
.attr("fill", "blue");
},

exponentialGen = function(lambda, simulations, barXScale) {
var datum = [];
for(var row = 0; row < 30; row++) {
datum.push(0);
}

for(var i = 0; i < simulations; i++) {
var u = Math.random();
var barNumber = barXScale(-Math.log(u)/lambda);
datum[Math.floor(barNumber)]++;
}
return datum;
};

generator();
[/d3-source]

Un interesante ejemplo de los riesgos por el exceso de datos disponibles lo retrataba hace un par de semanas el blog del colegio de periodismo en su blog de la BBC.  No comparto al completo la visión, pero sí los efectos primarios (sesgo) y secundarios (toma de decisiones errónea) debido a un problema relativamente nuevo: el exceso de datos.

Lo cierto es que el Big Data me tiene el corazón dividido. Leyendo un reciente artículo de Yusef sobre Data (que no sólo me ha valido la pena leer, sino que a su vez referencia artículos muy interesantes), comparto el hecho que el término es puro marqueting, y que el objetivo es vender más hardware para centros de proceso de datos; que los algoritmos no habrán mejorado tanto en los últimos años. Y que si has llegado al Big Data porque pensaste que era algo totalmente nuevo, te equivocaste.

Intento ceñirme estrictamente al tema de la utilidad del Big Data.  Dejo a un lado las consecuencias en la privacidad, y otros debates que me parecen relevantes para esta temática. Me gustaría verlo desde el punto de vista más técnico.

Porque claro, eso es el mercado.  No veo yo ningún sector en el que eso de intentar vender, no suceda.  Lo que ahora es Big Data, antes fue data mining, inteligencia artificial,... Y así podríamos ir tirando del hilo hasta llegar al momento en que la informática y las matemáticas (o directamente la estadística) cruzaron sus caminos (y eso fue bastante pronto). Eso, el uso del márqueting para vender más, desde los ojos de un técnico, es ignorable.

Tambien, mientras imagino ese volumen de datos, pienso en la cantidad de ruido que habrá. Y aunque no es deseable, también es intrínseco al análisis.  Antes de decidir la señal que queremos extraer de los datos, estaba el ruido. La señal no es más que una porción del ruido que responde a nuestras preguntas.  Entonces, en ese ruido está el sonido que buscamos. El ruido, a pesar de todo, es deseable. Porque el ruido es contexto.

Filtrar ese ruido tiene su intríngulis. Pero por ejemplo, ese filtrado puede ser iterativo. Incluso puede hacerse después de recopilar datos en bruto (con el permiso de las políticas de uso de las APIs). Tener una buena base de datos y que un técnico pueda responder con algunos càlculos a las preguntas que le caen al vuelo, formuladas por un responsable de negocio: no veo yo que sea para tirarse de los pelos. Si sólo se dispone de los datos estrictamente necesarios para llevar a cabo un experimento, el resto de preguntas quedan fuera.

Por eso, cuando pienso en la parte Big del término, no me sugiere el volumen de datos: más bien pienso en la cantidad de preguntas que pueden responder y que antes no podíamos preguntarle a los datos. Desde mi punto de vista el Big Data es el mar, o el acuario. Es el espacio en el que se desarrolla (o simula, o analiza) todo un ecosistema. No son solo los datos, sino también el contexto que podemos apreciar si podemos aprovechar esos datos. Es lo que permite trabajar con los datos como si estuviéramos en un entorno real.

Por eso, es cierto que si un estudio está enfocado (y eso me parece correcto) hacia preguntas muy concretas, este volumen de datos es excesivo. Pero rechazar el Big Data porque tiene ruido, o porque  el conjunto de datos no da valor en conjunto, pues no lo comparto. El mar está lleno de espacios vacíos. Y de peces. Es una cuestión de reenfoque.

Sería como si el pescador no pescara más porque hoy no ha capturado nada. Ese pescador no se da cuenta que el propio hecho de no haber capturado nada hoy, le está dando información sobre su contexto de pesca, que le puede ayudar a tomar decisiones. Y que sin ese mar, no tendría esa posibilidad. Ese pescador está aprendiendo a pescar. Encontrará más valor buscando las corrientes de agua y los arrecifes. Esto le llevará tiempo. Pero si le gusta pescar, aprenderá.

Me planteo una actitud diferente ante el Big Data. Cambio el proceso de análisis a fondo, por un enfoque más contemplativo. Cambio el contraste de hipótesis por un buen análisis exploratorio de los datos. Cambio las respuestas, por las historias que hay detrás.

Pero quizá me equivoque. Es probable ;-).