Erros, bugs, perguntas - página 1781

 

Desempenho instável

  • Indicador do caminho de localização: \Indicadores Test_i.ex5
  • Caminho de destino do Consultor Especialista: \Test.ex5
  • Percurso de localização do guião: \Textos de teste

Sequência de passos: Ligar o guião 'Test_s.ex5' várias vezes ao gráfico M15 (símbolo EURUSD)

Resultado:

2017.02.05 15:17:59.076 OnStart 1ª vez em anexo
2017.02.05 15:18:03.293 OnStart 2ª vez em anexo
2017.02.05 15:18:07.760 OnStart 3ª vez juntou-se
2017.02.05 15:18:07.778 OnInit
2017.02.05 15:18:07.781 OnDeinit:1
2017.02.05 15:18:16.891 OnStart 4ª vez juntou-se

Os resultados das adesões são diferentes. Não se espera que sejam diferentes, mas o resultado é aleatório: a linha com OnInit\OnDeinit pode aparecer a partir da 1ª vez, ou a partir da 10ª vez

//Test_i.mq5 //Индикатор
void OnInit()                    { Print( __FUNCTION__ ); }
void OnDeinit( const int reason ) { Print( __FUNCTION__, ":", reason ); }
int OnCalculate( const int, const int, const int, const double& [] ) { return 0; }
//Test_s.mq5 //Скрипт
#import "..\\Experts\\Test.ex5"
        void OnInit();
#import
void OnStart()
{
        Print( __FUNCTION__ );
        OnInit();
}

Ficheiro especializado anexado (actualmente utilizado como biblioteca), codifique aqui https://www.mql5.com/ru/forum/1111/page1801#comment_4059227

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • www.mql5.com
Форум алго-трейдеров MQL5
Arquivos anexados:
Test.mq5  1 kb
 

Não compreendo se o erro é meu ou do terminal

No 5º dígito
void OnStart()
  {

double A=1.11111;
double B=1.11111;
double C=1.11111;

long CalcX=
NormalizeDouble(A,Digits)*MathPow(10,(Digits+1)*3-1)+
NormalizeDouble(B,Digits)*MathPow(10,(Digits+1)*2-1)+
NormalizeDouble(C,Digits)*MathPow(10,(Digits+1)*1-1);

Print ("CalcX=",CalcX);  
  }

Imprime CalcX=111111111111111111111104 valor esperado CalcX=1111111111111111

 
A100:

