ja_mageia

O que pode ser acrescentado ao artigo em que já tratamos desta operação, agora que ela foi estopada com 14,4% de prejuízo?

Em primeiro lugar, pode-se perguntar se isso muda alguma coisa. E a resposta é que, do ponto de vista técnico, tudo permanece praticamente igual. Mas do ponto de vista publicitário, é um resultado ruim, por causar um impacto psicológico, agravado pelo fato de ser um sistema que até então não levara nenhum stop loss em 10 anos de back tests e 5 meses de conta demonstrativa, sobre o qual as expectativas são muito grandes, e isso tornou o resultado mais traumático. Se o mesmo tivesse sucedido a uma versão em que os stops fossem mais freqüentes, haveria menos surpresa, ou se tivesse ocorrido depois de várias operações lucrativas, também não causaria esse impacto. As outras versões que estão positivas em 5%, 7%, 4% não são tão boas quanto o Saturno V 3.1415926c, mesmo depois deste resultado. O fato de ele ter sofrido este viés não o tira do topo, ele continua sendo o melhor para longo prazo.

O que deveria ser feito para evitar que algo assim se repita? A resposta é: provavelmente não queremos evitar. Queremos que isso se repita sempre, com 127 operações positivas consecutivas e 1 negativa. Mudar algo, por enquanto, com base apenas nesse evento, não me parece plausível, pois o fato de ser uma operação em conta real não confere a ela maior peso, do ponto de vista técnico, do que algumas operações em contas demonstrativas e centenas em back test. A mudança em qualquer parâmetro visando evitar que ele entre nesta operação específica e seja estopado, ou visando que ele saia antes de o movimento inverter, ou que ele seja estopado mais cedo, nos três casos, além de representar um grave erro metodológico (isso seria um ajuste a posteriori dos parâmetros para evitar um fato que não seria possível conhecer com antecipação), implicaria também afetar várias outras operações bem-sucedidas, tornando o resultado global pior. O parâmetro que pode ser modificado com maior flexibilidade sem interferir muito na performance é o tamanho do stop loss fixo. Com stop acima de 30 pips ele já funciona conforme gráfico abaixo (30 pips nesse caso):

Mantendo os demais parâmetros e mudando o stop fixo para 40 pips, fica assim:

E com 60 pips fica assim:

E na situação em que está rodando, com stop loss 250 pips, fica assim:

A esmagadora maioria das versões, bem como a maioria de outros sistemas, não consegue funcionar com stops tão curtos. O diferencial que possibilita ao Saturno V 3.1415926c funcionar nestas condições é que ele faz entradas muito certeiras na grande maioria das vezes. Nas poucas vezes que erra o momento para entrada, pode chegar a pouco mais de 200 pips na direção contrária. Essa versatilidade no uso de diferentes stops também é um indicador muito importante de eficiência, pois geralmente a largura do espectro dentro do qual se pode variar um parâmetro tão importante como o stop é bem estreita. Deslocar muito um parâmetro de seu valor ótimo costuma deteriorar drasticamente a performance. O Saturno pode usar stops entre 25 e 230 com execuções e acima de 250 sem execuções (até agora). Além disso, pode variar com certa folga outros parâmetros.

Para avaliar os resultados de testes, há 3 elementos importantes a serem considerados:

1) Similaridade entre back tests, contas demonstrativas e contas reais.

2) Homogeneidade no comportamento e na performance do sistema dentro de um back test.

3) Robustez dos padrões utilizados como referência para sinalizar pontos de entrada e saída, perante mudanças significativas no cenário.

Analisaremos cada um destes:

1a) Diferenças entre back tests e contas demonstrativas.  

1b) Diferenças entre back tests e contas reais.

1c) Diferenças entre contas reais e contas demonstrativas.

Os resultados desta operação foram:

Na aba "diário" os horários de entrada são 22:09:25 e 22:09:26, mas na aba "histórico" os horários são 21:09 e 21:09 (por motivo de fuso horário) e não informam os segundos. Na tabela acima, uniformizamos o fuso com base nas informações do histórico. No artigo anterior usamos como referência o fuso da aba "diário". Por que o fuso no histórico difere do fuso no diário é algo que deve ser perguntado à FXCM. De qualquer modo, isso é irrelevante. Apenas esclarecemos porque no artigo anterior falamos em 22:09h e aqui de 21:09h.

