Permítanme ilustrar lo que está sucediendo con un ejemplo. No tengo skin ni en los juegos de CS o de ciencia de datos (soy un tipo de teoría de control con estatus de cinturón amarillo aficionado en ambos campos). Una ex gerente había estado masajeando algunos datos financieros y tenía la intuición de que se podía construir un modelo general de LP. Había construido un ejemplo muy simple de 2 variables y optimizado a mano la respuesta. Ella no sabía cómo construir el LP general. Yo tampoco, inicialmente, cuando ella me trajo para sistematizar lo que estaba haciendo.
Me arrojó una gran hoja de cálculo de datos. No puedo entrar en detalles, pero básicamente pasé unos 3-4 días jugando con el ejemplo del juguete a nivel de hoja de cálculo, luego me fui e hice una gran cantidad de cálculos con lápiz y papel para enviar los datos generales al formulario de un LP, y luego escribió el código de Matlab para extraer los datos de Excel y mostrar los resultados óptimos. Era una solución general que dependía de algunas elegantes manipulaciones de álgebra lineal para llegar a una representación eficiente. No fue innovador, pero de todos modos estaba muy orgulloso porque las matemáticas resultaron ser muy bonitas. Era lo que mi asesor de doctorado solía llamar “matemáticas románticas” (todas las secuencias, sumaciones y demás). Lo escribí como un documento interno principalmente porque las 4-5 páginas de las ecuaciones de LaTeX eran muy bonitas.
La clave en esta pequeña viñeta es el “salto” de la hoja de cálculo a los modelos programados, y el hecho de que se necesitaban algunas ideas “elegantes” para hacer el salto. No podía pasar sin problemas de un régimen a otro, o la fuerza bruta hacia un modelo programado. Tuve que hacer un cambio de marcha discontinuo (apoyado por derivaciones matemáticas de papel de lápiz en este caso). El cambio fue habilitado por una visión específica del problema sobre la representación correcta.
- ¿Cómo la computadora puede calcular?
- ¿Puede la notación musical (cualquiera que elija) considerarse Turing Complete?
- ¿Cuál es la diferencia entre una base de datos y un índice?
- ¿Cuál es el complemento del problema de detención?
- ¿Por qué instala Fedora 22 actualizaciones cuando reinicio mi máquina?
El corazón de la respuesta a su pregunta es: “¿Por qué fue necesario el salto? ¿Por qué no podría refinar gradualmente el juguete, el modelo de hoja de cálculo computarizado a mano para convertirme en el modelo genérico de resolución de LP?”
La brecha es la razón por la cual las dos comunidades están separadas. También es la razón por la cual los tipos CS pasan a segundo plano.
En el estado actual de la técnica, no puede evitar el salto. Y no creo que puedas, en el caso general. La razón por la que los tipos de CS pasan a un segundo plano es que la “visión elegante” necesaria para que el salto comience en el lado de la hoja de cálculo de la brecha, que muchos tipos de CS desprecian. Este es el por qué.
Las hojas de cálculo y la programación aportan metáforas conceptuales fundamentalmente diferentes al pensamiento acerca de los números, y admiten diferentes formas de discutirlas. La brecha entre los dos “regímenes” hasta hace poco no tenía herramientas tecnológicas. Solo puede saltar a través de la brecha con ideas elegantes específicas del problema.
Las hojas de cálculo se basan en nuestras intuiciones directas sobre la clasificación y el orden. Le ayudan a detectar patrones básicos en datos sin procesar y estructurar relaciones de manera eficiente para presentaciones humanas en lugar de esquemas db. Al jugar con datos tabulares directamente, obtienes las pistas que te permiten hacer cortes, dados y gráficos muy básicos que te ayudan a desarrollar una intuición para el conjunto de datos. Le ayuda a improvisar y comenzar a “atascar” en un sentido de jazz / raga con los números, directamente.
En algún momento obtienes un ¡Ajá! experiencia (“hmm … ARIMA ??”) sobre los datos, y la hoja de cálculo UX metáfora comienza a fallar. Pero el ajá! es también la visión estratégica que hace rodar la bola de programación.
Pero hay una brecha oscura entre la intuición y la primera línea de código, a la que llegaremos. Más allá de la brecha está la programación.
Piense en el régimen de programación como lo opuesto a la música de estilo jazz / raga. Es como componer una sinfonía para una orquesta. Muchas partes móviles que deben sincronizarse con precisión. Consigue una pieza en el lugar equivocado y todo se derrumba. Pero hazlo bien y obtendrás belleza.
La programación trata con números de manera procesal, como un proceso de línea de ensamblaje. Si sigue un período inicial de “jazz jamming con los datos”, obtendrá elegantes sinfonías de código. Si crea un modelo de datos en abstracto sin buscar primero patrones y posibles eficiencias de representación, obtendrá cacofonías.
Muchos tipos de CS saltan directamente a diseños cacofónicos sin hacer suficiente “jazz de datos” para crear las ideas elegantes que pueden conducir a sinfonías. Prefieren analizar los datos en formas burocráticas de “talla única” que MIRARlos.
Las excepciones tienden a ser personas con un sentido de la estética en torno a los problemas NP-completos, que conocen cosas como las transiciones de fase en la capacidad de solución, etc. Tienden a buscar las ideas elegantes a nivel de hoja de cálculo antes de sumergirse.
Tengo una regla: NUNCA construyo modelos matemáticos o modelos de programación sin tener un sentido práctico de los datos primero, a través del juego / improvisación. Y no construyo modelos en absoluto si no puedo obtener una visión “Ajá” para atacar el problema de una manera elegante.
La brecha es también la brecha entre la minería de datos y el análisis. Es por eso que no puede simplemente mirar sus datos de Google Analytics y seguir usando los filtros / herramientas automatizados para obtener información realmente profunda. NUNCA he tenido una pregunta de tráfico web que Google Analytics haya podido responder de inmediato.
La brecha NO es necesaria. En la mecánica newtoniana, por ejemplo, puedes jugar con un problema, obtener una “visión creativa” sobre el conjunto correcto de marcos de coordenadas para resolver las ecuaciones de movimiento con elegancia (bastante difícil).
Pero no tienes que hacerlo. La mecánica newtoniana es un dominio en el que puede llegar a la solución general de formas eficientes de fuerza bruta. Comenzando con las formulaciones lagrangianas en lugar de las newtonianas (en realidad, un descendiente matemático vectorial de Lagrange llamado ecuaciones de Kane), puede omitir la parte de comprensión. Simplemente describa su modelo mecánico y presione “ir” y la cosa se simulará. Eso es lo que hacen los paquetes CAD. No intentan ser inteligentes con marcos de coordenadas. Me encantaba ser inteligente hasta que aprendí Lagrange. Mi profesor de dinámica avanzada nos dijo explícitamente: no intentes ser inteligente, deja que las matemáticas hagan el trabajo por ti.
Pero hasta las innovaciones de Lagrange, TENÍA que ser bastante inteligente en “matemática elegante” para resolver problemas mecánicos difíciles. Fue Kepler volviéndose “inteligente” con los datos orbitales (elipses sobre epiciclos) lo que permitió a Newton llegar a la GRAN idea que resolvió todos los problemas de mecánica clásica de una sola vez.
Ahora, ¿qué pasa con el análisis de datos generales?
Hay intentos de crear tecnología “gap” que podría permitirle deslizarse sin problemas desde la hoja de cálculo a los modelos codificados sin problemas. Pivot de Microsoft es un gran ejemplo. Tengo muchas esperanzas de que dejará sin trabajo a muchos codificadores basados en Matlab o R. No creo en la intuición creativa en los dominios donde se puede diseñar de manera eficiente.
Pero en general, la discusión de datos NO es mecánica newtoniana. La mayoría de los problemas terminan siendo NP-completos, lo que significa que se ve obligado a confiar en las ideas del tipo “condiciones locales” para resolver el problema de manera elegante para un régimen particular de datos.
Para tomar un ejemplo completamente trivial, el problema del circuito de Hamilton es NP-completo. Pero para los gráficos densamente conectados y escasamente conectados, la solución es trivial: en el primer caso, casi cualquier recorrido de gráfico aleatorio le dará un circuito de Hamilton. Para este último, casi cualquier camino lo llevará a un callejón sin salida que pruebe que no existe un circuito de Hamilton.
Mientras se mantenga alejado de la parte intermedia de “transición de fase” donde viven las instancias difíciles (busque los documentos de Cook, Cheeseman, etc. si no sabe de lo que estoy hablando), puede refinar la integridad de NP. Pero la clave es que necesita mirar los datos reales para descubrir qué “heurística elegante” aplicar. No hay una forma mecánica de encontrar la heurística correcta para un régimen dado antes / después de una transición de fase. De hecho, no hay una forma general de parametrizar un espacio problemático para encontrar la transición de fase automáticamente.
En el caso del circuito de Hamilton, una forma de llegar a la idea de que la dispersión es la variable correcta para parametrizar el espacio es, bueno, mirar sus gráficos en forma de matrices o listas de adyacencia en Excel. La escasez / densidad de sus gráficos saltará a la vista.
Obviamente, los problemas de datos “reales” rara vez son tan triviales (aunque los ejemplos de juguetes que he visto para las descomposiciones de tipo MapReduce / Hadoop tienden a ser tan triviales como la situación del circuito de Hamilton). Pero aún debe buscar esa idea.
Para resumir: si eres un tipo CS que busca vencer a los Excel-wranglers en su propio juego, ensucia tus manos jugando con conjuntos de datos RAW. De lo contrario, tendrán el monopolio de la parte de “visión elegante” del juego, y usted simplemente estará subcontratando a los contratistas que implementan el diseño.
