Erreurs, bugs, questions - page 524
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
Par ailleurs, d'après ce que j'ai compris, la fermeture d'une transaction par un stop loss est liée à une transaction perdante dans le rapport de résultats du testeur (où se trouve le pourcentage de transactions perdantes et profitables).
Après la mise à niveau vers la Build 507, j'ai deux problèmes dans le testeur :
1. Pendant l'optimisation, lors du changement d'onglet du testeur, le terminal se bloque occasionnellement (pas toujours) ;
2. Si une énumération a été sélectionnée comme paramètre optimisé, lorsque l'on essaie d'exécuter l'un des résultats de l'optimisation, le conseiller expert ne voit pas la valeur de cette énumération, c'est-à-dire qu'elle est toujours égale à zéro.
Après la mise à niveau vers la Build 507, j'ai deux problèmes dans le testeur :
1. Pendant l'optimisation, lors du changement d'onglet du testeur, le terminal se bloque occasionnellement (pas toujours) ;
2. Si une énumération a été sélectionnée comme paramètre d'optimisation, lorsqu'on essaie de lancer l'un des résultats de l'optimisation, le conseiller expert ne voit pas la valeur de cette énumération, c'est-à-dire qu'elle est toujours égale à zéro.
Veuillez écrire à Servicedesk en donnant le plus de détails possible.
Nous savons qu'il y a un problème avec les énumérations lors de l'optimisation, mais nous ne pouvons reproduire l'erreur d'aucune manière.
J'ai écrit à Servicedesk...
J'ai accepté votre candidature et posé des questions complémentaires
...Et là, la question se pose (rhétorique ?)...
Il y a plusieurs calculs supplémentaires des mêmes valeurs dans l'indicateur, qui donnent bien sûr les mêmes résultats. La solution semble évidente : calculer une fois (lors du premier accès aux données historiques), mettre tout dans le tampon et dans les autres cas, appliquer aux résultats prêts. Mais...
L'indicateur a déjà un nombre énorme de tampons (au moins 10 pour stocker les données calculées de l'historique complet sur plusieurs périodes différentes) - on y accède déjà avec les données correspondantes initialement calculées. Maintenant, dans l'idée et comme option, il est nécessaire de doubler le nombre de tampons.
Bien sûr, tout cela dépend des spécifications matérielles : la puissance de traitement du processeur et la quantité de mémoire. Et c'est lui qui va gagner. Mais considérons le matériel comme très moyen - pas le dernier PC de salon. Ni trop, ni trop peu. Il est difficile de décider tout de suite s'il faut gaspiller de la mémoire ou de la puissance de calcul.
La question à poser à un public averti est donc la suivante : que recommandez-vous ? Peut-être y aura-t-il des arguments pour l'une ou l'autre option... Soit on n'encombre pas la mémoire en doublant les tampons d'indicateurs calculés, et on fait chauffer le processeur en calculant la même chose à chaque fois qu'on en a besoin, ou vice versa ?
Merci.
...Ce qui pose la question (rhétorique ?)...
...Bien entendu, tout repose sur les paramètres techniques du matériel : la puissance du processeur et la quantité de mémoire vive. Et c'est lui qui va gagner. Mais considérons que le matériel est plutôt moyen - pas un PC domestique récent. Ni trop, ni trop peu. Il est difficile de décider tout de suite s'il faut gaspiller de la mémoire ou de la puissance de calcul.
...
...Et là, la question se pose (rhétorique ?)...
Il y a plusieurs calculs supplémentaires des mêmes valeurs dans l'indicateur, qui donnent bien sûr les mêmes résultats. La solution semble évidente : calculer une fois (lors du premier accès aux données historiques), mettre tout dans le tampon et dans les autres cas, appliquer aux résultats prêts. Mais...
L'indicateur a déjà un nombre énorme de tampons (au moins 10 pour stocker les données calculées de l'historique complet sur plusieurs périodes différentes) - on y accède déjà avec les données correspondantes initialement calculées. Maintenant, dans l'idée et comme option, il est nécessaire de doubler le nombre de tampons.
Bien sûr, tout cela dépend des spécifications matérielles : la puissance de traitement du processeur et la quantité de mémoire. Et c'est lui qui va gagner. Mais considérons le matériel comme très moyen - pas le dernier PC de salon. Ni trop, ni trop peu. Il est difficile de décider tout de suite s'il faut gaspiller la mémoire ou la puissance de calcul.
La question à poser à un public averti est donc la suivante : que recommandez-vous ? Peut-être y aura-t-il des arguments pour l'une ou l'autre option... Soit on n'encombre pas la mémoire en doublant les tampons d'indicateurs calculés, et on fait chauffer le processeur en calculant la même chose à chaque fois qu'on en a besoin, ou vice versa ?
Merci.
Sinon, pourquoi ne pas utiliser des bases de données pour vos besoins ? Calculé, enregistré... le temps est venu - extrait sous la forme la plus pratique, utilisez-le.
Sur le plan architectural, la solution permet de séparer le calcul et la mise en cache des résultats.
Sinon, pourquoi ne pas utiliser des bases de données pour vos besoins ? Calculé, enregistré... c'est le temps - extrait sous la forme la plus pratique, utilisez-le.
Sur le plan architectural, la solution permet de séparer le calcul et la mise en cache des résultats.
Je ne le nie pas, mais l'expression "c'est l'heure" semble drôle, étant donné que chaque référence sera rejouée dans OnCalculate à chaque tick. Soit la BD doit se trouver entièrement dans la RAM, soit il faudrait accéder lentement au disque et le réduire en cendres. Bien que... ce que je comprends du SGBD...
Cependant, MQL n'est-il pas un langage de requête pour DB ? Si c'est le cas, il fonctionne déjà avec la base de données du disque et le disque semble être vivant pour le moment. Il n'est pas nécessaire d'inventer quelque chose de nouveau ici.
Si vous voulez parler d'une base de données différente et d'une manière spécifique (non standard) d'y accéder, veuillez expliquer. Si vous avez suggéré d'intégrer l'interaction du MQL5 avec quelque chose d'autre, c'est trop tôt pour moi, car je viens de commencer à étudier le MLQ et je me dirige vers l'allumage avancé...
Très souvent, la connexion au serveur est coupée. Cependant, l'indicateur montre une connexion stable :
Le terminal ne se reconnecte pas. Je dois me connecter manuellement. Est-il possible de faire cela de manière programmatique en utilisant MQL5 ?