Souhaits pour le MQL5 - page 3

Nouveau commentaire
 
alexnau:
wellx:
Je l'ai déjà écrit auparavant, mais je vais le répéter :
- des fonctions de rappel pour travailler avec le terminal lui-même
- Rupture/rétablissement de la connexion
- gestion de la file d'attente de plusieurs EA (mutex, sections critiques....)
- débogueur (n'importe lequel)
- support direct de la numérotation des barres (de la plus ancienne à la plus récente) avec message sur les changements du nombre de barres
 - création de dll à partir de fonctions MQL (aidera à créer des bibliothèques, ce qui réduira le code global avec un grand nombre d'indicateurs)


Résoudre les problèmes avec incertitude, il est peu probable que cela améliore le MQL mis à jour. Pourquoi avons-nous besoin de certaines alertes pour calculer le numéro de la barre actuelle (barre zéro) ?

Malgré le "compte à rebours", la logique pour déterminer la barre nécessaire est claire et simple, à mon avis.

Je ne demande pas de changer la variante actuelle, mais seulement d'ajouter un support. Ce que cela fera, c'est de ne pas recalculer l'historique à chaque nouvelle barre, il suffit de vérifier le changement du nombre de barres. En conséquence, la charge sur le terminal est réduite et la recherche de personnes est moins fréquente.
 
Le nombre de barres peut encore être contrôlé. C'est à ça que sert Bars.
 
alexnau:
wellx:
- support pour la numérotation directe des barres (de la plus ancienne à la plus récente) avec notification du changement du nombre de barres


pour résoudre les problèmes d'incertitude, il est peu probable que cela améliore le MQL mis à jour. Pourquoi avons-nous besoin d'alertes pour calculer ensuite le numéro de la barre actuelle (barre zéro) ?

Malgré le "compte à rebours", la logique de détermination de la barre nécessaire est claire et simple, à mon avis.


Cela réduirait le problème de la recherche de la bonne barre dans l'historique à la spécification de son index "en arrière" et serait beaucoup plus économique.

Eh, l'enthousiasme et l'optimisme d'antan ont disparu :), mais je vais ajouter mes 5 kopecks :

Dans le testeur, à la place du mode "points de contrôle", ajoutez le paramètre "tous les ticks" "nombre de démarrages du conseiller expert par barre". Le mode "par les prix ouverts" ne devrait pas être annulé de toute façon, puisque des fxt plus compacts sont utilisés pour cela. Cependant, non, il est préférable de le remplacer par le mode "à des prix proches" :)

Et encore :

-Ajouter la liaison des variables globales aux variables du programme dans init.

-Faire un fichier exe pour le testeur.

-Ajouter aux tampons des indicateurs ( pour chaque type de variables) - pour un échange de données efficace avec Expert Advisor.

 
Aussi : ajouter la possibilité de tester un fichier fxt donné avec un nom arbitraire. Pourquoi la relation rigide actuelle entre le nom de fichier fxt et le caractère ?
 
Voici mes souhaits pour le nouveau système qui me viennent à l'esprit jusqu'à présent (par ordre décroissant) :

Langue
----

Convertir un double en chaîne avec une précision maximale (> 8)

Compilation conditionnelle (#ifdef, #ifndef, #define, #undefine)

Possibilité de remplacer les mots-clés par #define (pour la compilation conditionnelle). La valeur peut être vide.
exemple :
//#define EXTERN extern // normal
#define EXTERN // concours
EXTERN int opt = 0 ;

Commentaires imbriqués /* */.
Pas ANSI, mais implémenté presque partout (et désactivé). Permet de commenter rapidement un gros morceau de code avec des commentaires de texte normaux.

Structures (promis)

Tableaux multidimensionnels, meilleure gestion des din.

Débogueur (promis ?)

Événements

Exceptions

API

Pointeurs ou similaires, pour les listes, les paquets, ...

Interface avec la base de données (SQL ou ODBC). La base de données ne doit pas être un serveur.

Fonctions en ligne

Surcharge de fonctions

Obfusqué (difficile à décompiler).
Cryptage de chaînes de caractères avec décryptage unique à l'initialisation de l'EA, modification du flux de code, mélange de code, ne pas supprimer le code inutilisé,
ajouter du code et des données inutiles...
Contrôler tout cela avec #pragma.


Terminal
--------
Dans les paramètres, spécifiez un programme ou un script MQL avec des options (et des méta-variables) à appeler avant (et après ?) la compilation (pour un prétraitement personnalisé).


Rédacteur en chef
--------
Opérations de commentaire/dé-commentaire (par bouton et/ou touche de raccourci)
 
1. Faites le testeur dans un programme séparé (comme l'éditeur MQL et le terminal).
2. Réaliser un algorithme génétique plus puissant (pour pouvoir tester un nombre de variantes de 10 à la 20e puissance).
3. Accélérer le processus d'essai. (J'attendrai difficilement 15-30 heures, et ce sera une tâche mortelle !
4. Présentez la fonction d'inversion de position (c'est-à-dire que si vous avez une position d'achat de 5 lots, vous pouvez la convertir en vente de 5 lots).
C'est tout pour le moment.
 

Un autre souhait pour la balançoire à bascule. Il serait bon qu'outre la période d'optimisation, nous puissions spécifier la période de vérification croisée des paramètres trouvés. Cette fonction permet d'éviter de réapprendre le système de négociation (ou le SN).

 
Je veux une fonction. Les données d'entrée sont les données d'optimisation plus une gamme de valeurs retournées. Le résultat est, bien sûr, les valeurs optimisées.
 
klot:

Un autre souhait pour la balançoire à bascule. Il serait bon qu'outre la période d'optimisation, nous puissions spécifier la période de vérification croisée des paramètres trouvés. Cette fonction permet d'éviter de réapprendre le système de négociation (ou le SN).

C'est ce dont nous avons vraiment besoin.
 
Integer:
drknn:
Eh bien, j'ai une modeste suggestion. Je propose d'introduire une fonction dans le langage, qui retournera le nombre de cellules du tableau, où se trouve la valeur donnée (ou en cas d'échec retournera moins un). Sinon, nous devons organiser une boucle à chaque fois. La fonction ArrayBsearch() ne convient pas - elle renvoie une valeur erronée.

La valeur retournée par cette fonction sera toujours vérifiée pour l'égalité -1, donc nous pouvons vérifier la valeur avec l'index retourné par ArrayBsearch pour l'égalité à la valeur désirée. Pas une grande différence

Pour citer la référence.

int ArrayBsearch(...)
Renvoie l'indice du premier élément trouvé dans la première dimension du tableau.
S'il n'y a pas d'élément avec la valeur spécifiée dans le tableau, la fonction retournera l'index de l'élément le plus proche (par valeur).

Eh bien, lorsque vous recherchez l'index non pas d'un simple numéro dans le tableau, mais d'un ticket de la commande, cette fonction ne convient pas du tout - pourquoi ai-je besoin de l'index du ticket similaire le plus proche, alors que j'ai besoin exactement de ce ticket, et s'il est absent, la commande n'est pas parmi celles du marché - elle est fermée et nous devrions la trouver dans l'historique ! Lorsque vous travaillez avec des tableaux à décalage synchrone, l'indice est une chose très importante, et il doit être soit précis, soit non disponible.


12345678910...131
Nouveau commentaire
Raison: