Erreurs, bugs, questions - page 1129

 
Fleder:

La limite pour le type datetime n'est tout simplement pas définie correctement :

Apparemment la limite est définie en considérant la possibilité de présenter l'heure locale en GMT ou UTC en même temps. Il serait alors logique de faire une fourchette plus large (+/-12 heures) de -43'200 à 32'535'291'599
 
Fleder:

Le compilateur traite le nombre 13,7 comme le type double. Mais en même temps, ce nombre peut être converti sans perte en type flottant.

et cet avertissement est inutile.

Comment savez-vous qu'un nombre réel 13,7 peut être converti en type flottant sans perte ?
 
stringo:
Comment savez-vous que le nombre réel 13,7 peut être converti en type flottant sans pertes ?

N'est-ce pas ? Le nombre 13,7 = 0,137*1e+2. En convertissant trois décimales en type float, y a-t-il une perte ? D'après ce que j'ai vu, la précision est perdue lorsque vous essayez de convertir

des nombres avec six décimales ou plus.

J'ai essayé d'utiliser le type float pour enregistrer des guillemets de caractères à cinq chiffres (par exemple 1,38829) dans un fichier binaire. Après les avoir lues à partir du fichier et avoir essayé de les afficher sur un graphique en tant que

L'indicateur graphique appliqué aux chandeliers du graphique lui-même présente de petites divergences. Mais après la normalisation au cinquième chiffre, ils ont disparu.

Mais il y a eu une double perte de précision : on est d'abord passé du double au flottant, puis du flottant au double.

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

N'est-ce pas ? Le nombre 13,7 = 0,137*1e+2. En convertissant trois décimales en type float, y a-t-il une perte ? D'après ce que j'ai vu, on perd en précision lorsqu'on essaie de convertir

des nombres avec six décimales ou plus.

J'ai essayé d'utiliser le type float pour enregistrer des guillemets de caractères à cinq chiffres (par exemple 1,38829) dans un fichier binaire. Après les avoir lues à partir du fichier et avoir essayé de les afficher sur un graphique en tant que

L'indicateur graphique appliqué aux chandeliers du graphique lui-même présente de petites divergences. Mais après la normalisation au cinquième chiffre, ils ont disparu.

Mais il y a eu une double perte de précision : d'abord du double au flottant, puis de nouveau du flottant au double.

Non. C'est une fraction infinie. Nous avons écrit et écrit, mais vous ne lisez pas.
 
stringo:
Non. C'est une fraction sans fin. Nous avons écrit et écrit et vous ne lisez pas.

On lit! Mais la perte se produit "techniquement" (particularités du format) et dans ces fractions qui ne sont même pas nécessaires.

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

J'ai eu ce problème aussi. Se produit lors de l'exécution d'un script si le terminal (910) et le compilateur (921) ne correspondent pas.

Voici le code

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

Compilateur 930, Terminal 910. Résultat :

 
A100:

Voici le code

Compilateur 930, Terminal 910. Résultat :

Comment se fait-il que le terminal soit à 910 et le compilateur à 930 ?

Si les deux sont 910, alors ce script ne "plante" pas.

 

Pas un seul terminal (je ne sais pas exactement, mais je pense que c'est courant sur le marché).

Je peux partager l'original depuis le dossier ...\MQL5\Scripts.

Dossiers :
Crash.ex5  4 kb
 
A100:

Pas un seul terminal (je ne sais pas exactement, mais je pense que c'est courant sur le marché).

Je peux partager l'original depuis le dossier ...\MQL5\Scripts.

Eh bien, c'est ce que j'ai dû prouverWin XP 32 bit:


 
Passez à la version 930 dans son intégralité, s'il vous plaît.