Consultoría

Clústering (IV): una digresión real como la vida misma

Entré a trabajar en una consultora hace un tiempo ?no diré si mucho o poco? y uno de mis primeros encargos fue el de supervisar el desarrollo e implementación de unos modelos que habían creado unos compañeros. Les eché un vistazo y me sorprendió que sin mayor miramiento habían eliminado aquellas observaciones cuya variable objetivo tomaba el 4% de los valores más altos y el 4% de los más pequeños.

Clústering (III): sobresimplificación

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

Clústering (II): ¿es replicable?

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…

Google Refine para analizar, estudiar y limpiar los datos

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.

Sobre el libro "The flaw of averages"

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

Sweave, investigación reproducible... y más

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.

Diez mandamientos del análisis de datos

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.

Grandes números

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

Minitutorial de subversion

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.

Gestión de proyectos en R

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.