Bibliotecas: BestInterval - página 13
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Atualizei para a última versão do BestInterval e do Virtual.
Quando compilei com novas linhas no início do código, obtive muitos erros. No final, apenas 3 (veja a imagem).
Muito obrigado por sua ajuda
Coloque essas linhas no início, não no final.
Normalmente, esse backtest vai direto para a lixeira durante a otimização (ou em uma única passagem)
No entanto, o BestInterval durante a otimização dessa passagem mostrará uma das melhores. Motivo
A desvantagem é que não há métricas para determinar o quanto ele não está se ajustando ao intervalo que está sendo otimizado
Por exemplo, minha biblioteca desenha exatamente a mesma coisa para 1 passagem no testador, mas não descarta os intervalos, mas vira as negociações perdidas e aproxima uma nova sequência.
Acontece que quanto mais negociações houver no TS inicial, mais belas imagens o Bestinterval mostrará, e não importa qual distribuição de negociações havia antes disso.
A desvantagem é que não há métricas para determinar o quanto ele não se ajusta ao intervalo que está sendo otimizado
Você pode escrever qualquer métrica que quiser para o OnTester. A biblioteca permite isso.
Por exemplo, minha biblioteca desenha exatamente a mesma coisa para 1 passagem no testador, só que ela não descarta os intervalos, mas inverte as negociações perdidas e aproxima uma nova sequência
Acontece que quanto mais negociações houver no TS inicial, mais belas imagens o Bestinterval mostrará, e não importa qual distribuição de negociações havia antes disso.
Declaração ambígua. Eu determino o ajuste de forma simples - pego UM dos melhores resultados do BestInterval e o executo (individualmente) em um intervalo duas vezes maior. Se a extensão do intervalo não alterar o caráter do saldo direto, não se trata de um ajuste. Na segunda figura acima, > 1000 negociações. Se eu dobrar o intervalo, a linha reta permanecerá. Ou seja, não é um ajuste de 100%.
Outra coisa é que "não se ajustar" significa apenas uma coisa - os padrões foram considerados reais. Mas nada garante que eles continuarão. E essa falta de garantia não indica nenhum tipo de ajuste. É apenas uma lei da vida.
Você pode escrever qualquer métrica para o OnTester. A biblioteca permite.
Declaração ambígua. Eu defino o ajuste de forma simples: pego UM dos melhores resultados do BestInterval e o executo (individualmente) em um intervalo duas vezes maior. Se a extensão do intervalo não alterar o caráter do saldo direto, não se trata de um ajuste. Na segunda figura acima, > 1000 negociações. Se eu dobrar o intervalo, a linha reta permanecerá. Ou seja, não está se ajustando 100%.
Outra coisa é que "não se encaixar" significa apenas uma coisa - os padrões foram considerados reais. Mas nada garante que eles continuarão. E essa falta de garantia não indica nenhum tipo de ajuste. É apenas uma lei da vida.
Em geral, você está fazendo aprendizado de máquina puro, mas por algum motivo você ignora esse tópico :)
Sim, se você criar algumas métricas e selecionar modelos com base nessas métricas, apenas a rotina de ajuste excessivo seria reduzida, esse é o meu ponto. O ideal seria que a máquina selecionasse o melhor modelo, o que também teria maior probabilidade de mostrar algo no OOS
Em geral, você está fazendo aprendizado de máquina puro, mas, por algum motivo, está ignorando esse tópico :)
Não posso aceitar isso.
Sim, se você criar algumas métricas e selecionar modelos com base nelas, apenas a rotina de pesquisa será reduzida, esse é o meu ponto. Idealmente, se o melhor modelo for selecionado automaticamente, o que, com uma probabilidade maior no OOS, também mostrará algo
Bem, se houvesse ordens de magnitude a mais de recursos computacionais, não seria necessário usar o BestInterval. Ou seja, não há nenhum indício de MO aqui. É apenas um filtro que é conveniente e rápido de aplicar, nada mais.
Quanto à probabilidade de OOS, ela é determinada exatamente como eu disse acima. Ou seja, qualquer fator de seleção/otimização é eliminado. Ou tudo é ótimo ou é lixo.
Uma questão muito mais complicada é quando há um TS em funcionamento e é necessário selecionar valores de parâmetros de entrada ideais para o real.
Descobri que o GA+BestInterval é um mapeamento repugnante. Ou seja, ocorre a convergência para algum extremo local e, quando verificado, ele se revela um ajuste absoluto.
Mas o Buteforce+BestInterval é um mapeamento excelente, como se vê. Em grande parte, enquanto o GA me fez acreditar que o TC era um lixo, o Bruteforce se mostrou promissor.
Bem, para que o Bruteforce seja rápido, você precisa de um pequeno número de ticks e de uma lógica de TC rápida. É por isso que todos os mecanismos de aceleração fornecem resultados não apenas quantitativos, mas também qualitativos.
O próprio GA é tão bom quanto o leite de um touro. Ele é considerado uma otimização exploratória, que não deve nada em termos de confiabilidade dos resultados.
Não consigo fazer amizade com o GA.