O que podemos observar é que não há diferenças significativas. No caso da MIG, simplesmente não estava logada porque aparentemente o servidor da MIG estava fora do ar no horário em que os pontos de entrada foram sinalizados. Digo "aparentemente" porque seria desejável que houvesse a corroboração de outras pessoas em outros locais (várias cidades), no mesmo horário, para fortalecer esta hipótese de que o problema estava no servidor da MIG. Por enquanto a hipótese se fundamenta no fato de que as plataformas da ATC e FXCM estavam logadas e operaram normalmente, enquanto a MIG, na mesma máquina e usando mesma conexão, não executou estas operações, além disso na aba "diário" consta que a MIG não estava conectada. Em outros horários a MIG possibilitou operar normalmente em outras contas, o que descarta algumas alternativas e reforça, por exclusões, a hipótese de falha no servidor da MIG.

O nível de similaridade observado nesta operação é o mesmo que temos observado nos últimos meses, portanto esta operação não destoa das demais no sentido de haver mais diferença entre conta real e conta demonstrativa do que a diferença observada entre conta demonstrativa e back test. Aliás, a conta real tem se mostrado mais semelhante ao back test do que as contas demonstrativas, talvez devido à maior rapidez nas execuções, indicando que os back tests são representações extremamente fiéis do que sucederia nas operações reais no mesmo período. Quando os volumes negociados forem muito grandes, é provável que as contas reais comecem a apresentar maior diferença em comparação às demonstrativas e aos back tests, devido à liquidez, conforme já comentado em outros artigos, pois os pontos de entrada e saída serão modificados em alguns pips pela própria operação, o que não ocorre nem no back test nem nas contas demonstrativas.

Não há problemas no que diz respeito à fidedignidade dos back tests e das contas demonstrativas, como representações do que se pode esperar das contas reais.

2) Similaridade entre o comportamento do sistema num determinado período de back test em comparação a outro período de back test, sendo preferencialmente a otimização dos parâmetros feita numa fração menor do período total e depois verificada, mantendo os mesmos parâmetros, numa fração maior. Exemplo: otimização em 3 anos e verificação do comportamento e da performance num período de 7 anos diferentes daqueles 3 anos. Se nos 7 anos a performance for semelhante e o comportamento geral também, isso sugere que o sistema não está super-especializado no período de teste e pode funcionar igualmente bem em períodos diferentes, desde que o Mercado não tenha um comportamento peculiar muito destoante de todos os eventos considerados no período de otimização e no período de confirmação. Se entre 2000 e 2003 o sistema funciona de maneira muito semelhante a que se observa nos 5 anos seguintes, é muito razoável supor que essa semelhança de comportamento se prolongará, salvo no caso de ocorrências especiais. O segundo semestre de 2008 foi não apenas peculiar, mas também foi mais destoante do "normal" do que qualquer outro período das últimas décadas. Isso poderia representar um problema ou não, dependendo do que comentaremos a seguir no item 3.

3) No histórico de dados de que dispomos, há padrões que são afetados por eventos inéditos e deixam seqüelas que exigem mudanças na estratégia para que ela continue a funcionar. E há padrões que são temporariamente afetados por eventos inéditos, mas em pouco tempo estes padrões voltam a se repetir como antes, sem que fiquem seqüelas.

Quem tenta usar redes neurais, procura identificar tanto os padrões que ficam com seqüelas permanentes como aqueles que sofrem apenas uma mudança temporária, e tentam manter a funcionalidade do sistema por meio de aprendizado, tentando fazer com que se adapte às mudanças. O ponto positivo disso é que é muito mais fácil desenvolver estratégias baseadas em padrões que deixem de se reproduzir após um evento marcante ou mesmo que sofram mudanças graduais, pois estes são muito mais abundantes. O ponto negativo é que é muito difícil fazer com que a adaptabilidade seja suficientemente rápida e acurada para se atualizar com poucos dados sobre a nova situação e, ao mesmo, tempo evitar falsos sinais de mudança. Solucionar satisfatoriamente este último problema esbarra não somente em dificuldades relacionadas à concepção de idéias e estratégias complexas, como também nas limitações tecnológicas para otimizar tais estratégias em tempo hábil. Há ainda motivos conceituais para se preferir uma solução mais geral, conforme discutido em alguns artigos. Em parte é por isso o Saturno V não usa redes neurais. Ele tenta gerar sinais com base em padrões que, após o mercado sofrer uma convulsão extrema (de alta ou baixa), depois da tempestade os mesmos padrões voltem a se repetir normalmente, e o sistema volte a funcionar. Em outras palavras, procuramos por padrões que sejam minimamente dependentes das particularidades do período. Também tentamos encontrar padrões que sejam válidos inclusive durante os eventos mais dramáticos, porque embora sejam eventos raros, eles podem ser muito longos e causar sérios prejuízos.

