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
Voici le code pour lire à partir d'un fichier :
PourquoiFileReadString() ?
Vous pouvez utiliserFileReadArray(), ainsi vous n'avez pas besoin de faire une boucle.
PourquoiFileReadString() ?
Ne serait-il pas préférable d'utiliserFileReadArray(), ce qui évite d'avoir à faire une boucle.
Rosh:
Écrire les valeurs d'équité dans un fichier. Ensuite, construisez l'indicateur en fonction de ces valeurs. Cependant, le fichier de données doit être déplacé manuellement car, pendant les tests, les fichiers sont écrits dans le dossier Agent_name/MQL5/Files.
Ce n'est que maintenant que je me suis rendu compte à quel point tout est compliqué.
Mais la méthode manuelle n'est clairement pas la solution à ce problème, car nous parlons de centaines de tests.
Et il semblerait qu'au début, les données sont disponibles, mais - oh, Miracle ! - le programme est conçu de telle manière qu'il n'y a aucune possibilité de les sauvegarder d'une manière ou d'une autre et quelque part jusqu'à ce qu'ils soient extraits et utilisés de manière programmatique !
Je ne suis pas un programmeur professionnel, mais cette situation est difficile à comprendre.
Une énorme documentation..., de vastes possibilités pour construire, semble-t-il, tout et n'importe quoi..., la gestion de la mémoire, la POO, et ici, de façon fondamentalement simple et critiquement nécessaire (ce que, j'espère, j'ai déjà expliqué) - une impasse.
...Et pourtant... Question !
N'y a-t-il pas la possibilité d'écrire en mode test dans des tableaux de programmes forcés et presque effaçables, qui pourraient ensuite être utilisés pour construire un indicateur ?
Y compris la possibilité de faire passer par une variable globale un pointeur vers un tel tableau ?
Et quel est le problème du stockage et du transfert des données entre la phase de test et le moment du travail principal, non pas en termes de mise en œuvre actuelle, mais en principe ?
Renat a mentionné des centaines de mégaoctets de données, mais, premièrement, pourquoi devrions-nous toujours recharger les données alors que nous ne pouvons prévoir une telle possibilité qu'à la demande explicite du programmeur et, deuxièmement, la quantité de données en termes de la tâche à accomplir est beaucoup plus petite et s'élève à quelques milliers de chiffres.
Une fois de plus, je déclare que du point de vue de l'utilisateur, l'option de transfert manuel des fichiers pendant les tests multiples (et le marché, en raison de sa complexité, nécessite des tests multiples) est absolument gênante et peu prometteuse, alors que je suis prêt à discuter avec quiconque que la dynamique des indicateurs de compte en corrélation directe avec la dynamique des prix dans l'historique des tests est l'une des plus importantes en général.
Qu'en est-il de l'extension de la visibilité dans le mode principal des opérations d'ouverture des fichiers en mode lecture au dossier des fichiers du testeur ? Quelle serait la menace même hypothétique dans ce cas ?
Et quel est le problème de ne pas pouvoir forcer le stockage des données requises entre le mode principal et le mode test dans la RAM ?
Utilisez le DLL pour écrire et lire des fichiers à partir de dossiers arbitraires sur le disque. Il suffit de déplacer les fonctions d'écriture et de lecture de fichiers dans la dll et le tour est joué.
...Et pourtant... Question !
N'y a-t-il pas la possibilité d'écrire en mode test dans certains tableaux de programmes à étroitesse forcée, qui pourraient ensuite être utilisés pour construire un indicateur ?
Essayez de définir l'indicateur FILE_COMMON lors de l'ouverture du fichier - https://www.mql5.com/ru/docs/constants/io_constants/fileflags
Identifiant
Valeur
Description
FICHIER_COMMON
4096
Emplacement d'un fichier dans le dossier partagé de tous les terminaux clients. Cet indicateur est utilisé lors de l'ouverture de fichiers (FileOpen()), la copie de fichiers (FileCopy(), FileMove()) et la vérification de l'existence de fichiers (FileIsExist()).
Essayez de spécifier l'indicateur FILE_COMMON lors de l'ouverture d'un fichier - https://www.mql5.com/ru/docs/constants/io_constants/fileflags
Exécutez ce script et voyez où il écrit
joo, Rash, merci !
L'option du dossier partagé semble plus... intégré.
La seule chose qui surprend est que lors de l'exécution de ce code, un message concernant l'échec de l'écriture s'affiche dans l'indicateur, bien que l'écriture elle-même soit toujours effectuée. De plus - toujours une question ouverte comment et quand exactement il est préférable d'écrire les données (séparément pour chaque tick, mais c'est gourmand en ressources, ou à la toute fin - le tableau entier, mais avec l'écriture du tableau quelque chose n'est pas encore tout à fait clair et, en outre, il est difficile de comprendre comment OnCalculated fonctionnera dans ce cas pour son extraction - dans le second, il s'avère le passage déjà après le test ?)
Et une autre question, quelque peu hors sujet, mais sur la question déjà abordée hier.
Inséré dans OnTick et dans OnCalculated :
mais après l 'achèvement du test, malgré la présence d'objets liés aux positions d'ouverture et de fermeture (flèches et lignes - visibles dans Terminal : Charts>Objects>Objects List), la valeur de retour est 0 pour une raison quelconque.Il est préférable d'écrire dans le fichier aussi rarement que possible, et donc de le faire sous forme de tableau d'entiers. Les valeurs ne doivent pas être mesurées plus d'une fois par minute, sinon leur affichage sur le graphique posera des problèmes (sans compter que cela consommera beaucoup de ressources). C'est-à-dire, à la fin de la course. Mais c'est aussi possible :
L'algorithme se présente comme suit :
1) Exécuter l'expert dans le testeur.
2) Mesuré la valeur de l'intérêt.
3) Enregistré la valeur dans le fichier.
4) Écrire vrai dans un fichier séparé, ce qui signifie que nous avons enregistré une nouvelle valeur.
5) Démarrer une boucle infinie, la condition de sortie est fausse dans le fichier flag.
6) Dans un graphique séparé, le script lit le fichier avec le drapeau, s'il y a une nouvelle valeur, dessine un risque sur le graphique, écrit false dans le fichier.
Voici en gros à quoi ressemblera le mode visuel des tests dans le testeur.
Attendez un peu, le concours sera terminé, peut-être que des solutions plus élégantes et plus belles seront présentées.
joo, Rash, merci !
L'option du dossier partagé semble plus... intégré.
La seule chose surprenante est qu'en exécutant ce code dans l'indicateur, un message d'échec d'écriture s'affiche, bien que l'écriture elle-même soit effectuée.
Je ne reçois aucune de ces données. Essayez-le :
Je ne comprends rien à tout ça. Vous devriez essayer :
Rosh
Je ne comprends pas la raison, mais contrairement à mes indicateurs, lorsque je les démarre avec les vôtres, j'obtiens un message :Maintenant, j'ai fait un Conseiller Expert simple similaire, basé sur votre code, qui devrait écrire toutes les valeurs d'équité dans le fichier (j'ai changé seulement la sortie de toutes les valeurs, y compris les octets zéro écrits, rendu les variables globales, et divisé l'ouverture et l'écriture du fichier en OnInit et OnTick), mais bien qu'aucune erreur ne soit écrite et que le fichier soit créé, les enregistrements et le fichier sont vides.