Programas para trabajar con datos (Análisis, transformación, etc)

[CulitoDeRana]

A ver, mozos, qué usáis vosotros, a ver si alguien tiene alguna joya escondida. No pongáis los clásicos de R, Excel, Stata y tal porque ya los conocemos todos.

Yo cada vez uso más KNIME, que es el ahorrador de tiempo definitivo. Es una lástima que las versiones server sean de pago. De verdad, es increíble la cantidad de tiempo que ahorro con esta mierda. Voy guardando plantillas de proyectos para cosas que hago muchas veces, y he llegado a ahorrar semanas de curro. Incrédibol.




Knime funciona a base de nodos. Cada nodo tiene una función, y los datos se van pasando de unos a otros. Tiene nodos para (casi) todo. Puedes importar movidas de WEKA (que es el horror) y en general está muy chulo. Puedes cargar datos de bases de datos y todo tipo de archivos. Puedes desarrollar tus propios nodos (en JAVA), puedes instalar nodos nuevos del repositorio oficial, de la comunidad o tercerlos... @hijitus por ejemplo tienen estos nodos de Selenium https://seleniumnodes.com/

Para hacer visualizaciones es bastante caca, pero para transformación y análisis es como navegar con viento de popa. Se traga datasets bien grandotes sin rechistar. Yo lo tengo limitado a 7 GBs, pero en cualquier caso si os da problemas de memoria en todos los nodes hay una movida que se llama "memory policy" y os deja escribir la movida en disco, en lugar de guardar los datos en memoria. Va más lento así, claro.

Al principio cuesta un poco pillarle el tranquillo, y hay cosas que necesitan pulirse más, como los nodos de series de tiempo, pero en general muy bien. Hecho de menos algunas funciones de SPSS como los dendogramas y estas movidas, pero bueno supongo que acabarán apareciendo.

Al contrario que con SPSS y demás clásicos, he conseguido que peña que no tiene ni idea empiece a usarlos. Por ejemplo una compi del curro hizo un grado de márketing. Al ver los workflows, si los anoto los entiende, y los puede usar ella para sus propios casos. Esto sería totalmente impensable en otros programas. Al principio me hacía preguntas pero cada vez menos.

Para gente más principiante, y que es casi igual, está Orange Canvas (de Biolab), que corre sobre python. Muy muy intuitivo, con más colorines y tal, pero a mí personalmente con datasets ya algo grandotes me va mucho mejor KNIME.



Yo dejo estos dos, porque veo que casi nadie los usa, y es una pena.

[Frank Zappa]

Yo no uso nada especial, la verdad . Todo bastante mundano:

- Si el archivo tiene menos que mi memoria ram disponible para trabajar, es un trabajo de una vez y listo y es un formato legible (CSV y no un parquet, por ejemplo) tiro del trío cat, grep y awk. Rara vez necesito algo más sofisticado. Por lo general, haré cosas como cat archivo.csv | grep -e $MY_FILTER | awk -F"$SEPARATOR" '{whatever}END{print whatever}'. Para la mayoría de tareas que son de una sola vez, es perfecto: Rápido, está integrado con mi sistema perfectamente y lo entiendo. Si es de más, spark-shell.

- Si el archivo tiene un tamaño manejable pero es para un trabajo recurrente, normalmente escribiría un script. Dependiendo del archivo y de la complejidad de lo que tenga que hacer, tiraré por Python o Clojure.

- Si el archivo es mayor que mi memoria, pero menor que cosas bizarras, seguramente use alguna base de datos. PostgreSQL se está ganando un lugar en mi corazón últimamente y seguramente utilice eso. En otros tiempos habría usando MongoDB o cosas así, pero la edad me ha ganado y, con ella, el sentido común.

- Para cosas más complejas, Spark. En general, si necesito manejar cosas mayores de 100GB, en menos de 10 minutos y tengo un cluster a mano, no existe nada mejor.

He usado cosas como KNIME o Excel, pero rara vez consigo encontrarlos atractivos. Reconozco que se debe en gran medida a que mi entorno de trabajo ha sido siempre sistemas *nix y estoy demasiado acostumbrado a usar terminales y pequeños scripts. Al mismo tiempo, me gusta que mis aplicaciones no se cuelguen y rara vez puedo conseguir eso de manera consistente con Excel y amigos (admito que puede ser porque no sé usarlos eficientemente).

[CulitoDeRana]

Yo no uso nada especial, la verdad . Todo bastante mundano:

- Si el archivo tiene menos que mi memoria ram disponible para trabajar, es un trabajo de una vez y listo y es un formato legible (CSV y no un parquet, por ejemplo) tiro del trío cat, grep y awk. Rara vez necesito algo más sofisticado. Por lo general, haré cosas como cat archivo.csv | grep -e $MY_FILTER | awk -F"$SEPARATOR" '{whatever}END{print whatever}'. Para la mayoría de tareas que son de una sola vez, es perfecto: Rápido, está integrado con mi sistema perfectamente y lo entiendo. Si es de más, spark-shell.

- Si el archivo tiene un tamaño manejable pero es para un trabajo recurrente, normalmente escribiría un script. Dependiendo del archivo y de la complejidad de lo que tenga que hacer, tiraré por Python o Clojure.

- Si el archivo es mayor que mi memoria, pero menor que cosas bizarras, seguramente use alguna base de datos. PostgreSQL se está ganando un lugar en mi corazón últimamente y seguramente utilice eso. En otros tiempos habría usando MongoDB o cosas así, pero la edad me ha ganado y, con ella, el sentido común.

- Para cosas más complejas, Spark. En general, si necesito manejar cosas mayores de 100GB, en menos de 10 minutos y tengo un cluster a mano, no existe nada mejor.

He usado cosas como KNIME o Excel, pero rara vez consigo encontrarlos atractivos. Reconozco que se debe en gran medida a que mi entorno de trabajo ha sido siempre sistemas *nix y estoy demasiado acostumbrado a usar terminales y pequeños scripts. Al mismo tiempo, me gusta que mis aplicaciones no se cuelguen y rara vez puedo conseguir eso de manera consistente con Excel y amigos (admito que puede ser porque no sé usarlos eficientemente).

Excel no está pensado para trabajar con grandes volúmenes de datos, aunque PowerQuery sí, el problema es luego guardar los datos. Si te da problemas con archivos grandes, mi consejo es desactivar la opción de "cargar en el modelo de datos", y simplemente que cargue todo en una tabla de Excel. Luego ese mismo archivo lo consultas desde otro libro o programa.

KNIME a mí no se me ha colgado nunca que yo recuerde. Me ha llegado a ir lentísimo, pero ese es otro tema. De todas formas, no sé qué tipo de transformaciones de datos haces, pero a mí la verdad me resultaría muy pesado trabajar sin KNIME.

[Frank Zappa]

Yo no uso nada especial, la verdad . Todo bastante mundano:

- Si el archivo tiene menos que mi memoria ram disponible para trabajar, es un trabajo de una vez y listo y es un formato legible (CSV y no un parquet, por ejemplo) tiro del trío cat, grep y awk. Rara vez necesito algo más sofisticado. Por lo general, haré cosas como cat archivo.csv | grep -e $MY_FILTER | awk -F"$SEPARATOR" '{whatever}END{print whatever}'. Para la mayoría de tareas que son de una sola vez, es perfecto: Rápido, está integrado con mi sistema perfectamente y lo entiendo. Si es de más, spark-shell.

- Si el archivo tiene un tamaño manejable pero es para un trabajo recurrente, normalmente escribiría un script. Dependiendo del archivo y de la complejidad de lo que tenga que hacer, tiraré por Python o Clojure.

- Si el archivo es mayor que mi memoria, pero menor que cosas bizarras, seguramente use alguna base de datos. PostgreSQL se está ganando un lugar en mi corazón últimamente y seguramente utilice eso. En otros tiempos habría usando MongoDB o cosas así, pero la edad me ha ganado y, con ella, el sentido común.

- Para cosas más complejas, Spark. En general, si necesito manejar cosas mayores de 100GB, en menos de 10 minutos y tengo un cluster a mano, no existe nada mejor.

He usado cosas como KNIME o Excel, pero rara vez consigo encontrarlos atractivos. Reconozco que se debe en gran medida a que mi entorno de trabajo ha sido siempre sistemas *nix y estoy demasiado acostumbrado a usar terminales y pequeños scripts. Al mismo tiempo, me gusta que mis aplicaciones no se cuelguen y rara vez puedo conseguir eso de manera consistente con Excel y amigos (admito que puede ser porque no sé usarlos eficientemente).

Excel no está pensado para trabajar con grandes volúmenes de datos, aunque PowerQuery sí, el problema es luego guardar los datos. Si te da problemas con archivos grandes, mi consejo es desactivar la opción de "cargar en el modelo de datos", y simplemente que cargue todo en una tabla de Excel. Luego ese mismo archivo lo consultas desde otro libro o programa.

KNIME a mí no se me ha colgado nunca que yo recuerde. Me ha llegado a ir lentísimo, pero ese es otro tema. De todas formas, no sé qué tipo de transformaciones de datos haces, pero a mí la verdad me resultaría muy pesado trabajar sin KNIME.

Yo me quedé con la sensación de que no cubre lo que necesito. Normalmente lo que necesito hacer es una de tres:

- Debuggear un problema en algún punto de nuestra pipeline. Eso normalmente incluye o bien conectarme a presto y empezar a hacer queries o bajarme un csv y empezar a hacer operaciones. Esas queries y operaciones son muy simples, básicamente porque nos aseguramos de machacar mucho los datos antes de meterlos: Sums, counts y avgs. Y ya. Eso awk me lo hace en cero coma.
- Investigar algo. "Oh, este sitio de repente tiene un ad fill menor que X, ¿por qué?" Así que me toca ir al dataset de eventos y empezar a mirar qué le pasa a ése sitio. Eso puede involver operaciones más complejas, pero rara vez lo hace. Y al mismo tiempo, ese dataset está en Hive con Presto encima, así que puedo simplemente escribir SQL queries y no complicarme la vida.
- Agregar o modificar algo en la pipeline. Aquí podría integrarlo, supongo, pero lo cierto es que el set de tools que tenemos instalado funciona bastante bien. Tengo un cluster con más de 1000 cpus a mi disposición para usar con Spark, nuestra propia framework para Spark para correr trabajos frecuentes que ya considera muchas de las cosas más comunes y para cosas menos sofisticadas, postgresql, que es nuestra base de datos de facto.

Luego, para proyectos personales, pasan dos cosas:

- No manejo la misma cantidad de datos ni en pedo. El que estoy haciendo ahora incluye un dataset de 570k rows. Muchísimo más pequeño y manejable. Ese dataset no requiere ni Spark, ni clusters con 1000 cpus, ni Hive, ni Presto, ni pollas.
- Soy un perro viejo y de costumbres ya establecidas, que además está malcriado: A mí me gusta que mis programas terminen al instante o que en su defecto, pueda hacer otras cosas mientras ellos hacen lo suyo. Es decir, no quiero cosas realentizadas, ni mi entorno tildado. En ese sentido estoy dispuesto a sacrificar comodidad. Al mismo tiempo, estoy MUY acostumbrado a las interfaces de terminal de comandos y a herramientas unix. Las interfaces gráficas me marean. Así que para cosas de andar por casa... grep, awk y alguna base de datos modestita.

He intentado usar muchos de esos programas, del palo de PowerQuery y KNIME, y son geniales. Pero no he conseguido que se ajusten a lo que yo busco :/. Algo parecido me pasó con Tableau, por ejemplo: Te reconozco que es muy bueno, pero a mí no me sirve. Entiendo más un alista de números que un gráfico y en la mayoría de los casos, es un overkill. Pa eso uso Python/R/Julia/X para hacer grafiquitas sencillas y ya.

Uno que sí vengo usando bastante, se sale de todo esto que comento y me tiene contento es Redash: Mola. Mola mucho. Su integración con Presto es un poco chapucera, pero es culpa de Presto porque tiene la peor HTTP API del mundo.

[CulitoDeRana]

Y no te aburres leyendo documentación, normalmente de pena? Es que yo esa es la ventaja que le veo a las guis. La documentación puede ser una mierda pero te acabas haciendo con ello.

Yo es que soy un vago tio.

[Frank Zappa]

Je, fair enough. Creo que en mi caso no hay escapatoria: No importa que haga, tendré que consultar documentación. Creo que semanalmente me paso al menos un 10% de mi tiempo leyéndola y es en cosas de las que simplemente no puedo escaparme. Así que añadir un poco más, tampoco me importa (aunque a estas alturas, lo único que consulto de vez en cuando es postgresql). En muchos casos no es problema: La mayor parte de proyectos se toman en serio tener una documentación productiva. Aunque sí hay algunos que da mucha pena. Presto, por ejemplo, es un desastre. En más de una ocasión "leer documentación" significa tener que irme a su puñetero código fuente para entender qué hacen. Uno de los proyectos peor organizados que he visto (poniendo especial énfasis en la API). Luego, la mayoría, son decentillos: Spark tiene documentación general excelente, aunque un poco precaria para cosas específicas. PostgreSQL es de las mejores. La de Scala está bien. La de Python es sobresaliente. La de Clojure da un poco de pena, pero la comunidad es brillante y lo compensa. Y la de otras librerías que uso es lo suficientemente buena.

[CulitoDeRana]

Claro, pero tu eres dev. En mi caso como la documentación sea mala ya tengo un problema, puedo leer codigo, pero me cuesta.

[Jaime]

KNime lo usé durante un tiempo y me pareció un horror. Lo único que quería que me hiciera era ejecutar unas queries de una BBDD, hacer primero unos appends para producir una tabla con registros de distintos clientes y, finalmente, de esa tabla hacer una serie de splits y recombinaciones para un proceso (un poco custom) de validación cruzada. Tardaba la vida y el volumen total de datos ni se acerca a la giga (quizá 300 Mb tirando largo).

El GUI está guay, pero la performance es para echarse a llorar. Teniendo Mac-OS, como veo por tu captura, prueba con DataIku. El GUI es básicamente lo mismo que KNime pero más bonito, y la performance es un par de órdenes de magnitud mejor. Además, permite hacer reports como Dios manda (comparados con los de KNime no hay por dónde empezar).

También te digo que yo con los GUI soy amateur total. Cuando la cosa se me complica y quiero estar seguro de lo que hago, tiro de R, python y Excel. En orden ascendente según simplicidad de la tarea (i.e., la más simple con Excel) y en el orden inverso según lo absurdamente complicado que sea de picar en código (i.e. cuanto más simple la tarea, peor es el código en R).

Al final, una estrategia que yo seguiría habitualmente, sería picar las queries con SQLserver, exportarlas a Excel, hacer allí los stackings y VLOOKUPs que haga falta (dobleplusnoelegante, pero efectivo) y guardar en csv. Luego los csv los leo desde python o R y hago lo que sea. Como trabajo con machine-larning, hago los experimentos en R e implemento las soluciones en python (los módulos lmodels y patsy permiten TRABAJAR EN PYTHON CON FÓRMULAS DE R HOGO HAL DATTO). Por ahora es lo que mejor me funciona y lo que más tiempo y líneas de código me ahorra. Si necesito lanzar datos a aplicaciones web mediante web-sockets (por ejemplo, GeckoBoard) también uso python.

[CulitoDeRana]

KNime lo usé durante un tiempo y me pareció un horror. Lo único que quería que me hiciera era ejecutar unas queries de una BBDD, hacer primero unos appends para producir una tabla con registros de distintos clientes y, finalmente, de esa tabla hacer una serie de splits y recombinaciones para un proceso (un poco custom) de validación cruzada. Tardaba la vida y el volumen total de datos ni se acerca a la giga (quizá 300 Mb tirando largo).

El GUI está guay, pero la performance es para echarse a llorar. Teniendo Mac-OS, como veo por tu captura, prueba con DataIku. El GUI es básicamente lo mismo que KNime pero más bonito, y la performance es un par de órdenes de magnitud mejor. Además, permite hacer reports como Dios manda (comparados con los de KNime no hay por dónde empezar).

También te digo que yo con los GUI soy amateur total. Cuando la cosa se me complica y quiero estar seguro de lo que hago, tiro de R, python y Excel. En orden ascendente según simplicidad de la tarea (i.e., la más simple con Excel) y en el orden inverso según lo absurdamente complicado que sea de picar en código (i.e. cuanto más simple la tarea, peor es el código en R).

Al final, una estrategia que yo seguiría habitualmente, sería picar las queries con SQLserver, exportarlas a Excel, hacer allí los stackings y VLOOKUPs que haga falta y guardar en csv. Luego los csv los leo desde python o R y hago lo que sea. Como trabajo con machine-larning, hago los experimentos en R e implemento las soluciones en python. Por ahora es lo que mejor me funciona y lo que más tiempo y líneas de código me ahorra. Si necesito lanzar datos a otras aplicaciones (por ejemplo, GeckoBoard) también uso python.

Pues tío, algo harías ¿no tendrías la memoria limitada? ¿Te miraste las políticas de memoria? Yo a KNIME le meto unos trotes que flipas eh. No estoy exagerando que uso datasets enormes. Me extraña mucho lo que dices, porque a mí me va mejor que casi cualquier otra que he probado.

Todas esas operaciones que mencionas son bastante comunes y no deberían darte ningún problema. En serio que me extraña bastante. Vamos, yo pasé de SQL -> Excel / R a usar KNIME precisamente porque me ahorra tiempo y me funciona bien. La consulta la hago en KNIME, la transformación también, el análisis bueno, mayormente en KNIME también aunque a veces uso Excel, Gretl, SPSS o movidas así pero es por la costumbre, a mí lo que más me rallaba era el tema de preparar los datasets, curar las movidas, hacer appends y toda esta mierda.

Por otra parte la captura no es mía, no tengo MacOS. Dataiku he leído algo y tal pero eso es free? En el curro puedo pedir licencias pero en casa no xD, tiene server para meterle las operaciones y no tener que ejecutar los workflows en local? En KNIME esto es de pago y es lo que más me jode.

Bueno estoy mirando ahora https://www.dataiku.com/dss/editions/ pinta bien, a ver si la semana que viene puedo echarle un ojo.

No sé, yo lo que intento es simplificar al máximo el curro ahora. 



PD: Si alguien sabe de alguna herramienta de reporting para LAMP que me avise, es para conectarla a la bd del foro y hacer los KPIs

[Frank Zappa]

KNime lo usé durante un tiempo y me pareció un horror. Lo único que quería que me hiciera era ejecutar unas queries de una BBDD, hacer primero unos appends para producir una tabla con registros de distintos clientes y, finalmente, de esa tabla hacer una serie de splits y recombinaciones para un proceso (un poco custom) de validación cruzada. Tardaba la vida y el volumen total de datos ni se acerca a la giga (quizá 300 Mb tirando largo).

El GUI está guay, pero la performance es para echarse a llorar. Teniendo Mac-OS, como veo por tu captura, prueba con DataIku. El GUI es básicamente lo mismo que KNime pero más bonito, y la performance es un par de órdenes de magnitud mejor. Además, permite hacer reports como Dios manda (comparados con los de KNime no hay por dónde empezar).

También te digo que yo con los GUI soy amateur total. Cuando la cosa se me complica y quiero estar seguro de lo que hago, tiro de R, python y Excel. En orden ascendente según simplicidad de la tarea (i.e., la más simple con Excel) y en el orden inverso según lo absurdamente complicado que sea de picar en código (i.e. cuanto más simple la tarea, peor es el código en R).

Al final, una estrategia que yo seguiría habitualmente, sería picar las queries con SQLserver, exportarlas a Excel, hacer allí los stackings y VLOOKUPs que haga falta (dobleplusnoelegante, pero efectivo) y guardar en csv. Luego los csv los leo desde python o R y hago lo que sea. Como trabajo con machine-larning, hago los experimentos en R e implemento las soluciones en python (los módulos lmodels y patsy permiten TRABAJAR EN PYTHON CON FÓRMULAS DE R HOGO HAL DATTO). Por ahora es lo que mejor me funciona y lo que más tiempo y líneas de código me ahorra. Si necesito lanzar datos a aplicaciones web mediante web-sockets (por ejemplo, GeckoBoard) también uso python.

No he conseguido todavía agarrarle el truco a R. No consigo ser eficiente con eso ni para experimentos ni nada. Me parece tan marciano xD. Al final acabo siempre haciendo algún Notebook con Python o Julia o tiro de la spark-shell si no necesito visualizaciones. Es superior a mis fuerzas. Y eso que me gustan los lenguajes funcionales

[CulitoDeRana]

KNime lo usé durante un tiempo y me pareció un horror. Lo único que quería que me hiciera era ejecutar unas queries de una BBDD, hacer primero unos appends para producir una tabla con registros de distintos clientes y, finalmente, de esa tabla hacer una serie de splits y recombinaciones para un proceso (un poco custom) de validación cruzada. Tardaba la vida y el volumen total de datos ni se acerca a la giga (quizá 300 Mb tirando largo).

El GUI está guay, pero la performance es para echarse a llorar. Teniendo Mac-OS, como veo por tu captura, prueba con DataIku. El GUI es básicamente lo mismo que KNime pero más bonito, y la performance es un par de órdenes de magnitud mejor. Además, permite hacer reports como Dios manda (comparados con los de KNime no hay por dónde empezar).

También te digo que yo con los GUI soy amateur total. Cuando la cosa se me complica y quiero estar seguro de lo que hago, tiro de R, python y Excel. En orden ascendente según simplicidad de la tarea (i.e., la más simple con Excel) y en el orden inverso según lo absurdamente complicado que sea de picar en código (i.e. cuanto más simple la tarea, peor es el código en R).

Al final, una estrategia que yo seguiría habitualmente, sería picar las queries con SQLserver, exportarlas a Excel, hacer allí los stackings y VLOOKUPs que haga falta (dobleplusnoelegante, pero efectivo) y guardar en csv. Luego los csv los leo desde python o R y hago lo que sea. Como trabajo con machine-larning, hago los experimentos en R e implemento las soluciones en python (los módulos lmodels y patsy permiten TRABAJAR EN PYTHON CON FÓRMULAS DE R HOGO HAL DATTO). Por ahora es lo que mejor me funciona y lo que más tiempo y líneas de código me ahorra. Si necesito lanzar datos a aplicaciones web mediante web-sockets (por ejemplo, GeckoBoard) también uso python.

No he conseguido todavía agarrarle el truco a R. No consigo ser eficiente con eso ni para experimentos ni nada. Me parece tan marciano xD. Al final acabo siempre haciendo algún Notebook con Python o Julia o tiro de la spark-shell si no necesito visualizaciones. Es superior a mis fuerzas. Y eso que me gustan los lenguajes funcionales

No está pensado para devs, es normal supongo.

[Frank Zappa]

Sí, tienes razón, puede que sea eso. Tengo un buen background en matemáticas, pero siempre he sido un picacódigo y no me metí a análisis de datos hasta hace unos años, así que seguramente tenga una deficiencia por ahí.

Aún así, qué lenguaje más raro.

[Jaime]

KNime lo usé durante un tiempo y me pareció un horror. Lo único que quería que me hiciera era ejecutar unas queries de una BBDD, hacer primero unos appends para producir una tabla con registros de distintos clientes y, finalmente, de esa tabla hacer una serie de splits y recombinaciones para un proceso (un poco custom) de validación cruzada. Tardaba la vida y el volumen total de datos ni se acerca a la giga (quizá 300 Mb tirando largo).

