Un robot sans indicateurs - page 6
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
Il existe des indicateurs qui déterminent... pas une tendance ou un plat... ils n'existent pas à l'état pur de toute façon. Ils déterminent l'avantage des forces à l'achat ou à la vente en général dans un sens ou dans l'autre. Vous ne pouvez pas le déterminer avec vos yeux. Car ce n'est pas la direction du prix qui compte, mais le degré d'entropie (caractère aléatoire) du prix. En fait, ces indicateurs sont en quelque sorte des inventions, c'est pourquoi ils ne sont pas populaires, bien sûr, j'en ai quelques uns développés sur demande dans une communication personnelle. Je ne pourrai pas déterminer la tendance a priori. Mais un appartement est tout à fait possible. Puisque l'aléatoire existe environ 98% du temps sur le marché.
Un plat n'existe pas 98% du temps, il existe exactement tant qu'il y a une tendance. Le marché passe d'une tendance à un plat, la loi de distribution fluctue mais ne devient jamais une distribution normale. Si le plat était 98% du temps, il serait trop facile de gagner de l'argent dessus.
Un plat n'existe pas 98% du temps, il existe tant qu'il y a une tendance. La nature du marché passe de tendance à plat, la loi de distribution fluctue autour de la normale, mais ne le devient jamais. Si un appartement était utilisé 98% du temps, il serait trop facile de gagner de l'argent avec.
1. Faites attention à vos émotions.
Vous savez, vous me rappelez la catégorie de personnes qui demandent une preuve et qui, après avoir présenté cette preuve, disent ce qui suit : "votre preuve, pas....".
Que puis-je dire à ce "ne dit que sur un code indicateur non-optimal", vous avez raison, dans votre compréhension le code optimal est... Je ne veux même pas deviner ce que c'est.
Peut-être avez-vous manqué quelque chose, mais j'ai initialement écrit que mettre toute la logique dans le code du Conseiller Expert n'est pas une bonne solution si un nombre N d'instruments est ouvert et chargé dans le terminal, car à mon avis la tâche du Conseiller Expert est de gérer les ordres dans le temps.
Ce que j'ai montré, et vous avez commenté "à propos du code d'indicateur non-optimal" (je ne dis pas le contraire), à condition que quelques instruments soient ouverts et quelques bots et indicateurs, je ne vois pas de tels décalages, c'est-à-dire, si nous suivons votre logique, à propos du code "optimal", les messages comme"l'indicateur est trop lent" n'apparaîtront jamais, si 10 ou plus d'instruments sont ouverts, y croyez-vous sérieusement ?
D'après mon expérience personnelle, je suis arrivé à la conclusion que tous les calculs "lourds" devraient être effectués dans un programme séparé afin de ne pas observer des décalages similaires, et que le MQL devrait être chargé des ordres de service basés sur les commandes reçues du programme qui n'affecte pas directement le moteur MQL et sa productivité. En fait, je suis en train de le faire.
En fait, je n'ai rien à prouver, puisque vous ne l'avez pas rencontré, alors.. :
1. Vous êtes un dieu dans le monde de la programmation :) ;
2. Tu n'as juste pas encore écrit quelque chose de sérieux.
3. Vous ne faites que vous évaluer vous-même avec vos hacks.
Vous savez, vous me rappelez la catégorie de personnes qui demandent une preuve et qui, après avoir présenté cette preuve, disent ce qui suit : "votre preuve, pas la preuve....".
Que puis-je dire à ce "ne parle que d'un code indicateur non optimal", vous avez raison, dans votre compréhension le code optimal est... Je ne veux même pas deviner ce que c'est.
Peut-être avez-vous manqué quelque chose, mais j'ai initialement écrit que mettre toute la logique dans le code du Conseiller Expert n'est pas une bonne solution si un nombre N d'instruments est ouvert et chargé dans le terminal, car à mon avis la tâche du Conseiller Expert est de gérer les ordres dans le temps.
Ce que j'ai montré, et vous avez commenté "à propos du code d'indicateur non-optimal" (je ne prétends pas le contraire), à condition que quelques instruments et quelques bots et indicateurs soient ouverts, je ne vois pas de tels décalages, c'est-à-dire, si nous suivons votre logique, à propos du code "optimal", des messages comme"l'indicateur est trop lent" n'apparaîtront jamais, si 10 instruments ou plus sont ouverts, y croyez-vous sérieusement ?
D'après mon expérience personnelle, je suis arrivé à la conclusion que tous les calculs "lourds" devraient être effectués dans un programme séparé afin de ne pas observer des décalages similaires, et que le MQL devrait être chargé des ordres de service basés sur les commandes reçues du programme qui n'affecte pas directement le moteur MQL et sa productivité. En fait, je suis en train de le faire.
En fait, je n'ai rien à prouver, puisque vous ne l'avez pas rencontré, alors.. :
1. Vous êtes un dieu dans le monde de la programmation :) ;
2. Tu n'as juste pas encore écrit quelque chose de sérieux.
3. Vous ne faites que vous évaluer avec vos détracteurs.
Un plat n'existe pas 98% du temps, il existe tant qu'il y a une tendance. La nature du marché passe de tendance à plat, la loi de distribution fluctue autour de la normale, mais ne le devient jamais. Si un appartement était utilisé 98% du temps, il serait trop facile de gagner de l'argent avec.
Au cas où vous n'auriez pas remarqué... "plat+aléatoire". C'est ce qui constitue 98% du temps.
Et les tendances... ne sont que des aberrations... des anomalies du marché... elles se produisent rarement, comme le Brexit au Royaume-Uni. Bien sûr, il y avait là une véritable tendance à la vente.
Ces "tendances" ne peuvent être détectées sans une liaison à haut débit avec l'échange. Il y a aussi un outil mathématique à inventer. Et attention, personne ne le dit ici, mais la tendance elle-même peut aussi être aléatoire =) Cela semble absurde, mais cela ne cesse pas d'être vrai).
Au cas où vous n'auriez pas remarqué... "plat+aléatoire". C'est ce qui constitue 98% du temps.
Et les tendances... ne sont que des pics... des anomalies du marché... elles se produisent rarement, comme le Brexit au Royaume-Uni. Bien sûr, il y avait là une véritable tendance à la vente.
Ces "tendances" ne peuvent être détectées sans une liaison à haut débit avec l'échange. Il y a aussi un outil mathématique à inventer. Et attention, personne ne le dit ici, mais la tendance elle-même peut aussi être aléatoire =) Cela semble absurde mais cela ne cesse pas d'être vrai).
Laissez-moi vous expliquer d'une autre manière. Si la probabilité de renversement est de 50 %, alors il ne s'agit pas d'une tendance ni d'un plat, mais le prix bougera quand même quelque part. Dans ce cas, le graphique aura une distribution de probabilité normale (comme un processus aléatoire). Mais sur le marché, la probabilité d'un retournement est le plus souvent inférieure à 50% pour une tendance, ou supérieure à 50% pour un repli. Mais si elle est prise sur une longue période, la probabilité de renversement est d'environ 50%. Le marché fluctue donc autour de cette valeur. Je parle ici du forex et des 28 paires principales. C'est un peu différent sur le fonds.
Vous savez, vous me rappelez la catégorie de personnes qui demandent une preuve et qui, après avoir présenté cette preuve, disent ce qui suit : "votre preuve, pas la preuve....".
Que puis-je dire à ce "ne parle que d'un code indicateur non optimal", vous avez raison, dans votre compréhension le code optimal est... Je ne veux même pas deviner ce que c'est.
Peut-être avez-vous manqué quelque chose, mais j'ai initialement écrit que mettre toute la logique dans le code du Conseiller Expert n'est pas une bonne solution si un nombre N d'instruments est ouvert et chargé dans le terminal, car à mon avis la tâche du Conseiller Expert est de gérer les ordres dans le temps.
Ce que j'ai montré, et vous avez commenté "à propos d'un code d'indicateur non-optimal" (je ne prétends pas le contraire), à condition que quelques instruments et quelques bots et indicateurs soient ouverts, je ne vois pas de tels décalages, c'est-à-dire, si nous suivons votre logique, à propos du code "optimal", des messages comme"l'indicateur est trop lent" n'apparaîtront jamais, si 10 instruments ou plus sont ouverts, y croyez-vous sérieusement ?
D'après mon expérience personnelle, je suis arrivé à la conclusion que tous les calculs "lourds" devraient être effectués dans un programme séparé afin de ne pas observer des décalages similaires, et que le MQL devrait être chargé des ordres de service basés sur les commandes reçues du programme qui n'affecte pas directement le moteur MQL et sa productivité. En fait, je suis en train de le faire.
En fait, je n'ai rien à prouver, puisque vous ne l'avez pas rencontré, alors.. :
1. Vous êtes un dieu dans le monde de la programmation :) ;
2. Tu n'as juste pas encore écrit quelque chose de sérieux.
3. Vous ne faites que vous évaluer vous-même avec vos hacks.
Apprenez à écrire du code correctement. Vous ne pouvez vous en prendre qu'à vous-même pour vos retards. Cela fait plus de 10 ans que je suis ici, et je n'ai écrit qu'un seul indicateur avec un tel message. Cependant, je l'ai corrigé moi-même.
Bien sûr, j'ai beaucoup de votre expérience...
Mais donnez-moi s'il vous plaît le code de l'indicateur qui accroche votre fil.
Vous savez, vous me rappelez la catégorie de personnes qui demandent une preuve et qui, après avoir présenté cette preuve, disent ce qui suit : "votre preuve, pas la preuve....".
Que puis-je dire à ce "ne parle que d'un code indicateur non optimal", vous avez raison, dans votre compréhension le code optimal est... Je ne veux même pas deviner ce que c'est.
Peut-être avez-vous manqué quelque chose, mais j'ai initialement écrit que mettre toute la logique dans le code du Conseiller Expert n'est pas une bonne solution si un nombre N d'instruments est ouvert et chargé dans le terminal, car à mon avis la tâche du Conseiller Expert est de gérer les ordres dans le temps.
Ce que j'ai montré, et vous avez commenté "à propos du code d'indicateur non-optimal" (je ne dis pas le contraire), à condition que quelques instruments soient ouverts et quelques bots et indicateurs, je ne vois pas de tels décalages, c'est-à-dire, si nous suivons votre logique, à propos du code "optimal", les messages comme"l'indicateur est trop lent" n'apparaîtront jamais, si 10 ou plus d'instruments sont ouverts, y croyez-vous sérieusement ?
D'après mon expérience personnelle, je suis arrivé à la conclusion que tous les calculs "lourds" devraient être effectués dans un programme séparé afin de ne pas observer des décalages similaires, et que le MQL devrait être chargé des ordres de service basés sur les commandes reçues du programme qui n'affecte pas directement le moteur MQL et sa productivité. En fait, je suis en train de le faire.
En fait, je n'ai rien à prouver, puisque vous ne l'avez pas rencontré, alors.. :
1. Vous êtes un dieu dans le monde de la programmation :) ;
2. Tu n'as juste pas encore écrit quelque chose de sérieux.
3. Tu te fais juste une place dans le classement avec tes piratages.
Réponse :
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Mon robot sans indicateurs
Artyom Trishkin, 2018.09.27 15:42
Je pense que c'est tout à fait correct (tolérant), l'exemple de calcul de l'indicateur entier, et une partie optimisée de celui-ci, l'optimisation donne un gain de 1-2 ordres de grandeur :
Si toutes les barres sont recalculées à chaque tick (probablement 99% de kodobase), vous obtiendrez un message concernant un indicateur lent. L'appel à icustom calcule toutes les barres.
Apprenez à écrire le code correctement. Vous n'avez que vous-même à blâmer pour vos freins. Cela fait plus de 10 ans que je suis ici, et je n'ai écrit qu'un seul indicateur avec un tel message. Cependant, je l'ai corrigé moi-même.
Bien sûr, j'ai beaucoup d'expérience dans ce domaine...
Mais s'il vous plaît donnez moi le code de l'indicateur qui accroche votre fil.
Tu ne comprends pas...
C'est triste... Il y a juste un algorithme, que vous traitez, et il y a une analyse d'une grande quantité de données, et peu importe comment vous optimisez votre code, vous ne pouvez pas y échapper, comme exemples je cite les mineurs, vous pensez qu'il y a un problème de code, que vous avez besoin de méga-ordinateurs ????.
Donc, je t'ai juste prévenu dans mon post, alors que tu essayais de faire le malin. C'est la fin de la discussion, cela n'a aucun sens.