Tema interessante para muitos: o que há de novo em MetaTrader 4 e MQL4 - grandes mudanças no caminho - página 9
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
Agora que tocámos o mercado, gostaria de ouvir opiniões sobre um assunto...
De acordo com a filosofia da MQL5, os indicadores devem contar e as EAs devem negociar.
Mas o Market vende soluções prontas, como se costuma dizer, tudo em um.
Que tal melhorar o compilador para que os indicadores sejam armazenados em EAs como recursos?
Caso contrário, temos de transferir o código do indicador para o Expert Advisor, onde este não tem ambiente adequado. Mais uma vez, o esquema "indicador de indicador" faz com que seja um epopee inteiro a transferir o código para o Conselheiro Especialista.
Concordo,
Penso que seria útil acrescentar agora um separador para o Mercado - FILES, onde se pode colocar conjuntos, instruções, etc,
Penso que seria útil adicionar um separador - FILES onde se podem guardar conjuntos, instruções, etc.
Podemos refinar o compilador para armazenar indicadores em EAs como recursos?
Caso contrário, temos de deslocar o código de um indicador para um Consultor Especialista, onde este não tem ambiente adequado. Mais uma vez, o esquema "indicador de indicador" torna todo um épico deslocar o código para o Expert Advisor.
Ver MetaTrader 5 Client Terminal build 730 em 24 de Novembro de 2012
8. MQL5: Apoio adicional para o armazenamento de indicadores nos recursos do EX5. Ao mesmo tempo, os indicadores em recursos não poderão trabalhar com os seus próprios recursos.
Ver comunicado de imprensa MetaTrader 5 Client Terminal build 730 datado de 24 de Novembro de 2012
Isto é exactamente o que eu faço. E já escrevi aulas que podem passar ao Expert Advisor o histórico personalizado (em vez do histórico real do servidor). Mas o Expert Advisor não deve utilizar as funções do terminal directamente para implementar totalmente a minha ideia. Digamos, o mesmo OrderSend(). Deve funcionar apenas através de um "invólucro", cujo papel pode ser maravilhosamente desempenhado pela Biblioteca Standard. Escrevemos classes derivadas, encaixamo-las no Expert Advisor, e voila - funciona agora em dados históricos. Se o Expert Advisor utilizar directamente as funções do terminal, não poderá utilizar o histórico.
Bem, talvez seja devido ao meu longo trabalho com a biblioteca do MFC, com o qual fiquei muito satisfeito e com o qual encontro muitos paralelos. Estou certo de que os criadores da Biblioteca Standard também estão bastante familiarizados com o MFC.
A principal vantagem da Biblioteca Standard é o bom suporte da ideologia OOP, que permite passar ao Consultor Especialista um historial personalizado para que este funcione correctamente sem quaisquer modificações.
Posso perguntar o que não lhe agrada na Biblioteca Standard (bem, além da óbvia desvantagem - "demasiado preguiçoso para aprender")?
Isso não é uma desvantagem, conheço muito bem a SB, e este conhecimento dá-me uma compreensão de como tudo é incómodo e ineficiente.
Em vez de enviar uma encomenda, inicia-se um avô para um avô e um avô para um nabo.
Mas a principal desvantagem (de acordo com o Comércio) é que não há absolutamente nenhum controlo da execução. Basta enviar uma ordem ao servidor e deixar a relva crescer. Mas embrulharam o Send de 10 maneiras, como para todas as ocasiões, mas os casos acabaram por ser 100.
Quanto à ideologia: a herança por mais de 2 gerações é um erro, perdem-se tanto a compreensão como a flexibilidade.
A maioria das classes (tem razão) não foram inventadas, foram apenas reinventadas pelo MFC, mas isso não é uma desvantagem, porquê reinventar a roda.
Mas penso que a principal desvantagem é que não podem contar com isso).
Escrevi tanto com como sem SB. Sem ela, torna-se mais rápido e mais transparente. É demasiado versátil, por isso é lento nas curvas.
Em Delphi, por exemplo, existe o conceito de um projecto, o que implica a compilação conjunta. E a divisão dos programas em 3 tipos é um pouco duvidosa em geral, porque o compilador, em teoria, pode determinar a si próprio o que o programa faz, mas uma vez que vai tão longe que os indicadores só negoceiam à força, e para a EA é necessário implementar o código no seu interior, então só podemos esperar que o coração dos programadores alguma vez derreta e que eles permitam fazer projectos).
secundado,
Penso que seria útil adicionar um separador FILES para o mercado para armazenar conjuntos, instruções e assim por diante, por exemplo,
embora o separador Discussão o permita, mas ainda não é o mesmo.
Ver MetaTrader 5 Client Terminal build 730 datado de 24 de Novembro de 2012
Óptimo, como é que eu perdi isto, aaah são as construções de pré-férias.
A travessia no seu posto significa que eles já podem?
Essa é exactamente a desvantagem, conheço muito bem a SB, e este conhecimento dá-me uma compreensão de como tudo é pesado e ineficiente.
Obrigado pela sua resposta abrangente. Não tenho objecções categóricas a nenhuma das vossas declarações. Apenas... algumas observações...
Em vez de enviar uma encomenda, avô por avô, avô por nabo.
Mas é isso que dá flexibilidade ao sistema, e é isso que nos permite enviar histórico personalizado e emulação de servidor para a EA. Se as encomendas fossem enviadas directamente através de OrderSend() - teríamos de ser nós próprios a escrever este "Grandma's for Grandpa, Grandpa for Grandpa"... Não está claro qual é melhor...
Mas a principal desvantagem (de acordo com o Comércio) é que não existe absolutamente nenhum controlo de aplicação. Se "bater" uma ordem a um servidor e não se importar com nada. Mas embrulharam o Send de 10 maneiras, como para todas as ocasiões, mas os casos acabaram por ser 100.
Não tenho experiência suficiente aqui - posso apenas teorizar. Eu próprio analiso os códigos de retorno, mas tenho muito pouca experiência. Concordo que não existe controlo suficiente da execução no próprio SB.
Quanto à ideologia: considero a herança por mais de 2 gerações um erro, além de perder tanto a compreensão como a flexibilidade.
Sim, de facto, uma herança demasiado profunda é muito prejudicial à compreensão. Mas quanto à flexibilidade - tenho dificuldade em concordar. Tenho um monte de casos de herança de 4-5 gerações, e não parece causar quaisquer problemas. Mas, posso concordar que este é o meu caso, para outros, esta profundidade da herança pode ser um grande obstáculo.
Mas a principal desvantagem penso que não é possível contar com ela, escreve-se algo sobre ela e ela será retrabalhada :)
Sim, concordo plenamente com isso.
Escrevi tanto com como sem SB. Escrevi com SB mas sem ele fiquei mais rápido e mais transparente. É demasiado versátil, por isso é desajeitado nas curvas.
Gostei de SB pela sua capacidade de criar um modelo TC, e subsequentemente ligar-lhe apenas classes de objectos descrevendo entradas, manutenção e saídas. Receio que sem SB tal ideologia levaria à criação do mesmo, mas SB proprietário.
Sobre "mais rápido e mais transparente" - parece-me que tal ideologia é boa quando temos qualquer TS tratado como um todo. No entanto, parece-me que se trata de um erro grave de algotrading. O TS deve ser visto apenas como um conjunto de "cubos" - um conjunto de geradores de entrada, determinante do TP-SL de entrada, determinante do lote de entrada, controlador de reboque e assim por diante... Esta ideologia permite obter muito rapidamente centenas de diferentes variantes TS, onde temos apenas algumas "mais rápidas e mais transparentes".
Por exemplo, tendo escrito cinco TS diferentes sem um modelo - para escrever o sexto, teremos de repetir tudo, mesmo utilizando partes destes cinco sistemas. Tendo escrito o modelo - só introduziremos estes cinco sistemas no mesmo em partes, e como resultado teremos até cinco geradores de entrada, filtros de entrada, determinantes TP-SL e assim por diante. Combinando-os obtemos facilmente uma centena de TS, dos quais podemos escolher os mais estáveis e rentáveis.
Portanto, na minha opinião, a lentidão da SB é realmente um "pau com duas pontas", e a sua aplicação ou não aplicação deve ser decidida em cada caso individualmente.
Super, como é que eu perdi isso, ahhhhhh são as construções anteriores ao Ano Novo.
Será que a travessia no seu posto significa que já podem?
Óptimo, como é que eu perdi isso, ahhhh são as construções anteriores ao Ano Novo.
Tem sido discutido aqui: https://www.mql5.com/ru/forum/3409#comment_408123