MT5 e velocidade em ação - página 71
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
Eu sugiro que este é o fim da teorização, que nunca se cruzará com a prática aqui.
Então sugiro que você também interrompa os inúteis testes síncronos de rosca única.
Esperando obter resultados paralelos.
O problema não é resolvido de forma alguma. Os programas MQL se tornarão mais complicados por uma ordem de grandeza, se as variáveis internas, por exemplo, forem lidas e escritas a partir de diferentes linhas.
É que a MQL6 deve ser semelhante à Erlang, e não à C++ )
Então sugiro que você interrompa também os testes síncronos sem sentido com uma única rosca.
Esperando obter resultados paralelos.
Estou preocupado com os atrasos de grande magnitude que ocorrem em quase todos os carrapatos. Não tem nada a ver com fios. Os desenvolvedores estão descobrindo isso.
É que a MQL6 deve ser semelhante à Erlang, e não à C++ )
então Scala é melhor.
.... mas não importa como você olhe para ele, por trás dos invólucros dessas fortes linguagens funcionais com digitação dinâmica... ainda será máquina C++, Python é uma prova disso, o discutido java com loops de eventos é de outra galáxia onde você precisa ter um sistema multiprocessador distribuído para obter algum tipo de expansão e escalabilidade do sistema de computação
Na escola.
- Vovochka, como você usa a penugem de frango?
- Eu não sei.
- Bem, em que você dorme?
- No chão.
- E no que você põe a cabeça?
- Em uma bota de feltro.
- E sobre o que seus pais dormem?
- No chão.
- E sobre o que eles colocam a cabeça?
- Sobre o valenki.
- E em que a vovó dorme?
- No fogão.
- E no que ela põe a cabeça?
- Em um travesseiro.
- E no travesseiro, o que é a penugem?
- E no travesseiro está um valenki.
Scala é melhor que
.... mas não importa como você olhe para ele, por trás dos invólucros dessas fortes linguagens funcionais com digitação dinâmica... Python é uma prova disso, o discutido java com loops de eventos é de outra galáxia onde você tem que ter um sistema multiprocessador distribuído para obter algum tipo de extensibilidade e escalabilidade do sistema computacional.
É isso mesmo, Python está escrito em C e Python tem uma biblioteca asyncio que é baseada no modelo de loop do evento.
Lá se vai a anedota da faixa ))
então Scala é melhor.
O principal é compilar em VHDL e fazer seu próprio servidor)
A discussão foi para algum lado - a velocidade de integração com Python é obviamente uma questão importante, mas há muitos problemas básicos que afetam a velocidade de execução dos EAs.
Sugiro focar no problema que na função OnTradeTransaction na chamada final de TRADE_TRANSACTION_HISTORY_ADD os campos das estruturas MqlTradeTransaction e MqlTradeResult estão praticamente vazios, ou seja, eles não são preenchidos por analogia com a forma como a ordem é então refletida na guia Histórico e como eles são arquivados em Ajuda/Documentação. A correção desta falha já daria uma verdadeira velocidade na execução do combate, pois não haveria necessidade de chamar a HistoryOrderSelect desnecessariamente para obter valores exaustivos sobre a ordem executada.
E em geral, no nível da comunidade Mql, a eliminação desta lacuna levará a uma redução maciça do esforço necessário para criar diferentes muletas em Expert Advisors para contornar as deficiências da implementação atual da OnTradeTransactio.
A questão é como influenciar a equipe MQ? Talvez um posto separado com votação e coleta de assinaturas para a eliminação desta deficiência desta função?
A questão é como influenciar a equipe de desenvolvimento da MQ?
Minha receita parece funcionar: reproduzir o problema com código conciso.
A discussão foi para algum lado - a velocidade de integração com Python é obviamente uma questão importante, mas há muitos problemas básicos que afetam a velocidade de execução dos EAs.
Sugiro focar no problema que na função OnTradeTransaction na chamada final de TRADE_TRANSACTION_HISTORY_ADD os campos da MqlTradeTransaction e MqlTradeResult estão praticamente vazios, ou seja, eles não são preenchidos por analogia com a forma como a ordem é então refletida na guia Histórico e como eles são arquivados em Ajuda/Documentação. A correção desta falha já daria uma verdadeira velocidade na execução do combate, pois não haveria necessidade de chamar a HistoryOrderSelect desnecessariamente para obter valores abrangentes sobre a ordem executada.
E em geral, no nível da comunidade Mql, a eliminação desta lacuna levará a uma redução maciça do esforço necessário para criar diferentes muletas em Expert Advisors para contornar as deficiências da implementação atual da OnTradeTransactio.
A questão é como influenciar a equipe MQ? Talvez um posto separado com votação e coleta de assinaturas para a eliminação desta deficiência desta função?
Python é um bom exemplo de um modelo orientado por eventos. E a anedota de Igor está exatamente no ponto.
E se o desenvolvedor entendeu o significado do exemplo, então ele sabe onde cavar.
Qualquer expectativa de resultado oportuno, mais cedo ou mais tarde, repousa em um modelo de execução síncrona.
Em mql chegou. As possibilidades do idioma são muito ricas, mas artificialmente limitadas à execução síncrona.
Roman:
Не понимание примера с Python, говорит о не понимании обсуждения асинхронности в целом.
Você é que não entende. Não desarrume o fio.