Toute question des nouveaux arrivants sur MQL4 et MQL5, aide et discussion sur les algorithmes et les codes. - page 1477
![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Pourtant, il vérifie à chaque fois
et le calcul minimum s'arrête... il recule de deux mesures.
Mon calcul minimum était de me faire frapper comme sur votre photo. Mais ensuite j'ai ajouté la variable LoY1 et cela a arrêté cette erreur. En conséquence, tous les ordres sont ouverts de la même manière (par heure, montant et prix) que dans mon code initial, c'est-à-dire de la manière dont j'en ai besoin. Mon code a échoué à un autre endroit .... Mais je l'ai réparé au même endroit.
Vous pouvez également placer un ordre en suspens à 30 points de la LoU au lieu d'ouvrir au marché, ce qui vous évite de vérifier l'offre à chaque tick. Mais dans le cas d'un ordre en attente, chaque fois que le LoU change , nous devons supprimer l'ancien ordre en attente et en définir un nouveau, ou modifier les paramètres d'un ordre en attente actuel sans le supprimer. Et tout cela devrait être fait beaucoup moins fréquemment que de vérifier chaque tic-tac de Bid .
Dans mon cas, quelle est la variante qui prend le moins de temps en termes de mise en œuvre du code ?
1. Vérifiez à chaque coche si l'offre est à 30 points de la LoU.
2. A chaque changement de LoU, supprimez l'ancien en attente et définissez un nouveau.
3. A chaque changement de LoU, modifier les paramètres de la LoU active
Merci pour votre aide.
Mon calcul du minimum s'envolait comme sur votre photo. Mais ensuite j'ai ajouté la variable LoY1 et ça l'a arrêté.
Il existe des fonctions standard iLowest etiHighest.
Mon calcul du minimum s'envolait comme sur votre photo. Mais alors j'ai ajouté une variable LoY1 et cela a stoppé cet égarement. En conséquence, tous les ordres s'ouvrent de la même manière (par le temps, le montant et le prix) que dans mon code original (c'est-à-dire comme je le veux). Mon code a échoué à un autre endroit .... Mais je l'ai réparé au même endroit.
Vous pouvez également placer un ordre en suspens à 30 points de la LoU au lieu d'ouvrir au marché, ce qui vous évite de vérifier l'offre à chaque tick. Mais dans le cas d'un ordre en attente, chaque fois que le LoU change , nous devons supprimer l'ancien ordre en attente et en définir un nouveau, ou modifier les paramètres d'un ordre en attente actuel sans le supprimer. Et tout cela devrait être fait beaucoup moins fréquemment que de vérifier chaque tic-tac de Bid .
Dans mon cas, quelle est la variante qui prend le moins de temps en termes de mise en œuvre du code ?
1. Vérifiez à chaque cochage si l'offre est à 30 points de la LoU.
2. A chaque changement de LoU, supprimez l'ancien en attente et définissez un nouveau.
3. A chaque changement de LoU, modifier les paramètres de la position active
1) x n'est pas un int, c'est une date (ce sera utile dans le futur).
2) votre code initial n'a pas d'ordres en attente
3) Maintenant votre code fait plus d'opérations sur chaque tick
Vérifiez votre message
il existe des fonctions standard iLowest etiHighest.
Ce n'est pas le cas... le nombre d'éléments de la série temporelle n'est pas constant.
er... cela vous empêche-t-il de trouver le haut/bas ?
er... cela vous empêche-t-il de trouver le haut/bas ?
Les fonctionsiLowest etiHighest permettent de rechercher parmi un certain nombre de barres (nombre d'éléments de la série temporelle).
dans ce cas, le numéro est inconnu et il change à chaque fois
1) x n'est pas int, c'est datetime (cela sera utile à l'avenir).
2) votre code initial n'a pas d'ordres en attente
3) maintenant votre code fait plus d'opérations sur chaque tick
Vérifiez votre message.
Voici mon ancien code
Voici mon nouveau code pour la même période que l'ancien.
Le nombre d'opérations par tic est beaucoup moins important pour moi que le temps consacré à ce nombre. Et le nouveau code prend 25% de temps en moins.... si je ne me trompe pas.
Merci pour votre aide.
Il y a une subtilité ici. D'abord, nous fixons la taille et ensuite, en remettant à zéro, nous libérons la fixation, ce qui ne change pas la taille. Il n'y a pas d'autre moyen de contourner le problème.
Pourtant, il vérifie à chaque fois
et le calcul du creux s'en va... recule de deux mesures.
Voici mon code original sans vos ajouts
![](https://c.mql5.com/3/356/3827948359728__1.png)
Ci-dessous avec vos dernières améliorations
Peut-être que if(TimeSeconds(TimeCurrent())==0) devrait être appliqué uniquement aux sections où aucun ordre n'est ouvert, et où le prochain minimum est recherché ?
Si je ne me trompe pas, grâce à votre fonction, mon code a commencé à s'exécuter seulement au début de chaque bougie minute, c'est pourquoi il n'ouvre pas correctement les ordres.
Merci pour votre aide.
Voici mon code original sans vos ajouts
Voici le code avec vos dernières améliorations
Peut-être que if(TimeSeconds(TimeCurrent())==0) ne devrait être appliqué qu'aux sections où aucun ordre n'est ouvert, et où l'on recherche le prochain point bas ?
Si je ne me trompe pas, votre fonction a commencé à exécuter mon code uniquement au début de chaque bougie minute.
Merci pour votre aide.