¿Puede utilizarse el lenguaje J como alternativa eficaz a Q/Kdb+?

Question

Oigo hablar mucho de Q/kdb+. Nunca he tenido la oportunidad de utilizarlo para nada real, pero he jugado con él utilizando su licencia de prueba y me pareció intrigante (si no algo deformación de la mente). He visto algunas referencias al Lengua J que también es un derivado de APL según Wikipedia y he oído que al menos un operador de quant lo utiliza como sustituto pobre de Q/kdb+.

¿Alguien ha utilizado J en el mundo real? ¿Vale la pena invertir tiempo y energía en aprenderlo, especialmente si no estoy interesado en invertir los dólares necesarios para obtener una licencia kdb+? Sospecho que gran parte del valor de K/Q proviene de la base de datos kdb+ en la que se basa. No estoy seguro de que exista un equivalente para J, pero no he realizado una búsqueda exhaustiva.

Curiosamente, J ha pasado recientemente a ser de código abierto y está alojado (no oficialmente) en Github: https://github.com/openj/core .

EDITAR: Suponiendo que algunos de los aquí presentes estén familiarizados con J y Q/kdb+ pero no hayan utilizado J de forma extensiva en la industria, ¿cuáles podrían ser algunas de las principales ventajas o desventajas de utilizar J?

EDITAR 2: J tiene una solución de base de datos en JDB . Un seguimiento obvio que también pregunté en un comentario a la respuesta de @chrisaycock a continuación es cómo JDB podría compararse con kdb + en términos de funcionalidad.

Answer 1

Tienes razón en que el componente de base de datos es el principal argumento de venta de q/kdb+. De hecho, muchos clientes de Kx utilizan kdb+ sólo para datos de series temporales (y a menudo sólo para el historial de ticks) y no aprovechan las ventajas del lenguaje q. Así que la primera desventaja de utilizar J tal cual sería perder la razón por la que la mayoría de la gente incluso se molesta con Kx: el almacenamiento de datos.

Por supuesto, se puede clonar el almacenamiento de datos de J, como se hace con cualquier otro lenguaje. Lo realmente difícil es inventar tu propia versión de las rutinas de consulta y unión que se encuentran en q.k ese archivo críptico que viene con la distribución del software q.

En relación con JDB La mayor diferencia que encuentro es que no admite particiones. Por ejemplo, kdb+ puede dividir los archivos mapeados en columnas en directorios separados para cada fecha. Esto significa que una consulta select from quotes where date=2011.09.08 hará que kdb+ salte directamente a los ticks de hoy. Llevando esto más lejos, kdb+ soporta threading hasta cierto punto (vía par.txt ) para que pueda procesar varias fechas en paralelo. Y más allá de las ventajas de rendimiento, la partición es prácticamente necesaria para tablas realmente grandes, ya que las columnas se mapean en memoria en el momento de la consulta; no hay forma viable de hacerlo para una base de datos de varios terabytes sin cierta selectividad.

La segunda desventaja es que no hay tantos talleres financieros que utilicen J. Casi todos los grandes bancos tienen una licencia de Kx en alguna parte, por lo que siempre hay un experto si es necesario. J no tiene ni de lejos esa adopción.

Por supuesto, la principal ventaja de J ahora es que es de código abierto. E incluso antes de ser abierto, J Software era más favorable al mundo académico que Kx Systems, por lo que hay más presencia de J en las universidades. Por eso, parece que hay más ejemplos de J en artículos y en el Proyecto Euler que de k o q.

Answer 2

Para añadir a la respuesta de chrisaycock,

J tiene ahora la base de datos Jd (comercial). Es un lenguaje vectorial más puro que q, pero puede utilizarse con la misma sencillez.

Answer 3

Si buscas una alternativa a Q, prueba R. Es un gran lenguaje para modelado y análisis de series temporales. Para una BD, prueba cassandra, que soporta datos particionados, acceso/consultas de alta velocidad.

Lo bueno es que puedes producir rápidamente gráficos y diagramas atractivos en R.

Además, R tiene una gran comunidad en comparación con J. Y todo es de código abierto, con una base sólida y dinámica de usuarios... así que no te quedarás atascado con un código que nadie puede soportar o entender.