Python de backtesting de forex

BigData. Iniciantes. Negociação

BigData. Iniciantes. Negociação

Construindo um sistema de backtesting em Python: ou como eu perdi $ 3400 em duas horas.

Construir um sistema de backtest é realmente muito fácil. Fácil de estragar eu quero dizer. Embora existam toneladas de excelentes bibliotecas por aí (e nós as percorremos em algum momento), eu sempre gosto de fazer isso sozinho para ajustá-las.

De todos os sistemas de backtesting que vi, podemos supor que existem duas categorias:

Hoje, falaremos sobre loopers.

Os "loopers" são o meu tipo favorito de backtesters. Eles são triviais para escrever e super divertidos de se expandir, mas eles têm alguns fluxos vitais e, infelizmente, a maioria dos backtesters por aí é "for-loopers" (ps: eu preciso encontrar um nome melhor para isso!).

Como funcionam os loopers? Usando um loop for (como você deve ter imaginado). É algo assim:

Muito simples né? É assim que funciona um sistema de backtesting, que executa uma estratégia de momentum:

Então qual é o problema?

Muito difícil de escalar (horizontalmente) Precisa de muito trabalho para manter seu apply_strategy () trabalhando em backtesting e produção Você precisa ter tudo na mesma linguagem de programação.

Vamos mergulhar neles, um por um.

Escalabilidade Eu estava experimentando algumas semanas atrás com um algoritmo de escalada para otimizar uma das minhas estratégias. Ainda está em execução. Depois de duas semanas. E eu construo sistemas escaláveis ​​para a vida. Por que ainda está funcionando? Você pode usar multiprocessamento, Disco, produtor / consumidor (usando ZeroMQ) ou apenas threads para acelerar isso, mas alguns problemas não são "paralelos embaraçosos" (sim, este é um termo real, não uma das minhas palavras inventadas). A quantidade de trabalho para escalar um backtester como este (especialmente quando você quer fazer o mesmo aprendizado de máquina em cima dele) é enorme. Você pode fazer isso, mas é o caminho errado.

Produção e backtesting em sincronia. As vezes eu fui mordido por isso. Eu me lembro dos negócios perdidos onde eu estava "hm, porque eu entrei neste comércio?" ou o meu favorito dos velhos tempos "PORQUE PARAR DE TRAILING FOI APLICADO AGORA?"

Hora da história: Eu tive uma idéia para otimizar minha estratégia, para executar um backtester para ver o que aconteceria se eu pudesse colocar uma parada depois que o negócio fosse lucrativo, a fim de sempre garantir lucros. O backtesting funcionou como um encanto, com um aumento de 13% nos lucros e a produção perdeu todos os negócios. Eu percebi isso depois que meu algo perdeu $ 3400 em um par de horas (uma lição muito cara).

Manter o apply_strategy em sincronia é muito difícil e se torna quase impossível quando você quer fazê-lo de maneira distribuída. E você não quer ter duas versões da sua estratégia que são "quase" idênticas. A menos que você tenha $ 3400 de sobra.

Usando diferentes linguagens eu amo o Python. E Erlang. E Clojure. E J. E C. E R. E Ruby (não, na verdade, eu odeio Ruby). Eu quero ser capaz de aproveitar a força de outras linguagens no meu sistema. Eu quero experimentar estratégias em R onde existem bibliotecas muito bem testadas e há uma enorme comunidade por trás disso. Eu quero ter Erlang para escalar meu código e C para processar dados. Se você quer ser bem sucedido (não apenas na negociação), você precisa ser capaz de usar todos os recursos disponíveis sem preconceitos. Eu aprendi toneladas de coisas de sair com desenvolvedores de R sobre como você pode delta de títulos de hedge e visualizá-los ou por que razão de Sharpe pode ser uma mentira. Cada idioma tem uma multidão diferente e você quer tantas pessoas despejando ideias em seu sistema. Se você tentar ter apply_strategy em uma linguagem diferente, então boa sorte com (2).

Você está convencido agora? Bem, eu não estou tentando convencê-lo como para loopers é uma ótima maneira de executar seus testes iniciais. Foi assim que comecei e, para muitas estratégias, não as envio para o pipeline. Um "melhor" caminho (assim você pode dormir à noite) é o gerador de eventos.

