Erreurs, bugs, questions - page 2301

[Artyom Trishkin]

aleger:

Mais cela nécessite la création de DEUX objets nommés, par exemple, Hi et Lo (extrémités supérieure et inférieure du zigzag ou extrémités supérieure et inférieure de la tendance locale réelle à la hausse ou à la baisse) et de les lier tous les deux au graphique avec les valeurs correspondantes de ANCHOR_LOWER et ANCHOR_UPPER. Ne serait-il pas plus simple de lier (d'une manière ou d'une autre) le haut du zigzag - au bas précédemment "lié" ? C'est à peu près ce que j'ai fait, en ajoutant une ligne à la fonction précédente

ObjectSetInteger(0,Obj,OBJPROP_ANCHOR,ANCHOR_CENTER) ; et introduire une "correction de décalage" à la ligne de sortie if(tvT) ORT(kBtT,Low[kBtT]-2*_Point,DtT,LowClr) ; else ORT(kBtT,High[kBtT]+2*_Point,DtT,HighClr) ; //

Jusqu'à présent, cela semble fonctionner. Merci !

Quel est l'intérêt ? Vous pouvez modifier l'attachement à tout moment. Ou est-ce que je rate quelque chose ? Vous changez la couleur. Donc, vous changez l'attelage.

[fxsaber]

Après avoir fermé la fenêtre de débogage, recompilé et lancé une seule exécution dans le testeur sans visualisation, j'ai obtenu ceci

2018.09.27 14:01:52.784 Core 1  agent process started
2018.09.27 14:01:52.784 Core 1  connecting to 127.0.0.1:3000
2018.09.27 14:02:11.358 Core 1  tester agent authorization error
2018.09.27 14:04:15.875 Core 1  no connection
2018.09.27 14:04:15.875 Core 1  connect error

Je n'ai rien pu faire pendant 20 secondes. Le bouton Start était grisé tout le temps.

Les registres de l'agent.

DM      3       14:01:49.711    Tester  close visual tester window
RH      0       14:01:49.711    Tester  shutdown tester machine
LN      0       14:01:54.186    Server  MetaTester 5 stopped

Les journaux montrent que le testeur a essayé de se connecter à l'agent à 01:52, mais que l'agent (serveur) lui-même ne s'est arrêté qu'à 01:54. D'où l'incapacité à se connecter et à se suspendre. C'est un bogue de longue date, mais au moins la cause est maintenant claire.

[fxsaber]

Résultats du profileur sur les données historiques

Le système interne OrderSend prend un tiers du temps. Qu'est-ce qui provoque des résultats aussi désagréables ?

[Slava]

fxsaber:

Résultats du profileur sur les données historiques

L'OrderSend interne prend un tiers du temps. Qu'est-ce qui provoque des résultats aussi désagréables ?

Dans le testeur, toute la logique de négociation est ici, et non sur le serveur de négociation.

[fxsaber]

Slava:

Dans le testeur, toute la logique de négociation est ici, et non sur le serveur de négociation.

Presque trois millions de ticks et seulement 16K OrderSend. Mais ces ordres commerciaux prennent un tiers du temps. Et à chaque tick, il y a des calculs dans l'Expert Advisor.

D'où ma question. Pourriez-vous exécuter le code de OrderSend dans le profiler ? À quel endroit y a-t-il un tel problème ?

Je suppose que si vous remplacez la fonction standard par la vôtre, elle fonctionnera plus rapidement. Probablement, il y a quelques contrôles et gestes coûteux dans OrderSend. Par exemple, s'il n'y a pas de fonctions d'historique et de OnTrade* dans le conseiller expert (+ indicateurs), la création des enregistrements/événements appropriés est une perte de temps.

Je comprends que pour certaines personnes, une course dure plusieurs minutes. Mais il existe des cas comme celui-ci - des unités de quelques secondes, si vous prêtez attention à la vitesse d'exécution. Et là, il s'avère que je lance Optimize pendant trois heures, dont une heure pour OrderSend, dont le temps d'exécution moyen est de 69 µs (voir capture d'écran) :

• TRADE_ACTION_PENDING - 104 µs.
• TRADE_ACTION_SLTP/TRADE_ACTION_MODIFY/TRADE_ACTION_REMOVE - 68 microsecondes.

[Slava]

J'ai établi le profil du testeur à de nombreuses reprises. Et je sais où se trouve le "hitch". Il s'agit de calculs financiers, qui impliquent plusieurs normalisations des résultats en fonction du nombre de chiffres de la monnaie de dépôt.

[fxsaber]

Slava:
J'ai établi le profil du testeur à de nombreuses reprises. Et je sais où se trouve le "hitch". Il s'agit de calculs financiers, qui impliquent plusieurs normalisations des résultats en fonction du nombre de chiffres de la monnaie de dépôt.

Je vais écrire mon OrderSend et le comparer.

[Calunea]

Bonjour à tous ! Je suis nouveau dans le trading, j'en apprends tous les détails depuis six mois. C'est une activité très tentante, mais je ne sais pas, j'ai souvent l'impression que tous les profits et les pertes en quelques mois ou années sont pratiquement nuls, dans le meilleur des cas.Je ne veux pas décevoir qui que ce soit dans cette activité est le choix de chaque personne, mais un fait très important que je ne donne tout simplement pas la paix jamais dans cette entreprise, c'est le SPARK (SPARK est quand une affaire s'ouvre avec -16 points ou -21 points) à 16 ou 21 points, ou même 34 points, apparemment il flotte, Dieu sait, bien, comment pouvez-vous faire de l'argent ici ?Je n'ai qu'une seule question : Dites-moi qui est le plus expérimenté, une si grande majoration est la main de mon courtier (mon courtier dit qu'il n'a pas de majoration et que cela vient d'un fournisseur de liquidité) ou cela affecte tout le monde en général, dites-moi en détail s'il a la majoration et combien de points.

[Sergey Eremin]

Veuillez noter ce post (ou je peux le déplacer ici et il pourra y être écrasé) : https://www.mql5.com/ru/forum/281440

[fxsaber]

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Conversion correcte de double en int

Slava, 2018.09.28 07:10

Je vais aussi vérifier. Pourquoi avez-vous besoin de normaliser les doublages ?

Première réponse. Pour convertir le prix afin que le serveur de trading puisse reconnaître le prix comme étant le s ien, provenant du même système, arrondi correctement, comme si c'était le serveur lui-même qui arrondissait.

Ma compréhension du testeur est-elle correcte ?

1. Nous envoyons un ordre BuyLimit en utilisant BuyLimit_PriceRequest.
2. Le testeur crée un BuyLimit qui a BuyLimit_Price = NormalizeDouble(BuyLimit_PriceRequest).
3. A chaque tick le testeur fait une vérification (BuyLimit_Price <= Ask) SANS NormalizeDouble.

C'est-à-dire que la deuxième étape, très coûteuse, est effectuée pour éviter que la troisième étape ne soit très coûteuse. Puisqu'il y a plusieurs ordres de grandeur de ticks (troisième étape) par rapport à OrderSend (deuxième étape).

Quand Digits == 0, NormalizeDouble ralentit ?