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

[Victor Kirillin]

Reshetov:

Até agora, existe apenas uma única solução para resolver 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, com identificador duplo getMainSingnal(), que se refere a 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 está em modo apenas de leitura, a segurança não é comprometida de forma alguma.

Para o fazer

1. Atribuir campos nas classes CExpertMoney e CExpertTrailing para armazenar uma instância da classe CExpertSignal, ou seja, o módulo principal de sinais.
2. Esta mesma instância de classe CExpertSignal, ou seja, o módulo de sinal, deve ser passada para os módulos de gestão de posições e de gestão monetária durante a inicialização das instâncias destas classes de módulos e a sua poupança nos campos especificados no passo 1. Obviamente, antes de o fazer, deve verificar (certificar-se) de 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 getMainSignal(), que se refere à instância de classe do módulo de sinais, armazenado nos campos apropriados destas classes e retorna como resultado, o resultado do método Direction() do módulo de sinais.

Quase tudo é claro. A única coisa que quero esclarecer: "porque é que este vosso desejo de ver o sinal ao nível do MM e do trailing deve ser implementado ao nível da classe base?

Não creio que isso seja uma coisa boa (ou seja, má). O algoritmo não é típico (do meu ponto de vista). Pelo que entendi, tem os seus próprios módulos MM e de rastreio (com os seus próprios algoritmos ligados ao sinal).

Aqui e colocar neles o correspondente 1.,2.,3.

[Yury Reshetov]

uncleVic:

Quase tudo é claro. A única coisa que gostaria de esclarecer é "porque é que este seu desejo de ver o sinal a nível de MM e de trailing deve ser implementado a nível de classe base".

Não creio que isso seja uma coisa boa (ou seja, má). O algoritmo não é típico (do meu ponto de vista). Como eu entendi, têm os vossos próprios módulos de MM e trailing (com os vossos próprios algoritmos ligados ao sinal).

Por isso, ponha neles os 1, 2, 3 apropriados.

A questão é que o Master toma a classe SEhregt como base. E consequentemente, não posso substituir as funções necessárias nos módulos que crio, porque já são incompatíveis com esta classe CEhregt muito básica desde o início, porque não têm acesso a uma instância de classe de módulos de sinais.

Porque a instância da classe do módulo de sinal é armazenada apenas no campo da classe SEhregt no ficheiro Expert.mqh, linha 67

CExpertSignal    *m_signal;                   // trading signals object

e este campo não é partilhado (inacessível) com outras classes e módulos criados a partir delas.

Por esta mesma razão, não há maneira de anular as classes CExpertMoney e CExpertTrailing para as tornar compatíveis com o feiticeiro.

Afinal de contas, se o acesso for negado nas classes dos pais, os descendentes não o obterão de forma alguma.

Chegar à raiz (c) "Aphorismos" de Kozma Prutkov

[Yury Reshetov]

Descobri como passar sinais de negociação do módulo de sinal para os módulos de manutenção de posição e de gestão de dinheiro e risco sem passar instâncias de CExpertSignal.

Vamos adicionar duas linhas cada uma às classes CExpertMoney e CExpertTrailing:

  double m_signaldirection; // Direction from signals module
 
  void              setSignalDirection(double value)  { m_signaldirection = value; }
  

Para o ficheiro ExpertMoney.mqh:

class CExpertMoney : public CExpertBase
  {
protected:
   //--- Direction from signals module  
   double m_signaldirection;
   //--- input parameters
   double            m_percent;

public:
                     CExpertMoney();
   void              setSignalDirection(double value) { m_signaldirection = value; }        
   //--- methods of setting adjustable parameters
   void              Percent(double percent)    { m_percent=percent; }
   //--- method of verification of settings
   virtual bool      ValidationSettings();
   //---
   virtual double    CheckOpenLong(double price,double sl);
   virtual double    CheckOpenShort(double price,double sl);
   virtual double    CheckReverse(CPositionInfo* position,double sl);
   virtual double    CheckClose(CPositionInfo* position);
  };

Para o ficheiro ExpertTrailing.mqh:

class CExpertTrailing : public CExpertBase
  {
protected:
   
    //--- Direction from signals module
   double m_signaldirection;
public:
   //---
   void              setSignalDirection(double value) { m_signaldirection = value; }        
   virtual bool      CheckTrailingStopLong(CPositionInfo *position,double& sl,double& tp)  { return(false); }
   virtual bool      CheckTrailingStopShort(CPositionInfo *position,double& sl,double& tp) { return(false); }
  };

Ao fazê-lo, definimos os campos e métodos necessários para passar os sinais comerciais. Agora precisamos de passar estes sinais comerciais para as classes de módulos. Fazemo-lo em Expert.mqh, ou seja, para a classe CExpert

Escreveremos uma linha para passar os nossos sinais de negociação para a classe de apoio às posições

m_trailing.setSignalDirection(m_signal.Direction());

e inseri-lo logo no início do método, que é chamado antes de cada paragem, ou seja, CheckTrailingStop():

bool CExpert::CheckTrailingStop()
  {
//--- Set signal direction to trailing stops module
   m_trailing.setSignalDirection(m_signal.Direction()); 
//--- position must be selected before call
   if(m_position.PositionType()==POSITION_TYPE_BUY)
     {
      //--- check the possibility of modifying the long position
      if(CheckTrailingStopLong()) return(true);
     }
   else
     {
      //--- check the possibility of modifying the short position
      if(CheckTrailingStopShort()) return(true);
     }
//--- return without operations
   return(false);
  }

Iremos escrever uma linha para passar sinais de negociação para a classe de gestão de dinheiro e risco:

m_money.setSignalDirection(m_signal.Direction());

e inseri-lo logo no início do método, que é chamado antes da abertura de cada posição, ou seja, CheckOpen():

bool CExpert::CheckOpen()
  {
//--- set signal direction to money management module
   m_money.setSignalDirection(m_signal.Direction());
   if(CheckOpenLong())  return(true);
   if(CheckOpenShort()) return(true);
//--- return without operations
   return(false);
  }

E é só isso, o problema está resolvido.

Agora, podemos obter o valor actual dos sinais de negociação nos módulos de gestão de posições e gestão de acções e riscos, acedendo ao valor do campo m_signaldirection. Tudo o que temos de fazer agora é registar os novos campos e métodos nas classes CExpertMoney e CExpertTrailing na documentação e adicionar os ficheiros modificados às actualizações.

[Victor Kirillin]

Aqui estão os ficheiros. No Expert, as linhas 100 e 123 são manuscritas.

Se tiver mais alguma pergunta, não hesite em fazer.

[Yury Reshetov]

uncleVic:

Aqui estão os ficheiros. No Expert, as linhas 100 e 123 são manuscritas.

Se tiver mais alguma questão, não hesite em contactar-me.

Que tipo de pessoas são estes criadores? Quando começarão a ouvir o que os comerciantes, que já têm experiência na criação de sistemas de negociação, precisam em vez de terem a sua própria visão de conceber sistemas de negociação que são praticamente inutilizáveis para os utilizadores finais, porque precisam de ajustar manualmente o código fonte? Quantas vezes tenho de explicar que posso subir e corrigir manualmente, e mesmo assim demorarei muito tempo a compreender o que é o quê, apesar de estar familiarizado com programação. E é pouco provável que o utilizador final entre no código, porque ele não compreende a programação. O senhor mesmo declarou, e passo a citar:

"O conhecimento de linguagens de programação já não é um pré-requisito para a criação de robôs comerciais. "Ver https://www.mql5.com/ru/articles/240.

"A primeira versão do MQL5 Wizard já tinha a possibilidade de criar rapidamente um Expert Advisor pronto a usar como um conjunto de módulos simples sob a forma de um código fonte na MQL5. Nem sequer precisava de conhecer a MQL5- bastava ler"Build your own Expert Advisor in MQL5 Wizard" (ver https://www.mql5.com/ru/articles/275).

Agora acontece que o conhecimento de linguagens de programação é necessário, uma vez que o utilizador tem de introduzir o código após o Wizard e editar algo lá. Ou seja, todas as declarações anteriores são invenções e enganos dos criadores.

