Consultoría

¿Quién fue el segundo hombre en pisar la luna? ¿Y el tercero? Aunque a veces pareciese lo contrario, ¿sabe que hay futbolistas que no son ni Ronaldo ni Messi? ¿Y otros ciclistas además de Contador e Induráin? ¿Y que la Fórmula 1 no se reduce a un tal Alonso?

Diríase que por razones sicológicas, nuestro cerebro tiende a sobresimplificar, se siente cómodo con una representación escueta de la realidad, es reacio a los distingos y grises. Le pirran las etiquetas: dígame de qué partido político es Vd. y enseguida crearé mis propias certezas sobre su opinión acerca de la Guerra de Irak, la visita del Papa a Madrid y el bikini de Leire Pajín.

Sólo conozco un estudio ?y lo digo bona fide; si alguno de mis lectores conoce otro, le ruego que me lo indique? en el que las técnicas de clústering hayan sido rectamente aplicadas. Se trata del artículo Molecular Classification of Cancer: Class Discovery and Class Prediction by Gene Expression Monitoring de cuyo resumen extraigo y traduzco lo siguiente:

Un procedimiento de detección de clases automáticamente descubrió la distinción entre la leucemia mieloide aguda (AML) y la leucemia linfoblástica aguda (ALL) sin conocimiento previo de las clases. Después se construyó un predictor de clases…

En esta entrada de hoy, hija de la pereza, reproduzco un vídeo que el lector puede encontrar igualmente en Medialab Prado. Es una presentación de Javier de la Torre, de Vizzuality, una compañía que trabaja en un campo del que nos hemos venido ocupando en estas páginas: la visualización de la información. La presentación tuvo lugar el 15 de febrero de 2011 dentro del evento Barcamp: periodismo de datos. Trata sobre Google Refine.

Leí hace un tiempo The flaw of averages, un libro poco convencional que recomiendo a mis lectores. Su objetivo último es encomiable: conseguir que personas sin mayor preparación matemática o estadística pero obligadas a tomar decisiones frente a la incertidumbre apliquen el sentido común y entiendan claramente unos principios mínimos.

Para lograrlo, asume una postura tal vez anti-intelectualista, tal vez herética. Piensa el autor —¿con motivo?— que, a ciertas personas, conceptos tales como varianza, media, teorema central del límite o función de densidad les dificultan, más que facilitan, la comprensión de lo que la incertidumbre realmente es y de cómo puede afectarlos. ¡Cuánta gente se conforma con conocer la media (p.e., de una estimación)!

Me consta que algunos de mis lectores están al tanto de eso que llaman investigación reproducible. De acuerdo con la Wikipedia (en inglés),

[E]l término investigación reproducible se atribuye a Jon Claerbout, de la Universidad de Stanford y se refiere a la idea de que el producto final de la investigación no debería circunscribirse a un artículo sino comprender también el entorno computacional completo usado en la generación los resultados que contiene, tales como el código, los datos, etc. para que puedan ser reproducidos y se pueda avanzar a partir de ellos.

Extraigo de la bitácora de Rob J Hyndman y de una manera que roza el plagio mi entrada de hoy. Recoge diez reglas, diez mandamientos para el análisis de datos (en realidad, para el análisis econométrico, pero pueden trasladarse casi sin cambios al ámbito general) propuestas por Peter Kennedy. Son las siguientes:

1. Usa el sentido común (y la teoría económica)
2. Evita el error de tipo III (encontrar la respuesta adecuada a la pregunta incorrecta)
3. Conoce el contexto
4. Inspecciona los datos
5. KISS (Keep It Sensibly Simple)
6. Asegúrate de que tus resultados tienen sentido
7. Considera los beneficios y los costes de la minería de datos
8. Estáte preparado para aceptar soluciones de compromiso
9. No confundas significancia con relevancia
10. Acompaña tus resultados de un análisis de la sensibilidad

El lector interesado puede echar un vistazo a la discusión de estas reglas.

• 400 euros cuesta un disco duro en el que almacenar toda la música del mundo
• Hay 5.000 millones de teléfonos móviles funcionado
• 30.000 millones de contenidos circulan por Facebook cada mes
• Los datos generados mundialmente crecen un 40%, frente al 5% que se incrementa el gasto en tecnologías de la información
• La biblioteca del Congreso de Estados Unidos almacena 235 TB de información
• Pero las compañías de 15 de 17 sectores económicos de EE.UU. poseen bases de datos aún mayores
• El valor que pueden aportar los datos de salud en EE.UU. podría superar los 300 millardos de dólares, el doble que el gasto sanitario en España
• Y 250 millardos de valor a las administraciones públicas europeas, más que el PIB de Grecia

Para saber más, el informe de McKinsey sobre datos grandes completo.

Por popular demanda, voy a ilustrar en esta entrada el uso de subversion para el desarrollo colaborativo de software. Lo escribo teniendo en mente el desarrollo de paquetes alojados en R-Forge y para usuarios de sistemas operativos más o menos decentes. A quienes usan Windows les recomiendo Tortoise, cuyo uso queda fuera del alcance de lo que sigue.

En primer lugar, para los desavisados: subversion es un programa para gestionar versiones de ficheros. A usuarios particulares, les permite mantener fotos de tu trabajo (¿cómo estaba mi libro/tesis/código hace un mes?). Cuando varias personas trabajan en un mismo proyecto, les permite controlar quién ha hecho qué, cuándo y por qué; además, que cada uno de los integrantes del proyecto trabaje sobre su propia copia del código, aunque mandando su cambios a un repositorio central y recibiendo, claro está, los cambios del resto del equipo.

Muchos de mis lectores tienen, seguro, maneras distintas —y probablemente mejores— de organizar sus proyectos en R que yo. Pero me consta que a algunos les cuesta no convertir sus carpetas en un caos en los que sólo ellos se manejan —hasta que pasa el tiempo, se olvidan y tienen que volver sobre ello—. Para ellos, para sugerirles un procedimiento eficiente de trabajo, va esta entrada. En ella describo cómo organizo mis propios proyectos con R.

No sé si mis lectores están al tanto del problema conocido como tragedia de los comunes (que, más bien, debería denominarse tragedia de las dehesas). Consiste en que una serie de agentes económicos (ganaderos) comparten un bien común, que no pertenece a nadie (una dehesa), en la que hacen pastar sus vacas. Todos ellos están interesados en hacer pastar el máximo número posible de ellas. Pero la capacidad de generar pasto de la dehesa es limitada y llega un momento en que ésta se sobreexplota y es incapaz de alimentar tanta vaca. Todos los ganaderos pierden, pero a ninguno le interesa reducir unilateralmente el tamaño de su cañada.

Como esta semana se me están agotando las ideas antes que los días de blog, en lugar de discurrir una entrada, propongo un problema para que sean mis lectores quienes lo hagan por mí.

Que se imaginen dueños de un pozo petrolífero cuyos costes de explotación son de 75 dpb (dólares por barril). El precio del petróleo no es fijo: puede tomar aleatoriamente los valores 50, 100 o 150 dpb, aunque se sabe que todos son equiprobables.

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.

Esta bitácora tiene aspiraciones de excelencia (aunque no siempre lo consigue: por ejemplo, en esta entrada utiliza excelencia de una manera que es un calco del inglés incorrecto en español). De ahí que nos interese siempre estar al tanto de técnicas que nos ayuden a superarnos.

Así, de las bitácoras del Harvard Business Review extraemos estos seis consejos que deberían servir a quien apunte más arriba que a lo que nos invita la mediocridad del ambiente: