Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 20
![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Comecei a fazer experiências com clusters, com base nos motivos que mencionei anteriormente. Encontrei um problema - quando tentei colar o preço das peças que correspondem a um aglomerado, os locais colados eram lacunas de preço (e isto é lógico, mas não me ocorreu)) ) A questão é como corrigir estas lacunas.
Eu também tenho este problema. Normalmente só tem de executar atributos(KZP) para obter uma lista de variáveis disponíveis e depois apenas passar por elas, por exemplo KZP$window etc e encontrar os números de que necessita. Mas aqui estes números são gerados na própria função Resumo e não são armazenados em nenhum lugar.
Aqui está um código fonte: https://cran.r-project.org/web/packages/kza/index.html, devemos executar algo como isto:
A propósito, pode ser útil se você usar indicadores, esta função detecta em dados muito ruidosos componentes periódicos, período em suma, este período está em constante mudança no mercado.
A idéia é identificar constantemente este período dominante e ajustar os indicadores a ele, não apenas com parâmetros fixos como todos os outros fazem. Testei esta abordagem muito superficialmente numa data aleatória, e o resultado foi positivo em comparação com a abordagem habitual. Tomei o indicador RSI, ele perdeu com parâmetros fixos, e ganhou com parâmetros adaptativos. Se você quiser usá-lo, você pode usá-lo e eu estaria muito interessado em ler o resultado da sua pesquisa
Comecei a fazer experiências com clusters, com base nos motivos que mencionei anteriormente. Encontrei um problema - quando tentei colar o preço das peças que correspondem a um aglomerado, os locais colados eram lacunas de preço (e isto é lógico, mas não me ocorreu)) ) A questão é como corrigir estas lacunas.
Logaritmo a série de preços, depois converte-a para uma série de diferenças. Para colar a série, deixar apenas os intervalos que correspondem à condição encontrada. Depois faça uma nova série a partir desta série através da soma. E, se desejar, exponha-o depois.
Aprendi mais umas coisas interessantes:
A função para peneirar os preditores (designTreatmentsN$scoreFrame) postada anteriormente claramente não dá o conjunto final de preditores. Não remove nem mesmo os preditores 100% correlacionados, mais pode remover algo que você quer, além de deixar lixo. Eu compliquei um pouco o método de peneiramento deles - a princípio estou peneirando os preditores do jeito antigo, via designTreatmentsN$scoreFrame (aumentei o limiar duas vezes - 2/N, para peneirar menos preditores potencialmente bons). Então eu removo todos os preditores que correlacionam >0,99 (eu tenho muitos deles após geração aleatória de deltas e somas. E eu olho para a correlação dos preditores uns com os outros, não com a variável alvo). Então eu procuro geneticamente o melhor conjunto de preditores restantes.
Tento usar algo mais do artigo sobre os componentes principais. A função abaixo constrói o modelo do componente principal e retorna R^2 para o caso de eu ter usado todos os componentes principais encontrados. Não tem "escala Y" como outro exemplo do artigo, mas desta forma é mais rápido. Agora eu o uso para estimar o conjunto de preditores (provavelmente para nada, eu ainda não sei :) ). A última coluna do parâmetro srcTable é a variável alvo. Pode haver erros se o preditor tiver muito poucos valores, a função pode não caber em alguns dados.
Enquanto antes o meu R^2 era cerca de 0,1, agora consegui 0,3. Ainda não é suficiente, eles recomendam o uso de pelo menos 0,95. Outra coisa estranha é que com R^2=0,1 eu tive 37% de erro na frente, enquanto com R^2=0,3 este erro cresceu para 45%. Talvez o problema seja que acrescentei mais barras e mais indicadores ao conjunto de preditores. Um passo à frente e dois passos atrás, agora preciso analisar todo o conjunto de indicadores e remover os desnecessários. Ou o modelo de componentes principais simplesmente não é aplicável ao forex (difícil de verificar, primeiro preciso atingir R^2 > 0,95, e ver qual será o resultado na frente, com um modelo não treinado é muito cedo para tirar conclusões).
Eu também comparei o pacote GA (genética) e GenSA (recozimento gradiente, a partir do exemplo de Alexey). Ambos os pacotes alcançaram o mesmo resultado. A genética sabe como trabalhar com multi-tarefas, por isso ganhou a tempo. Mas a GenSA parece ganhar num só fio. Há também um truque para guardar os resultados, acho que o Alex vai gostar disso:
A questão é que a função intermediária fitness_GenSA_bin_Memoise retira dados do cache se esse conjunto de preditores já tiver sido encontrado pelo menos uma vez. O contentor fitness_GenSA_bin deve conter os próprios cálculos da função fitness, e só será chamado uma vez para cada conjunto único.
A propósito, pode ser útil se você usar indicadores, esta função detecta componentes periódicos em dados muito ruidosos, período em suma, este período está em constante mudança no mercado.
A idéia é identificar constantemente este período dominante e ajustar os indicadores a ele, não apenas com parâmetros fixos como todos os outros fazem. Testei esta abordagem muito superficialmente numa data aleatória, e o resultado foi positivo em comparação com a abordagem habitual. Tomei o indicador RSI, ele perdeu com parâmetros fixos, e ganhou com parâmetros adaptativos. Se você estiver interessado em usá-lo, eu estarei muito interessado em ler o resultado da sua pesquisa
Por enquanto, só estou usando parâmetros padrão para os indicadores. Se eu vou usar um indicador, será mais útil usar parâmetros padrão para negociar ações em D1, mas eles precisam ser ajustados. Eu não sou capaz de mudar os resultados de D1 para H1, quanto mais eu uso indicadores, mais eu fico preso em D1. Acontece que os parâmetros do indicador precisam ser alterados dependendo do tempo, e do tempo, sim.
Aprendi mais umas coisas interessantes:
A função anteriormente publicada para peneirar os preditores (designTreatmentsN$scoreFrame) claramente não dá o conjunto final de preditores. Não remove nem mesmo os preditores 100% correlacionados, mais pode remover algo que você quer, além de deixar lixo. Eu compliquei um pouco o método de peneiramento deles - a princípio estou peneirando os preditores do jeito antigo, via designTreatmentsN$scoreFrame (aumentei o limiar duas vezes - 2/N, para peneirar menos preditores potencialmente bons). Então eu removo todos os preditores que correlacionam >0,99 (eu tenho muitos deles após geração aleatória de deltas e somas. E eu olho para a correlação dos preditores uns com os outros, não com a variável alvo). Então eu procuro geneticamente o melhor conjunto de preditores restantes.
Tento usar algo mais do artigo sobre os componentes principais. A função abaixo constrói o modelo do componente principal e retorna R^2 para o caso de eu ter usado todos os componentes principais encontrados. Não tem "escala Y" como outro exemplo do artigo, mas desta forma é mais rápido. Agora eu o uso para estimar o conjunto de preditores (provavelmente para nada, eu ainda não sei :) ). A última coluna do parâmetro srcTable é a variável alvo. Pode haver erros se o preditor tiver muito poucos valores, a função pode não caber em alguns dados.
Enquanto antes eu tinha R^2 de cerca de 0,1, agora eu alcancei 0,3. Ainda não é suficiente, eles recomendam o uso de pelo menos 0,95. Outra coisa estranha é que com R^2=0,1 eu tive 37% de erro na frente, enquanto com R^2=0,3 este erro cresceu para 45%. Talvez o problema seja que acrescentei mais barras e mais indicadores ao conjunto de preditores. Um passo à frente e dois passos atrás, agora preciso analisar todo o conjunto de indicadores e remover os desnecessários. Ou o modelo de componentes principais simplesmente não é aplicável ao forex (difícil de verificar, primeiro preciso atingir R^2 > 0,95, e ver qual será o resultado na frente, com um modelo não treinado é muito cedo para tirar conclusões).
Eu também comparei o pacote GA (genética) e GenSA (recozimento gradiente, a partir do exemplo de Alexey). Ambos os pacotes alcançaram o mesmo resultado. A genética sabe como trabalhar com multi-tarefas, por isso ganhou a tempo. Mas a GenSA parece ganhar num só fio. Há também um truque para guardar os resultados, acho que o Alex vai gostar disso:
A questão é que a função intermediária fitness_GenSA_bin_Memoise retira dados do cache se esse conjunto de preditores já tiver sido encontrado pelo menos uma vez. O contentor fitness_GenSA_bin deve conter os próprios cálculos da função fitness, e só será chamado uma vez para cada conjunto único.
Até agora, só estou a usar parâmetros padrão para os indicadores. Penso que devem ser ajustados. Concordo, em geral, que se os indicadores tiverem sido desenvolvidos principalmente para D1, serão mais úteis com parâmetros padrão apenas neste período de tempo. Eu não sou capaz de mudar os resultados de D1 para H1, quanto mais eu uso indicadores, mais eu fico preso em D1. Acontece que os parâmetros do indicador precisam ser alterados dependendo do tempo, e do tempo, sim.
Não há "escala Y" a partir de outro exemplo do artigo,
Acho que é esse o objectivo do artigo. Reli-o, diz tão explicitamente.
Voltando ao esquema geral de preparar uma lista de preditores, no entanto.
O rastreio do ruído é apenas uma parte do problema e não resolve o resto dos problemas e recomendações nesta área.
Se tudo isso for feito, então o próximo algoritmo de trabalho está em loop, como a seguir.
1. nós pegamos um conjunto selecionado e processado de preditores. Esta lista é constante.
2. Para a janela atual, selecionamos os preditores por um dos algoritmos. Por exemplo, há dois algoritmos no carpete.
3. A adaptar o modelo.
4.
5. Desvie a janela e vá para o passo 2.
O número de preditores de ruído era mais de 80 daqueles conjuntos iniciais de preditores que eu tinha em minhas mãos!
O algoritmo padrão selecciona então cerca de metade dos restantes preditores que o algoritmo não classifica como ruído. medida que a janela se move, a composição desta metade está em constante mudança. Mas sempre o erro no conjunto de treinamento e o erro fora da amostra são aproximadamente iguais. Do qual concluo que o meu modelo não está excessivamente treinado e isto é uma consequência dos algoritmos de selecção de preditores descritos acima.
E que função de fitness você usa quando forçando o bruto?
Eu costumava treinar a floresta, e devolver um erro na amostra de validação. Em princípio, funcionou - se a floresta se sobrepõe aos comboios, mesmo que um pouco, o erro tende a 50%.
Agora eu uso GetPCrsquared(), esse código acima. Também tenho o seu exemplo do feature_selector_modeller.txt, mas preciso de o descobrir e obter o código correcto, por isso ainda não o testei nos meus dados.
Acho que é disso que se trata no artigo. Reli-o, diz explicitamente.
Eu também tentei Y-scale, R^2 em ambos os casos (com e sem Y-scale) saiu o mesmo (apesar de usarem pacotes diferentes!).
Acho que a escala Y pode dar o mesmo bom resultado com menos componentes principais. Mas, se mesmo usando todos os componentes o resultado ainda não é satisfatório (como no meu caso) - não há diferença. Além disso, funciona mais rápido, o que é mais importante para mim agora. Mas não provei pela teoria ou pela prática se este método é adequado para a seleção de preditores... No início tive a idéia de modelar os componentes principais em todos os preditores e selecionar os preditores através da análise dos coeficientes dos componentes. Mas depois reparei que com a adição de lixo - R^2 do modelo cai. Seria lógico tentar diferentes conjuntos de preditores e procurar por aqueles com R^2 mais alto, mas ainda assim é apenas uma teoria.