El GUI está guay, pero la performance es para echarse a llorar. Teniendo Mac-OS, como veo por tu captura, prueba con DataIku. El GUI es básicamente lo mismo que KNime pero más bonito, y la performance es un par de órdenes de magnitud mejor. Además, permite hacer reports como Dios manda (comparados con los de KNime no hay por dónde empezar).

También te digo que yo con los GUI soy amateur total. Cuando la cosa se me complica y quiero estar seguro de lo que hago, tiro de R, python y Excel. En orden ascendente según simplicidad de la tarea (i.e., la más simple con Excel) y en el orden inverso según lo absurdamente complicado que sea de picar en código (i.e. cuanto más simple la tarea, peor es el código en R).

Al final, una estrategia que yo seguiría habitualmente, sería picar las queries con SQLserver, exportarlas a Excel, hacer allí los stackings y VLOOKUPs que haga falta (dobleplusnoelegante, pero efectivo) y guardar en csv. Luego los csv los leo desde python o R y hago lo que sea. Como trabajo con machine-larning, hago los experimentos en R e implemento las soluciones en python (los módulos lmodels y patsy permiten TRABAJAR EN PYTHON CON FÓRMULAS DE R HOGO HAL DATTO). Por ahora es lo que mejor me funciona y lo que más tiempo y líneas de código me ahorra. Si necesito lanzar datos a aplicaciones web mediante web-sockets (por ejemplo, GeckoBoard) también uso python.

No he conseguido todavía agarrarle el truco a R. No consigo ser eficiente con eso ni para experimentos ni nada. Me parece tan marciano xD. Al final acabo siempre haciendo algún Notebook con Python o Julia o tiro de la spark-shell si no necesito visualizaciones. Es superior a mis fuerzas. Y eso que me gustan los lenguajes funcionales

R es mayormente un coñazo, pero tiene sus ventajas. Para mí la mayor es que las funciones devuelven objetos que son como estrcuturas de datos particulares. Al final todo anda camuflado en forma de listas anidadas, pero está hecho con cierto ingenio. Para entendernos, la función foo devuelve una variable bar de tipo foo. Gracias a la orden names(bar) puedes ver todo lo que la función foo ha hecho y ha guardado en bar, y con el operador $ puedes añadir sufijos a bar de manera que puedes operar con "porciones" de la variable bar sin tener que redefenir ni hacer cosas raras.

Imaginemos que foo es una función que ajusta un modelo lineal por mínimos cuadrados. Disponemos del dataset foodin para el cual queremos hallar la función lineal que mejor lo apromxima. Llamaremos a foo como siguie:

Code:

>bar <- foo(foodin)

Imagínate que, en lugar del predictor en sí, sólo me interesa cierta información intermedia, por ejemplo los residuales. Podremos obtenerlos si examinamos la variable bar de tipo foo con la instrucción names:

Code:

>names(bar)

>regressor, coefficients, intercept, residuals

De modo que podré a partir de ahora operar con los residuales invocando

Code:

>bar$residuals

>r1,r2,...,rn

Esta manera de hacer las cosas a mí me resulta súmamente flexible para hacer workflows y librerías de funciones custom.

Ahora bien, si quiero que algo funcione en producción, traduzco el core a un script python y hago que el software llame a este script con un bat cuando sea necesario.

[Frank Zappa]

No he conseguido todavía agarrarle el truco a R. No consigo ser eficiente con eso ni para experimentos ni nada. Me parece tan marciano xD. Al final acabo siempre haciendo algún Notebook con Python o Julia o tiro de la spark-shell si no necesito visualizaciones. Es superior a mis fuerzas. Y eso que me gustan los lenguajes funcionales

R es mayormente un coñazo, pero tiene sus ventajas. Para mí la mayor es que las funciones devuelven objetos que son como estrcuturas de datos particulares. Al final todo anda camuflado en forma de listas anidadas, pero está hecho con cierto ingenio. Para entendernos, la función foo devuelve una variable bar de tipo foo. Gracias a la orden names(bar) puedes ver todo lo que la función foo ha hecho y ha guardado en bar, y con el operador $ puedes añadir sufijos a bar de manera que puedes operar con "porciones" de la variable bar sin tener que redefenir ni hacer cosas raras.

Imaginemos que foo es una función que ajusta un modelo lineal por mínimos cuadrados. Disponemos del dataset foodin para el cual queremos hallar la función lineal que mejor lo apromxima. Llamaremos a foo como siguie:

Code:

>bar <- foo(foodin)

Imagínate que, en lugar del predictor en sí, sólo me interesa cierta información intermedia, por ejemplo los residuales. Podremos obtenerlos si examinamos la variable bar de tipo foo con la instrucción names:

Code:

>names(bar)

>regressor, coefficients, intercept, residuals

De modo que podré a partir de ahora operar con los residuales invocando

Code:

>bar$residuals

>r1,r2,...,rn

Esta manera de hacer las cosas a mí me resulta súmamente flexible para hacer workflows y librerías de funciones custom.

Ahora bien, si quiero que algo funcione en producción, traduzco el core a un script python y hago que el software llame a este script con un bat cuando sea necesario.

Sí, esa es la parte que me gusta, es muy "lispy." Mi problema es que tiene la sintaxis más incómoda del mundo y me cuesta mucho pensar de una manera idiomática a R, siempre acabo exasperado a los poco minutos y vuelvo a viejos conocidos. Mis respetos a los que trabajáis con eso en vuestro día a día y no perdéis la cordura.

[Milk]

Ay, esto me va a venir de perlas. Ahora os leo con más detenimiento. ¿Una inexperta como yo podría entenderse con eso? Creo que son herramientas que me van a venir muy bien este curso. Me voy a bajar el software.

¿Podría acosaros a dudas?

[kollapzo]

Ay, esto me va a venir de perlas. Ahora os leo con más detenimiento. ¿Una inexperta como yo podría entenderse con eso? Creo que son herramientas que me van a venir muy bien este curso. Me voy a bajar el software.

¿Podría acosaros a dudas?

¿Cual de los softwares?

[Frank Zappa]

Ay, esto me va a venir de perlas. Ahora os leo con más detenimiento. ¿Una inexperta como yo podría entenderse con eso? Creo que son herramientas que me van a venir muy bien este curso. Me voy a bajar el software.

¿Podría acosaros a dudas?

No estoy seguro de ninguno de los que yo mencioné te vaya a ayudar mucho, son bastante específicos de mi trabajo. Pero R es el lenguaje universal de la estadística y HDP trabaja en algo parecido a lo que tú estudias por lo que he podido leer, así que en principio diría que te pueden servir y deberías ser capaz de entenderlo. ¿Qué es lo que vas a hacer exactamente?

[Milk]

Pues de momento quiero currarme el trabajo de investigación de Sociología de la desviación, y creo que partir de un análisis de un porrón de datos y variables me vendría muy bien. Necesito algo que me permita hacer algo pro, para conseguir la matrícula de honor en esa asignatura.

P.D.: soy muy noob, lo siento. No sé ni si esto me ayudaría realmente, pero estoy dispuesta a aprender.

[Frank Zappa]

Pues de momento quiero currarme el trabajo de investigación de Sociología de la desviación, y creo que partir de un análisis de un porrón de datos y variables me vendría muy bien. Necesito algo que me permita hacer algo pro, para conseguir la matrícula de honor en esa asignatura.

P.D.: soy muy noob, lo siento. No sé ni si esto me ayudaría realmente, pero estoy dispuesta a aprender.

Dejo que te conteste el resto entonces, porque trabajo en una rama completamente distinta y no te quiero dar malos consejos. Pero si tienes los datos, puedes conseguir eso con R seguro y te será útil más adelante, porque como decía, es el estándard de la industria.

Suerte con tu materia ^^

[Milk]

Muchas gracias, Hijitus

A ver si Silvio me ilumina un poco.