Souhaits pour Meta Trader 4/5

 

1) Créer un générateur de stratégie intuitif, par glisser-déposer, à la Gordago (ou mieux encore, des générateurs de stratégie plus complexes). Cela attirera certainement les nouveaux utilisateurs qui veulent trader plus ou moins systématiquement, mais qui ne veulent pas passer beaucoup de temps à étudier et à fouiller dans MQL. L'activité du trader consiste à réfléchir au marché et à essayer des options, et non à se demander où un bug s'est glissé dans le code du programme.

2) Cocher l'historique pour les tests. Vous devrez faire le "pour tous" tôt ou tard de toute façon en raison de la concurrence et des changements qui se produisent, et les personnes bien informées et "de longue date" savent comment aborder les tests dans MT4 de toute façon.

Faites ces choses et MT sera le numéro 1 pendant longtemps sans aucun doute. Et si vous ne le faites pas, d'autres le feront (et le font déjà). Mais vous disposez déjà d'un produit de qualité suffisamment élevée et adapté pour la superstructure de ces éléments nécessaires.

Avec l'espoir de comprendre.

 
Très naïf.

Peu de gens peuvent résister au rêve du "je vais lancer les dés visuellement et puis c'est fait". La dure réalité et la pratique à long terme prouvent que cela n'a jamais fonctionné, n'a jamais fonctionné et a peu de chances de fonctionner ainsi. Nous allons exactement dans la direction opposée : nous nous concentrons sur les programmeurs et leur fournissons des outils de développement complets.
 
Cher Renat.

Est-il possible dans la nouvelle version de Meta Trader 4
dans le testeur de stratégie sur la page "Log"
par le menu qui apparaît après un clic droit
avec l'élément "Auto-scrolling" ajouter les éléments
"Disable output of tester messages".
"Désactiver la sortie du journal".

Les journaux ne montreront donc que les résultats du conseiller expert et aucun message :

2007.09.04 22:49:44 Expert : chargé avec succès
2007.09.04 22:55:37 2006.01.02 07:00 Expert : EURUSD,M1 : open #1 buy 0.50 EURUSD at 1.1832 sl : 1.1732 tp : 1.1882 ok
2007.09.04 22:55:38 2006.01.03 06:03 Tester : take profit #1 at 1.1882 (1.1883 / 1.1886)

et des messages similaires.
Lorsqu'un conseiller expert envoie de nombreux ordres au cours d'une période de test
, il est presque impossible de trouver les messages du conseiller expert lui-même
et cela rend le débogage très difficile.
Il n'est pas pratique de chercher quelque chose dans les journaux sur le disque.

Merci d'avance.
 
1)Capacité totale à jouer avec l'histoire.
2) Possibilité d'examiner la forme complète de l'espace de deux variables pendant l'optimisation.
et pas seulement le meilleur résultat, lorsque toutes les autres valeurs sont fixées.
3) Capacité d'effectuer des WFA automatiques.
4) Capacité à tester et à optimiser des EA multi-devises (portefeuille).
 
Renat:
Très naïf.

Peu de gens peuvent résister au rêve d'une sorte de "maintenant je lance les dés et c'est tout". La dure réalité et la longue pratique prouvent que cela n'a pas fonctionné, ne fonctionne pas et a peu de chances de fonctionner ainsi. Nous allons exactement dans la direction opposée : nous nous concentrons sur les programmeurs et leur fournissons des outils de développement complets.


