Toute question des nouveaux arrivants sur MQL4 et MQL5, aide et discussion sur les algorithmes et les codes. - page 1477

Nouveau commentaire
 
MakarFX:

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.


double LoU,LoY1,Pr;
int x;
void OnTick()
{
if (Low[1]>Low[2]&&Time[2]>x&&Low[2]<LoY1)
{
LoU=Low[2];
LoY1=Low[2];
}
//**************************************************************
if (Bid-LoU>=0.0030&&Pr!=LoU)
{
OrderSend(Symbol(),OP_SELL,0.1,Bid, 3,0,0,"300",0);
Pr=LoU;
LoU=Bid;
LoY1=Bid;
x=TimeCurrent();
}
}

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.

 
ANDREY:

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.

 
ANDREY:

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

 
Taras Slobodyanik:

il existe des fonctions standard iLowest etiHighest.

Ne convient pas... le nombre d'éléments de la série chronologique n'est pas constant.
 
MakarFX:
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 ?

 
Taras Slobodyanik:

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

 
MakarFX:

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.

 
Aleksei Stepanenko:
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.
Merci beaucoup !
 
MakarFX:

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

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.

 
ANDREY:

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.

Oui
1...147014711472147314741475147614771478147914801481148214831484...1954
Nouveau commentaire
Raison: