Menos código, mais ação... escrever um EA - página 2

Novo comentário
 
Maxim Kuznetsov:

o estilo de caso de uso é fundamentalmente processual, pois é o mais comum. Os usuários em potencial(programadores novatos) escrevem desta forma.

O que eu quero dizer é que seu estilo é procedimental em essência. Ou seja, é processual tanto por dentro como por fora, com todos os problemas resultantes. No nível do usuário, não se pode revelar detalhes de implementação por uma questão de princípio. E você tem uma coisa muito específica acontecendo em seu código no nível do usuário:

double GetData(EA *ea,int id,int shift,double &data[])
{
#ifdef __MQL4__
   // для 4-ки всё просто - по идентификаторам серии и бара получить данные
   switch ((ENUM_SERIES)id) {
      case FAST_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,FAST_MA_PERIOD,0,FAST_MA_METHOD,FAST_MA_PRICE,shift);
      case SLOW_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,SLOW_MA_PERIOD,0,SLOW_MA_METHOD,SLOW_MA_PRICE,shift);
   }
   return EMPTY_VALUE;
#else
   ...
#endif
}

Macros de compilação condicional, chamadas de implementações de funções específicas de MA, etc., etc. Isto é, não OOP, não FP, mas este tipo de programação processual mate. E como a cereja no bolo: ea.Symbol, ou seja, formalmente, ainda é OOP.

 
Maxim Kuznetsov:

Tentarei (ou tentarei, se estiver interessado) fazer uma base para EAs.

O resultado será tão inútil (para a maioria das pessoas) como todos aqueles mencionados no fio.

porque você imediatamente tenta escrever à sua maneira e não bem. assim como os autores de todos aqueles mencionados.

 
Vasiliy Sokolov:

Quero dizer que seu estilo é de natureza processual. Ou seja, é processual tanto interna quanto externamente, com todos os problemas que lhe são inerentes. No nível do usuário, os detalhes da implementação não podem ser divulgados como uma questão de princípio. E você tem uma coisa muito específica acontecendo em seu código no nível do usuário:

Macros de compilação condicional, chamadas de implementações de funções específicas de MA, etc., etc. Isto é, não OOP, não FP, mas este tipo de programação processual mate. E como a cereja no bolo: ea.Symbol, ou seja, formalmente ainda é OOP.

Mais uma vez, o caso de uso é escrito do ponto de vista presumido dos usuários potenciais.

Mas em medida suficiente para poder prosseguir até a biblioteca sem tocar no caso de uso em si.

Temos que utilizar a compilação condicional, pois tanto o 4 como o 5 estão no fórum.


 
Maxim Kuznetsov:

Mais uma vez, o caso de uso é escrito a partir da perspectiva presumida dos usuários potenciais.

Para reformular: onde está a exigência de estilo de procedimento para inserir chamadas de funções específicas dependentes da plataforma como iMA(...)?

Maxim Kuznetsov:

Mas em volume suficiente para permitir que se prossiga para a biblioteca sem tocar no caso de uso em si.

Como podemos fazer isso quando o caso de uso está cheio de chamadas específicas de funções dependentes da plataforma?

Maxim Kuznetsov:

Você tem que usar a compilação condicional porque há tanto 4 como 5 no fórum.

Então o "código universal" no nível do usuário não pode nem mesmo ser independente da plataforma?

 
Maxim Kuznetsov:

...

Se estamos falando de caso de usuário - mandamento número um: nenhuma implementação específica a este nível. Mas no nível do usuário você já tem total dependência de: 1) plataforma, 2) API do terminal. Isto é, a implementação proposta é completamente inconsistente com o conceito declarado.

 
Vasiliy Sokolov:

Se estamos falando de caso de usuário - mandamento número um: nenhuma implementação específica a este nível. No nível do usuário, você já tem total dependência de: 1) plataforma, 2) terminal API. Ou seja, a implementação sugerida não corresponde completamente ao conceito declarado.