Chegando em seguida, compartilhando e discutindo meu mais simples (mas mais bem sucedido) backtester!

Se você tiver mais comentários, envie-me um ping no jonromero ou inscreva-se no boletim informativo.

Outro Jurídico Este é um tutorial de engenharia sobre como construir uma plataforma de algotrading para experimentação e DIVERSÃO. Todas as sugestões aqui não são conselhos financeiros. Se você perder algum (ou todo) dinheiro porque seguiu qualquer aviso de negociação ou implantou este sistema em produção, não poderá culpar este blog aleatório (e / ou eu). Aproveite por sua conta e risco.

Backtesting baseado em eventos com Python - Parte I.

Backtesting baseado em eventos com Python - Parte I.

Nós passamos o último par de meses no QuantStart fazendo backtesting de várias estratégias de negociação utilizando Python e pandas. A natureza vetorizada dos pandas garante que certas operações em grandes conjuntos de dados sejam extremamente rápidas. No entanto, as formas de backtester vetorizado que estudamos até agora sofrem de algumas desvantagens na maneira como a execução da negociação é simulada. Nesta série de artigos, vamos discutir uma abordagem mais realista da simulação de estratégia histórica, construindo um ambiente de backtesting baseado em eventos usando o Python.

Software orientado a eventos.

Antes de nos aprofundarmos no desenvolvimento de um backtester, precisamos entender o conceito de sistemas baseados em eventos. Os videogames fornecem um caso de uso natural para software orientado a eventos e fornecem um exemplo direto para explorar. Um videogame tem vários componentes que interagem entre si em uma configuração em tempo real em altas taxas de quadros. Isso é feito executando todo o conjunto de cálculos dentro de um loop "infinito" conhecido como loop de eventos ou loop de jogos.

A cada tick do loop de jogo, uma função é chamada para receber o último evento, que terá sido gerado por alguma ação prévia correspondente dentro do jogo. Dependendo da natureza do evento, que pode incluir um pressionamento de tecla ou um clique do mouse, alguma ação subseqüente é executada, o que terminará o loop ou gerará alguns eventos adicionais. O processo continuará então. Aqui está um exemplo de pseudo-código:

O código está continuamente verificando novos eventos e, em seguida, realizando ações com base nesses eventos. Em particular, ele permite a ilusão de manipulação de resposta em tempo real, porque o código está continuamente em loop e os eventos são verificados. Como ficará claro, é precisamente disso que precisamos para realizar a simulação de negociação de alta frequência.

Por que um backtester orientado por eventos?

Os sistemas orientados a eventos fornecem muitas vantagens sobre uma abordagem vetorizada:

Reutilização de código - um backtester baseado em eventos, por design, pode ser usado tanto para backtesting histórico quanto para negociação ao vivo com o mínimo de troca de componentes. Isso não é verdade para os backtesters vetorizados, onde todos os dados devem estar disponíveis ao mesmo tempo para realizar a análise estatística. Lookahead Bias - Com um backtester baseado em eventos, não há viés de antecipação, pois o recebimento de dados de mercado é tratado como um "evento" que deve ser considerado. Assim, é possível "drenar" um backtester orientado a eventos com dados de mercado, replicando como um sistema de gerenciamento de pedidos e portfólio se comportaria. Realismo - backtesters orientados a eventos permitem personalização significativa sobre como os pedidos são executados e os custos de transação são incorridos. É fácil lidar com ordens básicas de mercado e de limite, assim como com o mercado aberto (MOO) e com o mercado no fechamento (MOC), já que um manipulador de troca personalizado pode ser construído.

Embora os sistemas baseados em eventos tenham muitos benefícios, eles sofrem de duas grandes desvantagens em relação aos sistemas vetoriais mais simples. Em primeiro lugar, eles são significativamente mais complexos para implementar e testar. Existem mais "partes móveis" que levam a uma maior chance de introduzir bugs. Para mitigar esta metodologia adequada de teste de software, como o desenvolvimento orientado a testes, pode ser empregado.

Em segundo lugar, eles são mais lentos para executar em comparação com um sistema vetorizado. Operações otimizadas vetorizadas não podem ser utilizadas ao realizar cálculos matemáticos. Vamos discutir maneiras de superar essas limitações em artigos posteriores.

