Erros, bugs, perguntas - página 2708

Novo comentário
 

Sugiro que se acrescentem pormenores à validação automática dos produtos no mercado. Para além dos erros gerais comunicados pelo validador, o contexto do teste que está a ser realizado e os registos são fortemente solicitados. Em particular, não consigo actualizar um indicador há já alguns anos devido ao erro "tester takes too long time". A primeira versão foi carregada sob moderação "humana" e não teve queixas. Os critérios do autovalidador para a emissão deste erro são totalmente obscuros.

Eis uma pergunta específica: quantas carraças em que período de tempo o produto deve fornecer sobre que hardware para que o "testador demore demasiado tempo" não apareça?

O indicador destina-se a processar carraças pelo algoritmo MapReduce, são utilizados cálculos inteiros, pelo que não há nada para comprimir, a menos que se deite fora o próprio algoritmo. O profiler foi utilizado, foi acrescentado um trotlining para recalcular o conjunto de novas carraças com um determinado período. Em vão.

No meu computador, o ano é testado em poucos minutos. O que está realmente a acontecer no autovalidador e porque está a abrandar é impossível de saber neste momento.

A falta de apoio adequado ao produto é um problema tanto para os utilizadores como para a MQ - afecta a implementação.

 

É suposto ser assim?

class cA
  {
public:
   int               Add(int i1,int i2)
     {
      return i1+i2;
     };
                     cA()
     {
      Print("+++");
     };
                    ~cA()
     {
      Print("---");
     };
  };

void OnStart()
  {
   cA a=cA();
  }

Diário de bordo:

2020.04.17 18:39:32.996 test3 (EURUSD,M1)       +++
2020.04.17 18:39:32.996 test3 (EURUSD,M1)       +++
2020.04.17 18:39:32.996 test3 (EURUSD,M1)       ---
2020.04.17 18:39:32.996 test3 (EURUSD,M1)       ---

Dupla chamada de construtor e destruidor, como se dois objectos fossem criados e apagados. Tudo está bem quando se usa novo e eliminar.

Construir 2380.

 
Aliaksandr Hryshyn:

como se dois objectos estivessem a ser criados e apagados.

É assim que as coisas são.

 
fxsaber:

E é.

E o meu objecto é criado em segundo lugar:

class cA
  {
public:
   int               my_i;
   int               Add(int i1,int i2)
     {
      return i1+i2;
     };
                     cA()
     {
      static int i=0;
      my_i=i;
      i++;
      Print("+++");
     };
                    ~cA()
     {
      Print("---");
     };
  };

void OnStart()
  {
   cA a=cA();
   Print(a.my_i);
  }
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       +++
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       +++
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       ---
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       1
2020.04.17 18:47:34.771 test3 (EURUSD,M1)       ---
 
Aliaksandr Hryshyn:

E o meu objecto é criado em segundo lugar:

Primeiro objecto.

cA a=cA();


Segundo objecto.

cA a=cA();
 

Então é assim que deve ser:

cA a;
Print(a.my_i);
 
Stanislav Korotky:

No meu computador, um ano é testado em poucos minutos. O que está realmente a acontecer no autovalidador e porque está a abrandar é impossível de saber neste momento.

Um ano em poucos minutos é muito. Quase ninguém teria esperado (se fosse uma EA).
Está a desenhar visualmente normalmente? É possível compreender alguma coisa observando o provador?

Adicionar uma ficha para o mercado - acelerar os cálculos em detrimento da precisão (se possível), ou desenhar "algo semelhante" no seu conjunto. O produto é claramente específico, e quem precisar dele poderá mudar o parâmetro certo.

 
Andrey Khatimlianskii:

Um ano em poucos minutos é muito. Quase ninguém teria esperado (se fosse uma EA).
Está a desenhar visualmente bem? É possível compreender algo observando o provador?

Adicionar um toco para o mercado - acelerando os cálculos à custa da precisão (se possível), ou desenhando "algo semelhante" no seu conjunto. O produto é claramente específico, e quem precisar dele poderá mudar o parâmetro certo.

Na minha opinião, um ano em poucos minutos em modo poético está bem. Costumava haver um limite de 15-20 minutos em campeonatos (não me lembro exactamente). Já foi acrescentada uma banca (trote com lapso de tempo). Pode-se saltar carraças, mas depois o ponto do produto desaparece. A especificidade é um conceito relativo: sei que muitos trabalham em modo ticking (e todos eles têm um suplemento com verificação de preço e/ou volume). E ainda mais importante, para ter critérios mais precisos, mais feedback do autovalidador (se dissermos "o seu terminal não está a funcionar" no fórum, nós MQ o que perguntamos? - dar registos e condições de reprodução; aqui recebemos uma mensagem de que o nosso produto não funciona, mas sem especificações). E é mais correcto ter em conta as especificidades do produto. Afinal, o tempo total de execução do produto não é apenas o tempo do código MQL, mas o próprio terminal. Há chamadas mais caras, tais como a CopyTicksRange. Estas despesas gerais são agora consideradas como defeitos no produto MQL.

PS. No caso dos indicadores, parece que não é a operação por carraças que é mais crítica, mas o número de amortecedores (há muitos deles por causa das peculiaridades da tarefa). Vou tentar limitar o número deles para o testador (torna o produto mais complicado e cheio de erros, bem como outras bandeiras impostas por condições externas, tais como o trote). Isto prova mais uma vez a necessidade de o autovalidador variar a pontuação de desempenho em vários parâmetros.

PPS. Estou a pedir carraças para o último dia, e o testador está a carregá-las durante 2 anos - e isso também leva tempo.

 
Stanislav Korotky:

PPS. Estou a pedir carraças para o último dia, e o testador está a carregá-las há 2 anos

Por alguma razão, este comportamento é oficial.

Suponho que não devem gerar barras para Consultores Especialistas que não utilizem indicadores ou barras de endereço, etc.

Por exemplo, se houver apenas SymbolInfoTick - não gerar barras, não guardar o histórico para os copyticks.


Não está nada claro sobre esta barofilia para uma ferramenta de comércio séria como o Testador. Mas como até mesmo os estetas MO continuam a mastigar este cacto, provavelmente não há compreensão.

 

Porque é que na MQL não posso chamar construtor protegido do meu método de fábrica?

class A1
{
  protected:
    A1(const bool x = false){}
  public:  
    static A1 *creator()
    {
      return new A1(true);
    }
};

void OnStart()
{
  A1 *a = A1::creator();
}

O código dá um erro de compilação "'A1::A1' - não pode aceder à função de membro protegido", e especifica a linha onde a descrição da classe começa, não onde o construtor é chamado (ou seja, tenho de procurar manualmente onde está o problema).

Mas a questão é que não deve haver qualquer erro. C++ compila sem qualquer problema.

1...270127022703270427052706270727082709271027112712271327142715...3184
Novo comentário