Aprendizado de máquina no trading: teoria, prática, negociação e não só - página 2947
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
Muito bom. E quais versões e conjuntos de operações do ONNX serão suportados?
Todas as que aparecem no projeto de código aberto ONNX Runtime.
Tudo isso aparece no projeto de código aberto ONNX Runtime.
onnx.defs.onnx_opset_version() escreve que opset=17. Sobre a versão no registro MT, ele diz 1.14.0, embora eu ache que a versão mais recente do ONNX seja a 1.13.1
onnx.defs.onnx_opset_version() escreve que opset=17. Sobre a versão no registro MT, ele diz 1.14.0, embora pareça que a versão mais recente do ONNX seja a 1.13.1
Não, é isso mesmo. É a versão mais recente do ONNX, 1.13.1, e a versão mais recente do ONNX Runtime, 1.14.1
O conjunto de funções para acesso a gráficos/ticks/posições de negociação/histórico de transações é apresentado acima. Isso é suficiente para o trabalho direto dos scripts python.
Talvez adicionemos o acesso a indicadores.
A transferência de indicadores não é um método universal, embora provavelmente seja suficiente para a maioria dos operadores. Por exemplo, estou mais interessado em transmitir dados não em cada barra, mas nos momentos em que os níveis são rompidos. Alguém está interessado em outra coisa, etc.
Dificilmente é possível criar uma forma ideal de troca que atenda a todos, portanto, os métodos de muleta no estágio de desenvolvimento são inevitáveis. O principal é evitar métodos alternativos no estágio de lançamento em um testador ou em um VPS.
Testei o projeto ONNX.Price.Prediction na nova versão do MT5 b3601. Tudo parece funcionar - treinamento e saída em python, saída no MT5 (removi a dll para onnx da raiz e reiniciei o terminal).
Podemos aguardar o lançamento e começar a tentar com nossos próprios modelos)
A transmissão de indicadores não é um método universal, embora seja suficiente para a maioria dos traders. Por exemplo, estou mais interessado em transmitir dados não em cada barra, mas nos momentos em que os níveis são rompidos. Alguém está interessado em outra coisa, etc.
Dificilmente é possível criar uma forma ideal de troca que atenda a todos, portanto, os métodos de muleta no estágio de desenvolvimento são inevitáveis. O principal é evitar métodos alternativos na fase de lançamento em um testador ou em um VPS.
. .
Se tudo isso for resolvido, o MT deixará de ser um intermediário entre uma corretora e um cliente e se tornará apenas uma ferramenta conveniente para escrever estratégias e indicadores.
A MT fornece cotações e, ao mesmo tempo, é muito rápida e confiável - um excelente elemento para ser incorporado em um sistema de negociação. Permitir que a string seja passada para o python significa consolidar essa função do terminal.
Por exemplo, a criptografia passou o MT porque o corretor na criptografia é um elemento supérfluo e desnecessário, mas isso não cancela o uso do terminal para escrever e usar Expert Advisors.
Para simplificar: escreva um EA => execute-o no BTCUSD => negocie na Binance por meio de um script Python => agradeça ao MetaTrader por tê-lo.
Não entendo por que você precisa de todas essas coisas com o ONNX.
Há um cenário básico óbvio de como tornar o MT5 e o MO amigos:
1. A partir de OnInit(), inicie o script python como um processo separado.
2. Você precisa de algumas funções de troca de informações entre o python e o EA, no modo em que o EA pode esperar por informações.
3. Crie uma pasta Models e jogue os modelos do TensorFlow nela.
É ISSO!!! A integração do MT e do MO aconteceu! Todos estão felizes.
Em primeiro lugar, não entendo o porquê de toda essa fantasia com a ONNX.
Há um cenário básico óbvio para tornar o MT5 e o MO amigos:
1. A partir de OnInit(), o script python é iniciado como um processo separado.
2. Precisamos de algumas funções de troca de informações entre o python e o EA, no modo em que o EA pode esperar pela chegada das informações.
3. Criamos uma pasta Models e lançamos modelos TensorFlow nela.
É ISSO!!! A integração do MT e do MO aconteceu! Todos estão felizes.
Existe essa integração com o R. Só que não está claro por que o R é necessário no VPS e por que você precisa de problemas para dar suporte à sua integração com o MT (controle de versão da linguagem e dos pacotes, etc.). O mesmo ocorrerá com o python.
Há também um ponto relacionado à velocidade, que é muito importante em nosso negócio. Veja como o fxsaber arranha milissegundos em uma batalha constante com metaquotes à medida que eles se transformam em pontos de lucro. Obviamente, um pacote de qualquer coisa com qualquer coisa será executado mais lentamente do que os dois programas isoladamente.
Parece que o que poderia ser mais óbvio.....
Podemos aguardar o lançamento e começar a tentar com nossos próprios modelos)
Existe essa integração com o R. Só que não está claro por que o R é necessário no VPS e por que precisamos de problemas com o suporte à sua integração com o MT (controle de versão da linguagem e dos pacotes, etc.). O mesmo ocorrerá com o python.
Há também um ponto relacionado à velocidade, que é muito importante em nosso negócio. Veja como o fxsaber arranha milissegundos em uma batalha constante com metaquotes à medida que eles se transformam em pontos de lucro. Obviamente, um pacote de qualquer coisa com qualquer coisa será executado mais lentamente do que os dois programas isoladamente.
Parece que o que poderia ser mais óbvio.....
Levando em conta o spread e as comissões da bolsa/corretora, é necessário prever o tempo medido em dezenas de minutos ou horas. O que a diferença de 50 milissegundos tem a ver com isso?
Como exatamente, na vida real, o MQ supera o fxsaber em 5 milissegundos?