Question aux maîtres du MQL4. Encore une fois à propos de Double Comparaison. - page 9

Nouveau commentaire
 
SK. писал (а):

Je l'ai dit dans le sens d'une comparaison plus ou moins poussée :

if (NormalizeDouble(x,Digits) > NormalizeDouble(y,Digits))

ce qui signifie que les constructions de vues ne fonctionnent pas toujours :

double a = NormalizeDouble(x,Digits);
double b = NormalizeDouble(y,Digits);
 
if (a > b)
  {
  ...
  }
Je pense que le premier et le second ont le même résultat.
Les résultats attribués aux variables a et b sont normalisés, puis ils peuvent être comparés, rien ne leur arrivera.
Renat a parlé d'autre chose, car dans cet exemple, le résultat de la soustraction de valeurs normalisées n'est pas normalisé.
Si vous normalisez le résultat final d'une opération, vous pouvez l'affecter à une variable et le manipuler ultérieurement. L'essentiel est que la variable elle-même ne change pas de valeur par la suite.
 
gravity001:
Je n'ai pas vérifié le plus ou le moins, mais j'ai vérifié l'égalité.
J'ai eu des erreurs de comparaison lorsque j'ai utilisé cette construction :

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
Pourquoi, tu ne sais pas ?

Quel genre d'erreurs ?
 
Simca:
Et pour moi, le premier et le second en termes de résultat sont UN ET UN.

Cela fonctionne dans certains cas, mais pas toujours. Ce "pas toujours" est dicté par la manière particulière dont les valeurs sont stockées dans la mémoire des ordinateurs. C'est justement ça.

Les résultats attribués aux variables a et b sont normalisés et ils peuvent être comparés ultérieurement, rien ne leur arrivera.
Tu ne peux pas. Autrement dit, vous pouvez faire ce que vous voulez, mais pour obtenir un résultat garanti, vous devez appliquer NormalizeDouble() directement dans l'expression contenant l'opération de comparaison.

Renat a écrit sur quelque chose d'autre, parce que dans son exemple le résultat de la soustraction des valeurs normalisées n'est pas normalisé.
Oui. Mais cela ne signifie pas que vos déclarations précédentes sont correctes.

Si vous normalisez le résultat final d'une opération, vous pouvez l'affecter à une variable et le manipuler ultérieurement. L'essentiel est que la variable elle-même ne doit pas changer de valeur par la suite.
 Elle peut changer de valeur dans le dernier chiffre en raison de la technologie informatique spécifique utilisée. Cela peut se produire et se produit sans que l'utilisateur s'en aperçoive. C'est là l'essentiel. Dans certains cas, cela fonctionnera (par exemple, pendant le débogage d'un programme), et lors de l'utilisation de ce programme, il fonctionnera souvent comme prévu par l'infortuné programmeur, et parfois il ne fonctionnera pas.

 

Mes sincères condoléances aux développeurs qui doivent expliquer 1000 fois la même chose à chaque nouvel utilisateur.

 
SK. писал (а):
gravity001:
Je n'ai pas vérifié cette construction pour plus ou moins, mais j'ai vérifié l'égalité.
J'ai eu des erreurs de comparaison lorsque j'ai utilisé cette construction :

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
Pourquoi, tu ne sais pas ?

Quel genre d'erreurs ?
La condition n'est pas remplie, c'est-à-dire que l'égalité n'est pas respectée ?
De plus, pourquoi pensez-vous que l'erreur se situe au niveau du stockage ou de la lecture des variables doubles de la mémoire ? Peut-être une erreur dans les opérations arithmétiques?

Pensez-vous qu'il ne peut y avoir d'erreur dans un tel cas ?

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?
 
gravity001 писал (а):
На больше или меньше я не проверял эту конструкцию, а вот на равенство проверял.
У меня были ошибки при сравнении, когда я использовал такую конструкцию:

if (NormalizeDouble(x, digits) == NormalizeDouble(y, digits))
{
    ...
}
Почему, не знаете?

Veuillez démontrer cette erreur !!!!
 
gravity001:
La condition n'est pas remplie, c'est-à-dire que l'égalité n'est pas respectée ?
De plus, pourquoi pensez-vous que l'erreur se situe au niveau du stockage ou de la lecture des variables doubles de la mémoire ? Peut-être une erreur dans les opérations arithmétiques ?

Pensez-vous qu'il ne peut pas y avoir d'erreur dans un tel cas :

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?

Je pense que l'opération de division elle-même est exécutée correctement.

La question à l'étude ne porte pas sur la manière d'obtenir la valeur d'une variable (qu'il s'agisse de la valeur obtenue à la suite de calculs ou de l'initialisation de la variable), mais sur le sort de la valeur de cette variable au cours de l'exécution du programme et même simplement du fonctionnement de l'ordinateur. Et son sort est imprévisible. C'est pourquoi, lorsque vous programmez des opérations logiques, vous devez utiliser la fameuse fonctionNormalizeDouble().

Pour l'appliquer, c'est bien. L'appliquer correctement est très bien.

Ne pas l'utiliser est mauvais. Utilisation incorrecte - mauvais.

---

En vacances, je veux...

 
SK. писал (а):
 Cela fonctionne dans certains cas, mais pas toujours. Ce "pas toujours" est dicté par les méthodes particulières de stockage des valeurs dans la mémoire des ordinateurs. C'est justement ça.
Je connais les moyens de stocker des valeurs dans la mémoire d'un ordinateur. :) J'ai environ 20 ans d'expérience en programmation. J'ai même enseigné la programmation à des étudiants universitaires dans le passé.

Les résultats attribués aux variables a et b sont normalisés et ils peuvent être comparés ultérieurement, rien ne leur arrivera.
Tu ne peux pas. Vous pouvez donc faire ce que vous voulez, mais pour obtenir un résultat garanti, vous devez appliquer NormalizeDouble() directement dans l'expression contenant l'opération de comparaison.

Naturellement, avant de pouvoir comparer le résultat du calcul d'une expression avec quoi que ce soit, vous devez le normaliser ! Qui peut se disputer avec ça ? ! Mais ce n'est pas pertinent pour notre argument. Je parlais de l'identité du code. La différence est que dans le second cas, les résultats de la normalisation sont stockés dans des variables. ET C'EST TOUT !

Autrement dit, vous affirmez que la fonction NormalizeDouble a un résultat dont la taille de bit est supérieure à celle du double (le résultat de cette fonction occupe au moins un bit de mémoire). Ce n'est qu'ainsi que je peux expliquer toute perte (ou changement) lors de la sauvegarde du résultat d'une fonction dans une variable. Ou, lors de l'assignation, une opération délicate est effectuée, et pas seulement une duplication octet par octet des données d'une cellule de mémoire à une autre.

Encore une fois, je ne discute pas de l'exactitude des normalisations séparées des opérandes de droite et de gauche de l'opération de comparaison ou de quoi que ce soit d'autre. Je me demande seulement si les résultats des deux fragments de code ci-dessus sont identiques.

Si vous normalisez le résultat d'une opération, vous pouvez l'affecter à une variable et effectuer d'autres opérations sur celle-ci. L'essentiel est que la variable elle-même ne change pas de valeur par la suite.
 Elle peut changer de valeur dans le dernier chiffre en raison de la technologie informatique spécifique utilisée. Cela peut se produire et se produit sans que l'utilisateur s'en aperçoive. C'est là l'essentiel. Dans certains cas, cela fonctionnera (par exemple, lors du débogage d'un programme), et lors de l'utilisation de ce programme, il fonctionnera souvent comme prévu par l'infortuné programmeur, et parfois il ne fonctionnera pas.

WOW ! Et de quel type de "technologie informatique spécifique" parlez-vous ? Beaucoup de choses " passent inaperçues " pour l'utilisateur, mais nous sommes, après tout, desprogrammeurs. :) Rien ne doit passer inaperçu pour nous, sinon il ne sera pas un ordinateur mais un générateur de résultats imprévisibles. :) Ou peut-être que notre ordinateur a déjà quelques bits errants ? Ils peuvent lire dans un sens ou dans l'autre... Encore une fois ! Dans les opérations arithmétiques avec des nombres réels, le résultatn' est en effetpas absolument exact (cela tient à la façon dont les nombres réels sont représentés). Mais cela ne s'applique pas aux opérations d'affectation. Une fois que la fonction NormalizeDouble a fonctionné et renvoyé un résultat de type double, ce résultat est placé dans une variable en copiant simplement la valeur (tous les octets seront appariés). De plus, si la valeur de la variable reste inchangée (c'est-à-dire qu'elle est seulement lisible, mais rien n'est écrit dedans), elle est préservée dans sa forme originale et il n'y a pas de signes flottant à n'importe quel endroit. Lisez-le et vous obtiendrez la même chose. Mais si vous vous contentez de le multiplier par 1 et de réécrire le résultat, rien n'est garanti.

 
SK. писал (а):

Mes sincères condoléances aux développeurs qui doiventexpliquer 1000 fois la même chose à chaque nouvel utilisateur.

C'est une attaque flagrante - je pense que je vais l'ignorer. :)
 
gravity001:

Vous pensez qu'il ne peut y avoir d'erreur dans un tel cas :

double a = 4.0;
double b = 2.0;

double c = a / b; // думаете, здесь в опрерации "деления" не может быть ошибки
                     (т.е. появление цифр отличных от нуля после точки)?

Dans ce cas, le résultat de l'opération serait APPLICABLE 2.0
Une erreur sur des chiffres très éloignés peut très bien être due à la façon dont les nombres réels sont représentés.
1234567891011
Nouveau commentaire