Erreurs, bugs, questions - page 2286
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
Quel dossier du Terminal via mklink doit être placé sur le RAMdisk pour que les données soient lues/écrites depuis la mémoire plutôt que depuis le SSD ? Je suis prêt à fournir des données sur la vitesse que cela donnera pendant l'optimisation.
Le dossier du testeur a été déplacé sur undisque RAM de 5 Go et dans le répertoire MT5.
Le SSD dort maintenant paisiblement, l'optimisation est ~1,5 fois plus rapide (à l'œil), et ce gratuitement !
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Bugs, bugs, questions
fxsaber, 2017.01.26 17:33
Le modèle de l'optimiseur étant basé sur les agents, qu'est-ce qui vous empêche de mettre en œuvre une seule exécution déjà passée par un optimiseur qui n'est pas encore terminé ?
Par exemple, en optimisant. Il reste encore quelques heures. Mais je vois déjà des résultats intéressants. Je veux voir quelques bons résultats individuels - à exécuter dans le backtester. Mais en même temps ne pas arrêter d'optimiser (particulièrement pertinent pour les GA). Est-il possible dans cette situation de libérer l'un des agents locaux et de lui envoyer un seul passage ? Et puis continuez à charger cet agent avec des packs d'optimisation.
Maintenant, les études sont bloquées jusqu'à ce que l'optimiseur termine. Et cela prend parfois beaucoup de temps.
Pertinent, malgré d'excellentes caches. Veuillez ouvrir le format des fichiers opt.
Par exemple, pourquoi en ai-je besoin ? J'ai trié ici les résultats de l'optimisation de la rentabilité (PF)
Regardez le nombre de transactions - elles ne veulent statistiquement rien dire : moins de 30. Mais leur IP est hors normes et il y a des centaines/milliers de ces résultats. Alors pourquoi ces déchets figurent-ils dans le tableau ?
Si l'opt-format était ouvert, ces déchets pourraient être automatiquement éliminés, ne laissant que des résultats intéressants plus ou moins statistiquement significatifs.
Que dire du tri personnalisé par plusieurs critères en même temps, etc.
ZZY Il est censé être possible non seulement de lire mais aussi d'écrire soi-même des fichiers opt-files. Et ensuite le transmettre au testeur, car il est déjà implémenté.
Il utilise ainsi tous les avantages de l'interface graphique du testeur pour un cache sans déchets. Pour ce faire, il suffit d'ouvrir l'opt-format.
Lesrésultats de l'optimisation peuvent être triés en fonction de différents critères.
MT5 dispose déjà d'un mécanisme permettant de spécifier des formules de texte pour ce que l'on appelle les formules synthétiques.
Je propose d'utiliser le même mécanisme de formules de texte pour définir des critères de tri arbitraires.
"Tout a déjà été volé avant vous".
Au début de la journée, coche complète. Ensuite, l'offre et/ou la demande et/ou l'offre complète, tout le reste en incréments si disponible. La moyenne est de 10 octets par tic.
Puisque l'accès aux ticks est strictement séquentiel, il n'y a aucun problème pour organiser un accès rapide à chaque élément du tableau.
Oui, vraiment. Super !
Certes, je n'ai fait des recherches que sur les bars. Et j'en ai conclu que c'était la même chose pour les tics. J'avais tort.
Mais ensuite, c'est étrange - pourquoi les barres sont-elles conservées pratiquement sans emballage ?
C'est facile à vérifier : regardez la taille du fichier hcc pour n'importe quelle année, puis comptez le nombre de barres pour cette année avec la fonction Bars. C'est ~42.2 octets par barre de 1 minute. C'est moins que 60, mais clairement redondant.
Le dossier du testeur a été déplacé sur undisque RAM de 5 Go et dans le répertoire MT5.
Le SSD dort maintenant paisiblement, l'optimisation est ~1,5 fois (à vue de nez) plus rapide, gratuit !
Wow, quelle solution simple et inattendue.
Génial ! et Bravo !
un bogue étrange dans la version 1881 du 9 juillet.
Je ne l'ai pas compris tout de suite.
J'ai réduit la fenêtre du terminal, défini tous les paramètres et saisi un dépôt de 100 $.
J'ai ouvert la fenêtre en plein écran et j'ai appuyé sur démarrer. Une heure après avoir optimisé.... Après une heure, j'ai découvert qu'il n'y avait pas 100 dollars mais 10 000 dollars.
Lorsque j'étend le terminal en plein écran, le champ "Dépôt" est réinitialisé à ses valeurs par défaut !
Le même bug apparaît même lorsque l'optimisation est déjà en cours.
Une demande importante dans le testeur est de fermer par Bid/Ask, si le dernier connu est zéro.
Dans la vidéo
Instrument boursier sur ticks réels. Les barres sont construites par Bid, pas de fin-data, BUY position ouverte. On voit clairement que le prix actuel de fermeture de la position
est toujours égal à zéro, malgré le fait que la soumission change de manière significative. Comment expliquer au testeur que le symbole boursier doit fermer la position BUY en utilisant Bid ? Maintenant, même l'équité n'est pas calculée.
Quelle en est la raison ?
Chaque course se termine avec ExpertRemove.
Il n'y a aucune indication sur les raisons de la cessation d'emploi (pas de véritable tic) et, en général, il y a eu une sorte de rupture.
Est-il possible d'informer le journal de ce moment ?