O Saturno V 3.1415926c tem se mostrado superior a outras versões tanto na versatilidade para operar em diferentes períodos antes e depois dos longos e rápidos movimentos de tendência como durante os tais movimentos. As particularidades que podem se produzir logo depois destes longos movimentos (seja em Forex ou Bolsas), como nas quedas das bolsas de 1929, 1937, 1988, 1999 e 2008 podem ser períodos mais perigosos do que os próprios movimentos. As versões que podem se mostrar promissoras em algumas situações específicas, como agora, apresentaram problemas com uma quantidade maior de outras situações do que o Saturno V 3.1415926c, e não se pode incorrer no erro de deixar que um caso particular, por ser mais influente emocionalmente, por ser mais recente e por ser a primeira operação em conta real da versão 3.1415926c, tenha maior peso do que uma quantidade muito maior de outras operações que corroboram a supremacia desta versão.

O que as evidências nos mostram em relação aos 3 itens que mencionamos no início é que:

1) Back tests bem conduzidos são muito confiáveis, reproduzindo com fidelidade e precisão o que se pode esperar em contas demonstrativas e reais.

2) Se o comportamento é aproximadamente uniforme durante todo o período de otimização, e se mantém uniforme num período diferente e mais extenso, provavelmente será igualmente funcional em outros períodos.

3) A versatilidade da versão 3.1415926c tem se verificado em diversos períodos ao longo de 10 anos, porém experimentou apenas uma situação de anomalia logo depois de uma grande queda (em 1999), e a segunda vez foi em 2008, portanto a otimização para estes períodos logo depois desse tipo de evento (e durante os tais eventos) não é baseada numa amostra muito grande de dados sobre estas situações específicas, e está mais sujeita a surpresas excessivamente boas, como os ganhos em outubro e novembro de 2008, que foram maiores do que em qualquer bimestre dos 10 anos precedentes, ou surpresas excessivamente ruins, como o único stop loss entre 10 anos de testes. Como ele opera em tendência, conseguiu se sair muito bem durante o próprio evento de outubro de 2008, mas terminada a tendência principal, ele não encontrou nas anomalias subseqüentes um quadro comparável a nenhum dos anteriores que havia experimentado, ficando mais susceptível a cometer erros. Essa é uma tentativa de explicação, pode não ter sido nada disso que aconteceu, mas, por enquanto, é o que me parece mais plausível, pelo menos até reunir mais dados de modo a fortalecer e complementar esta explicação, ou talvez substituí-la por outra com maior probabilidade de representar o que de fato deve ter ocorrido.

Para finalizar, é importante dizer que um stop é ruim, sem dúvida, porém não implica nenhuma mudança significativa na avaliação da qualidade do sistema. Um problema realmente grave seria se os pontos de entrada e saída destoassem muito entre conta real e back test, ou se houvesse mais operações em tempo real do que em back test, ou o contrário, porque isso colocaria em dúvida a confiabilidade de todo o trabalho de back test realizado até agora. Se esta operação do Saturno V na conta real tivesse ficado positiva, enquanto a mesma operação no back test tivesse ficado negativa, com entrada num ponto diferente ou saída num ponto diferente, isso sim seria um fato preocupante. Não seria alarmante por ser apenas 1 operação, mas se se repetisse em mais de 10% das operações, seria algo a exigir atenção urgente. A questão crucial é se seria preferível ganhar numa operação real destoando do back test ou perder numa operação real com grande similaridade com o back test. Não há a menor dúvida de que perder mantendo similaridade com back test é muito melhor, pois apesar da perda imediata, isso é mais um ponto que corrobora os 10 anos de back tests do Saturno V 3.1415926c e, em menor proporção, corrobora também os back tests das versões 3.03 e 3.1459 em 30 anos.