Erreurs, bugs, questions - page 2875
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
J'ai le même aspect de terminal que vous sur WinDin anglais, j'ai donc conseillé de regarder les paramètres
Votre langue par défaut est le russe ? - Si oui, alors je ne sais pas pourquoi le terminal ne voit pas les paramètres
La langue est oui, c'est du russe. Et tous les terminaux une telle chose.
J'ai trouvé la solution)))
Les paramètres du terminal étaient en quelque sorte réglés sur l'arabe.
Contradiction :
Supposons qu'il existe une différence fondamentale entre (*) et (**) - permettant de compiler (3) sans erreur, mais alors quelle est la différence fondamentale entre (3) et (4) ?
Attendu : même comportement du compilateur en (1) et (3) et même comportement en (3) et (4).
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
Bugs, bugs, questions
A100, 2020.08.31 15:55
Sur un graphique (en particulier EURUSD) avec des délais mensuels et hebdomadaires, le réticule se déplace très lentement en suivant le curseur - pour le lire, il suffit de déplacer le curseur en douceur le long de la diagonale...
Jouez comme suit :
Sur le graphique quotidien EURUSD (MetaQuotes-Demo), via l'onglet Calendrier, ajoutez des événements pour le mois précédent, le mois en cours et le mois suivant (il y a environ 1400 objets). Après l'ajout spécifié, le graphique commence à ralentir au point qu'il est difficile de déplacer le réticule et les lignes de tendance.
Si l'on supprime tous les objets OBJ_EVENT, le décalage disparaît.
Contradiction :
Supposons qu'il existe une différence fondamentale entre (*) et (**) - permettant de compiler (3) sans erreur, mais alors quelle est la différence fondamentale entre (3) et (4) ?
Attendu : le même comportement du compilateur en (1) et (3), ou en (3) et (4).
Oui, il y a une contradiction pour ArrayResize, nous la résoudrons dans la prochaine mise à jour de la syntaxe du langage.
(1) et (3) sont des cas différents, dans le premier - la mémoire pour le tableau fait partie de l'objet constant, dans le second non, l'objet tableau lui-même est constant, mais ses éléments ne le sont pas.
Erreur critique pendant l'exécution
Résultat : échec du chargement de l'EX5
Merci pour votre message. Corrigé.
Pourquoi est-il impossible d'effectuer une optimisation dans le testeur ?
de -2147483648 à 2147483647 par incréments de 1 ?
ZS : en général, je ne suis pas intéressé par le pourquoi, mais par la façon de faire de l'optimisation génétique pour une valeur de 32 bits, dans le code EA bit par bit des paramètres d'entrée que j'utilise, c'est-à-dire que je veux pouvoir optimiser de -2147483648 à 2147483647 par incréments de 1 ?
ZS : en général, la question intéressante n'est pas de savoir pourquoi, mais comment faire de l'optimisation génétique pour une valeur de 32 bits, dans le code EA les paramètres d'entrée sont utilisés bit par bit, c'est-à-dire que je veux pouvoir optimiser de -2147483648 à 2147483647 par pas de 1 ?
Je sais combien de passages il faut pour optimiser
la question n'est pas le nombre de passes ( - je n'espère pas passer toutes les passes un jour )
la question est la suivante : je limite mon algorithme aux contraintes du testeur - je définis l'étape 2 - alors oui, tout fonctionne (les paramètres mineurs (les derniers bits) peuvent également être exécutés avec une telle étape dans GA).
UPD :
étrange comment fonctionne la restriction dans les paramètres d'entrée :
J'ai mis de -2147483648 à 0 avec l'étape 2 - OK
réglé de -2147483648 à 0 par pas de 1 - ne me laisse pas optimiser
réglé de -2147483648 à 2147483645 par pas de 2 - OK
passer de -2147483648 à 2147483645 par incréments de 1 - n' optimise pas
Je sais combien de passes d'optimisation il y a
Variable Num dans la source.
Variable Num dans la source.
c'est-à-dire que la restriction ne concerne que l'ancien ushort ?
OK, merci, je vais le corriger chez moi.
ZS : mais je pense que ce n'est pas la bonne limite, l'optimiseur devrait optimiser tous les paramètres possibles dans les limites de la précision du type de données, ce n'est pas son "mal de tête" - est-ce trop ou pas assez ?