Visão geral do backtester orientado a eventos.

Para aplicar uma abordagem orientada a eventos em um sistema de backtesting, é necessário definir nossos componentes (ou objetos) que manipularão tarefas específicas:

Evento - O Evento é a unidade de classe fundamental do sistema baseado em eventos. Ele contém um tipo (como "MARKET", "SIGNAL", "ORDER" ou "FILL") que determina como ele será tratado no loop de eventos. Fila de Eventos - A Fila de Eventos é um objeto Fila Python na memória que armazena todos os objetos de subclasse Event que são gerados pelo restante do software. DataHandler - O DataHandler é uma classe base abstrata (ABC) que apresenta uma interface para lidar com dados históricos ou ao vivo no mercado. Isso proporciona uma flexibilidade significativa, pois os módulos de Estratégia e Portfólio podem ser reutilizados entre as duas abordagens. O DataHandler gera um novo MarketEvent a cada pulsação do sistema (veja abaixo). Estratégia - A Estratégia também é um ABC que apresenta uma interface para obter dados de mercado e gerar SignalEvents correspondentes, que são utilizados pelo objeto Portfolio. Um SignalEvent contém um símbolo, uma direção (LONG ou SHORT) e um timestamp. Portfólio - Este é um ABC que lida com o gerenciamento de pedidos associado às posições atuais e subsequentes de uma estratégia. Ele também executa o gerenciamento de riscos em todo o portfólio, incluindo a exposição do setor e o dimensionamento de posições. Em uma implementação mais sofisticada, isso poderia ser delegado a uma classe RiskManagement. O Portfólio pega SignalEvents da Fila e gera OrderEvents que são adicionados à Fila. ExecutionHandler - O ExecutionHandler simula uma conexão com uma corretora. O trabalho do manipulador é pegar OrderEvents da Fila e executá-los, seja por meio de uma abordagem simulada ou uma conexão real com uma corretora de fígado. Quando as ordens são executadas, o manipulador cria FillEvents, que descreve o que foi realmente transacionado, incluindo taxas, comissão e derrapagem (se modelado). O Loop - Todos esses componentes são agrupados em um loop de eventos que manipula corretamente todos os tipos de eventos, roteando-os para o componente apropriado.

Este é um modelo básico de um mecanismo de negociação. Existe um espaço significativo para expansão, particularmente no que diz respeito à forma como a Carteira é utilizada. Além disso, os diferentes modelos de custo de transação também podem ser abstraídos em sua própria hierarquia de classes. Nesta fase, introduz desnecessária complexidade dentro desta série de artigos, por isso não vamos discutir mais sobre isso. Em tutoriais posteriores, provavelmente expandiremos o sistema para incluir realismo adicional.

Aqui está um trecho de código Python que demonstra como o backtester funciona na prática. Existem dois loops ocorrendo no código. O loop externo é usado para dar ao backtester um heartbeat. Para negociação ao vivo, essa é a frequência com que os novos dados de mercado são pesquisados. Para estratégias de backtesting, isso não é estritamente necessário, já que o backtester usa os dados de mercado fornecidos na forma de alimentação por gotejamento (veja a linha bars. update_bars ()).

O loop interno realmente manipula os eventos do objeto Fila de eventos. Eventos específicos são delegados ao respectivo componente e, subsequentemente, novos eventos são adicionados à fila. Quando os eventos Queue estão vazios, o loop de pulsação continua:

Este é o esboço básico de como um backtester baseado em eventos é projetado. No próximo artigo, discutiremos a hierarquia de classes de eventos.

A Quantcademy.

Participe do portal de associação da Quantcademy que atende à crescente comunidade de traders de quantificação de varejo e aprenda como aumentar a lucratividade de sua estratégia.

Backtesting uma estratégia de previsão para o S & amp; P500 em Python com pandas.

Backtesting uma estratégia de previsão para o S & amp; P500 em Python com pandas.

Recentemente, no QuantStart, discutimos a aprendizagem de máquina, previsão, projeto de backtesting e implementação de backtesting. Vamos agora combinar todas essas ferramentas anteriores para fazer um backtest de um algoritmo de previsão financeira para o índice do mercado acionário americano S & P500, negociando com o ETF do SPY.

Este artigo se baseará no software que já desenvolvemos nos artigos mencionados acima, incluindo o mecanismo de backtesting orientado a objetos e o gerador de sinais de previsão. A natureza da programação orientada a objetos significa que o código que escrevemos posteriormente pode ser mantido curto, já que o "trabalho pesado" é realizado em classes que já desenvolvemos.

Bibliotecas maduras do Python, como matplotlib, pandas e scikit-learn, também reduzem a necessidade de escrever código clichê ou criar nossas próprias implementações de algoritmos bem conhecidos.

A estratégia de previsão.

A estratégia de previsão em si é baseada em uma técnica de aprendizado de máquina conhecida como um analisador discriminante quadrático, que está intimamente relacionado a um analisador discriminante linear. Ambos os modelos são descritos em detalhes no artigo sobre previsão de séries temporais financeiras.

O previsor usa os dois retornos diários anteriores como um conjunto de fatores para prever a direção atual do mercado de ações. Se a probabilidade do dia estar "acima" exceder 50%, a estratégia compra 500 ações do ETF e vende no final do dia. se a probabilidade de um dia de baixa for superior a 50%, a estratégia vende 500 ações do SPY ETF e depois compra de volta no fechamento. Assim, é o nosso primeiro exemplo de uma estratégia de negociação intradiária.

Note que esta não é uma estratégia de negociação particularmente realista! É improvável que consigamos obter um preço de abertura ou fechamento devido a muitos fatores, como a volatilidade excessiva da abertura, o encaminhamento de ordens pela corretora e possíveis problemas de liquidez ao redor da abertura / fechamento. Além disso, não incluímos custos de transação. Estes provavelmente seriam uma porcentagem substancial dos retornos, pois há um comércio de ida e volta realizado todos os dias. Assim, nosso analista precisa ser relativamente preciso na previsão de retornos diários, caso contrário, os custos de transação irão consumir todos os nossos retornos comerciais.

Implementação.

Como com os outros tutoriais relacionados a Python / pandas, usei as seguintes bibliotecas:

A implementação do snp_forecast. py abaixo requer o backtest. py deste tutorial anterior. Além disso, o forecast. py (que contém principalmente a função create_lagged_series) é criado a partir deste tutorial anterior. O primeiro passo é importar os módulos e objetos necessários:

Uma vez que todas as bibliotecas e módulos relevantes tenham sido incluídos, é hora de subclassificar a classe base abstrata Strategy, como fizemos nos tutoriais anteriores. O SNPForecastingStrategy é projetado para ajustar um Analisador Discriminante Quadrático ao índice S & amp; P500 como um meio de prever seu valor futuro. O ajuste do modelo é realizado no método fit_model abaixo, enquanto os sinais reais são gerados a partir do método generate_signals. Isso corresponde à interface de uma classe de estratégia.

Os detalhes de como um analisador discriminante quadrático funciona, assim como a implementação do Python abaixo, são descritos em detalhes no artigo anterior sobre previsão de séries temporais financeiras. Os comentários no código fonte abaixo discutem extensivamente o que o programa está fazendo:

Agora que o mecanismo de previsão produziu os sinais, podemos criar um MarketIntradayPortfolio. Esse objeto de portfólio difere do exemplo dado no artigo de backtest de Moving Average Crossover, uma vez que ele realiza negociações em uma base intraday.

A carteira é projetada para "comprada" (comprar) 500 ações da SPY pelo preço de abertura, se o sinal declarar que um dia útil ocorra e depois vender no fechamento. Por outro lado, o portfólio é projetado para "vender" 500 ações da SPY se o sinal declarar que um dia de baixa ocorrerá e, subsequentemente, fechará o preço de fechamento.

Para alcançar este objetivo, a diferença de preço entre os preços de abertura de mercado e de fechamento de mercado é determinada todos os dias, levando a um cálculo do lucro diário das 500 ações compradas ou vendidas. Isso leva naturalmente a uma curva de capital, somando cumulativamente o lucro / prejuízo para cada dia. Ele também tem o benefício de nos permitir calcular as estatísticas de lucros / perdas para cada dia.

Aqui está a listagem do MarketIntradayPortfolio:

O passo final é vincular os objetos Estratégia e Portfólio com uma função __main__. A função obtém os dados para o instrumento SPY e cria a estratégia de geração de sinal no próprio índice S & P500. Isso é fornecido pelo ticker ^ GSPC. Em seguida, um MarketIntradayPortfolio é gerado com um capital inicial de 100.000 USD (como nos tutoriais anteriores). Finalmente, os retornos são calculados e a curva de capital é plotada.

Observe como é necessário pouco código nesse estágio, porque todo o cálculo pesado é realizado nas subclasses Estratégia e Portfólio. Isso torna extremamente simples criar novas estratégias de negociação e testá-las rapidamente para uso no "pipeline de estratégia".

A saída do programa é dada abaixo. Nesse período, o mercado de ações retornou 4% (assumindo uma estratégia de compra e manutenção totalmente investidas), enquanto o próprio algoritmo também retornou 4%. Observe que os custos de transação (como taxas de comissão) não foram adicionados a este sistema de backtesting. Como a estratégia realiza uma negociação de ida e volta uma vez por dia, essas taxas provavelmente reduzirão significativamente os retornos.

Desempenho da S & amp; P500 Forecasting Strategy de 2005-01-01 a 2006-12-31.

Nos artigos subseqüentes, adicionaremos custos de transação realistas, utilizaremos mecanismos adicionais de previsão, determinaremos métricas de desempenho e forneceremos ferramentas de otimização de portfólio.

A Quantcademy.

Participe do portal de associação da Quantcademy que atende à crescente comunidade de traders de quantificação de varejo e aprenda como aumentar a lucratividade de sua estratégia.

Negociação Algorítmica Bem Sucedida.

Como encontrar novas ideias de estratégia de negociação e avaliá-las objetivamente para o seu portfólio usando um mecanismo de backtesting personalizado no Python.

Comércio Algorítmico Avançado.

Como implementar estratégias de negociação avançadas usando análise de séries temporais, aprendizado de máquina e estatísticas Bayesianas com R e Python.

Forex Mecânico

Negociação no mercado de câmbio usando estratégias de negociação mecânicas.

Backtesting Trading Systems em Python: Não é uma boa escolha.

A linguagem python é extremamente versátil, fácil de usar e conveniente. Não há discussão sobre a versatilidade desta linguagem quando se trata da quantidade de tempo que leva para colocar uma ideia utilizável no código. Quer carregar um arquivo csv? Quer realizar um cálculo de indicador? Quer traçar um conjunto de valores? Todas essas coisas podem ser feitas com apenas algumas linhas de código em python, enquanto certamente seriam necessárias páginas inteiras, se não milhares, de linhas para fazer as mesmas coisas em linguagens como C e Fortran. No entanto python tem várias fraquezas que o tornam uma má escolha quando se trata de back-testing estratégias de negociação, especialmente quando se trata de back-testing baseado em eventos. Neste post irei analisar as diferentes coisas que tornam o python uma má escolha para codificar mecanismos de back-testing e porque & # 8211; apesar do muito mais tempo de codificação & # 8211; os benefícios de usar uma linguagem de nível mais baixo provavelmente superam os problemas para certos tipos de teste. Para realizar o teste abaixo, faça o download do código aqui.

Em geral, é importante entender que há duas maneiras principais de fazer back-testing. O primeiro é o que é chamado de back-testing baseado em vetores e o segundo é chamado de back-testing baseado em eventos. Quando você faz back-tests baseados em vetores, calcula vetores que representam decisões de negociação e, em seguida, faz operações de vetor para extrair o desempenho dessas variáveis. Digamos que você queira fazer back-teste de uma estratégia cruzada de média móvel da forma vetorial, você primeiro calcula um vetor com todos os valores de média móvel, então cria um segundo vetor que contém um booleano com a média móvel maior ou menor que preço, você então usa estes valores para calcular um vetor que representa a equidade de acordo com o local onde você tem sinais, etc. O teste de retorno baseado em vetor faz tudo através de vetores de cálculo e esses vetores são usados ​​para gerar seus resultados de teste. É uma maneira matematicamente eficiente de realizar back-testing de certos tipos de sistemas.