C'est une réponse étrange. "Politique", comme, d'ailleurs, de nombreuses autres réponses. Je ne parle pas d'une "chimère", mais bien d'une interface. Et je ne perdrai pas mon temps à discuter de quoi, de qui l'a et de comment elle "fonctionne" exactement, pour ainsi dire. Je vous propose plutôt de conserver et de développer une programmation complexe, et d'y ajouter un concepteur visuel intuitif pour une autre partie de la plate-forme CA. Si vous la rendez fonctionnellement identique à la programmation (même si ce n'est pas immédiatement) et, mieux encore, si vous avez la possibilité de combiner ces deux méthodes, alors quelle différence cela fait-il que l'utilisateur forme sa stratégie - par code, "aux dés" ou sommairement ?

Apparemment, vous me direz que "nous n'avons pas les ressources nécessaires pour faire toutes ces bêtises". On va passer le reste de notre vie à chanter la même chanson." C'est bien ça ?

 
ADI:


Apparemment, à cela, vous me répondrez : "Nous n'avons pas les ressources nécessaires pour faire toutes ces bêtises. Nous allons passer le reste de notre vie à chanter la même chanson." C'est bien ça ?

La théorie, c'est bien, mais nous sommes des praticiens. Des tentatives pour "apporter une solution simple aux commerçants" ont déjà été faites auparavant (MQL, MQL2). J'ai déjà écrit à ce sujet à de nombreuses reprises.

Mais nous allons travailler avec le constructeur/visiteur - nous allons essayer de faire des squelettes de base simples (pas des programmes complets) automatiquement.
 
En plus de la déclaration habituelle des variables, j'aimerais vraiment créer des variables similaires par le nom de la chaîne, qui agit comme un paramètre qui peut être changé pendant le fonctionnement d'un indicateur ou d'un Expert Advisor. Ceci est similaire aux variables globales ! Par exemple, comme ceci :
CreatIntVariable("Variable_Name");
 

Renat, je vous suggère de penser au prototype de fonction iCustom dans les futures versions. Maintenant vous devez écrire la liste des paramètres explicitement dans le code, et de cette façon vous ne pouvez pas appeler un indicateur arbitraire par son nom, par exemple, donné par un utilisateur, parce que le nombre d'arguments de tout indicateur est inconnu à l'avance. Il limite sévèrement l'utilisation d'iCustom. Et en plus, il y a deux paramètres d'appel (int mode, int shift) à la fin de la liste des arguments de l'iCustom, c'est-à-dire que les paramètres de l'indicateur "cassent" les paramètres de l'iCustom lui-même dans le prototype.

Je peux proposer un tel prototype :

double iCustom( string symbol, int timeframe, string name, int mode, int shift, object[] indicatorParams)

C'est-à-dire que tous les paramètres obligatoires de iCustom lui-même sont au début, et le dernier argument de la fonction est un tableau des arguments indicateurs d'un nouveau type d'objet arbitraire (en fait, ce sont des int, bool, double, datetime et d'autres types MQL intégrés) avec un numéro variable dans le tableau. Bien que l'idée en soi ne soit pas réaliste - il y a environ 5 ans, un homme m'a dit que les programmeurs étaient une catégorie de personnes en voie d'extinction, c'est-à-dire une couche inutile entre les professionnels et les ordinateurs. Avec le temps, le pronostic se vérifie au contraire : le nombre et la complexité des solutions informatiques ne font qu'augmenter.

Et il serait bien d'avoir des fonctions pour énumérer leurs arguments pour les indicateurs : IndicatorArgsCount(), ArgsItemName[i] retournera le nom du paramètre, etc.
Et le plus important - c'est un débogueur dans MQL 5.

 

Pour chv - il est toujours possible d'utiliser les paramètres par défaut dans iCustom - voir https://docs.mql4.com/ru/indicators/iCustom.

En principe, MQL4 représente tout ce qu'il y a à présent, mais il y a encore plus de possibilités. Voici ma liste :

1.) Il est possible de déterminer si un ordre StopLoss ou TakeProfit vient d'être clôturé. Cela peut être fait maintenant, mais c'est assez compliqué :

3 fonctions

int OrderJustClosedCount() - renvoie le nombre d'ordres fermés aux stops

int OrderJustClosed(int pos) - numéro du ticket

void OrderJustClosedClear() - vide le tampon - immédiatement après que OrderJustClosedCount ait retourné 0 - si le traitement a pris trop de temps.

2.) Pour certains objets (par exemple, un canal de régression linéaire), vous ne pouvez pas lire certaines valeurs après le dessin (par exemple, le prix à la fin du canal).

3.) Ajout de plus de MathArcTan2 - au moins MathArcTan2 - bien sûr beaucoup a déjà été implémenté dans MQL4, mais quand même - pourquoi ne pas les intégrer ?

Et à propos du débogueur - je crois que vous y travaillez déjà ;-)

 
Itso:

1.) La possibilité de déterminer si les ordres StopLoss ou TakeProfit viennent d'être clôturés. Cela peut être fait maintenant, mais c'est assez compliqué.

Ensuite, il y a aussi une liste des ordres en attente déclenchés.

En général, il suffit d'introduire le concept d'"événement", et toutes les situations de ce type peuvent être traitées.
Par exemple, l'événement "ordre déclenché", "SL déclenché", ou "ordre supprimé par le délai d'expiration".
 
Itso:

Pour chv - la possibilité d'utiliser les paramètres par défaut dans iCustom existe toujours - voir https://docs.mql4.com/ru/indicators/iCustom.


Vous savez, j'ai déjà lu le prototype de la fonction iCustom ;). Les "paramètres par défaut" ne me permettent pas de faire ce dont j'ai besoin. Voici la tâche la plus simple - le conseiller expert prend comme argument dans une chaîne le nom d'un indicateur arbitraire et, par exemple, une liste séparée par des virgules des valeurs de ses paramètres dans un fichier texte. Le conseiller expert doit appeler l'indicateur par son nom avec les valeurs d'argument spécifiées et recevoir ses valeurs et les imprimer dans le journal, disons que la description iCustom contient une phrase :

...   -   Список параметров (при необходимости). Передаваемые параметры должны соответствовать порядку объявления и типу внешних (extern) переменных  пользовательского индикатора.

Or, nous ne pouvons pas le faire pour un indicateur arbitraire - écrire ce que nous ne savons pas. Au stade de la compilation du conseiller expert, le nombre et le type d'arguments des indicateurs sont inconnus. Elle n'est déterminée qu'au moment de l'exécution. Dans les langages de programmation, ce phénomène est appelé "liaison tardive". Elle n'existe pas dans MQL pour le moment.