Por exemplo, se eu escrever o meu próprio módulo de gestão de dinheiro e risco que deve abrir uma posição de acordo com o nível de sinal comercial emitido por um módulo escrito por outro desenvolvedor de módulos. Como resultado, o meu módulo será incompatível com o feiticeiro. Como explicar aos utilizadores que têm de ir a algum lugar no código e inserir algumas cordas para que o módulo funcione? Afinal, os criadores de módulos devem criar módulos, e o assistente deve combiná-los automaticamente num sistema consistente, para que os módulos, no mínimo, não entrem em conflito uns com os outros e sejam totalmente compatíveis uns com os outros. Mas no seu caso, o feiticeiro não o faz, porque depois do feiticeiro, tem de entrar em código e refazer tudo manualmente.

É realmente tão difícil colocar apenas seis linhas nos ficheiros das turmas de pais, que apontei no meu post anterior? E o problema será resolvido por si só e ninguém terá de entrar nas fontes e mudar alguma coisa aí. O que lhe vai cair das mãos? Porquê perder o seu tempo numa algaraviada com a demonstração de como algo deve ser corrigido manualmente depois do feiticeiro? Não pode passar este mesmo tempo numa tarefa mais útil, para que ninguém tenha de entrar no código para resolver problemas semelhantes mais tarde?

Qual é a ideologia da sua empresa - por um lado declara a automatização completa, mas quando se trata da prática, sugerem que entre no código e refaça tudo à mão depois da chamada "automatização"?

Em suma, como eu entendo, é inútil explicar tudo isto. Não se deve surpreender que os comerciantes não queiram mudar para o MT5 porque a plataforma é grosseira e desenvolvida não para a conveniência da auto-negociação, mas para a conveniência dos criadores dessa mesma plataforma. E a menos que o utilizador aprenda bem a programação, é melhor que se mantenha afastado do comércio automático.

Se não quiser, não tem de o fazer. Se não tiver mais nada para fazer, então sente-se aqui e explique a cada utilizador onde e como precisa de entrar no código fonte com as suas mãos e o que deve exactamente corrigir.

[Renat Fatkhullin]

Receio que esteja no aperto do maximalismo ou simplesmente não compreenda os limites da aplicabilidade das ferramentas.

Em qualquer caso, com este nível de argumentação e levando quase todas as questões para além dos limites do exagero, não pode haver trabalho consigo. O verdadeiro trabalho envolve a tomada de decisões conscientes, não a demagogia verbal.

[Yury Reshetov]

Renat:
Receio que esteja no aperto do maximalismo ou simplesmente não compreenda os limites de aplicabilidade das ferramentas.

Em qualquer caso, com este nível de argumentação e levando quase todas as questões para além dos limites do exagero, não pode haver trabalho consigo. O verdadeiro trabalho implica uma tomada de decisão consciente, não uma demagogia verbal.

Em geral, não pedi trabalho, ou seja, para ganhar dinheiro, e fiquei bastante satisfeito por cooperar numa base voluntária. Como e onde ganho o meu sustento eu decido.

Bem, não o fará e não tem de o fazer. O nosso negócio é oferecer, tem o direito de recusar. Como se costuma dizer: o mestre é o chefe.

Se a sua empresa já compreendeu tudo e até ensinou bonecos a criar os chamados Expert Advisors "ready-made". Além disso, a questão é que eles são apenas bons para demonstração do Wizard, mas não são muito bons para negociação automatizada, porque mesmo nos dados históricos a curva de equidade parece inconveniente à medida que a modularidade é implementada, mas falta a consistência dos módulos para um sistema de negociação completo.

Boa sorte!

[Mykola Demko]

Reshetov:
...

Por exemplo, se eu escrever o meu próprio módulo de gestão de dinheiro e risco, que deverá abrir uma posição de acordo com o nível do sinal de negociação emitido pelo módulo escrito por outro desenvolvedor de módulo. O resultado será que o meu módulo já é incompatível com o feiticeiro. Como explicar aos utilizadores que têm de ir a algum lugar no código e inserir algumas cordas para que o módulo funcione? Afinal, os criadores de módulos devem criar módulos, e o assistente deve combiná-los automaticamente num sistema consistente, para que os módulos, no mínimo, não entrem em conflito uns com os outros e sejam totalmente compatíveis uns com os outros. E tem um feiticeiro que não o faz, porque depois disso tem de entrar em código e refazer tudo manualmente.

É realmente tão difícil escrever apenas seis linhas nos ficheiros das turmas de pais, que apontei no meu post anterior? E o problema será resolvido por si só e ninguém terá de ir às fontes e mudar alguma coisa lá. O que lhe vai cair das mãos? Porquê desperdiçar o seu tempo numa algaraviada, demonstrando como consertar algo manualmente depois do feiticeiro? Não pode passar este mesmo tempo em algo mais útil, para que ninguém tenha de entrar em código mais tarde para resolver problemas semelhantes?

...

A sua abordagem viola o encapsulamento de classes, e como resultado traz confusão hierárquica.

Leia o livro de Steve McConell "O Código Perfeito" à sua vontade.

Imagine como uma fábrica para a produção de luvas, há um carimbo de cinco dedos para a mão direita e esquerda, mas depois vem uma pequena encomenda de luvas de seis dedos. Afinal de contas, há pessoas assim. Mas em vez de fazer um carimbo para eles (que fará um lote e aí permanecerá durante algum tempo), sugere a modificação do carimbo de cinco dedos, fazendo um dedo deslizante. Parece ser universal e tudo é grande, mas a força do selo de cinco dedos será enfraquecida em nome da universalidade (em nome de uma pequena necessidade de ocasionalmente produzir luvas de seis dedos). E então um lote de 300 quatro dedos será encomendado, e mais uma vez desmoronará o modelo bem provado e fiável.

Já lhe foi dito acima:

"porque é que o seu desejo de ver o sinal ao nível do MM e do trailing precisa de ser implementado ao nível da classe base".

Não creio que seja bom (ou seja, mau). O algoritmo não é típico (do meu ponto de vista). Pelo que entendi, tem os seus próprios módulos MM e de rastreio (com os seus próprios algoritmos ligados ao sinal).

Em vez de alterações à Bíblia padrão, seria melhor fazer desenvolvimentos para a alargar (através da herança). Então seria realmente interessante.

HZZ Além disso, para que as pessoas não tenham de lidar com os meandros do código (como escreveu acima), pode embrulhar os módulos prontos em biblio e deitá-los no mercado, depois basta ligar o módulo a partir de Reshetov e carregar no botão [download dough].

[Yury Reshetov]

Urain:

A sua abordagem viola o encapsulamento de classes, e como resultado introduz confusão hierárquica.

Leia o livro "Código Perfeito" de Steve McConell à sua vontade.

Simplificando, pense no Mestre como uma fábrica de luvas, há um carimbo de cinco dedos para a mão direita e esquerda, mas depois chega uma pequena encomenda de luvas de seis dedos. Afinal de contas, há pessoas assim. Mas em vez de fazer um carimbo para eles (que fará um lote e aí permanecerá durante algum tempo), sugere a modificação do carimbo de cinco dedos, fazendo um dedo deslizante. Parece ser universal e tudo é grande, mas a durabilidade do selo de cinco dedos será enfraquecida em nome da universalidade (em nome de uma pequena necessidade de produzir ocasionalmente luvas de seis dedos). E então um lote de 300 quatro dedos será encomendado, e novamente desmoronará o modelo bem provado e fiável.

Já lhe foi dito acima:

Em vez de fazer alterações à Bíblia padrão, seria melhor fazer desenvolvimentos para a alargar (através da herança). Então será realmente interessante.

Quantas vezes podemos dizer que não podemos herdar o que não está disponível nas aulas dos pais? Quando irá finalmente conhecer o livro "Code Complete" escrito pelo próprio Steve McConell?

1. A minha abordagem não viola os princípios de encapsulamento, porque na versão que propus, tudo o que é supérfluo está escondido, e os módulos recebem apenas um sinal comercial como um valor do tipo duplo e apenas no modo de leitura. Ao contrário de algumas pessoas, não só li os livros sobre o OOP, como os estudei cuidadosamente.
2. Não sugeri a criação de luvas de seis dedos para os modelos, ou seja, fixar os seis dedos como módulos adicionais, mas apenas sugerir a correspondência de todos os módulos existentes com os sinais do módulo de sinais, que é na realidade o principal para os sistemas de trading, porque todo o sistema deve funcionar pelo seu comando. Foi você quem sugeriu a modularidade, ou seja, luvas com dedos intercambiáveis. Mas como a mão direita não sabe o que faz a mão esquerda, ou seja, outros módulos não conseguem obter informações do módulo de sinal e sincronizar as suas acções com ele, as luvas terão dedos (módulos) de tamanhos diferentes, quando o utilizador coloca a luva na mão e vê que um dos seus dedos é pequeno e não cabe nele, enquanto o outro é grande e excessivo.

Por exemplo, uma paragem móvel é executada de acordo com um sistema de sinais separado desenvolvido por um terceiro desenvolvedor do módulo, tal como uma onda móvel ou parabólica, cujos sinais em alguns pontos contradizem os sinais do módulo e o sistema de negociação começa a funcionar de forma inconsistente. O módulo de gestão de dinheiro e risco também não pode adivinhar telepaticamente que o sinal de negociação é fraco e é tempo de reduzir o volume de posições abertas e agir de acordo com algumas regras independentes do módulo de sinal, ou seja, uma delas pede para abrandar nas esquinas e a outra acelera. E todo o sistema comercial, criado com a ajuda do seu chamado mestre, revela-se como na fábula de Krylov chamada "O caranguejo e o lúcio". Nem mais nem menos. E esta mesma ideologia fábula da montagem de consultores imprudentes, a sua empresa está a tentar impor-nos para o autotrading. Será que precisamos dele?

O resultado são sistemas comerciais com tais gráficos de equidade e equilíbrio que só podem assustar tanto os comerciantes como os investidores, ver https://www.mql5.com/ru/code/833.

Isto não se deve ao facto do criador do módulo, neste caso particular Nikolay Kositsin, ter feito algo de errado, mas porque os restantes módulos do sistema de comércio não podem ser coordenados uns com os outros e estão a funcionar de forma inconsistente.

Mas é inútil explicar. Os criadores da plataforma, em vez de escreverem uma miserável seis linhas para corrigir os problemas, escreverão quilómetros de notas de rodapé nos fóruns, acusando os criadores de sistemas comerciais de espalhar demagogia, violações de encapsulamento e outros pecados mortais, mas não levantarão um dedo para corrigir as suas próprias deficiências e mal-entendidos.

Por isso, não vale a pena continuar as discussões. Fique com a sua opinião e faça o que lhe apetecer. Estou farto disto e é inútil, porque os criadores da plataforma não se importam, porque não fazem as suas próprias coisas e se estas mesmas ferramentas podem ser utilizadas pelos utilizadores da plataforma para auto-comercialização, os criadores não se importam. Um homem que está bem alimentado não conhece um homem faminto.

[Mykola Demko]

Reshetov:
...

Reshetov, não quero sequer ler os seus rabiscos emocionais. Se quer discutir, argumente o seu caso.

O objectivo de um feiticeiro é criar um modelo que vá ao encontro das necessidades da maioria dos comerciantes. Tenho um modelo de EA no cherver (fui eu que o escrevi), ele define a funcionalidade básica. E na prática tem sempre de ser corrigido. Mas as edições são mínimas. Se eu tivesse criado um modelo para não o editar de todo, teria sido um código enorme para todas as ocasiões, em que se poderia perder.

O mago cria um modelo que já está a funcionar, e uma pessoa que não sabe programar pode utilizá-lo tal como está. Se compreender a codificação, é fácil mudá-la para o que se quer. Basta apenas uma vez para compreender como as coisas são criadas e onde estão separadas na biblioteca padrão. Além disso, também pode utilizar a biblioteca padrão como modelo e simplesmente copiar as secções que desejar para o seu próprio código.