Erreurs, bugs, questions - page 2938
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Oui, je m'en souviens parfaitement : faire une fausse tentative de préchargement d'historique à OnInit. Cela n'a pas fonctionné là, ni dans OnCalculate, même dans une boucle avec une centaine de répétitions. Je ne sais pas comment cela fonctionne réellement, mais extérieurement il n'y a pas eu de chargement de l'historique promis (bien qu'avec un retard), le résultat est resté insatisfaisant jusqu'à la fin.
En outre, il y a eu d'autres cas où la réponse a été renvoyée à plusieurs reprises :
mais à la fin il n'y a pas eu de continuation de l'indicateur, il y a eu un silence dans la réponse.
Il n'est pas nécessaire de faire des cycles avec des répétitions.
S'il s'agit d'un indicateur, faites une seule demande pour la bonne période-symbole dans OnCalculate. Si elle a échoué, alors return(0)
Prenez le temps de réception du tick du symbole requis, normalisez ce temps au début de la période requise, demandez 1 dernière barre de la période du symbole requis et vérifiez son temps. Demandez ensuite le statut temporel de l'histoire
Selon la lenteur et la charge des ressources de votre ordinateur, plus d'une centaine de OnCalculate peuvent passer.
Le code auquel vous faites référence est très ancien. Mais c'est bon pour l'illustration. Mais il ne convient pas aux indicateurs, car les demandes d'historique des indicateurs sont exécutées sans aucune attente (ce qui est clairement écrit dans la documentation) et le sommeil des indicateurs est inutile.
Le serveur donne l'historique même le week-end.
Contrôlez la construction des barres par l'heure du dernier tick du symbole approprié.
S'il s'agit d'un indicateur, faites une demande unique pour la période de caractères requise dans OnCalculate. En cas d'échec, retour(0)
Le retour(false) en cas d'échec est un classique. C'est ce que je fais. Tout irait bien, mais le problème est que mes calculs ultérieurs sont liés au chargement réussi de l'historique (et cette logique ne peut pas changer), et en cas d'échec et de retour de la fonction de calcul, ils ne se produisent tout simplement pas et les constructions graphiques ultérieures n'obtiennent pas les coordonnées nécessaires, tout se plante. Comment éviter cela - je n'y ai pas encore pensé et je ne m'attends pas à changer quelque chose aussi. Jusqu'à présent, j'ai obtenu les résultats suivants : soit tout l'historique est chargé et toutes les séries temporelles pour toutes les périodes sont construites et l'indicateur fonctionne presque immédiatement sans manquer aucun calcul en raison de return(false), soit une partie de l'historique est manquante, et le coderetourne à une fonction de niveau supérieur avecreturn et essaie de demander l'historique manquant dans une boucle sans fin, ce qui ne mène à rien. J'ai simplement refusé la troisième variante - sans retour - et certains calculs échouent, ce qui rend le dessin des graphiques incomplet.
Encore un peu dans le réservoir, je suis toujours perplexe... Est-il réel d'organiser la logique MQL de l'indicateur pour qu'il ne travaille qu'avec l'historique local, sans avoir besoin de télécharger l'historique manquant et de subir des retards à cause de cela ? Ou toute fonction de copie... ... doit inévitablement contacter le serveur pour télécharger même cette partie de l'historique, dont je n'ai pas besoin pour le traitement ? Pour faire simple, les indicateurs standards se dessinent instantanément sur l'historique existant sur mon PC, sans aucun téléchargement (j'ai cherché les indicateurs dans le dossier Examples et là ils n'utilisent que CopyBuffer(), et pas dans tous)... Ou la reprise est cachée aux yeux de tous ? Quel est le but de la reprise ?
Merci. Je vais réfléchir à vos recommandations - elles me seront probablement utiles.
J'étais loin de l'ordinateur pendant quelques heures. Pendant ce temps, une situation anormale s'est produite et le robot a commencé à broder un grand nombre d'impressions. En conséquence, le disque est complètement obstrué. Cela perturbe le travail des terminaux, car ils ne peuvent pas transférer leur historique de prix sur le disque.
Nous devons empêcher un tel engorgement du disque. L'une des solutions consiste à interdire l'écriture dans le dossier. C'est-à-dire vivre sans journaux sur le disque en permanence. Une autre option consiste à supprimer les fichiers journaux lorsqu'il ne reste plus assez d'espace libre.
Quelqu'un a-t-il résolu ce problème ?
S'il s'agit d'un indicateur, faites une demande unique pour la période de caractères requise dans OnCalculate. Si elle échoue, alors return(0)
Et si vous voulez faire l'indicateur le week-end ?
Seulement un appel forcé de OnCalculate depuis le timer (avec toutes les béquilles sous forme de copie de tableaux à passer par référence) ?
Est-il réaliste d'organiser une logique MQL non redondante de l'indicateur pour ne travailler qu'avec l'historique local, sans avoir besoin de télécharger l'historique manquant et de subir les délais qui y sont associés ? Ou toute fonction de copie... ... doit inévitablement accéder au serveur pour télécharger ne serait-ce que cette partie de l'historique, dont je n'ai pas besoin pour le traitement ?
Vous pourriez créer votre propre cache(écrire dans des fichiers).
Lorsque cela m'a été suggéré, je me suis bien sûr tordu la tempe, mais c'est vraiment mieux que d'attendre que MQ change son approche de la gestion des séries chronologiques.
J'étais loin de l'ordinateur pendant quelques heures. Pendant ce temps, une situation anormale s'est produite et le robot a commencé à broder un grand nombre d'impressions. En conséquence, le disque est complètement obstrué. Cela perturbe le travail des terminaux, car ils ne peuvent pas transférer leur historique de prix sur le disque.
Nous devons empêcher un tel engorgement du disque. L'une des solutions consiste à interdire l'écriture dans le dossier. C'est-à-dire vivre sans journaux sur le disque en permanence. Une autre option consiste à supprimer les fichiers journaux lorsqu'il ne reste plus assez d'espace libre.
Quelqu'un a-t-il résolu ce problème ?
Par souci d'intérêt, je me suis précipité pour le vérifier et j'ai frappé le sol avec ma mâchoire : 183 Go ! C'est presque 4/5 de ma SSD. Les images de machines virtuelles prennent moins de temps. Au moins, j'aurai quelque chose à lire dans mes vieux jours...
Juste pour le plaisir, je me suis précipité pour vérifier ma maison et j'ai frappé le sol avec ma mâchoire : 183GB ! C'est presque 4/5 de ma SSD. Les images de machines virtuelles prennent moins de temps. Au moins j'ai quelque chose à lire dans mes vieux jours...
L'impression et l'alerte sont des fonctions potentiellement dangereuses.
Price=0.7235200000000001Pourquoi ferait-il ça ? S'agit-il d'une erreur ou devons-nous ajuster la sortie d'une manière unifiée ? Bon, disons que je vais le peigner avec PrintFormat ou fprint, mais en principe ce n'est pas une représentation incorrecte du nombre ?Tous les prix sont affichés avec cinq décimales, et l'un d'entre eux, pour une raison ou une autre, dans la même liste, le prend de cette façon : Pourquoi ? Est-ce une erreur ou mon résultat doit-il être modifié pour obtenir un aspect uniforme ? Bon, disons que je peux le faire avec PrintFormat ou fprint, mais en principe ce n'est pas une représentation incorrecte du nombre ?
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Bugs, bugs, questions
Nikolai Semko, 2020.01.05 21:41
Je me pose toujours cette question.
On parle constamment de la norme 754 de l'IEEE, mais souvent, lorsqu'on consulte Wikipédia - que ce soit à cause de la complexité ou par paresse - on ne comprend pas le sens de la norme.
Je vais prendre un peu de temps pour essayer d'expliquer cette norme le plus brièvement possible et avec des mots simples, afin de faire référence à ce post.
Ainsi, le type double est constitué de 8 octets = 64 bits.(float 4 bytes = 32 bits)
Et la représentation numérique dudouble et du flottant se compose de 3 éléments : lesigne, l'exposant et la mantisse .
DOUBLE :
FLOAT :
Naturellement, il n'existe pas de représentation décimale des nombres dans ce format, mais uniquement binaire.
Une petite compréhension de la représentation binaire des nombres et de sa relation avec les nombres décimaux :
2 4= 100002 = 1610
2 3= 10002 = 810
2 2= 1002 = 4
2 1=102= 2
2 0=12=110
2 -1= 0.12 =(1/2)10= 0.510
2 -2= 0.012 = (1/4)10= 0.2510
2 -3= 0.0012 = (1/8)10= 0.12510
2 -4= 0.00012 = (1/16)10= 0.062510
2 -5= 0.000012 = (1/32)10= 0.0312510
2 -6= 0.0000012 = (1/64)10= 0.01562510
2 -7= 0.00000012 = (1/128)10= 0.007812510
2 -8= 0.000000012 = (1/256)10= 0.0039062510
2 -9= 0.0000000012 = (1/512)10= 0.00195312510
2 - 10= 0.00000000012 = (1/1024)10= 0.000976562510
2 - 11= 0.000000000012 = (1/2048)10= 0.0004882812510
2 - 12= 0.0000000000012 = (1/4096)10= 0.00024414062510
2 - 13= 0.00000000000012 = (1/8192)10= 0.000122070312510
Passons en revue les exemples pour le double:
Exemple n° 1
Nous avons un nombre décimal : 891677.4025191
Ce nombre peut être représenté sous forme binaire :
1101100110110001110101.01100111000010110111111111011000101000001111111010001110
(qui veut peut vérifier)))
Nous extrayons la mantisse du nombre donné en déplaçant simplement la virgule de 19 chiffres vers la gauche (dans ce cas) afin qu'elle vienne après la première unité.
1.1011001101100011101011001110000101101111101111000101000001111101110001110* 2 19
Mais nous avons une mantisse de seulement 52 bits. Donc on prend les 52 premiers bits significatifs
Мантисса = 1011001101100011101011001110000101101111101111000101
Exposant = (19+1023)10 = 100000100102(comme l'exposant est un nombre signé et que l'exposant peut être négatif (par exemple si nous avons 0.0000042132), nous devons ajouter 1023 à 10(01111111111112), 011111111112 est zéro, tout ce qui est plus est positif, moins est négatif. En d'autres termes, pour obtenir la valeur inverse de l'exposant, nous devons soustraire 1023 de la valeur de 11 bits de l'exposant.
Au total, notre numéro 891677.4025191 se présentera comme suit en type double:
0100000100101011001101100011101011001110000101101111101111000101
Mais comme il s'agit d'une représentation binaire, convertissons-la exactement en décimal :
ce serait891677.40251909999996425211429595947265625
Exemple n° 2
Nous avons un nombre décimal : -0.00000145258556224114
Ce nombre peut être représenté sous forme binaire :
-0.000000000000000000011000010111101100111010110111010011010101001111001110
Sélectionnez la mantisse de ce nombre en déplaçant simplement la virgule de 20 chiffres vers la droite, de sorte qu'elle se trouve après la première unité.
1.1000010111101100111010110111010011010101001111001110 * 2 -20
Мантисса = 1000010111101100111010110111010011010101001111001110
exposant = (-20+1023)10=011111010112
signe moins, donc le premier bit est 1.
Notre nombre total -0,00000145258556224114 se présentera comme suit en caractères doubles :
1011111010111000010111101100111010110111010011010101001111001110
le convertir exactement en décimal :
это будет -0.00000145258556224113991124017968015191826225418481044471263885498046875
Dans votre cas, le problème se pose avec le nombre 0,01, puisque dans le type double il sera représenté sous la forme :
0 01111111000 0100011110101110000101000111101011100001010001111011
qui, converti dans le système de notation décimale, est égal à 0,010000000000000000208166817117216858513294309377670288085937510
Considérant qu'avec la représentation
310 = 1.5*2 = 1.12*2 1
510 = 2.5*2 = 10.12*2 1
610 = 1.5*4 = 1.12*2 2
710 = 3.5*2 = 11.12*2 1
pas de problème.
Pourquoi le nombre double 0,01 est-il vraiment supérieur à 0,01 ?
Voici pourquoi :
0 01111111000 01000111101101011101000010111101011101001010001111011 - 0,010000000000000000000020816681711721685132943093776702880859375 erreur = 0,000 000 000 000 000 000 208166817...
0 01111111000 01000111101101011100001010001111010 - 0.009999999999999999999847344334114097569175064563751220703125 erreur = - 0.000 000 000 000 000 001 5265566...
Pour comprendre ce processus chimique, vous pouvez jouer avec ces calculatrices :
https://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html
https://baseconvert.com/ieee-754-floating-point
https://baseconvert.com/ieee-754-floating-point