Toute question des nouveaux arrivants sur MQL4 et MQL5, aide et discussion sur les algorithmes et les codes. - page 1857
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
collecter (ou se souvenir/connaître) tout, trier par temps ouvert. C'est ça, mais l'heure d'ouverture ne change pas :-)
Si la logique de l'EA contient plus d'un ordre (par exemple, une grille), vous devrez les mémoriser tous. Ou vous devrez ralentir en essayant de vous souvenir de tous à chaque éternuement.
Pouvez-vous me dire si le bénéfice dans l'historique est encerclé en bleu, cela inclut-il la commission et le swap ?
L'heure et le prix de l'ordre à sélectionner à l'aide de la fonction OrderSelect() seront obtenus.
Pour autant que je sache, il n'y a aucune mention de cela dans la documentation. Il est donc préférable de jouer la sécurité. Ça ne va pas empirer les choses.
Certains se sont plaints du fait que cette procédure prend beaucoup de temps au CPU.
En ce qui concerne SL et TP, ils sont calculés. Ils doivent donc absolument être normalisés en fonction de la valeur des chiffres.
Ici, en tout cas, il est nécessaire de découvrir l'intention de l'auteur.
Certains se sont plaints du fait que cette procédure prend beaucoup de temps au CPU.
La normalisation des SL et TA calculés prend deux fois plus de temps. Mais je ne dirais pas que cela a beaucoup d'impact sur l'optimisation et encore moins sur les tests de robots.
La documentation indique noir sur blanc qu'il faut normaliser les niveaux calculés! Et quelle pourrait être "l'intention de l'auteur" ? Qu'est-ce qui n'est pas normal pour normaliser SL et TP ? Je ne vais pas discuter avec vous car les faits sont évidents ici !
Si c'est une question, prenez le ticket du premier, sélectionnez le premier et les suivants qui ont le ticket !=premier.
Il faut deux fois plus de temps pour normaliser les SL et TA calculés. Mais je ne dirais pas que cela a beaucoup d'impact sur l'optimisation et encore moins sur les tests de robots.
C'est le cas, et il y a eu des questions sur ce forum concernant la simplification de cette procédure.
Je ne connais pas de cas où les prix reçus qui ne sont pas normalisés ont causé une erreur.
Pour référence :
Et quelle pourrait être "l'intention de l'auteur" dans ce cas ? Que ne pas normaliser SL et TP ? Je ne vais pas discuter avec vous car les faits sont évidents !
On peut aussi penser à arrondir les chiffres. En théorie, cela ne se fait pas, mais cette façon de faire fonctionnera en cas d'arrondi à moins de chiffres , au cas où les prix seraient corrects pour SL et TP. Vous devez donc trouver ce qui est prévu dans tous les cas.
J'ai essayé de le résoudre moi-même, en ajoutant grossièrement dans le code de cet indicateur, mais ça ne marche pas. Bien qu'il compile et ne présente aucune erreur.
Peut-être devrions-nous utiliser l'indicateur iCustom et handle ?
Si vous essayez d'identifier le problème, puis de décrire plus en détail ce que vous ne pouvez pas faire exactement, la probabilité d'obtenir une réponse sera beaucoup plus élevée.
Il faut deux fois plus de temps pour normaliser les SL et TA calculés. Mais je ne dirais pas que cela a un impact aussi important sur l'optimisation, sans parler des tests de robots.
En plus de cela, certaines personnes négligent des contrôles aussi simples que
en pensant que cela peut consommer beaucoup de temps CPU :)
Mais en réalité, ce sont des fonctions comme ObjectCreate et ObjectDelete qui consomment du temps processeur. Si un programmeur dispose, par exemple, d'un tableau d'objets graphiques et que celui-ci est supprimé et recréé à chaque tic, il faut faire quelque chose. Alors que les contrôles et les calculs simples sont de peu de temps. C'est pourquoi beaucoup de programmeurs cherchent simplement au mauvais endroit.
C'est le cas, et il y a eu des questions sur ce forum concernant la simplification de cette procédure.
Je ne sais pas qui cela affecte ou ce que cela affecte. Je n'ai jamais eu de problèmes avec NormaizeDouble. En fait, tout code affecte la vitesse d'une application. Mais si tout est si critique, vous pouvez laisser les gestionnaires OnTick ou OnCalculate vides. Dans ce cas, votre demande ne pourra pas voler du tout. :) Ou réécrire les fonctions en assembleur, les compiler en DLL et les connecter à l'application.
Je ne connais pas de cas où les prix reçus et non normalisés ont causé une erreur.
Mais la documentation le fait ! Et vous ignorez les conseils de la documentation. Faites comme vous voulez. C'est votre affaire. Je pense que c'est évident et je ne vais pas discuter avec vous à ce sujet, je le répète !
L'arrondi peut être une réflexion après coup.
Il ne s'agit pas d'arrondir, mais de couper tout ce qui dépasse deux décimales.
Je ne connais pas non plus l'idée de l'auteur. Mais je n'en ai pas besoin. Je pense qu'il peut se débrouiller tout seul.