Erreurs, bugs, questions - page 738
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
Question :
Vous devez passer un tableau de pointeurs vers des objets dans une fonction. Par référence, bien sûr (un tableau).
Quelle syntaxe utiliser ?
Ou dois-je l'utiliser d'une autre manière ?
Déclaration du pointeur (type, type de variable) : MyObject* hobject
Déclaration d'un tableau de pointeurs (type, tableau de variables de type) : MyObject* hobject[].
Il s'avère que lorsqu'il est passé par référence (type, tableau de variables de type passé) : MyObject* &hobject[]
Ce qui est déroutant, c'est que je n'ai pas trouvé d'informations sur le passage de pointeurs et de tableaux de pointeurs comme paramètres de fonction. Mais ce n'est même pas une question, juste un avertissement.
J'ai été confronté à un tel besoin, tordu et brutal, mais le résultat correct est obtenu. Les drapeaux sont activés sur les trois données d'entrée, puis bloqués à faux.
Je ne suis pas très doué pour les explications. Laissez-moi essayer à nouveau. La tâche consiste à constituer un portefeuille de devises, chaque devise ayant ses propres paramètres. Dans un portefeuille optimisé, une devise peut ne pas participer. J'ai calculé six devises en 21 étapes d'optimisation pour chaque devise, et la somme totale se chiffre en milliards.
Maintenant la question. Si nous interdisons à une monnaie de s'échanger avec un drapeau, il n'y a aucun sens à optimiser ses paramètres, de toute façon ils n'affecteront en rien le résultat, mais l'optimiseur continuera à essayer d'adapter des paramètres qui n'affectent pas le résultat. Un peu comme si je savais moi-même que tu ne peux pas, mais que l'espoir subsiste.
Je ne suis pas très doué pour les explications. Laissez-moi essayer à nouveau. La tâche consiste à constituer un portefeuille de devises, chaque devise ayant ses propres paramètres. Dans un portefeuille optimisé, une devise peut ne pas participer. J'ai calculé six devises en 21 étapes d'optimisation pour chaque devise, et la somme totale se chiffre en milliards.
Maintenant la question. Si nous interdisons à une monnaie de s'échanger avec un drapeau, il n'y a aucun sens à optimiser ses paramètres, de toute façon ils n'affecteront en rien le résultat, mais l'optimiseur continuera à essayer d'adapter des paramètres qui n'affectent pas le résultat. Comme moi, je sais que vous ne pouvez pas, mais l'espoir est toujours présent.
Donc, je vous ai quand même dit la même chose dès la première fois.
Vous ne devez pas vérifier ces paramètres dans le testeur.
Pour que les paramètres soient impliqués dans l'optimisation, vous devez cocher ces cases. Si les cases à cocher ne sont pas sélectionnées, ces paramètres ne seront pas optimisés.
P.S. Vous pouvez aussi effectuer l'optimisation séparément pour chaque outil. Maintenant je vois ce que vous voulez dire. :) Et après toutes les optimisations, mettez en marche tous les outils et voyez le résultat cumulé.
Donc j'avais raison la première fois après tout.
Non, ça ne l'est pas. À en juger par les explications complémentaires, l'auteur lance l'optimisation pour tous ses paramètres d'entrée en même temps, et se demande si certaines des passes peuvent être sautées si trpair2==false. Vous ne pouvez pas définir manuellement les "cases à cocher dans le testeur" ici.
Eh bien, je suis moi-même curieux de savoir s'il existe une telle solution.
Non, ça ne l'est pas. À en juger par les explications complémentaires, l'auteur lance l'optimisation pour tous ses paramètres d'entrée en même temps, et se demande si certaines des passes peuvent être sautées si trpair2==false. Il n'y a pas de "cases à cocher" manuelles dans le testeur.
Je n'ai pas non plus trouvé de solution pour cette situation. Bien sûr, il est possible de combiner dans int OnInit() un bloc qui stockerait la valeur des paramètres optimisables par d'autres symboles lors de l'assignation à trpair2 du paramètre false, et en cas de deuxième passage avec trpair2==false et avec 'les valeurs stockées des paramètres optimisables par d'autres symboles', il générerait un code de retour non nul (c'est-à-dire qu'il générerait l'événement Deinit avec le code de raison de désinitialisation.c'est-à-dire qu'il génère un événement Deinit avec le code de raison de désinitialisation REASON_INITFAILED). Mais tout cela semble plutôt fastidieux.
Exactement. Vous seul avez oublié d'écrire le verdict, que vous puissiez ou non.
C'est beaucoup plus simple. Lorsqu'une condition est exécutée, vous pouvez simplement supprimer le conseiller expert - ExpertRemove(). Je l'ai mis en place en cas de drawdown. Si le tirage a atteint la valeur fixée, par exemple pendant l'optimisation, nous le supprimons et commençons le passage suivant.
Comment cela peut-il être "plus facile" ? :) Les conditions de suppression d'une EA ou de REASON_INITFAILED doivent encore être suivies. C'est ce qui est si gênant.