Ordem incorrecta das chamadas de função ao alterar o período do gráfico

  • Caminho de localização do indicador: \Test_i.ex5
  • Caminho da localização dos peritos: {Experts\Test.ex5

Sequência de acções:

  1. Anexar o 'Test.ex5' Expert Advisor ao gráfico M5 (símbolo GBPUSD)
  2. Alterar o período do gráfico para M15
  3. Alterar o período do gráfico para M30
  4. Retirar o Consultor Especialista do quadro

Mostrar registos. Para que se possa ver o prazo.

Resta acrescentar aqui que adicionar um indicador ao gráfico e remover um indicador do gráfico são operações não-síncronas.

Além disso, quando o período de tempo é alterado, o indicador não é imediatamente descarregado deste período de tempo. E cria uma nova cópia do indicador no novo período de tempo. Vejo as suas impressões no construtor-destrutor, acha que o destruidor é chamado imediatamente? Não, está enganado. O destruidor é chamado quando o indicador é descarregado e o indicador é descarregado apenas em alguns segundos após o indicador ter sido apagado
 
Slawa:
Mostrar os registos. Para que se possa ver o calendário.
Resta acrescentar que adicionar um indicador a um gráfico e remover um indicador de um gráfico são operações não-síncronas.
Além disso, quando se altera o período de tempo, o indicador não será imediatamente descarregado deste período. E cria uma nova cópia do indicador no novo período de tempo. Vejo as suas impressões no construtor-destrutor, acha que o destruidor é chamado imediatamente? Não, está enganado. O destruidor é chamado quando o indicador é descarregado e o indicador só é descarregado alguns segundos após a remoção do indicador

Assume-se que há tempo suficiente entre as etapas (alterações do período gráfico)

2017.02.05 19:49:49.984 I::I->M5 #step 1: join
2017.02.05 19:49:49.984 OnInit->M5

2017.02.05 19:51:39.853 I::I->M15 #step 2: mudança de período M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #step 3: mudança de período M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30

2017.02.05 19:54:03.245 OnDeinit->M30:3 #step 4: mudança de período M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #step 5: H1 ->H4 period change
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1

2017.02.05 19:55:50.697 I::I->D1 #step 6: H4 ->D1 period change
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7: eliminar
2017.02.05 19:56:11.122 I::~I->M5

2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1

A não simultaneidade só afecta diferentes ordens de chamadas de função dentro de um passo (como visto nos passos #3 e #5)

Como se pode ver, todos os períodos subsequentes do gráfico mudam, excepto o primeiro (passo#2:duas linhas de saída), são esperados (semelhante ao passo#3:quatro linhas de saída). E porque é que o primeiro período do gráfico deve ser diferente de todos os outros? Como é melhor/pior? Porque é que as duas linhas de saída em falta do passo#2(e apenas aquela) passaram para o passo#7 (destacado a vermelho)?

 
-Aleks-:

Não compreendo se o erro é meu ou do terminal

Imprime CalcX=111111111111111111111104 valor esperado CalcX=1111111111111111

Se o número de decimais significativos em dobro for > DBL_DIG=15, as regras normais não funcionam
 
A100:

Assume-se que há tempo suficiente entre as etapas (alterações do período gráfico)

2017.02.05 19:49:49.984 I::I->M5 #step1: junte-se a
2017.02.05 19:49:49.984 OnInit->M5

2017.02.05 19:51:39.853 I::I->M15 #step 2: mudança de período M5 ->M15
2017.02.05 19:51:39.853 OnInit->M15
2017.02.05 19:53:29.813 OnDeinit->M15:3 #step 3: mudança de período M15->M30
2017.02.05 19:53:29.813 I::~I->M15
2017.02.05 19:53:29.864 I::I->M30
2017.02.05 19:53:29.864 OnInit->M30

2017.02.05 19:54:03.245 OnDeinit->M30:3 #step 4: mudança de período M30->H1
2017.02.05 19:54:03.245 I::~I->M30
2017.02.05 19:54:03.286 I::I->H1
2017.02.05 19:54:03.286 OnInit->H1
2017.02.05 19:55:02.984 I::I->H4 #step 5: H1 ->H4 period change
2017.02.02.05 19:55:02.984 OnInit->H4
2017.02.05 19:55:02.984 OnDeinit->H1:3
2017.02.05 19:55:02.984 I::~I->H1

2017.02.05 19:55:50.697 I::I->D1 #step 6: mudança de período H4 ->D1
2017.02.05 19:55:50.697 OnInit->D1
2017.02.05 19:55:50.697 OnDeinit->H4:3
2017.02.05 19:55:50.697 I::~I->H4
2017.02.05 19:56:11.122 OnDeinit->M5:1 #step 7: eliminar
2017.02.05 19:56:11.122 I::~I->M5

2017.02.05 19:56:11.122 OnDeinit->D1:1
2017.02.05 19:56:11.123 I::~I->D1

A não simultaneidade só afecta diferentes ordens de chamadas de função dentro de um passo (como visto nos passos #3 e #5)

Como podemos ver, todas as alterações do gráfico do período subsequente, excepto a primeira (passo #2), ocorrem como esperado (semelhante ao passo #3). Porque é que o primeiro período deve ser diferente de todos os outros? Como é melhor/pior?

Deixe-me tentar explicar novamente

Há algum tipo de indicador no gráfico M5. Quando se muda o prazo de M5 para M15, é criada uma segunda cópia do mesmo indicador. Um comando é enviado para ambos os indicadores - o primeiro para M5 Deinit, o segundo para M15 Init. Ao mesmo tempo, não sabemos qual destes comandos será executado antes do outro - há uma corrida clássica entre os diferentes fios.

Depois disso, o primeiro indicador terá o seu contador de utilização diminuído. Em vários segundos após o contador de utilização se tornar zero, o indicador será descarregado do gráfico. A esses destruidores de objectos globais deste indicador serão chamados
 
Slawa:
Deixe-me tentar explicar novamente

Existe um certo indicador no gráfico M5. Quando se muda o prazo de M5 para M15, é criada uma segunda cópia do mesmo indicador. Um comando é enviado para ambos os indicadores - o primeiro para M5 Deinit, o segundo para M15 Init. Ao mesmo tempo, não sabemos qual destes comandos será executado antes do outro - há uma corrida clássica entre os diferentes fios.

Depois disso, o primeiro indicador terá o seu contador de utilização diminuído. Em vários segundos após o contador de utilização se tornar zero, o indicador será descarregado do gráfico. Os destruidores dos objectos globais deste indicador serão chamados

Afirmo (e proponho verificar) que quando o cronograma é alterado de M5 para M15 nenhum comando M5 Deinit é enviado para o primeiro indicador (e apenas para ele - neste caso M5) e não é descarregado do gráfico até o utilizador remover a EA

Se a estrutura I em 'Test_i.ex5' for excluída (sem efeito), a saída é simplificada:


2017.02.05 20:49:06.842 OnInit->M5

2017.02.05 20:49:21.253 OnInit->M15(*) mudança de período M5 -> M15: O indicador M5 não é descarregado
2017.02.05 20:56:40.001 OnDeinit->M15:3 mudança de período M15 -> M30: O indicadorM15 é descarregado imediatamente
2017.02.05 20:56:40.132 OnInit->M30

Passaram mais de 5 minutos desde (*), mas o indicador M5 não está descarregado

Retirar o Consultor Especialista do quadro

2017.02.05 20:57:35.176 OnDeinit->M5:1 o indicador M5 só é descarregado após a remoção do Expert Advisor
2017.02.05 20:57:35.177 OnDeinit->M30:1

 
Slawa:
Deixe-me tentar explicar novamente

Existe um certo indicador no gráfico M5. Quando se muda o prazo de M5 para M15, é criada a segunda cópia do mesmo indicador. Um comando é enviado para ambos os indicadores - o primeiro para M5 Deinit, o segundo para M15 Init. Ao mesmo tempo, não sabemos qual destes comandos será executado antes do outro - há uma corrida clássica entre os diferentes fios.

Depois disso, o primeiro indicador terá o seu contador de utilização diminuído. Em vários segundos após o contador de utilização se tornar zero, o indicador será descarregado do gráfico. A isso os destruidores dos objectos globais deste indicador serão chamados
Pode explicar de que fios estamos a falar? Todos os indicadores de um símbolo não funcionam num só fio?
 
Vladimir Gribachev:

Falhas ao instalar indicadores Bill Williams

Coloco fractais - faz

conjunto AO - conjunto ADX

construir 1031

Centenas de anos de erros com menu não actualizado ao mudar /MQx/Indicators directório estrutura :-) O insecto é tão antigo que já é visto como uma característica, habitue-se... a usabilidade é martelada com um parafuso quadrado, mas o número pi conta o mais rápido :-)
 
A100:
Se o número de casas decimais significativas em dobro > DBL_DIG=15, então as regras normais não funcionam

Quais funcionam?

No ficheiro Help diz que o valor máximo por muito tempo é922337203636854775807 - obviamente que não o alcanço.

Razão: