Le problème du transfert de MT4 à MT5. Ou, plus précisément, l'impossibilité d'exécuter certains algorithmes dans MT5 sans "err". - page 7
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
L'absurdité consiste à organiser votre propre copie des données, qui sont déjà disponibles dans le terminal.
Il y a beaucoup d'absurdités de ce genre. Lorsque MT4 est sorti en août 2005, l'indicateur ZigZag est apparu. Il y a beaucoup d'erreurs. Dans un cas, il pourrait accrocher le terminal sur le marché rapide à ce moment-là. Et il affichait souvent des extrema en l'air, sans rapport avec les minimums/maximums des barres.
Dans un post, le développeur de ce zigzag a déclaré que ceci - (veuillez ne pas vous émouvoir davantage) est une manifestation de la logique floue.........
Mais jusqu'à présent, 14 ans se sont écoulés depuis le lancement de MT4, dans l 'indicateur du zigzag il y a un paramètre - Déviation - qui ne produit aucune action. Autrement dit, quelle que soit la valeur de ce paramètre, le dessin du zigzag sur le graphique ne changera pas.
De nombreux programmes sont basés sur cet indicateur. La plupart des développeurs incluent ce paramètre dans leurs programmes. C'est un paramètre inutile. Les développeurs font preuve d'une indifférence fantastique à son égard. Ce paramètre est d'ailleurs gourmand en ressources informatiques.
Il y a eu de nombreux moments de ce genre à d'autres occasions.
Je vais continuer.
Ces zigzags extrêmes suspendus dans l'air sont exactement de la même nature que ceux que nous avons en accédant aux séries chronologiques.
C'est juste que l'accès aux séries chronologiques n'était pas refusé dans MT4. Certaines fonctions n'y fonctionnaient pas correctement (peut-être le font-elles encore maintenant). J'avais une explication pour mon propre usage interne. J'ai aussi fait un forcing tout seul. Et tout a commencé à fonctionner sans erreurs, sans charge CPU. Même la sortie de plusieurs dizaines de zigzags sur des graphiques n'a pas provoqué le blocage du terminal...
Si tout fonctionnait, il n'y aurait pas un million de sujets consacrés à ce problème.
La logique s'est avérée plus compliquée que ce que les utilisateurs de terminaux sont prêts à gérer.
Et il doit y avoir des erreurs, mais les développeurs n'ont pas le temps de les chercher, et personne ne veut non plus les reproduire et les prouver auprès des utilisateurs.
Andrei, je suggère que nous commencions avec ce que nous avons. Et puisque nous avons ce dont vous parlez, est-il préférable d'en parler ou de l'éviter ?
Je pense qu'il y a suffisamment de problèmes, mais plutôt que d'en parler d'une branche à l'autre (ce qui est également utile - parfois, ils sont corrigés), mais faites la solution de rechange.
J'ai proposé une bonne solution : mettre en cache les séries temporelles nécessaires au moment où elles sont pleinement disponibles. Et ensuite - obtenir toutes les données nécessaires à partir de séries chronologiques prêtes et toujours disponibles. Et ne les compléter qu'avec de nouvelles données. Quand ils sont disponibles - lentement et pas nécessairement au moment où vous en avez besoin.
Au moins, de cette façon, les choses avanceront. Et les conversations peuvent être laissées pour plus tard - quand il n'y a rien à faire.
Je vais continuer.
Ces zigzags extrêmes suspendus dans l'air sont exactement de la même nature que ceux que nous avons en accédant aux séries chronologiques.
C'est juste que l'accès aux séries chronologiques n'était pas refusé dans MT4. Certaines fonctions n'y fonctionnaient pas correctement (peut-être le font-elles encore maintenant). J'avais une explication pour mon propre usage interne. J'ai aussi fait un forcing tout seul. Et tout a commencé à fonctionner sans erreurs, sans charge CPU. Même la sortie de plusieurs dizaines de zigzags sur les graphiques n'a pas provoqué le blocage du terminal...
Si l'accès à la série chronologique est refusé, cela signifie qu'elle est au stade de la synchronisation. Vous devez attendre le prochain tic-tac.
Dans votre situation - mieux vaut mettre en cache les timeseries - elles seront toujours disponibles sans attendre, et à la première demande.
Mettre en cache lorsque l'indicateur démarre - lorsqu'il y a du temps pour "attendre la synchronisation" et en attendant de demander des données pour la série temporelle suivante.
Andrei, je suggère que nous devrions faire avec ce que nous avons. Et puisque nous avons ce dont vous parlez, est-il préférable d'en parler ou de le contourner ?
Je pense qu'il y a suffisamment de problèmes, mais plutôt que d'en parler d'une branche à l'autre (ce qui est également utile - parfois, ils sont corrigés), mais faites la solution de rechange.
Et j'ai suggéré une bonne option - mettre en cache les séries temporelles nécessaires au moment de leur pleine disponibilité. Et en outre - pour recevoir toutes les données nécessaires à partir de séries chronologiques prêtes et toujours disponibles. Et ne les compléter qu'avec de nouvelles données. En même temps, quand ils sont disponibles - pas à la hâte, et pas nécessairement au moment où ils sont nécessaires.
Au moins de cette façon, les choses avanceront. Et les conversations peuvent être laissées pour plus tard - quand il n'y a rien à faire.
Il est alors déjà plus efficace de faire un exemple reproductible pour que les développeurs puissent le corriger.
Andrei, je suggère que nous devrions faire avec ce que nous avons. Et puisque nous avons ce dont vous parlez, est-il préférable d'en parler ou de le contourner ?
Je pense qu'il y a suffisamment de problèmes, mais plutôt que d'en parler d'une branche à l'autre (ce qui est également utile - parfois, ils sont corrigés), faites la solution de contournement.
J'ai proposé une bonne solution : mettre en cache les séries temporelles nécessaires au moment où elles sont pleinement disponibles. Et ensuite, recevoir toutes les données nécessaires à partir de séries chronologiques prêtes et toujours disponibles. Et ne les compléter qu'avec de nouvelles données. En même temps, quand ils sont disponibles - pas à la hâte, et pas nécessairement au moment où ils sont nécessaires.
Au moins, de cette façon, les choses avanceront. Et les conversations peuvent être laissées pour plus tard - quand il n'y a rien à faire.
Et pourquoi les développeurs du terminal ne peuvent-ils pas le faire ? De toute façon, il n'y a pas d'accès aux séries chronologiques au moment de la mise à jour. Laissez tout le monde avoir accès à cet historique, disons, en cache. Quelle différence cela ferait-il ? C'est-à-dire pour qu'il n'y ait jamais d'interruption de l'accès. Eh bien, peut-être qu'il y aurait des retards à la barre de zéro. Le reste de l'histoire serait toujours disponible.
J'ai suggéré une bonne option - mettre en cache les séries temporelles nécessaires au moment où elles sont pleinement disponibles. Et ensuite - obtenir toutes les données nécessaires à partir de séries chronologiques prêtes et toujours disponibles. Et ne les compléter qu'avec de nouvelles données.
C'est une mauvaise variante, vous devez répéter entièrement la logique de construction et de synchronisation des séries chronologiques dans le terminal - un nouveau tick est arrivé, la synchronisation n'était pas terminée... puis un échec de la connexion.
ZS : Oui, et pourquoi le faire ? - Je ne sais pas combien dans la vie, j'ai un téléphone portable, une voiture, et même un portefeuille avec un seul, mais beaucoup de cas dans la vie ? - besoin d'une assurance ? .... "Trois magnétophones, trois caméras étrangères, trois étuis à cigarettes domestiques, une veste... en daim... Trois. Vestes" ))))
Si l'accès à la série chronologique est refusé, cela signifie qu'elle est synchronisée. Vous devez attendre le prochain tic-tac.
Vous avez raison ! mais il est nécessaire d'arrêter le programme MQL à n'importe quel endroit et de quitter le terminal jusqu'au prochain tick... Je suggère périodiquement quelque chose comme dans Delphi "Abort() ou Halt()" - obtenez une erreur d'accès aux séries temporelles une fois - c'est uneerreur critique qui n'a pas de sens de la traiter plusieurs fois - cela ne fonctionnera pas jusqu'à ce que le terminal établisse la communication avec le programme MQL de toute façon ;)))
SZZ : Je ne crée pas cette erreur (erreur d'accès aux séries temporelles) - elle est créée par le terminal, mais tous les programmeurs MQL devraient être prêts à déboguer les erreurs générées par le terminal... ( lorsque le code consiste en quelques centaines de lignes ) il est facile de jouer avec, mais lorsque le code est volumineux et qu'il est pratique d'utiliser l'accès aux séries temporelles à partir de différentes sections du programme - et qu'il faut 999 façons de sortir de n'importe quelle section sans perdre les calculs précédents ? - Oui, c'est possible, mais cela nécessite un plan clair (algorithme) selon lequel le code source sera écrit ... Et si le code source est affiné par l'ajout de fonctions (classes) toutes faites ? - c'est-à-dire qu'à chaque fois, vous devrez découvrir ce qu'il y a à l'intérieur... une tâche généralement chronophage pour les grands projets pour tout fournir, imho
Si un programme a été créé pendant 14 ans, le traduire en utilisant la nouvelle méthode de conception est plus facile que de se tirer une balle dans le pied. Et le débogage des liens multiples est également difficile. La vérification de l'accessibilité aux délais entraîne de sérieux retards s'il n'y a pas d'accès. Ce serait bien si lesconstructions graphiques automatiques étaient activées. La reconstruction en mode automatique est un phénomène peu fréquent. Vous ne remarquerez peut-être même pas les retards ici. Cependant, dans ce cas également, lorsque l'accès aux séries chronologiques est interrompu, les constructions graphiques sont parfois produites sous une forme tronquée. Certains des éléments ont le temps d'être construits et d'autres non... Ou encore, la filtration fractale tronque certains tf.
***
Si un programme a été créé pendant 14 ans, le traduire en utilisant la nouvelle méthode de conception est plus facile que de se tirer une balle dans le pied. Et le débogage des liens multiples est également difficile. La vérification de l'accessibilité aux délais entraîne de sérieux retards s'il n'y a pas d'accès. Ce serait bien si les constructions graphiques automatiques étaient activées. La reconstruction en mode automatique est un phénomène peu fréquent. Vous ne remarquerez peut-être même pas les retards ici.
Mais le problème se pose lorsque le réglage est effectué via l'interface graphique. L'utilisateur appuie sur le bouton et... doit attendre le prochain tic. Ou bien l'utilisateur appuie plusieurs fois sur le bouton jusqu'à ce que la réponse souhaitée se produise. Quelle est la réponse de l'utilisateur... ? -***
Et il n'y a pas de tels problèmes dans MT4.
Je vous comprends très bien, donc j'ai décidé de soutenir la discussion
Fonctions iClose()...iXXX() pour accéder aux séries chronologiques - génial !
Il peut s'agir de fonctions synchrones, c'est-à-dire que l'accès aux séries chronologiques sera plus long mais garanti au niveau du terminal, ou bien les développeurs de l'U.V. devraient ajouter la directive du précompilateur qui donnera un tick au programme MQL seulement si le terminal est prêt à accéder aux données historiques (OHLC) - pas de tick sinon.
....
mais le seul but est de se débarrasser des interminables vérifications de l'état de préparation des graphiques OHLC, ce problème a été résolu depuis l'apparition de MT5 seulement au niveau des vérifications à l'intérieur du programme MQL, c'est un processus qui prend du temps et à mon avis les utilisateurs s'attendent à ce que le terminal reçoive les données de la série chronologique sans aucun problème et garanti à tout moment, dans n'importe quelle section de code.
c'est une mauvaise option, vous devez répéter complètement la logique de construction et de synchronisation des séries temporelles dans le terminal - puis un nouveau tick est arrivé, puis la synchronisation ne s'est pas terminée...puis un échec de connexion
ZS : Oui, et pourquoi le faire ? - Je ne sais pas combien dans la vie, j'ai un téléphone portable, une voiture, et même un portefeuille avec un seul, mais beaucoup de cas dans la vie ? - besoin d'une assurance ? .... "Trois magnétophones, trois caméras étrangères, trois étuis à cigarettes domestiques, une veste... en daim... Trois. Vestes" ))))
Mais le programme MQL doit arrêter les calculs à n'importe quel endroit et quitter le terminal jusqu'au prochain tick... Je suggère parfois quelque chose comme dans Delphi "Abort() ou Halt()" - vous avez une erreur d'accès aux séries temporelles - c'est une erreur critique, qui n'a pas de sens à être traitée plusieurs fois - de toute façon, jusqu'à ce que le terminal établisse une interaction avec le programme MQL "ça ne sert à rien" ))).
SZZ : Je ne crée pas cette erreur (erreur d'accès aux séries temporelles) - elle est créée par le terminal, mais tous les programmeurs MQL devraient être prêts à déboguer les erreurs générées par le terminal... ( lorsque le code consiste en quelques centaines de lignes ) il est facile de jouer avec, mais lorsque le code est volumineux et qu'il est pratique d'utiliser l'accès aux séries temporelles à partir de différentes sections du programme - et qu'il faut 999 façons de sortir de n'importe quelle section sans perdre les calculs précédents ? - Oui, c'est possible, mais cela nécessite un plan clair (algorithme) selon lequel le code source sera écrit ... Et si le code source est affiné par l'ajout de fonctions (classes) toutes faites ? - c'est-à-dire qu'à chaque fois, vous devrez découvrir ce qu'il y a à l'intérieur... ... une tâche qui prend du temps pour les grands projets, à mon avis.
Si le programme est exécuté par un clic de souris, peu importe qu'il y ait un accès ou non - il faut réagir. Vous pouvez écrire beaucoup de choses sur la façon dont tout est mal fait, mais dans ce cas, il est préférable d'avoir son propre cache, auquel vous pouvez toujours accéder à la demande.
Imaginez un programme qui, au lieu de donner quelque chose sur les données historiques calculées depuis longtemps par un clic de souris, dit - allez fumer - je récupère les données actuelles, dont vous n'avez pas besoin maintenant, et je reconstruis les séries chronologiques...
Quoi qu'il en soit, si vous devez vous contenter de ce que vous avez, il est préférable de sortir ce qui se trouve dans le cache et de le reconstruire après avoir débloqué l'accès aux séries chronologiques.