No entanto, existem muitas desvantagens em usar testes baseados em vetores (que deixarei para discutir em um post futuro), o que leva muitas pessoas à alternativa, que são testes baseados em eventos. No back-testing baseado em eventos, você percorre os dados de negociação disponíveis e transmite ao seu algoritmo todas as informações disponíveis em cada ponto no tempo. Este é o caminho do back-testing que mais se aproxima da execução real do mercado, porque sua estratégia é apenas fazer a mesma coisa, é receber dados e tomar decisões sobre cada unidade de tempo quando for necessário. Por essa razão, os back-tests baseados em eventos podem testar todas as estratégias que poderiam ser negociadas no mercado e algoritmos codificados para back-testing baseados em eventos geralmente podem ser usados ​​sem modificações no comércio ao vivo, porque a mecânica é simplesmente a mesma. No back-testing baseado em eventos, você faz uma simulação explícita da sua estratégia através de seus dados, como sua estratégia teria feito no comércio ao vivo (ou pelo menos o mais próximo possível).

Se você deseja codificar um mecanismo de teste de retorno baseado em eventos em python, você enfrentará alguns problemas sérios devido à natureza do python. Você pode ter decidido usar python porque codificar dentro desta linguagem é muito fácil, mas você logo descobrirá que isso tem um grande custo. Se você deseja executar um simples carregamento de dados e um exercício de teste baseado em eventos, provavelmente usará algum código como o mostrado no exemplo acima. Este exemplo carrega dados de um arquivo chamado TEST_60.csv (dados 1H de 1 ano gerados aleatoriamente) e, em seguida, executa um loop simples por todo o dataframe do pandas para calcular a média de 20 bar em cada barra (algo extremamente simples). Fazer este exercício simples leva cerca de 12 a 15 segundos para carregar os dados em um dataframe de pandas & # 8211; principalmente devido à data de análise & # 8211; e depois vários minutos para realizar o exercício de looping. É extremamente lento percorrer um dataframe de pandas porque bibliotecas como pandas simplesmente não são projetadas para executar esse tipo de tarefa, elas são projetadas para operações baseadas em vetores que são otimizadas dentro de funções baseadas em C dentro da biblioteca.

Quando você usa bibliotecas como pandas ou numpy, o custo do loop é realmente muito maior do que o custo de looping através de uma lista python simples, porque essas bibliotecas têm funções ineficientes para acessar elementos únicos dentro de seus objetos porque esse tipo de operação não é para o qual as bibliotecas foram projetadas. Os dataframes e os matrizes numpy do Pandas não devem ser iterados, eles devem ser usados ​​para executar operações baseadas em vetores (essa é a coisa que o Pythonic faz). Você pode executar alguns testes e ver o quanto seu tempo muda quando você altera a função usada para acessar valores dentro do dataframe do pandas, se você mudar de ix para iat ou iloc você notará algumas diferenças importantes nos tempos de execução (veja aqui mais sobre desempenho do método de indexação). Usar uma biblioteca como pandas ou numpy é ótimo em termos da quantidade de tempo de codificação salva, mas se você estiver fazendo back-testing baseado em eventos, nunca terá algo rápido o suficiente.

O custo de executar esse tipo de looping em python torna a linguagem praticamente inútil para qualquer projeto de teste de back-end em grande escala que exija testes baseados em eventos. O loop de barras 1H, codificado acima, leva vários minutos para ser executado e não está nem fazendo cálculos altamente exigentes, ele não está nem acompanhando a equidade, negoceia ou fazendo qualquer geração de sinal. Isso tudo porque looping através de objetos pandas é tremendamente lento. Claro, poderíamos torná-lo mais rápido se não utilizássemos pandas para isso ou se usássemos ctypes, mas, em seguida, você já está se movendo para o território de idiomas de baixo nível. Você está desistindo de algo que é tremendamente amigável para codificar com (pandas) algo mais rápido (ctypes). Se você está disposto a aumentar seu tempo de codificação para ganhar velocidade, então é melhor simplesmente ir para um idioma de nível mais baixo. Se você está gastando 10 vezes mais tempo fazendo o código python mais rápido, então gaste esse tempo codificando-o em C, onde você saberá que será o mais rápido possível.

