Comprometimento do forward testing em razão do cenário de otimização
O grande problema que vejo no mercado, a partir dessa análise, é que a maior parte dos traders, desconhecendo a realidade do forward testing, e até mesmo muitos cientistas de dados, vivendo no mundo da teoria e desconhecendo a realidade do testset, como são denominados esses dados na região OOS, forçam um volume tão grande de testes que acabam por sobreajustar o setup para todo o conjunto da obra, resultando em um modelo totalmente artificial, quando enfrenta a realidade futura.
Espero ter ajudado.
@Rogerio Figurelli, muito obrigado pelas considerações. Sim o assunto é bem intricado mesmo. Sei que há n variáveis, interdependência de parâmetros, a própria questão da estratégia e até mesmo possíveis erros na lógica. Com respeito à sua pergunta, sim, referia-me ao OOS que é 1/3 do período total. Concordo com tudo que disse, apesar de conhecer programação a muito tempo e as regras do mercado há aproximadamente 10 anos, estou dando meus primeiros passos esses testes. Pena que o MT não dispõe de uma biblioteca ou recursos nativos para realizar um WFT ou WFA sem que seja preciso desprender esforço ou adquirir uma biblioteca no mercado.
É fato que o EA deve ser robusto o suficiente para nos casos mais adversos passar pelo menos com o mínimo drawdown, dentro de um gerenciamento de risco adequado. O que deixou realmente intrigado é o tipo de "calibragem" que meu EA obteve nesse período OOS. Acredito que o ruído capturado foi alto a ponto de não ser filtrado a níveis aceitáveis. Havia escolhido esse período para "escapar" do horário de verão (pois parte da minha estratégia é relacionado ao horário do pregão), mas acabei implementando ontem uma lógica para preparar o EA para testes em períodos mais representativos considerando horário de verão. Espero com isso obter resultados mais consistentes ou comprovar a ineficácia da minha estratégia.
Ajudou muito. Avançando no backtesting, atualizarei esse post.
Abraços,
Conrado
@Rogerio Figurelli, muito obrigado pelas considerações. Sim o assunto é bem intricado mesmo. Sei que há n variáveis, interdependência de parâmetros, a própria questão da estratégia e até mesmo possíveis erros na lógica. Com respeito à sua pergunta, sim, referia-me ao OOS que é 1/3 do período total. Concordo com tudo que disse, apesar de conhecer programação a muito tempo e as regras do mercado há aproximadamente 10 anos, estou dando meus primeiros passos esses testes. Pena que o MT não dispõe de uma biblioteca ou recursos nativos para realizar um WFT ou WFA sem que seja preciso desprender esforço ou adquirir uma biblioteca no mercado.
É fato que o EA deve ser robusto o suficiente para nos casos mais adversos passar pelo menos com o mínimo drawdown, dentro de um gerenciamento de risco adequado. O que deixou realmente intrigado é o tipo de "calibragem" que meu EA obteve nesse período OOS. Acredito que o ruído capturado foi alto a ponto de não ser filtrado a níveis aceitáveis. Havia escolhido esse período para "escapar" do horário de verão (pois parte da minha estratégia é relacionado ao horário do pregão), mas acabei implementando ontem uma lógica para preparar o EA para testes em períodos mais representativos considerando horário de verão. Espero com isso obter resultados mais consistentes ou comprovar a ineficácia da minha estratégia.
Ajudou muito. Avançando no backtesting, atualizarei esse post.
Abraços,
Conrado
Muito bom @Conrado Carvalho, na verdade o forward testing é uma espécie de walk forward, só que você tem toda razão pois ele é muito simplificado ainda no MT5, e essa realmente é uma funcionalidade a melhorar.
No passado criei um método pioneiro para operar com robôs onde percebi que os testes em conta demonstração e real são a real arena para ajustes e escolha de estratégias, portanto meus dois centavos são você avaliar até que ponto vale esse esforço de validação usando o forward. Uma boa parte dos meus esforços foi parecida com a sua, só que justamente em alinhar resultados de backtesting com conta demonstração e, posteriormente, conta real, e o avanço das tecnologias e ferramentas de inteligência artificial ajudaram muito para isso.
Seja como for, considero o MT5 insuperável como plataforma, tanto no Brasil como no mercado internacional, por dois fatores diferenciados: uma comunidade de longo prazo e uma ferramenta integrada a todos mercados e que na prática foi pioneira no mercado Forex.
Isso não é uma crítica ao mercado de plataformas brasileiras, que tem evoluído, mas no meu entender muitas vezes sem uma visão correta da competitividade internacional, com soluções amarradas a fatores regionais, o que é um problema recorrente em muitas de nossas tecnologias.
Por esse motivo, penso que qualquer estratégia eficaz deve se comprovar nos mais variados mercados, da mesma forma que os seus estudos atuais.
Abraço e sucesso,
Rogério Figurelli
Oi Conrado.
Prever o comportamento do preço no mercado financeiro é realmente um dos problemas mais desafiadores de Machine Learning que existe, pois trata-se de uma série temporal não-estacionária, cuja lei de formação tem componentes estocásticos, variantes no tempo, e talvez até caóticos, a maioria deles inteiramente desconhecidos e imprevisíveis.
Basta olhar o gráfico para perceber que o comportamento do mercado muda repentinamente de padrão a todo momento.
Se o OOS está dando resultado melhor que o IS, isso indica que provavelmente (tudo aqui é "provavelmente", nada é certeza) o nível de "aprendizado" do seu algoritmo está abaixo do nível de "ruído aleatório" (digamos assim) do comportamento do mercado.
De qualquer forma 1 única avaliação é muito pouco para se tirar qualquer conclusão. O ideal seria fazer um teste "walk-forward" variando o período IS e o período OOS 1 a semana à frente em cada iteração ao longo de 1 ano, para assim obter 52 amostras e aferir média e desvio padrão do desempenho IS e OOS, para avaliar se essas distribuições estão realmente sobrepostas ou se uma delas está (pelo menos ligeiramente) deslocada em relação à outra.
A avaliação em um grande número de janelas de treinamento e de validação é importante para poder aferir média e desvio padrão do desempenho obtido, pois o que acontece muitas vezes é que o desempenho do algoritmo tem uma variância enorme quando simulado em períodos diferentes, e aí a pessoa acaba encontrando um conjunto de parâmetros que dá um resultado maravilhoso para um determinado par de períodos IS e OOS, mas decepciona quando aplicado a períodos posteriores.
Na hora em que você encontrar um algoritmo que desempenha bem consistentemente ao longo de algumas dezenas de janelas de tempo OOS distintas consecutivas, isso dará uma segurança muito maior quanto ao desempenho futuro do algoritmo.
Oi Conrado.
Prever o comportamento do preço no mercado financeiro é realmente um dos problemas mais desafiadores de Machine Learning que existe, pois trata-se de uma série temporal não-estacionária, cuja lei de formação tem componentes estocásticos, variantes no tempo, e talvez até caóticos, a maioria deles inteiramente desconhecidos e imprevisíveis.
Basta olhar o gráfico para perceber que o comportamento do mercado muda repentinamente de padrão a todo momento.
Se o OOS está dando resultado melhor que o IS, isso indica que provavelmente (tudo aqui é "provavelmente", nada é certeza) o nível de "aprendizado" do seu algoritmo está abaixo do nível de "ruído aleatório" (digamos assim) do comportamento do mercado.
De qualquer forma 1 única avaliação é muito pouco para se tirar qualquer conclusão. O ideal seria fazer um teste "walk-forward" variando o período IS e o período OOS 1 a semana à frente em cada iteração ao longo de 1 ano, para assim obter 52 amostras e aferir média e desvio padrão do desempenho IS e OOS, para avaliar se essas distribuições estão realmente sobrepostas ou se uma delas está (pelo menos ligeiramente) deslocada em relação à outra.
A avaliação em um grande número de janelas de treinamento e de validação é importante para poder aferir média e desvio padrão do desempenho obtido, pois o que acontece muitas vezes é que o desempenho do algoritmo tem uma variância enorme quando simulado em períodos diferentes, e aí a pessoa acaba encontrando um conjunto de parâmetros que dá um resultado maravilhoso para um determinado par de períodos IS e OOS, mas decepciona quando aplicado a períodos posteriores.
Na hora em que você encontrar um algoritmo que desempenha bem consistentemente ao longo de algumas dezenas de janelas de tempo OOS distintas consecutivas, isso dará uma segurança muito maior quanto ao desempenho futuro do algoritmo.
Olá @Trader_Patinhas, ótima análise, obrigado por compartilhar.
Minha visão é um pouco diferente, pois na prática não podemos esquecer que backtesting é sempre com dados do passado, seja IS ou OOS, ou seja, em tese, qualquer robô com uma estratégia minimamente lógica, pode gerar resultados em backtesting, e quanto mais criamos mecanismos para isso maiores as chances de gerar um sobreajuste, inclusive em OOS. Seja como for, acredito que o que pode ajudar muito em um sistema de ML é focar em cenários futuros. Por exemplo, o trader ou gestor escolher um período no passado que acredita irá se repetir no futuro com maior probabilidade. Nesse sentido, um método de avaliação que faço eventualmente, para algumas tecnologias que desenvolvo, é fazer algo mais radical. A partir de um ajuste dos últimos 30 dias, fazer um backtesting com um período mais longo do passado, como por exemplo os últimos 24 meses.
O resultado, muitas vezes, é que as melhores tecnologias conseguem de alguma forma se repetir com maior consistência em períodos aleatórios do passado, mesmo com ajustes em períodos muito curtos. E, quando se coloca isso em um sistema, com testes permanentes, se abre a porta para descobertas típicas de inteligência artificial, uma vez que nenhum gestor teria condições de fazer isso exaustivamente com múltiplos instrumentos e mercados 24/7/365, e esse é apenas um exemplo de abordagem competitiva.
Nesse sentido, minha conclusão prática é que, com a entrada de grandes players no mercado brasileiro, como a UBS, com uso massivo de inteligência artificial e abordagens diferenciadas, ficará cada vez mais difícil encontrar boas tecnologias e estratégias que gerem resultados consistentes, o que representa uma grande ameaça para todos players, principalmente os pequenos traders, e oportunidade para todos traders e desenvolvedores de MQL, que acreditarem nessa nova realidade e potencial da plataforma para ML.
Sds.,
Rogério Figurelli
Olá @Trader_Patinhas, ótima análise, obrigado por compartilhar.
Minha visão é um pouco diferente, pois na prática não podemos esquecer que backtesting é sempre com dados do passado, seja IS ou OOS, ou seja, em tese, qualquer robô com uma estratégia minimamente lógica, pode gerar resultados em backtesting, e quanto mais criamos mecanismos para isso maiores as chances de gerar um sobreajuste, inclusive em OOS. Seja como for, acredito que o que pode ajudar muito em um sistema de ML é focar em cenários futuros. Por exemplo, o trader ou gestor escolher um período no passado que acredita irá se repetir no futuro com maior probabilidade. Nesse sentido, um método de avaliação que faço eventualmente, para algumas tecnologias que desenvolvo, é fazer algo mais radical. A partir de um ajuste dos últimos 30 dias, fazer um backtesting com um período mais longo do passado, como por exemplo os últimos 24 meses.
O resultado, muitas vezes, é que as melhores tecnologias conseguem de alguma forma se repetir com maior consistência em períodos aleatórios do passado, mesmo com ajustes em períodos muito curtos. E, quando se coloca isso em um sistema, com testes permanentes, se abre a porta para descobertas típicas de inteligência artificial, uma vez que nenhum gestor teria condições de fazer isso exaustivamente com múltiplos instrumentos e mercados 24/7/365, e esse é apenas um exemplo de abordagem competitiva.
Nesse sentido, minha conclusão prática é que, com a entrada de grandes players no mercado brasileiro, como a UBS, com uso massivo de inteligência artificial e abordagens diferenciadas, ficará cada vez mais difícil encontrar boas tecnologias e estratégias que gerem resultados consistentes, o que representa uma grande ameaça para todos players, principalmente os pequenos traders, e oportunidade para todos traders e desenvolvedores de MQL, que acreditarem nessa nova realidade e potencial da plataforma para ML.
Sds.,
Rogério Figurelli
Muito bem colocado, Figurelli.
Na verdade nossas visões não são diferentes, pois concordo gênero, número e grau com o que vc escreveu.
É que, quando eu escrevi, assumi implicitamente a premissa de que o período de validação (distinto do período de treinamento) em que o algoritmo foi ajustado e teve seus hiperparâmetros otimizados já estava incluído na janela IS e que o que estamos chamando de OOS era uma nova janela de tempo jamais verificada antes, nem mesmo para ajustes.
Relendo agora o meu texto anterior, vejo que realmente eu não deixei isso claro.
Vou elaborar melhor a ideia agora ...
O que eu costumo fazer para evitar ser iludido pelo sobreajuste (overfitting), não somente no desenvolvimento de robôs de algotrading (que é uma área de aplicação em que comecei a atuar muito recentemente e ainda estou engatinhando), mas também em outras áreas de aplicação de Machine Learning nas quais já atuo há mais tempo, é a clássica divisão em 3 conjuntos de dados: treinamento, validação e teste.
Em aplicações mais "bem-comportadas", onde há mais previsibilidade e a dinâmica do processo que gera os dados é invariante (exemplo: processamento de imagens) ou varia pouco ao longo do tempo (exemplo: sensoriamento de processos industriais), geralmente o processo de ML pode ser feito mais ou menos assim:
1) Treinar o modelo preditivo com base em um conjunto de dados de treinamento.
2) Validar o modelo preditivo aferindo o seu desempenho em um conjunto de dados de validação (inteiramente distinto do conjunto de treinamento).
3) Refinar o modelo preditivo (selecionar atributos de entrada, gerar novos atributos derivados, ajustar escala, reduzir dimensionalidade, otimizar hiperparâmetros, ajustar regularização, etc.).
4) Repetir os passos 1, 2 e 3 até obter um bom resultado no conjunto de validação.
5) Antes de implantar o modelo preditivo em produção, fazer uma última verificação em um conjunto de dados de teste, inteiramente distinto dos dois anteriores e nunca antes verificado, para obter uma estimativa realista do desempenho que o modelo preditivo terá quando for posto em produção, visto que o modelo pode ter ficado "viciado" no conjunto de validação após um grande número de ajustes e refinamentos em função do resultado obtido no mesmo.
6) Se o resultado no conjunto de teste for ruim (o modelo ficou viciado no conjunto de validação), reservar um novo conjunto de teste nunca verificado antes e prosseguir o processo de 1 a 5 usando o conjunto de teste anterior como conjunto de validação.
7) Quando o resultado se mantiver bom em um conjunto de testes nunca verificado antes, liberar a implantação em produção (no nosso caso aqui, isso significa colocar o robô operando na conta real).
Porém, no caso do mercado financeiro, a dinâmica do processo que gera os dados (o comportamento do mercado) varia muito e de forma imprevisível ao longo do tempo (ou muito difícil de ser prevista, na melhor das hipóteses).
Sendo assim, acredito que não seja suficiente validar o desempenho do algoritmo em 1 único conjunto de validação (ou seja, em 1 única janela de tempo), pois é necessário assegurar que o algoritmo será robusto o suficiente para ter bom desempenho (ou pelo menos "sobreviver") em face das muitas e diferentes dinâmicas de mercado que poderão se apresentar.
Por isso, tenho me proposto a fazer validações dos meus modelos preditivos em um grande número de janelas de tempo, distintas entre si e distintas da janela de treinamento, de modo que os resultados financeiros obtidos nos diferentes períodos de validação possam ser analisados em conjunto sob uma ótica estatística (média, mediana, desvio padrão, curtose, etc.), para poder ter uma ideia da variância que o desempenho financeiro do algoritmo pode apresentar face a diferentes dinâmicas de mercado, e assim não ficar iludido com algum desempenho excepcional numa janela de tempo específica que possa ser um mero "outlier" casual, que dificilmente se repetirá.
Uma segunda ideia em que tenho pensado é, em vez de tentar construir um modelo preditivo robusto que funcione bem em todas as situações (algo que talvez seja impossível), usar algum algoritmo de clusterização para tentar identificar diferentes dinâmicas de comportamento de mercado (em tendência, andando de lado, oscilatório, calmo, nervoso tipo A, nervoso tipo B, etc.) e assim treinar modelos preditivos específicos para cada tipo de situação identificada. Ao olhar os gráficos, percebe-se claramente que o mercado tem alguns "modos de operação" distintos e razoavelmente bem definidos, e muito provavelmente essa percepção pode ajudar a construir modelos mais específicos para cada situação.
Por exemplo, um cenário bem pitoresco que aparece especificamente no DOL/WDO de vez em quando são aqueles dias em que há uma pressão compradora enorme e o Banco Central fica intervindo periodicamente por meio de leilões/swaps, gerando quedas bruscas em instantes imprevisíveis em meio a um contexto gráfico de aparente tendência de alta. É um cenário relativamente raro, mas que vez por outra se repete. Um modelo preditivo treinado com dias comuns provavelmente levaria uma surra em um dia assim, enquanto que um modelo treinado especificamente para esse cenário poderia explorar suas características e render muito lucro, mas provavelmente tomaria uma surra nos dias comuns. Daí a ideia de distinguir contextos específicos e treinar um modelo preditivo específico pra cada um.
Muito bem colocado, Figurelli.
Na verdade nossas visões não são diferentes, pois concordo gênero, número e grau com o que vc escreveu.
É que, quando eu escrevi, assumi implicitamente a premissa de que o período de validação (distinto do período de treinamento) em que o algoritmo foi ajustado e teve seus hiperparâmetros otimizados já estava incluído na janela IS e que o que estamos chamando de OOS era uma nova janela de tempo jamais verificada antes, nem mesmo para ajustes.
Relendo agora o meu texto anterior, vejo que realmente eu não deixei isso claro.
Vou elaborar melhor a ideia agora ...
O que eu costumo fazer para evitar ser iludido pelo sobreajuste (overfitting), não somente no desenvolvimento de robôs de algotrading (que é uma área de aplicação em que comecei a atuar muito recentemente e ainda estou engatinhando), mas também em outras áreas de aplicação de Machine Learning nas quais já atuo há mais tempo, é a clássica divisão em 3 conjuntos de dados: treinamento, validação e teste.
Em aplicações mais "bem-comportadas", onde há mais previsibilidade e a dinâmica do processo que gera os dados é invariante (exemplo: processamento de imagens) ou varia pouco ao longo do tempo (exemplo: sensoriamento de processos industriais), geralmente o processo de ML pode ser feito mais ou menos assim:
1) Treinar o modelo preditivo com base em um conjunto de dados de treinamento.
2) Validar o modelo preditivo aferindo o seu desempenho em um conjunto de dados de validação (inteiramente distinto do conjunto de treinamento).
3) Refinar o modelo preditivo (selecionar atributos de entrada, gerar novos atributos derivados, ajustar escala, reduzir dimensionalidade, otimizar hiperparâmetros, ajustar regularização, etc.).
4) Repetir os passos 1, 2 e 3 até obter um bom resultado no conjunto de validação.
5) Antes de implantar o modelo preditivo em produção, fazer uma última verificação em um conjunto de dados de teste, inteiramente distinto dos dois anteriores e nunca antes verificado, para obter uma estimativa realista do desempenho que o modelo preditivo terá quando for posto em produção, visto que o modelo pode ter ficado "viciado" no conjunto de validação após um grande número de ajustes e refinamentos em função do resultado obtido no mesmo.
6) Se o resultado no conjunto de teste for ruim (o modelo ficou viciado no conjunto de validação), reservar um novo conjunto de teste nunca verificado antes e prosseguir o processo de 1 a 5 usando o conjunto de teste anterior como conjunto de validação.
7) Quando o resultado se mantiver bom em um conjunto de testes nunca verificado antes, liberar a implantação em produção (no nosso caso aqui, isso significa colocar o robô operando na conta real).
Porém, no caso do mercado financeiro, a dinâmica do processo que gera os dados (o comportamento do mercado) varia muito e de forma imprevisível ao longo do tempo (ou muito difícil de ser prevista, na melhor das hipóteses).
Sendo assim, acredito que não seja suficiente validar o desempenho do algoritmo em 1 único conjunto de validação (ou seja, em 1 única janela de tempo), pois é necessário assegurar que o algoritmo será robusto o suficiente para ter bom desempenho (ou pelo menos "sobreviver") em face das muitas e diferentes dinâmicas de mercado que poderão se apresentar.
Por isso, tenho me proposto a fazer validações dos meus modelos preditivos em um grande número de janelas de tempo, distintas entre si e distintas da janela de treinamento, de modo que os resultados financeiros obtidos nos diferentes períodos de validação possam ser analisados em conjunto sob uma ótica estatística (média, mediana, desvio padrão, curtose, etc.), para poder ter uma ideia da variância que o desempenho financeiro do algoritmo pode apresentar face a diferentes dinâmicas de mercado, e assim não ficar iludido com algum desempenho excepcional numa janela de tempo específica que possa ser um mero "outlier" casual, que dificilmente se repetirá.
Uma segunda ideia em que tenho pensado é, em vez de tentar construir um modelo preditivo robusto que funcione bem em todas as situações (algo que talvez seja impossível), usar algum algoritmo de clusterização para tentar identificar diferentes dinâmicas de comportamento de mercado (em tendência, andando de lado, oscilatório, calmo, nervoso tipo A, nervoso tipo B, etc.) e assim treinar modelos preditivos específicos para cada tipo de situação identificada. Ao olhar os gráficos, percebe-se claramente que o mercado tem alguns "modos de operação" distintos e razoavelmente bem definidos, e muito provavelmente essa percepção pode ajudar a construir modelos mais específicos para cada situação.
Por exemplo, um cenário bem pitoresco que aparece especificamente no DOL/WDO de vez em quando são aqueles dias em que há uma pressão compradora enorme e o Banco Central fica intervindo periodicamente por meio de leilões/swaps, gerando quedas bruscas em instantes imprevisíveis em meio a um contexto gráfico de aparente tendência de alta. É um cenário relativamente raro, mas que vez por outra se repete. Um modelo preditivo treinado com dias comuns provavelmente levaria uma surra em um dia assim, enquanto que um modelo treinado especificamente para esse cenário poderia explorar suas características e render muito lucro, mas provavelmente tomaria uma surra nos dias comuns. Daí a ideia de distinguir contextos específicos e treinar um modelo preditivo específico pra cada um.
Olá @Trader_Patinhas obrigado, ótima sua abordagem de testes, obrigado por compartilhar.
Meu maior foco nessa área de testes/validação, usando IA, é conseguir ao máximo obter em conta demonstração e real uma performance similar ao obtido em backtesting. Esse é um trabalho bastante complexo mas que vale a pena investir, principalmente quem está trabalhando com ML. Muitas Assets possuem ferramentas próprias para isso, e de alto investimento, mas conseguir resultados similares com a plataforma MT5 é sem dúvida um desafio e tanto, e que acredito ser cada vez mais determinante para criar um robô competitivo, principalmente com a entrada de grandes players no nosso mercado.
Obs: gostei do exemplo e cenário do DOL/WDO, na verdade esse é um dos mercados que considero com maior incerteza no mercado brasileiro, pelo menos no que se refere ao desenvolvimento de trading systems, sem interferência humana, principalmente pelas diversas forças atuantes, como a do Banco Central que você aponta muito bem, como de diversos players com grande expertise em tape reading. Seja como for, isso irá certamente implicar em modelos mais avançados para operar com esses cenários, mas sem dúvida é de grandes oportunidades para todos traders, pois talvez seja o ativo nacional mais impactado pelo cenário internacional de câmbio.
Sds.,
Rogério Figurelli
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Caros,
Primeiramente, obrigado pela atenção. Para quem não está familiarizado, o MT5 dispõe basicamente de dois dispositivos de testes: backtesting e forward testing. O primeiro é o teste clássico no qual definimos um período para testes e otimizações. O segundo ("pra frente") é opcional e realizado sobre uma amostragem que não serviu como base para otimização, ou seja, uma amostra out-of-sample. Por outro lado, os dados que embasaram a otimização são denominados in-sample.
Dito isso gostaria de compartilhar um fato que chamou minha atenção durante uma bateria de testes que vinha realizando com meu novo EA. Meu expert é customizado para Bovespa (ações) e para realizar somente operações intraday. Escolhi PETR4 para fazer os testes pela liquidez e volatilidade. Pois bem, defini o período de 19/02/2018 a 01/11/2018 para os testes, sendo in-sample (IS) 19/02 a 07/08 e out-of-sample (OSS) 08/08 a 01/11. Pensei ter selecionado adequadamente o período (para simular operações nos tempos M5, M10 e M15), porém os resultados dos testes estavam chamando minha atenção por diversas vezes IS ter desempenho superior, o que a princípio achei muito estranho por ser IS apenas 1/3 do período total.
Diante disso tive a (brilhante rs) ideia de olhar os preços históricos e o gráfico do período, e fiquei intrigado se escolhi muito bem ou muito mal o período. Abaixo o gráfico diário:
A opinião que queria saber dos colegas é: quanto o fato do período OOS ter sido tão disruptivo ou turbulento, enquanto o período IS com forte alta, pode ter influenciado nos resultados (ou se influenciou). Salientando que todas as operações são intraday.
Obrigado.