Una de las preguntas más frecuentes que recibo en la bolsa de correo es ¿Cuál es el mejor lenguaje de programación para el comercio algorítmico? La respuesta corta es que no existe un lenguaje
En primer lugar, se considerarán los principales componentes de un sistema de negociación algorítmica, como las herramientas de investigación, el optimizador de cartera, el gestor de riesgos y el motor de ejecución. Posteriormente, se examinarán las diferentes estrategias de negociación y cómo afectan al diseño del sistema. En particular, se discutirá la frecuencia de negociación y el volumen probable de negociación.
Una vez que se ha seleccionado la estrategia de negociación, es necesario diseñar todo el sistema. Esto incluye la elección de hardware, el sistema operativo y la resiliencia del sistema contra eventos raros y potencialmente catastróficos. Mientras se considera la arquitectura, se debe prestar la debida atención al rendimiento, tanto a las herramientas de investigación como al entorno de ejecución en vivo.
¿Qué está tratando de hacer el sistema comercial?
Antes de decidir el mejor lenguaje con el que escribir un sistema de negociación automatizado, es necesario definir los requisitos. ¿El sistema se basará puramente en la ejecución? ¿El sistema requerirá un módulo de gestión de riesgos o construcción de cartera? ¿El sistema requerirá un backtester de alto rendimiento?
La investigación se refiere a la evaluación del rendimiento de una estrategia sobre datos históricos. El proceso de evaluación de una estrategia comercial sobre datos de mercado anteriores se conoce como backtesting. El tamaño de los datos y la complejidad algorítmica tendrán un gran impacto en la intensidad computacional del backtester.
La generación de señales se refiere a la generación de un conjunto de señales comerciales a partir de un algoritmo y el envío de tales órdenes al mercado, generalmente a través de un corredor.
Tipo, frecuencia y volumen de la estrategia
El tipo de estrategia algorítmica empleada tendrá un impacto sustancial en el diseño del sistema. Será necesario considerar los mercados en los que se negocie, la conectividad con los proveedores de datos externos, la frecuencia y el volumen de la estrategia, la compensación entre la facilidad de desarrollo y la optimización del rendimiento, así como cualquier hardware personalizado, incluidos servidores personalizados, GPU o FPGA co-localizados que puedan ser necesarios.
Las opciones tecnológicas para una estrategia de acciones estadounidenses de baja frecuencia serán muy diferentes de las de una estrategia de arbitraje estadístico de alta frecuencia en el mercado de futuros.
Es necesario tener en cuenta la conectividad con el proveedor, la estructura de cualquier API, la puntualidad de los datos, los requisitos de almacenamiento y la resiliencia ante un proveedor que se desconecte. También es aconsejable tener acceso rápido a múltiples proveedores!
Es probable que la frecuencia de la estrategia sea uno de los principales factores determinantes de cómo se definirá la pila de tecnología. Las estrategias que emplean datos con más frecuencia que las barras mínimas o secundarias requieren una consideración significativa con respecto al rendimiento.
Una estrategia que exceda las barras secundarias (es decir, los datos de tick) conduce a un diseño basado en el rendimiento como requisito principal. Para las estrategias de alta frecuencia se necesitará almacenar y evaluar una cantidad sustancial de datos de mercado.
Para procesar los grandes volúmenes de datos necesarios para las aplicaciones HFT, se debe utilizar un sistema de backtester y ejecución ampliamente optimizado. C / C ++ (posiblemente con algún ensamblador) es probablemente el candidato de lenguaje más fuerte.
Sistemas de investigación
Los sistemas de investigación suelen implicar una mezcla de desarrollo interactivo y scripting automatizado. El primero a menudo tiene lugar dentro de un IDE como Visual Studio, MatLab o R Studio. El segundo implica extensos cálculos numéricos sobre numerosos parámetros y puntos de datos. Esto conduce a una elección de lenguaje que proporciona un entorno sencillo para probar el código, pero también proporciona un rendimiento suficiente para evaluar estrategias sobre múltiples dimensiones de parámetros.
Los IDE típicos en este espacio incluyen Microsoft Visual C ++ / C #, que contiene extensas utilidades de depuración, capacidades de finalización de código (a través de
Para backtesting numérico, todos los lenguajes anteriores son adecuados, aunque no es necesario utilizar una GUI/IDE ya que el código se ejecutará
Los lenguajes interpretados como Python a menudo utilizan bibliotecas de alto rendimiento como NumPy/pandas para el paso de backtesting, con el fin de mantener un grado razonable de competitividad con equivalentes compilados.
Construcción de cartera y gestión de riesgos
La construcción de la cartera y los componentes de gestión de riesgos a menudo son pasados por alto por los operadores algoritmicos minoristas. Esto es casi siempre un error. Estas herramientas proporcionan el mecanismo por el cual se preservará el capital.
Las versiones sofisticadas de estos componentes pueden tener un efecto significativo en la calidad y la consistencia de la rentabilidad. Es sencillo crear una estrategia estable ya que el mecanismo de construcción de cartera y el gestor de riesgos pueden modificarse fácilmente para manejar múltiples sistemas. Por lo tanto, deben considerarse componentes esenciales al principio del diseño de un sistema de negociación algorítmica.
El trabajo del sistema de construcción de cartera es tomar un conjunto de operaciones deseadas y producir el conjunto de operaciones reales que minimizan el desgaste, mantienen las exposiciones a varios factores (como sectores, clases de activos, volatilidad, etc.) y optimizan la asignación de capital a varias estrategias en una cartera.
La construcción de carteras se reduce a menudo a un problema de álgebra lineal (como una factorización de matrices) y por lo tanto el rendimiento depende en gran medida de la efectividad de la implementación de álgebra lineal numérica disponible. Las bibliotecas comunes incluyen uBLAS, LAPACK y NAG para C ++. MatLab también posee operaciones de matrices ampliamente optimizadas. Python utiliza NumPy / SciPy para tales cálculos.
La gestión de riesgos es otra parte extremadamente importante de un sistema de negociación algorítmica. El riesgo puede presentarse de muchas formas: aumento de la volatilidad (aunque esto puede verse como deseable para ciertas estrategias!), aumento de las correlaciones entre las clases de activos, incumplimiento de la contraparte, interrupciones de servidores, eventos de cisne negro y errores no detectados en el código de negociación, por nombrar algunos.
Los componentes de gestión de riesgos tratan de anticipar los efectos de la volatilidad excesiva y la correlación entre las clases de activos y su posterior efecto sobre el capital comercial. A menudo esto se reduce a un conjunto de cálculos estadísticos como las pruebas de Monte Carlo. Esto es muy similar a las necesidades computacionales de un motor de precios de derivados y, como tal, estará ligado a la CPU. Estas simulaciones son altamente paralelables (ver más abajo) y, hasta cierto punto, es posible "lanzar hardware al problema".
Sistemas de ejecución
El trabajo del sistema de ejecución es recibir señales de negociación filtradas de los componentes de construcción de cartera y gestión de riesgos y enviarlas a una correduría u otros medios de acceso al mercado. Para la mayoría de las estrategias de comercio algorítmico minorista, esto implica una conexión API o FIX a una correduría como Interactive Brokers.
La
La mayoría de las APIs proporcionan una interfaz C++ y/o Java. Por lo general, depende de la comunidad desarrollar envases específicos de lenguaje para C#, Python, R, Excel y MatLab. Tenga en cuenta que con cada complemento adicional utilizado (especialmente envases de API) hay margen para que los errores se infiltren en el sistema. Siempre pruebe plugins de este tipo y asegúrese de que se mantengan activamente.
La frecuencia de ejecución es de suma importancia en el algoritmo de ejecución. Tenga en cuenta que cientos de órdenes pueden enviarse cada minuto y, como tal, el rendimiento es crítico.
Los lenguajes de tipo estático (ver más abajo) como C ++ / Java son generalmente óptimos para la ejecución, pero hay una compensación en el tiempo de desarrollo, las pruebas y la facilidad de mantenimiento. Los lenguajes de tipo dinámico, como Python y Perl, ahora son generalmente lo suficientemente rápidos. Siempre asegúrese de que los componentes estén diseñados de manera modular (ver más abajo) para que puedan intercambiarse a medida que el sistema se escala.
Proceso de planificación y desarrollo arquitectónico
Los componentes de un sistema de negociación, sus requisitos de frecuencia y volumen se han discutido anteriormente, pero aún no se ha cubierto la infraestructura del sistema. Los que actúan como comerciantes minoristas o trabajan en un fondo pequeño probablemente estarán "llevándose muchos sombreros". Será necesario cubrir el modelo alfa, la gestión de riesgos y los parámetros de ejecución, y también la implementación final del sistema. Antes de profundizar en lenguajes específicos, se discutirá el diseño de una arquitectura de sistema óptima.
La separación de las preocupaciones
Una de las decisiones más importantes que se deben tomar desde el principio es cómo separar las preocupaciones de un sistema de negociación.
Al exponer interfaces en cada uno de los componentes, es fácil cambiar partes del sistema por otras versiones que ayudan al rendimiento, la confiabilidad o el mantenimiento, sin modificar ningún código de dependencia externa. Esta es la "mejor práctica" para tales sistemas. Para estrategias en frecuencias más bajas, se recomiendan tales prácticas. Para el comercio de ultra alta frecuencia, es posible que deba ignorarse el libro de reglas a expensas de ajustar el sistema para obtener aún más rendimiento.
Sin embargo, un enfoque óptimo es asegurarse de que haya componentes separados para las entradas de datos de mercado históricos y en tiempo real, almacenamiento de datos, API de acceso a datos, backtester, parámetros de estrategia, construcción de cartera, gestión de riesgos y sistemas de ejecución automatizados.
Por ejemplo, si el almacén de datos que se está utilizando actualmente tiene un rendimiento inferior, incluso a niveles significativos de optimización, se puede reemplazar con reescrituras mínimas en la API de ingestión de datos o acceso a datos.
Otro beneficio de los componentes separados es que permite que se utilicen una variedad de lenguajes de programación en el sistema general. No hay necesidad de limitarse a un solo idioma si el método de comunicación de los componentes es independiente del idioma.
Como ejemplo concreto, considere el caso de un sistema de backtesting escrito en C++ para el rendimiento de
Consideraciones de rendimiento
El rendimiento es una consideración importante para la mayoría de las estrategias comerciales. Para las estrategias de mayor frecuencia es el factor más importante. El rendimiento cubre una amplia gama de problemas, como la velocidad de ejecución algorítmica, la latencia de la red, el ancho de banda, la entrada y salida de datos, la concurrencia / paralelismo y el escalado. Cada una de estas áreas están cubiertas individualmente por grandes libros de texto, por lo que este artículo solo rascará la superficie de cada tema.
La sabiduría predominante según lo declarado por Donald Knuth, uno de los padres de la Ciencia de la Computación, es que
Las herramientas de perfiles se utilizan para determinar dónde surgen los cuellos de botella. Los perfiles se pueden hacer para todos los factores enumerados anteriormente, ya sea en un entorno de MS Windows o Linux. Hay muchos sistemas operativos y herramientas de lenguaje disponibles para hacerlo, así como utilidades de terceros.
C++, Java, Python, R y MatLab contienen bibliotecas de alto rendimiento (ya sea como parte de su estándar o externamente) para la estructura de datos básica y el trabajo algorítmico.
Una excepción es si se requiere una arquitectura de hardware altamente personalizada y un algoritmo está haciendo un uso extensivo de extensiones propietarias (como caché personalizado). Sin embargo, a menudo
La latencia es a menudo un problema del sistema de ejecución, ya que las herramientas de investigación generalmente están situadas en la misma máquina. Para el primero, la latencia puede ocurrir en múltiples puntos a lo largo de la ruta de ejecución. Las bases de datos deben consultarse (latencia de disco / red), las señales deben generarse (sistema operativo, latencia de mensajería del núcleo), las señales comerciales enviadas (latencia de NIC) y los pedidos procesados (latencia interna de los sistemas de intercambio).
Para las operaciones de mayor frecuencia es necesario familiarizarse íntimamente con la optimización del núcleo, así como con la optimización de la transmisión de la red.
El almacenamiento en caché es muy útil en el conjunto de herramientas de un desarrollador de comercio cuantitativo. El almacenamiento en caché se refiere al concepto de almacenar datos a los que se accede con frecuencia de una manera que permita un acceso de mayor rendimiento, a expensas de la estancamiento potencial de los datos. Un caso de uso común ocurre en el desarrollo web cuando se toman datos de una base de datos relacional respaldada por disco y se ponen en memoria.
Por ejemplo, el estado actual de una cartera de estrategias puede almacenarse en una caché hasta que se reequilibre, de modo que la lista no necesite ser regenerada en cada bucle del algoritmo de negociación.
Sin embargo, el almacenamiento en caché no está exento de sus propios problemas. La regeneración de datos de caché a la vez, debido a la naturaleza volátil del almacenamiento en caché, puede generar una demanda significativa en la infraestructura.
La asignación dinámica de memoria es una operación costosa en la ejecución de software. Por lo tanto, es imperativo que las aplicaciones de comercio de alto rendimiento estén bien conscientes de cómo se asigna y desaloja la memoria durante el flujo del programa.
La recolección de basura es extremadamente útil durante el desarrollo ya que reduce los errores y ayuda a la legibilidad. Sin embargo, a menudo es subóptima para ciertas estrategias de comercio de alta frecuencia.
C++ no proporciona un colector de basura nativo y por lo tanto es necesario manejar toda la asignación/desalocación de memoria como parte de la implementación de un objeto. Si bien es potencialmente propenso a errores (que potencialmente conducen a punteros colgantes), es extremadamente útil tener un control de grano fino de cómo los objetos aparecen en el montón para ciertas aplicaciones.
Muchas operaciones en los sistemas de negociación algorítmicos son susceptibles a la paralela. Esto se refiere al concepto de llevar a cabo múltiples operaciones programáticas al mismo tiempo, es decir, en paralelo. Los llamados algoritmos paralelamente embarazosos incluyen pasos que se pueden calcular completamente independientemente de otros pasos. Ciertas operaciones estadísticas, como las simulaciones de Monte Carlo, son un buen ejemplo de algoritmos paralelamente embarazosos, ya que cada sorteo aleatorio y la operación de ruta posterior se pueden calcular sin conocimiento de otras rutas.
Otros algoritmos son solo parcialmente paralelables. Las simulaciones de dinámica de fluidos son un ejemplo de ello, donde el dominio de cálculo se puede subdividir, pero en última instancia estos dominios deben comunicarse entre sí y, por lo tanto, las operaciones son parcialmente secuenciales. Los algoritmos paralelables están sujetos a la Ley de Amdahl, que proporciona un límite superior teórico para el aumento del rendimiento de un algoritmo paralelo cuando está sujeto a procesos separados NN (por ejemplo, en un núcleo o hilo de la CPU).
La paralelalización se ha vuelto cada vez más importante como un medio de optimización ya que las velocidades del reloj del procesador se han estancado, ya que los procesadores más nuevos contienen muchos núcleos con los que realizar cálculos paralelos.
Este tipo de hardware de GPU es generalmente adecuado sólo para el aspecto de investigación de las finanzas cuantitativas, mientras que otros hardware más especializados (incluidos los Field-Programmable Gate Arrays - FPGA) se utilizan para (U) HFT. Hoy en día, la mayoría de los lenguajes modernos admiten un grado de concurrencia / multithreading. Por lo tanto, es sencillo optimizar un backtester, ya que todos los cálculos son generalmente independientes de los demás.
La escalabilidad en ingeniería de software y operaciones se refiere a la capacidad del sistema para manejar cargas cada vez mayores en forma de mayores solicitudes, mayor uso del procesador y más asignación de memoria.
Si bien los sistemas deben diseñarse para escalar, a menudo es difícil predecir de antemano dónde ocurrirá un cuello de botella. El registro, las pruebas, el perfil y el monitoreo rigurosos ayudarán enormemente a permitir que un sistema se escale. Los lenguajes en sí mismos a menudo se describen como "no escalables". Esto generalmente es el resultado de la desinformación, en lugar de un hecho concreto.
Una forma de administrar la escala es separar las preocupaciones, como se mencionó anteriormente. Para introducir aún más la capacidad de manejar
En lugar de que las solicitudes se pierdan, simplemente se mantienen en una pila hasta que se maneja el mensaje. Esto es particularmente útil para enviar operaciones a un motor de ejecución. Si el motor está sufriendo una latencia alta, entonces realizará copias de seguridad de las operaciones. Una cola entre el generador de señales comerciales y la API de ejecución aliviará este problema a expensas de un posible deslizamiento comercial.
Hardware y sistemas operativos
El hardware que ejecuta su estrategia puede tener un impacto significativo en la rentabilidad de su algoritmo. Este no es un problema restringido a los operadores de alta frecuencia tampoco. Una mala elección en el hardware y el sistema operativo puede conducir a un accidente de la máquina o reiniciar en el momento más inoportuno. Por lo tanto, es necesario considerar dónde residirá su aplicación. La elección es generalmente entre una máquina de escritorio personal, un servidor remoto, un proveedor de
Las máquinas de escritorio son fáciles de instalar y administrar, especialmente con los nuevos sistemas operativos amigables para el usuario como Windows 7/8, Mac OSX y Ubuntu. Los sistemas de escritorio poseen algunos inconvenientes significativos, sin embargo.
El uso de hardware en un entorno doméstico (o de oficina local) puede conducir a problemas de conectividad a Internet y de disponibilidad de energía.
Un servidor dedicado o una máquina basada en la nube, aunque a menudo es más caro que una opción de escritorio, permite una infraestructura de redundancia más significativa, como copias de seguridad automatizadas de datos, la capacidad de garantizar de manera más directa el tiempo de actividad y la monitorización remota.
En Windows, esto generalmente se hace a través del Protocolo de escritorio remoto de la interfaz gráfica (RDP). En los sistemas basados en Unix, se utiliza la línea de comandos Secure Shell (SSH). La infraestructura del servidor basada en Unix casi siempre se basa en la línea de comandos, lo que inmediatamente hace que las herramientas de programación basadas en la interfaz gráfica (como MatLab o Excel) sean inutilizables.
Un servidor co-localizado, como se usa la frase en los mercados de capitales, es simplemente un servidor dedicado que reside dentro de un intercambio para reducir la latencia del algoritmo de negociación.
El aspecto final para la elección de hardware y la elección del lenguaje de programación es la independencia de la plataforma. ¿Hay necesidad de que el código se ejecute en múltiples sistemas operativos diferentes? ¿El código está diseñado para ejecutarse en un tipo particular de arquitectura de procesador, como el Intel x86/x64 o será posible ejecutarse en procesadores RISC como los fabricados por ARM? Estos problemas dependerán en gran medida de la frecuencia y el tipo de estrategia que se implemente.
Resiliencia y pruebas
Una de las mejores maneras de perder mucho dinero en el comercio algorítmico es crear un sistema sin resiliencia. Esto se refiere a la durabilidad del sistema cuando está sujeto a eventos raros, como quiebras de correduría, volatilidad excesiva repentina, tiempo de inactividad en toda la región para un proveedor de servidor en la nube o la eliminación accidental de una base de datos comercial completa. Años de ganancias se pueden eliminar en cuestión de segundos con una arquitectura mal diseñada. Es absolutamente esencial considerar temas como depuración, prueba, registro, copias de seguridad, alta disponibilidad y monitoreo como componentes centrales de su sistema.
Es probable que en cualquier aplicación comercial cuantitativa personalizada razonablemente complicada al menos el 50% del tiempo de desarrollo se gaste en depuración, pruebas y mantenimiento.
Casi todos los lenguajes de programación se envían con un depurador asociado o poseen alternativas de terceros bien respetadas. En esencia, un depurador permite la ejecución de un programa con la inserción de puntos de interrupción arbitrarios en la ruta del código, que detienen temporalmente la ejecución para investigar el estado del sistema.
La depuración es un componente esencial en la caja de herramientas para analizar errores de programación. Sin embargo, se utilizan más ampliamente en lenguajes compilados como C ++ o Java, ya que los lenguajes interpretados como Python a menudo son más fáciles de depurar debido a menos LOC y menos declaraciones verbales. A pesar de esta tendencia, Python se envía con el pdb, que es una herramienta de depuración sofisticada.
La prueba en el desarrollo de software se refiere al proceso de aplicación de parámetros conocidos y resultados a funciones, métodos y objetos específicos dentro de una base de código, con el fin de simular el comportamiento y evaluar múltiples rutas de código, lo que ayuda a garantizar que un sistema se comporte como debería. Un paradigma más reciente se conoce como Desarrollo Directo a Pruebas (TDD), donde el código de prueba se desarrolla contra una interfaz especificada sin implementación. Antes de la finalización de la base de código real, todas las pruebas fallarán.
TDD requiere un amplio diseño de especificación inicial, así como un grado saludable de disciplina para llevarlo a cabo con éxito. En C++, Boost proporciona un marco de pruebas unitarias. En Java, la biblioteca JUnit existe para cumplir con el mismo propósito. Python también tiene el módulo unittest como parte de la biblioteca estándar. Muchos otros lenguajes poseen marcos de pruebas unitarias y a menudo hay múltiples opciones.
En un entorno de producción, el registro sofisticado es absolutamente esencial. El registro se refiere al proceso de salida de mensajes, con diversos grados de severidad, con respecto al comportamiento de ejecución de un sistema a un archivo plano o base de datos. Los registros son una "primera línea de ataque" cuando se busca un comportamiento inesperado en el tiempo de ejecución del programa.
Tanto Microsoft Windows como Linux vienen con una amplia capacidad de registro del sistema y los lenguajes de programación tienden a suministrarse con bibliotecas de registro estándar que cubren la mayoría de los casos de uso.
Si bien el registro de un sistema proporcionará información sobre lo que ha ocurrido en el pasado, el monitoreo de una aplicación proporcionará información sobre lo que está sucediendo en este momento. Todos los aspectos del sistema deben considerarse para el monitoreo. Las métricas a nivel del sistema como el uso del disco, la memoria disponible, el ancho de banda de la red y el uso de la CPU proporcionan información básica de carga.
Las métricas de negociación tales como precios/volumen anormales, reducciones repentinas y rápidas y exposición de la cuenta para diferentes sectores/mercados también deben ser monitoreadas continuamente.
El monitoreo del sistema es a menudo el dominio del administrador del sistema o el gerente de operaciones. Sin embargo, como desarrollador comercial único, estas métricas deben establecerse como parte del diseño más amplio. Existen muchas soluciones para el monitoreo: propietarias, alojadas y de código abierto, que permiten una amplia personalización de las métricas para un caso de uso particular.
Las copias de seguridad y la alta disponibilidad deben ser las principales preocupaciones de un sistema de negociación. Considere las siguientes dos preguntas: 1) Si una base de datos de producción completa de datos de mercado e historial de negociación se eliminara (sin copias de seguridad), ¿cómo se vería afectado el algoritmo de investigación y ejecución? 2) Si el sistema de negociación sufre una interrupción durante un período prolongado (con posiciones abiertas), ¿cómo se verían afectadas la equidad de la cuenta y la rentabilidad continua?
Es imperativo poner en marcha un sistema para hacer copias de seguridad de los datos y también para probar la restauración de dichos datos. Muchas personas no prueban una estrategia de restauración.
De manera similar, la alta disponibilidad debe ser
Escoger el idioma
Se ha proporcionado ahora un detalle considerable sobre los diversos factores que surgen al desarrollar un sistema de comercio algorítmico de alto rendimiento personalizado.
Sistemas de tipo
Cuando se elige un lenguaje para una pila de operaciones es necesario considerar el sistema de tipos. Los lenguajes que son de interés para el comercio algorítmico son de tipo estático o dinámico. Un lenguaje de tipo estático realiza comprobaciones de tipos (por ejemplo, enteros, flotadores, clases personalizadas, etc.) durante el proceso de compilación.
Para un sistema altamente numérico como un motor de comercio algorítmico, la comprobación de tipo en el tiempo de compilación puede ser extremadamente beneficiosa, ya que puede eliminar muchos errores que de otro modo conducirían a errores numéricos. Sin embargo, la comprobación de tipo no lo captura todo, y aquí es donde entra en juego el manejo de excepciones debido a la necesidad de tener que manejar operaciones inesperadas. Los lenguajes dinámicos (es decir, los que están tipados dinámicamente) a menudo pueden conducir a errores de tiempo de ejecución que de otro modo se capturarían con una comprobación de tipo en el tiempo de compilación. Por esta razón, surgió el concepto de TDD (ver arriba) y pruebas unitarias que, cuando se llevan a cabo correctamente, a menudo proporcionan más seguridad que la comprobación de tiempo de compilación sola.
Otro beneficio de los lenguajes de tipo estático es que el compilador es capaz de hacer muchas optimizaciones que de otro modo no están disponibles para el lenguaje de tipo dinámico, simplemente porque el tipo (y por lo tanto los requisitos de memoria) se conocen en el momento de la compilación.
¿Fuente abierta o propiedad?
Una de las mayores opciones disponibles para un desarrollador de comercio algorítmico es si utilizar tecnologías propietarias (comerciales) o de código abierto. Hay ventajas y desventajas para ambos enfoques. Es necesario considerar qué tan bien se admite un idioma, la actividad de la comunidad que rodea un idioma, la facilidad de instalación y mantenimiento, la calidad de la documentación y cualquier costo de licencia / mantenimiento.
La pila Microsoft.NET (incluyendo Visual C++, Visual C#) y MathWorks
Microsoft y MathWorks proporcionan una amplia documentación de alta calidad para sus productos. Además, las comunidades que rodean a cada herramienta son muy grandes con foros web activos para ambos. El software.NET permite una integración cohesiva con múltiples lenguajes como C ++, C # y VB, así como un fácil enlace con otros productos de Microsoft como la base de datos SQL Server a través de LINQ. MatLab también tiene muchos plugins / bibliotecas (algunos gratuitos, algunos comerciales) para casi cualquier dominio de investigación cuantitativa.
También hay inconvenientes. Con cualquiera de las piezas de software, los costos no son insignificantes para un comerciante solitario (aunque Microsoft proporciona una versión de nivel de entrada de Visual Studio de forma gratuita). Las herramientas de Microsoft
MatLab también carece de algunos complementos clave, como un buen envoltorio alrededor de la API de Interactive Brokers, uno de los pocos corredores susceptibles a la negociación algorítmica de alto rendimiento. El principal problema con los productos propietarios es la falta de disponibilidad del código fuente.
Las herramientas de código abierto han sido de calidad industrial durante algún tiempo. Gran parte del espacio de activos alternativos hace un uso extensivo de Linux de código abierto, MySQL / PostgreSQL, Python, R, C ++ y Java en roles de producción de alto rendimiento. Sin embargo, están lejos de estar restringidos a este dominio. Python y R, en particular, contienen una gran cantidad de extensas bibliotecas numéricas para realizar casi cualquier tipo de análisis de datos imaginable, a menudo a velocidades de ejecución comparables a los lenguajes compilados, con ciertas advertencias.
El principal beneficio de usar lenguajes interpretados es la velocidad del tiempo de desarrollo. Python y R requieren muchas menos líneas de código (LOC) para lograr una funcionalidad similar, principalmente debido a las extensas bibliotecas. Además, a menudo permiten el desarrollo basado en consolas interactivas, reduciendo rápidamente el proceso de desarrollo iterativo.
Dado que el tiempo como desarrollador es extremadamente valioso, y la velocidad de ejecución a menudo menos (salvo en el espacio HFT), vale la pena dar una consideración extensa a una pila de tecnología de código abierto. Python y R poseen comunidades de desarrollo significativas y están extremadamente bien apoyadas, debido a su popularidad.
Las herramientas de código abierto a menudo sufren de la falta de un contrato de soporte comercial dedicado y funcionan de manera óptima en sistemas con interfaces de usuario menos tolerantes. Un servidor Linux típico (como Ubuntu) a menudo estará completamente orientado a la línea de comandos. Además, Python y R pueden ser lentos para ciertas tareas de ejecución.
Si bien el software propietario no es inmune a los problemas de dependencia / versión, es mucho menos común tener que lidiar con versiones incorrectas de la biblioteca en tales entornos.
Me atreveré a mi opinión personal aquí y declararé que construyo todas mis herramientas comerciales con tecnologías de código abierto. En particular, uso: Ubuntu, MySQL, Python, C ++ y R. La madurez, el tamaño de la comunidad, la capacidad de "excavar profundamente" si ocurren problemas y el menor costo total de propiedad (TCO) superan con creces la simplicidad de las interfaces gráficas de usuario propietarias y las instalaciones más fáciles.
¿Las baterías incluidas?
El encabezado de esta sección se refiere a las capacidades del lenguaje: qué bibliotecas contiene y qué tan buenas son? Aquí es donde los lenguajes maduros tienen una ventaja sobre las variantes más nuevas.
Python es conocido por ser capaz de comunicarse con casi cualquier otro tipo de sistema/protocolo (especialmente la web), principalmente a través de su propia biblioteca estándar. R tiene una gran cantidad de herramientas estadísticas y econométricas incorporadas, mientras que MatLab está extremadamente optimizado para cualquier código de álgebra lineal numérica (que se puede encontrar en la optimización de carteras y precios de derivados, por ejemplo).
Fuera de las bibliotecas estándar, C++ hace uso de la biblioteca Boost, que llena las partes faltantes de la biblioteca estándar.
Python tiene la combinación de biblioteca de análisis de datos NumPy / SciPy / Panda de alto rendimiento, que ha ganado una amplia aceptación para la investigación de comercio algorítmico. Además, existen complementos de alto rendimiento para acceder a las principales bases de datos relacionales, como MySQL ++ (MySQL / C ++), JDBC (Java / MatLab), MySQLdb (MySQL / Python) y psychopg2 (PostgreSQL / Python).
Un aspecto a menudo pasado por alto de un sistema de negociación mientras en la etapa inicial de investigación y diseño es la conectividad a una API de corredor. La mayoría de las API soportan nativamente C ++ y Java, pero algunas también soportan C # y Python, ya sea directamente o con código de envoltura proporcionado por la comunidad a las API de C ++. En particular, los corredores interactivos se pueden conectar a través del complemento IBPy. Si se requiere un alto rendimiento, los corredores admitirán el protocolo FIX.
Conclusión
Como ahora es evidente, la elección de lenguajes de programación para un sistema de comercio algorítmico no es sencilla y requiere una reflexión profunda. Las consideraciones principales son el rendimiento, la facilidad de desarrollo, la resiliencia y las pruebas, la separación de preocupaciones, la familiaridad, el mantenimiento, la disponibilidad del código fuente, los costos de licencia y la madurez de las bibliotecas.
El beneficio de una arquitectura separada es que permite que los idiomas se "conecten" para diferentes aspectos de una pila de comercio, a medida que cambian los requisitos.