É claro que não estou argumentando que não há lugar para python em back-testing (afinal, codificamos uma biblioteca de análise de séries temporais de código aberto em python chamada qqpat). Você pode executar testes rápidos baseados em vetores simples usando esta linguagem e se você está disposto a abrir mão das bibliotecas mais fáceis de usar, você pode codificar algo muito mais rápido usando ctypes e acelerar ainda mais usando algo como pypy . No entanto, o melhor uso que eu encontrei para python é realmente usá-lo como um frontend para bibliotecas de back-testing muito mais rápidas codificadas em C / C ++. Em nossa comunidade, usamos python para fazer coisas como carregar configurações, gerar gráficos e carregar arquivos csv, enquanto uma biblioteca C muito mais eficiente realiza o back-testing real baseado em eventos. Fazendo isso, podemos executar backtests de 30 anos inteiros em barras de 1H em questão de segundos, enquanto fazendo isso em python usando bibliotecas fáceis de usar, como pandas, provavelmente levaria 100 vezes o tempo, se não mais. Não é um mistério, então, por que existem simplesmente programas de back-testing baseados em eventos comerciais que usam python, simplesmente não é um corte de linguagem para esse trabalho.

Se você gostaria de aprender mais sobre back-testing e como você também pode codificar e testar estratégias usando nossa estrutura de programação C / C ++, considere juntar-se a Asirikuy, um site repleto de vídeos educacionais, sistemas de negociação, desenvolvimento e um som honesto e transparente. abordagem para negociação automatizada.

Bibliotecas de backtesting de Python para estratégias de negociação Quant.

Escrito por Khang Nguyen Vo, khangvo88 @ gmail, para o blog RobustTechHouse (Mobile App Development Singapore). Khang é formado pelo programa de Mestrado em Finanças Quantitativas e Computacionais, John Von Neumann Institute 2014. Ele é apaixonado por pesquisa em aprendizado de máquina, modelagem preditiva e backtesting de estratégias de negociação.

Bibliotecas de Backtesting de Python frequentemente mencionadas.

É essencial fazer backtest de estratégias de negociação de quant antes de negociá-las com dinheiro real. Aqui, revisamos as bibliotecas de backtesting do Python usadas com frequência. Nós as examinamos em termos de flexibilidade (pode ser usada para backtesting, negociação de papéis e negociação ao vivo), facilidade de uso (boa documentação, boa estrutura) e escalabilidade (velocidade, simplicidade e compatibilidade com outras bibliotecas).

Zipline: Esta é uma estrutura de backtesting baseada em eventos usada pela Quantopian. O Zipline tem uma ótima comunidade, boa documentação, ótimo suporte para a integração Interactive Broker (IB) e Pandas. A sintaxe é clara e fácil de aprender. Tem muitos exemplos. Se o seu principal objetivo de negociação for o patrimônio dos Estados Unidos, esse modelo pode ser o melhor candidato. A Quantopian permite que alguém faça backtest, compartilhe e discuta estratégias de negociação em sua comunidade. No entanto, em nosso experimento, o Zipline é extremamente lento. Essa é a maior desvantagem dessa biblioteca. O Quantopian tem alguma solução alternativa, como executar a biblioteca do Zipline em paralelo na nuvem. Você pode dar uma olhada neste post se isso lhe interessa. Zipline também parece funcionar mal com arquivos locais e dados não-americanos. É difícil usar essa estrutura para diferentes classes de ativos financeiros. PyAlgoTrade: Esta é outra biblioteca orientada a eventos que é ativa e suporta backtesting, negociação de papéis e negociação ao vivo. Ele é bem documentado e também suporta a integração do TA-Lib (biblioteca de análise técnica). Supera o Zipline em termos de velocidade e flexibilidade. No entanto, uma grande desvantagem do PyAlgoTrade é que ele não suporta os módulos Pandas-objeto e Pandas. pybacktest: estrutura de backtesting vetorizada em Python que é muito simples e leve. Este projeto pareceu reviver novamente em 21 de maio de 2015. TradingWithPython: Jev Kuznetsov estendeu a biblioteca de pybacktest e construiu seu próprio backtester. Esta biblioteca parece atualizada recentemente em fevereiro de 2015. No entanto, a documentação e o curso dessa biblioteca custa US $ 395. Alguns outros projetos: ultra-finance.

As bibliotecas de backtesting do Python estão resumidas na tabela a seguir: