O horizonte que fixas primeiro
Um registo ao vivo é o único teste que não podes vasculhar, por isso a sua fasquia cai dos 4,499 da aula 64 para 1,645 e precisa de 7,48 vezes menos operações do que um backtest de 15.000 células para sustentar a mesma afirmação. É todo este o argumento a favor do teste para a frente, e só se aguenta se fixares o número de operações antes de começar. Julga um registo de 156 operações uma só vez, na operação 156, e um sistema sem vantagem nenhuma passa em 5,05 por cento das vezes. Julga o mesmo registo depois de cada operação a partir da vigésima, parando à primeira vez que ultrapassa 1,645, e o mesmo sistema morto passa em 24,25 por cento das vezes.
Pré-requisitos: Aula 64, pela fasquia e pela contagem a partir da qual se calcula, a aula 19, por como um registo sequer acumula provas, e aula 62, pela frase com que a regra foi escrita antes de nada disto correr.
Para que serve realmente um teste para a frente
O argumento habitual a favor do teste para a frente é o realismo: execuções reais, latência real, custos reais, nenhuma das comodidades que um backtest se concede em silêncio. Esse argumento é verdadeiro e não é o importante. A aula 63 mostrou que um backtest cuidadoso pode modelar custos e slippage com honestidade e ainda assim não valer nada, e a aula 64 mostrou porquê: o número que o desacredita não é nenhum dos pressupostos sobre o mercado mas a contagem de configurações que foram a audição para o produzir.
Um teste para a frente fixa essa contagem em um. Corre exatamente uma regra, e nenhuma versão dela que terias preferido corre ao lado para ser descartada em silêncio. É essa, e não o realismo, a propriedade por que vale a pena pagar, e a aula 64 pôs-lhe preço: uma única configuração ultrapassa em 1,645 onde uma grelha de 15.000 células tem de ultrapassar 4,499, e como as operações necessárias crescem com o quadrado da fasquia, o registo ao vivo precisa de 7,48 vezes menos para dizer o mesmo.
Um teste para a frente não é, portanto, um backtest mais barato nem um mais honesto. É a mesma prova comprada noutra moeda. Um backtest gasta configurações e obtém a resposta no instante; um teste para a frente gasta uma configuração e paga em tempo. O que o tempo custa é aritmética, e aqui está por inteiro. Uma vantagem de d em R por operação produz uma estatística t de d vezes a raiz quadrada do número de operações, portanto ultrapassar a fasquia custa 1,645 a dividir por d, tudo ao quadrado. Converter isso em meses exige um ritmo de operação, e esta página usa quarenta operações por mês em toda a parte: um ritmo que não deriva de nada, apenas é declarado, para que quem opere a outro ritmo divida o número de operações pelo seu.
| Vantagem, R por operação | Operações para ultrapassar 1,645 | Meses a quarenta por mês |
|---|---|---|
| 0,05 | 1.083 | 27,1 |
| 0,10 | 271 | 6,8 |
| 0,15 | 121 | 3,0 |
| 0,20 | 68 | 1,7 |
| 0,30 | 31 | 0,8 |
| 0,50 | 11 | 0,3 |
Lê as duas primeiras linhas e a forma do problema fica à vista. As vantagens que as pessoas encontram de facto, depois de subtraídos os custos e o referencial, vivem na metade de cima daquela tabela, e a metade de cima mede-se em anos. Reduzir a metade a vantagem que estás disposto a aceitar quadruplica a espera, porque a fasquia está fixa e só a raiz quadrada da contagem cresce ao seu encontro. É por isso que o teste para a frente é abandonado: não porque alguém o dispute, mas porque o horizonte honesto para um décimo de R são seis vírgula oito meses, e quase ninguém começa um teste que tem de deixar em paz tanto tempo.
A folha que este módulo abriu na aula 62 ganha aqui uma quarta coluna, e é a mais curta da página: o número de operações que o teste vai durar, escrito antes da primeira operação. Quase ninguém contra quem negoceias o escreve. Custa um número inteiro e um gesto de contenção, e falta pela mesma razão pela qual faltava a contagem de configurações na aula 64: comprometeres-te com ele de antemão é a única versão que te pode custar alguma coisa.
O mesmo registo, julgado de cinco maneiras
Toma um sistema sem vantagem nenhuma: 156 operações cujos resultados são extraídos de uma distribuição centrada exatamente em zero. Fá-lo vinte mil vezes a partir da semente 20260903, e de cada vez calcula a estatística t acumulada da maneira corrente, a operação média a dividir pelo erro padrão dessa média. Agora faz variar uma só coisa, que é quando te é permitido olhar.
Julgado uma vez, na operação 156 e só aí: 5,05 por cento destes sistemas mortos ultrapassam 1,645. O teste está calibrado, que é justamente para o que esta verificação serve: uma fasquia pensada para deixar passar cinco em cada cem deixa passar 5,05 em cada cem, e tudo o resto se mede contra isso.
| Quando podes olhar | Olhares | Sistemas mortos que passam | Operação mediana em que passam |
|---|---|---|---|
| Uma vez, na operação 156 | 1 | 0,0505 | 156 |
| A meio e no fim | 2 | 0,0795 | 78 |
| Quatro portas igualmente espaçadas | 4 | 0,1187 | 78 |
| Todos os meses, com treze operações de intervalo | 12 | 0,1992 | 39 |
| Depois de cada operação a partir da vigésima | 137 | 0,2425 | 32 |
Nada naquela tabela muda o sistema, a fasquia, o número de operações ou a distribuição de onde saem. A única coisa que muda é quantas vezes é permitido declarar o registo um sucesso. Quatro portas — papel, depois um quarto do tamanho, depois metade, depois completo, que é o plano de implementação que qualquer guia de negociação sistemática recomenda, incluindo aquele que esta página substitui — deixa passar um sistema morto em 11,87 por cento das vezes. É mais do dobro da taxa que a fasquia pretendia permitir, e é comprado inteiramente a olhar.
Um registo que podes parar é uma procura entre momentos de paragem.
O que significa que se lhe pode pôr preço exatamente como a aula 64 o pôs a uma grelha. Resolve para o limiar que repõe os cinco por cento quando se olha depois de cada operação e dá 2,569. Não é um número de espécie nova: é a fasquia que a aula 64 dá para onze configurações. Vigiar um único registo ao vivo enquanto se acumula vale tanto como vasculhar onze, e custa 2,44 vezes mais operações chegar à mesma conclusão, o que transforma o horizonte de 6,8 meses para um décimo de R em 660 operações e 16,5 meses.
A versão que devia preocupar quem leva três sistemas candidatos lado a lado, que é a maneira habitual de testar para a frente, é pior do que a soma das partes. Três registos, cada um vigiado depois de cada operação a partir da vigésima, cada um com a mesma fasquia de 1,645: em 55,65 por cento das vezes pelo menos um dos três declara-se vivo sem que nenhum o esteja. Uma maioria. O plano parece diligência e é uma moeda viciada a favor de adotar alguma coisa.
Fixa portanto o horizonte antes da primeira operação, e lê o registo uma vez, no fim.
O que isto não resolve
Que as operações sejam independentes e identicamente distribuídas. Não são nem uma coisa nem outra, e o pressuposto está a fazer trabalho a sério aqui: operações consecutivas de um sistema partilham as mesmas semanas, o mesmo regime e muitas vezes o mesmo risco de posição aberta, pelo que o número efetivo de observações independentes num registo de 156 operações é menor do que 156. Isso empurra para cima, e não para baixo, todos os horizontes da primeira tabela, portanto a página é otimista na direção que mais importa, e não diz quanto porque isso depende do sistema.
Que a distribuição das operações seja normal. Não é, e um sistema com ganhos raros e grandes tem uma estatística t que converge devagar para a normalidade, o que torna a fasquia de 1,645 errada precisamente nas contagens que a primeira tabela chama curtas. Com trinta e uma operações a três décimos de R, a aproximação normal está a trabalhar mais do que a prova.
Que parar cedo seja o único dano de olhar. A simulação modela uma regra — parar à primeira vez que o registo ultrapassa a fasquia — e os operadores reais também param quando um registo tem mau aspeto, que é a regra espelho e não está modelada em parte alguma desta página. Retira sistemas que se teriam recomposto em vez de adotar sistemas que nunca funcionaram, portanto o seu custo é invisível e incontável, e nada aqui lhe põe preço.
Que um horizonte fixo seja compatível com gerir uma conta. Frequentemente não é. Um sistema que perde dinheiro quatro meses seguidos devia ser desligado, e desligá-lo é gestão de risco correta ainda que destrua a propriedade estatística sobre a qual assenta toda esta página. A posição honesta é que os dois objetivos entram mesmo em conflito, que a gestão de risco ganha, e que um teste abandonado por razões de risco tem de ser relatado como abandonado em vez de anotado em silêncio como um fracasso da ideia.
Que a vantagem tenha o mesmo tamanho no fim e no princípio. Tudo o que está acima trata d como constante ao longo do horizonte, e a razão inteira pela qual um teste para a frente pode valer a pena é que as condições ao vivo diferem das históricas. Se a vantagem se degrada enquanto o teste corre, o registo está a medir uma média de algo que já não existe quando essa média se torna significativa, e quanto mais honesto o horizonte, pior fica.
E a concessão que mais custa: o horizonte tem de ser calculado a partir do tamanho do efeito, e o tamanho do efeito é justamente aquilo para que o teste serve. A primeira tabela pede d antes de te dizer quanto tempo, o que é circular, e não há forma de contornar. O remédio menos desonesto é fixar o horizonte a partir da menor vantagem que valeria a pena negociar depois de custos, e não a partir daquela que o backtest relatou, porque esta segunda é o número que a aula 63 gastou uma página a mostrar que não podes usar. A aula 66 pega no registo que passa e pergunta o que o produziu, e descobre que sobre os sessenta fechos deste curso 57,7 por cento do rendimento da regra vencedora foi o mercado e não a regra.
Problemas
- Põe preço ao teu horizonte. Toma a menor vantagem em R por operação que valeria a pena negociar no teu instrumento depois do custo de ida e volta que calculaste na aula 63, e lê o número de operações na primeira tabela, ou calcula 1,645 a dividir por essa vantagem, ao quadrado. Dez minutos, e ficas com um número na mão, as operações que o teu teste para a frente tem de durar, que é o número com que tens de te comprometer antes de colocares a primeira.
- Conta os teus olhares. Escreve o teu plano de implementação real — papel, pequeno, maior, completo, mais cada revisão que tenhas marcada — e conta os pontos em que poderias decidir que o sistema funciona. Meia hora, e ficas com um número na mão, a contagem de portas, que a segunda tabela converte na taxa a que o teu plano adota um sistema que não tem nada dentro.
- Corre a nula sobre o teu próprio plano. Simula um sistema sem vantagem ao longo do teu horizonte, mil vezes a partir de uma semente que escrevas, e aplica a cada registo simulado as tuas portas e a tua fasquia. Conta com que frequência teria sido adotado. Uma noite, e ficas com um número na mão, essa fração, que é a taxa de adoção errada do processo a que estavas prestes a confiar dinheiro.
Fontes. Peter Armitage, C. K. McPherson e B. C. Rowe, «Repeated Significance Tests on Accumulating Data» (Journal of the Royal Statistical Society, Series A, 1969), pelo resultado que a segunda tabela reproduz: examinar repetidamente o mesmo registo em acumulação inflaciona a taxa de falsos positivos muito acima do seu nível nominal. Stuart J. Pocock, «Group Sequential Methods in the Design and Analysis of Clinical Trials» (Biometrika, 1977), pela prática de fixar de antemão o número de olhares intermédios e subir o limiar em conformidade, que é o que o 2,569 desta página é. Peter C. O’Brien e Thomas R. Fleming, «A Multiple Testing Procedure for Clinical Trials» (Biometrics, 1979), pela alternativa de repartir a taxa de erro de forma desigual pelos olhares, que é o desenho melhor que esta página não usa. David H. Bailey, Jonathan M. Borwein, Marcos López de Prado e Qiji Jim Zhu, «Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance» (Notices of the American Mathematical Society, 2014), pela fasquia que esta aula traz da aula 64 e converte em onze configurações.
O preço de procurar
A fasquia que uma procura tem de ultrapassar, e a contagem a partir da qual se calcula.
Ler a aula →O backtesting como prova
Porque a vantagem que um backtest relata não pode ser aquela a partir da qual fixas um horizonte.
Ler a aula →Apenas para fins educativos. Negociar envolve risco substancial de perda. Não é aconselhamento financeiro. Resultados passados não garantem resultados futuros.
💬 Discussão (0 comentários)
A carregar comentários…
Pronto para operar com a Signal Pilot?
Põe a tua formação em prática com indicadores profissionais e ferramentas de análise de mercado em tempo real.
Voltar à Signal Pilot →