RANT: Si MATLAB es supuestamente la mejor herramienta para analizar datos en ingenieria por que ese programa tiene tantos problemas para trabajar con archivos mixtos? Quizá fue un problema por parte del programador, pero este tiene suficiente experiencia con este programa como para decir que esta tarea es especialmente obscura. Definitivamente la capacidad de integración de MATLAB en un ambiente de producción/análisis conjunto es pobre y deja mucho que desear.
Para quienes quieran entender la idea del proyecto, es muy sencilla:
Toma de datos -> Almacenamiento y Categorización de datos -> Preprocesamiento -> Procesamiento y Análisis -> Almacenamiento y generación de reportes.
Esto resume un sistema general de trabajo, pero realmente matlab se ha quedado por fuera ya que se nego a participar rapidamente en el ciclo de forma que todo el proceso quedará completamente automatizado para poder generar reportes con muchos diferentes análisis.
Realmente me he convencido que Matlab podrá estar muy bien para estudiantes, pero cuando se trata de trabajo serio pongo en duda su útilidad, por lo que realmente pienso que nisiquiera los estudiantes deberian perder el tiempo con él.
Al final python no brillo por su velocidad en el análisis ni por su excelente uso de la memoria, pues con las cantidades de datos que se le alimentaron hicieron que varias fallas aparecieran. Sin embargo brillo por la facilidad con la que resumi casi tres meses de trabajo en matlab en 24 Horas de programación en Numeric de Python más todo el trabajo de automatización y trabajo con bases de datos. Por favor, una vez más escuchenme Open Source es simplemente mejor, no se dejen engañar por los botoncitos y los colorcitos!!!
EOR
EOT
neat
Comment by herulor — January 23, 2006 @ 2:25 am
Interesante lo que dices de Matlab… pero en tal caso, que software de este tipo recomiendas???
Comment by opterix — January 23, 2006 @ 10:15 pm
De ese tipo? Ummm no creo que haya un reemplazo, si por algo similar sería octave o scilab.
El programa lo hice con Numeric de Python y MySQL pero los recursos se los consumio de una forma absurda. Creo que en parte es por la inexperiencia con Numeric, sin embargo haciendo profiling encontre algunos metodos deficientes dentro de este.
Para hacer todo lo que hace Matlab no hace falta más que una colección de librerias de C y Fortran es decir:
BLAS, LAPACK, FFTW. Dentro de lo que es opensource se encuentran librerias de c para todo tipo de calculo que se imagine por lo que no hace falta realmente escribir muchas cosas, incluso para redes neuronales y algoritmos geneticos.
Por otro lado el proyecto continuo y el almacenar los datos en MySQL y el código en Python hizo que pudiese poner 5 computadores en paralelo a consumir el lote de datos, incluso los que usan windows. Punto para python.
Creo que la mejor opción para esta clase de tareas al final son lenguajes de programación de verdad y escojer el conjunto de herramientas de acuerdo a los requerimientos, es decir:
- Quiero empezar a analizar datos y obtener resultados pronto.
- Aun tengo o no más máquina(s) que puedo incluir en el proceso de cálculo.
Con esos dos criterios creo que ya se puede hacer una primera aproximación a decidir cuales van a ser las herramientas.
Notese que siempre hablo de herramientas pues pienso que ninguna herramienta en particular resuelve todos los problemas y ese es el motivo del rant contra Matlab.
Comment by valkertown — January 24, 2006 @ 2:11 pm
Python no se caracteriza por su manejo de memoria, para manejar un lote grande de datos seria mejor algo de mas bajo nivel tipo C. Sin embargo el tiempo de programacion puede incrementarse letalmente, tambien puede probar con Java que tiene un muy buen desempenho en aplicaciones de high-throughput.
http://evanjones.ca/python-memory.html
Por otro lado si no va a manejar ningun tipo de integridad referencial a nivel del almacenamiento trabajar con MySQL puede ser lo mas rapido, sin embargo en mi experiencia motores mas robustos como PostgreSQL o Firebird podrian darle el mismo desempenho con mas prestaciones.
Comment by angelripper — January 24, 2006 @ 10:25 pm
Luego de hacer más profiling, encontre que el tiempo total de calculo no resulta ser significativo en comparacion con los tiempos de write-back y generación de las gráficas. La introspección de un lenguaje como Python me hacen preferirlo sobre C para la mayoria de programas que no tengo que embeder en nada.
Ciertamente Python no es la mejor herramienta para triturar cantidades de datos, pero el tiempo apremia y no me podia dar el lujo de hacerlo en otro lenguaje.
Por otro lado si PostgreSQL hubiese sido mi elección para la base de datos, pero en Slack ya viene lista MySQL y como dije el tiempo apremia, espero cambiar la base de datos para los proximos analisis.
Por ahora tengo que rediseñar la estructura de las bases de datos para minimizar los tiempos de write-back y ajustarla a los multiples analisis.
Quizá separe el programa que escoge los datos a analizar de los analizadores y estos los haga en C, pero solo cuando el tiempo de analisis supere el tiempo de “manejo” de los datos, y el desempeño de MySQL con esta parte ha sido realmente deficiente.
En Numeric hay muchas cosas estupidas que propician memory leaks, o comportamientos similares a estos y es particularmente lento haciendo esto:
a= reshape(arange(XXXXXX),(d1,d2))
Se demora casi 10 veces lo que se demora haciendo la transformada de fourier de la misma cantidad de datos.
De cosas como esa no se salva ningún lenguaje, por lo que insisto el profiling se vuelve demasiado importante.
EOC
Comment by valkertown — January 26, 2006 @ 2:54 pm
Si la cantidad de datos para analizar es grande, y la visualizacion no cae mal dentro del proceso, es probable que Yorick pueda interesarle.
Comment by ovidio — February 25, 2006 @ 5:40 pm