Perguntas sobre MQL5 Wizard e biblioteca padrão de classes comerciais - página 11

Novo comentário
 
Reshetov:

Três perguntas:

  1. Como fazer o módulo de sinal funcionar apenas nos preços de abertura e não em todas as carraças?
  2. Como obter os valores de voto do módulo de sinal no módulo de rastreio de posição? É necessário arrastá-lo com um sinal já calculado e não inventar outro módulo de sinal a seguir.
  3. Como obter os valores de voto do módulo de alarme no módulo de gestão de dinheiro e risco? É necessário abrir volumes de acordo com os sinais comerciais já calculados, e não compor outro módulo de sinal para o cálculo do volume.

Teoricamente, podemos, evidentemente, construir a EA usando o assistente e depois adicionar todas estas características manualmente ao código. Mas é desejável que tudo isto tenha sido implementado sob a forma de métodos padrão, ou seja, para bonecos que querem usar o feiticeiro, para que não tenham de entrar no código e editar, por exemplo, caso queiram substituir um módulo de sinal por outro.

Responde a todas as suas próprias perguntas: "... construir a EA com a ajuda de um feiticeiro, e depois ... manualmente...". Ainda não há outras opções. O feiticeiro, muito provavelmente, não será desenvolvido num futuro próximo. As aulas da Biblioteca Standard não são um dogma, mas uma tentativa de fornecer um conjunto de soluções típicas (na minha opinião). Herdar (para utilização no Wizard), métodos de sobrecarga, adicionar os seus próprios métodos. E será "feliz"...
 
uncleVic:
Respondeu pessoalmente a todas as suas perguntas: "... ...construir a EA com a ajuda de um feiticeiro e depois... manualmente...". Ainda não há outras opções. O feiticeiro, muito provavelmente, não será desenvolvido num futuro próximo.

É uma pena que um tão bom empreendimento seja abandonado num canto distante.

Se tivesse sido actualizado, muito poderia ter sido feito, ou seja, poderíamos ter criado módulos prontos a partir dos quais os dummies e outros utilizadores poderiam montar vários EAs prontos sem ter de passar por códigos. Mas neste caso temos a mesma confusão que com o mql4 algorítmico, ou seja, pega-se num algoritmo, entra-se no código e utiliza-se manualmente. Mais uma vez, o princípio do OOP é violado. Por exemplo, se quiser substituir um módulo por outro, terá de voltar ao código e alterar tudo manualmente de novo. Recebe-se um monte de disparates, porque apenas "rastejar" através dos códigos, para pelo menos compreender onde e o que modificar, mataria muito tempo.

Foi um bom começo. É uma pena. Acabei de criar um módulo de sinal ontem, mas ainda estou intrigado com a forma de fazer com que toda a EA funcione sem ir sempre ao código fonte. Queria escrever um artigo sobre como utilizá-lo. Acabei de inserir e acrescentar gestão de posições, gestão de dinheiro e gestão de riscos, e tudo funciona. Mas não, não vai funcionar. Se um utilizador constrói uma EA usando o feiticeiro, esta não funcionará. Terá de escrever uma resma inteira de instruções onde procurar no código e o que mudar. Para não mencionar que ainda tenho de lidar com tudo isto pessoalmente antes de escrever uma instrução.

Portanto, agora não resta nada para os utilizadores a não ser aprender mql5, OpenCL, etc. para lidar com o autotrading. Caso contrário, não terão qualquer sorte.

Bem, uma vez que este projecto foi abandonado, vou agora pensar numa direcção diferente.

 
Reshetov:

É uma pena que um esforço tão bom seja abandonado a um canto distante.

Esperemos que não seja abandonado, mas que seja arquivado. Eu próprio tenho muitos pensamentos interessantes sobre o desenvolvimento do Mestre. Mas...
 
uncleVic:
Esperemos que não seja abandonado mas sim adiado. Eu próprio tenho muitos pensamentos interessantes sobre o desenvolvimento do Feiticeiro. Mas...

A esperança morre por último (c) provérbio popular

À primeira pergunta, ou seja, como testar o módulo de sinal abrindo preços e trocando por carrapatos, encontrei uma solução para não ter de escavar os códigos, e até melhor do que a geralmente aceite.

Ainda não descobri como ler as indicações do módulo de sinal nos módulos de gestão de posição e de equidade e de gestão de risco. Pesquisei o código fonte e olhei à minha volta. O módulo de sinal obtém os seus resultados através do método direction(), ou seja, só preciso de abordar uma instância desta mesma classe de módulo na gestão de posições e módulos de gestão de equidade e risco e chamar este mesmo método para ler os seus valores. Como isto pode ser feito sem alterar o código, ainda não está claro.

 
Reshetov:

A esperança brota eterna (c) provérbio popular

À primeira pergunta, isto é, como testar o módulo de sinal abrindo preços e comerciando por carrapatos, encontrei uma solução para não ter de entrar nos códigos, e ainda melhor do que a geralmente aceite.