Em geral, os desenvolvedores escrevem em MQL, e para o API dos terminais comerciais MT4, MT5 :-) Portanto, o uso do terminal API é normal.

O caso de uso deve demonstrar/fazer as coisas típicas para a área. Não apenas adicionar alguns números, mas ter um propósito compreensível para o usuário, aquele que queremos alcançar. O objetivo mínimo possível dos Expert Advisors é a negociação :-) O Expert Advisor mais simples que eu posso pensar é negociar em médias cruzadas. É dada na íntegra no posto de origem.

A propósito, funciona. Neste exato momento, em vez de funções de negociação, estão sendo desenhados stubs e checkmarks :-) Estou escrevendo/debugando os dados. Assim que a parte com os dados, embora rudimentar, mas pronta para discussão - eu afixarei


 
Maxim Kuznetsov:

Você geralmente escreve em MQL e API de terminais comerciais MT4,MT5 :-) portanto, a referência ao terminal API é normal.

O caso de uso deve demonstrar/fazer as coisas típicas para o campo. Não acrescente apenas alguns números, mas tenha um objetivo compreensível para o usuário, aquele que queremos alcançar. O objetivo mínimo possível dos Expert Advisors é a negociação :-) O Expert Advisor mais simples que eu posso pensar é negociar em médias cruzadas. É dada na íntegra no posto de origem

E pela forma como funciona. No momento estou escrevendo/debugando dados em vez de funções comerciais e desenhando carrapatos :-). Tão logo que os dados, embora em bruto, estejam prontos para discussão - também os colocarei

Você o escreve corretamente. Mas o usuário entende muito melhor tal pseudo-código:

if(SMA(Close, 12) > SMA(Close, 24))
   BUY();
else
   SELL();

Outra coisa é que fazê-la funcionar nesta forma (procedimento, observo) é muito difícil, mas ainda é possível. Isto é o que se deve tentar alcançar - tornar as instruções a nível de usuário tão simples e abstratas quanto possível. Mas em seu código, o usuário tem que especificar macros de compilação condicional, funções específicas para o cálculo de médias e outros detalhes técnicos que ele simplesmente não pode lidar.

 
Vasiliy Sokolov:

Para reformular: onde o estilo de procedimento tem um requisito para inserir chamadas de funções específicas da plataforma como iMA(...)?

Quão intocável, se o caso de uso estiver repleto de chamadas de funções específicas dependentes da plataforma?

Então o "código universal" no nível do usuário não pode nem mesmo ser independente da plataforma?

As plataformas 4/5 têm API's diferentes, é o que acontece.

Não estou escrevendo outra camada de compatibilidade para tudo, ou uma biblioteca universal. Por mais que eu não queira :-)

apenas a base para EAs.

 
Vasiliy Sokolov:

Bem, você o escreve corretamente. Mas o usuário entende muito melhor tal pseudo-código:

Outra coisa é que é muito mais difícil fazê-lo funcionar nesta forma particular (procedimento, eu noto), mas ainda assim é possível. Isto é o que se deve tentar alcançar - tornar as instruções a nível de usuário tão simples e abstratas quanto possível. Mas em seu código, o usuário precisa especificar macros de compilação condicional, funções específicas para o cálculo de médias e outros detalhes técnicos que ele simplesmente não pode lidar.

Em princípio, você pode usar uma entrada como a que você citou dentro do GetData OnCrossSignal. Potencialmente, você pode até escrever roteiros :-) Mas tudo em tempo hábil... O manuseio de dados é construído como uma mesa eletrônica.

 
Maxim Kuznetsov:

4/5 plataformas têm diferentes API's, é assim que as coisas são.

Não estou escrevendo outra camada de compatibilidade para tudo, ou uma biblioteca universal. Por mais que eu não queira :-)

apenas a base para EAs.

Dê uma olhada no código da Artem. Seu código tem uma única API, que é independente da plataforma alvo. É por isso que o argumento de que "funciona dessa maneira" é estranho de se ouvir.

12345678910
Novo comentário
Razão: