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

Nouveau commentaire
 
Simca:
SK. a écrit (a) :

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



C'est déjà une attaque flagrante...
Je suis d'accord. Bien que SK. soit une autorité sur le forum, mais "technologie informatique spécifique" me rend suspicieux aussi.
C'est écrit dans les manuels sur le stockage des nombres réels en mémoire et ça ne dit rien sur les variables qui changent d'elles-mêmes. Bien que je l'ai entendu non seulement de la part de SK sur ce forum.
Donc, si vous avez trompé chaque nouvel utilisateur 1000 fois, vous devriez maintenant les trouver et vous excuser pour vos paroles !

Je suis d'accord avec Simca. Lors de l'exécution d'opérations arithmétiques, des erreurs sont possibles, mais lors du stockage, de l'écriture ou de la lecture, elles sont exclues !

C'est pourquoi j'ai demandé l'algorithme de la fonction NormalizeDouble(), peut-être qu'elle a aussi des opérations arithmétiques qui provoquent une erreur ?
Qu'en penses-tu Simca?
 

OK. Tu dis ça avec tellement d'assurance que je commence à douter de ce que tu dis.

Il y a quelque temps encore, je travaillais sur un vieux PC avec 256 Mo de RAM. Lorsque vous googlez quelques programmes, le système d'exploitation vide une partie des données sur le disque, puis les recharge à nouveau. Depuis que j'ai modifié le code (en spécifiant la normalisation dans l'opérateur de comparaison) l'erreur a cessé d'apparaître. Mais j'ai commencé à douter après avoir entendu vos paroles - et si je n'avais pas remarqué l'erreur ?

Maintenant, je ne sais pas si je dois m'excuser ou non. Si je me trompe, que les 1000 utilisateurs me pardonnent.

(mais il est toujours préférable d'effectuer la normalisation directement lors du calcul de l'opération de comparaison :)

 
gravity001:
Dans les manuels, il est question de stocker des nombres réels en mémoire et il n'est pas question que les variables changent d'elles-mêmes. Ce n'est pas seulementSK qui m'a dit ça sur ce forum.
Rien n'est modifié en soi pendant le stockage. Mais la façon dont les nombres réels sont représentés dans la mémoire de l'ordinateur affecte la précision (profondeur de bit) des valeurs stockées. Lorsque l'on effectue des opérations arithmétiques sur des nombres réels, le résultat n'est souvent "pas assez précis" (d'un point de vue humain), il est donc parfois nécessaire de normaliser le résultat de l'opération. Il est absolument nécessaire de normaliser le résultat des opérations en cas de comparaison ultérieure à l'égalité (souvent à >, <). Il est également nécessaire de normaliser le résultat si vous travaillez avec des valeurs dont la capacité en chiffres est strictement définie (par exemple, les prix). Les calculs intermédiaires avec des nombres réels ne nécessitent généralement pas de normalisation.
Mais, tout ceci concerne des calculs alors que les valeurs stockées en mémoire ne changeront pas, qu'elles soient normalisées ou non.
gravity001:
C'est pourquoi je demandais l'algorithme de la fonction NormalizeDouble(), peut-être a-t-elle aussi des opérations arithmétiques qui provoquent une erreur ?
Qu'en penses-tu Simca?
En ce qui concerne l'algorithme de la fonction NormalizeDouble, nous devrions demander aux développeurs, et je ne suis pas l'un d'entre eux. :) D'ailleurs, ce n'est pas le sujet du litige, car la fonction NormalizeDouble dans les deux extraits de code a été utilisée de manière absolument identique. La seule différence réside dans la comparaison directe des résultats des deux normalisations et dans l'écriture de ces résultats dans des variables, puis dans la comparaison de leurs valeurs. Et j'ai remarqué que puisque le type de la valeur renvoyée par la fonction NormalizeDouble coïncide avec le type de la variable utilisée pour le stockage, il n'y aurait aucune différence entre les fragments cités. Mais si la fonction NormalizeDouble renvoie une valeur de plus grande dimension que la variable dans laquelle elle est stockée, alors la différence peut se produire et nous ne pouvons pas être sûrs qu'elle est identique. Mais selon l'AIDE de MetaEditor, le type de données dans les deux cas est double, il ne devrait donc pas y avoir de différence, quelle que soit la façon dont la fonction NormalizeDouble est mise en œuvre.
 
SK. писал (а):

(mais il est toujours préférable d'effectuer la normalisation directement lors du calcul de l'opération de comparaison :)

Et sur ce point, appliqué à chaque nouvel utilisateur, je suis absolument d'accord. Si vous n'avez pas une idée claire de ce qui se passe et de la manière dont cela fonctionne, il est plus raisonnable de suivre la voie la plus sûre et la plus fiable ! Mais cela ne nous concerne pas, vous et moi. :)
Et pour ma part (pour ceux qui ne comprennent pas bien l'essence de la question) je peux aussi recommander :

(mais il est tout de même préférable d'effectuer la normalisation directement lors du calcul de l'opération de comparaison (c) SK.

 
SK. писал (а):

(mais il est toujours préférable de faire la normalisation directement lors du calcul de la
l'opération de comparaison est calculée :)





Désolé, mais en termes d'efficacité, il existe de bien meilleures implémentations pour comparer des données nécessitant une normalisation. En général, il s'agit de la norme (algorithme de comparaison). Vous devez comparer la différence avec la moitié de la dimension de l'échelle. Ce que je veux dire : pour comparer les prix (qu'ils soient différents ou non), vous devez prendre la différence et la comparer à 0.5*Roynt ( elle ne peut être calculée qu'une seule fois lors de l'initialisation de l'Expert Advisor/Scriptoryindicator. C'est beaucoup plus efficace que d'appeler une seule fonction, et encore plus si elle est aussi dans une boucle) ..... Et peu importe comment ces données sont stockées et à quel signe insignifiant elles sont arrondies.

Bonne chance.
 
Tout d'abord, travailler avec des dubles est purement une question de compilateur, donc exiger la commodité de mql4, qui est essentiellement un compilateur intrinsèque caché, est déraisonnable. L'essentiel, c'est que les développeurs ont donné un moyen de GARANTIR le résultat correct de la comparaison, nous l'avons vérifié de nos mains, c'est, bien sûr, graphique, mais FONCTIONNEL ! !! Bien que la documentation dise que la normalisation ne se fait qu'en cas de " !!".=" ou "==", nos tests indépendants et experts ont montré que (a>b) NE GARANTIT PAS ( !) un résultat correct si a s'avère être égal à b ! Même si vous normalisez PRÉDVORABLEMENT a et b, le résultat est imprévisible. Et voici une construction des développeurs: : NormalizeDouble(a-b, Digits)>0 fonctionne de manière fiable ! Je ne sais pas pourquoi les gens ici n'aiment pas la fonction normalize... Peut-être qu'elle est (en interne) tout à fait semptotique et faite comme ceci : deux tableaux sont divisés en double précision, et arrondis vers le bas (ou vers le haut). Ensuite, l'ensemble est comparé sans aucun problème.
 
.FG писал (а):
Tout d'abord, travailler avec des dubles est purement une question de compilateur, donc exiger la commodité de mql4, qui est essentiellement un compilateur intrinsèque caché, est déraisonnable. La chose principale, les développeurs ont donné un moyen de GARANTIR le résultat correct de la comparaison, nous l'avons vérifié avec nos mains, c'est, bien sûr, graphique, mais FONCTIONNEL !!! Bien que la documentation dit que normaliser seulement en cas de " !=" ou "==", nos tests indépendants et experts ont montré que (a>b) NE GARANTIT PAS ( !) un résultat correct si a s'avère être égal à b ! Même si vous normalisez PRÉDVORABLEMENT a et b, le résultat est imprévisible. Et voici une construction des développeurs: : NormalizeDouble(a-b, Digits)>0 fonctionne de manière fiable ! Je ne sais pas pourquoi les gens ici n'aiment pas la fonction normalize... Peut-être qu'elle (en interne) est tout à fait semptotique et faite comme ceci : deux tableaux sont divisés en double précision, et arrondis vers le bas (ou vers le haut). Et ensuite, les entiers sont comparés sans aucun problème.

Veuillez écrire en russe correct.

 
Donnez-moi un lien vers le site du développeur (de la langue russe), et je vous promets que j'utiliserai UNIQUEMENT les définitions de l'auteur. :) Votre point, à mon avis, pas plus correct que le mien, mais si VOUS voulez personnellement à comprendre, je vais faire un "porte-parole de Rosh", si vous ne pouvez pas distinguer entre blah-blah de l'opinion d'experts. Parce que j'ai écrit pas vous, et le 1001e débutant. :)
 
.FG писал (а):
Donnez-moi un lien vers votre site et je vous promets que je n'utiliserai QUE les DÉFINITIONS DE L'AUTEUR. :) Votre idée, je pense, n'est pas plus correcte que la mienne, mais si VOUS voulez personnellement comprendre, je vais faire un "porte-parole de Rosh", si vous ne pouvez pas faire la distinction entre le bla-bla et l'expertise. Parce que je n'écrivais pas à toi, mais au 1001e nouveau venu. :)

Par exemple www.gramota.ru

Nous n'avons pas de section albanaise sur le forum. Néanmoins, après le prochain poste non-russe, vous serez envoyé là-bas. S'il te plaît, ne donne pas l'impression que tu utilises la langue.

 
Dans ce cas, toi, stringo, tu devrais aller à Cyril et Methodius avec un diplôme de réussite en programmation ! Tous ces problèmes de normalisation, que j'ai rencontrés dans les compilateurs DOS libres, sont depuis longtemps implémentés de manière pratique dans les versions actuelles. C'est pourquoi certains programmeurs ne comprennent pas pourquoi ils ont besoin d'une vérification aussi désuète des doublons. Quand ils réécriront leur code, en fourrant partout la normolyse par rapport à zéro, ils seront surpris de constater l'absence d'erreurs dans leur propre "C-logique", et non le commentaire DROIT des pères-exécutifs, car ils peuvent se servir de l'optimisation et d'autres choses secondaires. Mais les questions concernant les RÉSULTATS des calculs de base resteront cruciales, nécessitant la plus grande attention. Et si vous menacez encore de me renvoyer, nous irons chez un CME, nous prendrons leur documentation et nous écrirons un programme avec des FIXES et autres astuces en OLBANIC. :) Et vous serez au chômage. Vous ferez votre mq6 et vous voudrez que quelqu'un teste au moins vos produits en albanais, mais non, nous ne serons pas là... Parce que vous nous avez interdit tranquillement vous-même.... :)))))))))))))))))))))))000
1...34567891011
Nouveau commentaire