E não consigo perceber como ler as indicações do módulo de sinal na gestão de posições e módulos de equidade e gestão de risco, sem escavar os códigos. Pesquisei o código fonte e olhei à minha volta. O módulo de sinal obtém os seus resultados através do método direction(), ou seja, só preciso de abordar uma instância desta mesma classe de módulo nos módulos de gestão de posições e gestão de capital e risco e chamar a este mesmo método para ler os seus valores. Como isto pode ser feito sem alterar o código, ainda não está claro.

Sem alterar os códigos, provavelmente não vai funcionar.

 
uncleVic:

Não alterar os códigos provavelmente não vai funcionar.

Ainda não está tudo perdido. Pode criar classes herdadas de CExpert, CExpertMoneu e CExpertTrailing e acrescentar-lhes os métodos necessários para aceder a uma instância da classe do módulo de sinal. Mas também há aqui uma questão, como o feiticeiro escreve na EA criada #include <Expert\Expert.mqh> e não o seu descendente.

Ainda temos de pensar sobre isso.

Se os criadores tivessem adivinhado imediatamente que um módulo de sinal pode ser utilizado para todos os outros módulos como o principal e os sinais adicionais (como nesta versão do assistente) podem ser adicionados aos módulos de apoio à posição e à equidade e gestão de risco e os códigos teriam sido mais fáceis. Mas, no nosso caso, cada módulo requer a especificação de condições adicionais para os sinais e, portanto, precisam de configurações externas adicionais, o que resulta num tal monstro com muitos parâmetros a serem optimizados. Para não mencionar que os sinais de um módulo podem entrar em conflito, ou seja, um módulo de sinal pode abrir uma posição e um módulo de acompanhante - fechá-lo no tick seguinte, se as condições de entrada e saída do mercado forem contraditórias.

 
Reshetov:

Ainda não está tudo perdido. Afinal, é possível criar classes herdadas de CExpert, CExpertMoneu e CExpertTrailing e acrescentar-lhes os métodos necessários de acesso a uma instância da classe do módulo de sinal. Mas também há aqui uma questão, como o feiticeiro escreve na EA criada #include <Expert\Expert.mqh> e não o seu descendente.

Ainda temos de pensar sobre isso.

Se os criadores tivessem adivinhado imediatamente que um módulo de sinal pode ser utilizado para todos os outros módulos como o principal e os sinais adicionais (como nesta versão do assistente) podem ser adicionados aos módulos de apoio à posição e à equidade e gestão de risco e os códigos teriam sido mais fáceis. Mas, no nosso caso, cada módulo requer a especificação de condições adicionais para os sinais e, portanto, precisam de configurações externas adicionais, o que resulta num tal monstro com muitos parâmetros a serem optimizados. Sem mencionar o facto de que os sinais de um módulo podem entrar em conflito, ou seja, um módulo de sinal pode abrir uma posição e um módulo de acompanhante - fechá-lo no tick seguinte, se as condições de entrada e saída do mercado forem contraditórias.



É assim que é concebido. O feiticeiro cria o "peixe" da EA. Além disso:

  • substituir a inclusão não é problema;
  • o sinal principal é intencionalmente criado no exterior (por conveniência de substituição);
  • adicionar algumas entradas e chamadas de método de ajuste?
 
uncleVic:

Era assim que se pretendia que fosse. O mestre cria o 'peixe' do conselheiro. A seguir:

  • A substituição da linha em linha não é um problema;
  • o sinal principal é intencionalmente criado no exterior (para facilidade de substituição);
  • adicionar algumas intutas e chamadas de método de ajuste?


Isso é o que é feio, coisas do género:

  1. O acesso aos métodos das classes de módulos incluídos no sistema comercial é negado mesmo para leitura, o que exclui completamente a possibilidade de coordenar o seu trabalho.
  2. Os módulos de sinal podem facilmente entrar em conflito com os módulos de localização, porque têm sinais diferentes, pelo que não se pode excluir a incompatibilidade.
  3. Sinais diferentes em módulos, e portanto todos eles têm configurações separadas, o que resulta em não poucos, mas muitas configurações de entrada para uma EA. Quanto mais diferentes forem as configurações, maior será a probabilidade de encaixar na história.
  4. Após a operação do feiticeiro é por vezes necessário percorrer as fontes a fim de resolver os problemas. Para o utilizador final que não está familiarizado com a programação não é de todo adequado, porque precisa de "plug-and-play". Tais confusões também criam problemas para um programador, porque é muito mais fácil trabalhar com código próprio do que com código empilhado com um feiticeiro. Uma dificuldade adicional é que as classes são herdadas, ou seja, a causa do mal-entendido raramente pode ser encontrada ao nível dos descendentes, mas é preciso olhar mais a fundo para as classes dos pais.

Queríamos o melhor. Acontece que é o mesmo de sempre (c) Chernomyrdin

Em geral, a maioria dos mal-entendidos podem ser corrigidos, mas isto deve ser feito ao nível da classe mãe raiz e depois as classes fixas podem ser distribuídas através de actualizações da plataforma. Isto é, é necessário abrir o acesso ao método Direction() do módulo de sinal a partir dos módulos de apoio à posição e de equidade e gestão de risco. Porque se os criadores de módulos individuais editarem o código fonte das classes pai, a incompatibilidade resultante do código fonte será incompatível e os módulos criados não funcionarão em outros computadores. Se os criadores de módulos criarem classes pai com métodos sobrepostos, a incompatibilidade ainda estará a nível de mestre, porque este último escreve os seus próprios inlúdios, e, consequentemente, os utilizadores finais precisam de voltar a escrever instruções, e dificilmente quererão entrar nas fontes, e se o fizerem, então erro num único símbolo ou noutro lugar, etc...

 
Reshetov:

Esse é o problema, porque desde o início há coisas que não foram consideradas:

  1. Os métodos de classe dos módulos incluídos no sistema comercial não são acessíveis mesmo para leitura, o que exclui completamente a possibilidade de coordenar o seu trabalho.
  2. Os módulos de sinal podem facilmente entrar em conflito com os módulos de localização, porque têm sinais diferentes e, portanto, não se pode excluir a incompatibilidade.
  3. Sinais diferentes nos módulos, e portanto todos eles têm configurações separadas, o que resulta em não poucos, mas muitos parâmetros de entrada para a EA. Quanto mais diferentes forem as configurações, maior será a probabilidade de adaptação à história.
  4. Após o funcionamento do feiticeiro é por vezes necessário percorrer as fontes a fim de resolver os problemas. Para o utilizador final que não está familiarizado com a programação não é de todo adequado, porque precisa de "plug-and-play". Tais confusões também criam problemas para um programador, porque é muito mais fácil trabalhar com código próprio do que com código empilhado com um feiticeiro. Uma dificuldade adicional é que as classes são herdadas, ou seja, a causa do mal-entendido raramente pode ser encontrada ao nível dos descendentes, mas é preciso olhar mais a fundo para as classes dos pais.

Queríamos o melhor. Acontece que é o mesmo de sempre (c) Chernomyrdin

Em geral, a maioria dos mal-entendidos podem ser corrigidos, mas é desejável fazê-lo ao nível da classe mãe raiz e depois distribuir classes fixas através de actualizações. Porque se o código fonte das classes mãe for corrigido pelos programadores de módulos, a incompatibilidade resultante do código fonte será incompatível e os módulos criados não funcionarão em outros computadores. Se o programador criar classes pai com métodos sobrepostos, então a incompatibilidade já está ao nível de mestre, porque ele escreve as suas próprias inclusões, e por isso precisa novamente de escrever instruções aos utilizadores finais, e é pouco provável que eles queiram entrar no código fonte, e se entrarem, então erro num único carácter ou noutro lugar, e assim por diante e assim por diante.

Dê-nos as suas sugestões específicas. Iremos considerá-los.
 
uncleVic:
Deixe-nos dar-lhe algumas sugestões. Iremos revê-los.

Até agora, existe apenas uma única coisa que aborda as desvantagens acima referidas:

Acesso aberto à leitura dos valores devolvidos pelo método Direction() do módulo de sinal a partir dos módulos de gestão de posição e gestão de capital e risco.

Adicione mais um método, por exemplo o identificador duplo getMainSingnal(), que chama uma instância da classe do módulo de sinais e retorna o resultado do método Direction() do módulo de sinais. Uma vez que esta troca de informação tem lugar em modo apenas de leitura, a segurança não será quebrada de forma alguma.

Para o fazer

  1. Atribuir alguns campos nas classes CExpertMoney e CExpertTrailing para armazenar uma instância de CExpertSignal, ou seja, o módulo principal de sinais.
  2. Uma instância do CExpertSignal, isto é, o módulo de sinais, deve ser passada para os módulos de gestão de posição e gestão de capital e risco durante a inicialização das instâncias destes módulos e armazenada nos campos especificados na etapa 1. Obviamente, antes de o fazermos, devemos também verificar (certificar-se) que já existe uma instância da classe do módulo de sinal, ou seja, que foi criada.
  3. Criar em CExpertMoney e CExpertTrailing classes métodos adicionais, com identificador duplo getMainSingnal(), que se dirigem a uma instância de classe do módulo de sinais, armazenados nos campos correspondentes destas classes e devolver o resultado do método Direction() do módulo de sinais.

P.S. A classe CExpert tem uma referência a uma instância da classe do módulo de sinal.

CExpertSignal    *m_signal;                   // trading signals object
Tem de criar campos análogos para as classes CExpertMoney e CExpertTrailing e passar o mesmo valor do campo acima mencionado para a classe CExpert durante a inicialização
1...456789101112131415
Novo comentário
Razão: