Erros, bugs, perguntas - página 1129

 

A100:
32'535'244'799 != 32'535'215'999 - какое правильное? 

O correcto seria 32'535'215'999 para"3000.12.31 23:59:59".

E32'535'244'799 seria correcto para"3001.01.01 07:59:59".

 
Fleder:

O limite para o tipo de data/hora simplesmente não é definido correctamente:

Aparentemente, o limite é definido considerando a possibilidade de apresentar a hora local em GMT ou UTC ao mesmo tempo. Faria então sentido fazer um alcance mais amplo (+/-12 horas) de -43'200 a 32'535'291'599
 
Fleder:

O compilador trata o número 13.7 como o tipo duplo. Mas ao mesmo tempo, este número pode ser convertido sem perdas para o tipo de flutuador

e este aviso é desnecessário.

Como sabe que um número real 13.7 pode ser convertido para o tipo de flutuador sem perda?
 
stringo:
Como sabe que o número real 13.7 pode ser convertido para o tipo de flutuador sem perdas?

Não é? O número 13,7 = 0,137*1e+2. Ao converter três casas decimais para tipo flutuante, existe alguma perda? Pelo que vi, a precisão perde-se quando se tenta converter

números com seis casas decimais ou mais.

Tentei usar o tipo flutuador para guardar citações de caracteres de cinco dígitos (por exemplo 1,38829) num ficheiro binário. Após lê-los de volta do ficheiro e tentar exibi-los num gráfico como

O indicador do gráfico aplicado aos castiçais do próprio gráfico tem algumas pequenas discrepâncias. Mas após a normalização para o quinto dígito desapareceram.

Mas houve aí uma dupla perda de precisão: primeiro foi do dobro para flutuar e depois de volta de flutuar para o dobro.

 
https://www.mql5.com/ru/docs/convert/normalizedouble Fleder:

Não é? O número 13,7 = 0,137*1e+2. Ao converter três casas decimais para tipo flutuante, existe alguma perda? Pelo que vi, a precisão perde-se quando se tenta converter

números com seis casas decimais ou mais.

Tentei usar o tipo flutuador para guardar citações de caracteres de cinco dígitos (por exemplo 1,38829) num ficheiro binário. Após lê-los de volta do ficheiro e tentar exibi-los num gráfico como

O indicador do gráfico aplicado aos castiçais do próprio gráfico tem algumas pequenas discrepâncias. Mas após a normalização para o quinto dígito desapareceram.

Mas houve uma dupla perda de precisão: primeiro do dobro para a flutuação, e depois de volta da flutuação para o dobro.

Não. É uma fracção infinita. Nós escrevemos e escrevemos, mas o senhor não lê.
 
stringo:
Não. É uma fracção infinita. Nós escrevemos e escrevemos e você não lê

Nós lemos! Mas a perda acontece "tecnicamente" (peculiaridades do formato) e nas fracções que não são sequer necessárias.

void OnStart()
{
  Print((float)(13.7));   //13.7 - потерь "не видно"
  Print((double)(13.7));  //13.7 - здесь тоже
}
Особенности работы с числами типа double в MQL4 - Статьи по MQL4
  • www.mql5.com
Особенности работы с числами типа double в MQL4 - Статьи по MQL4: примеры использования экспертов, тестирования и оптимизации
 
A100:

Também já tive este acidente. Ocorre quando se executa um guião se o Terminal (910) e o Compilador (921) não corresponderem

Aqui está o código

class A  {
        int     array[];
};
void OnStart()
{
        A *a = new A();
        if ( a != NULL )
                delete( a );
}

Compilador 930, Terminal 910. Resultado:

 
A100:

Aqui está o código

Compilador 930, Terminal 910. Resultado:

Como é que o terminal é 910 e o compilador é 930?

Se ambos são 910, então este guião não "se estraga".

 

Apenas não há um terminal (não sei exactamente, mas penso que isto é comum no Mercado)

Posso partilhar o original a partir da pasta ...MQL5\\Scripts

Arquivos anexados:
Crash.ex5  4 kb
 
A100:

Apenas não há um terminal (não sei exactamente, mas penso que isto é comum no Mercado)

Posso partilhar o original a partir da pasta ...MQL5\\Scripts

Bem, era isso que eu tinha de provarWin XP 32 bit:


Razão: