Sujet intéressant pour beaucoup : les nouveautés de MetaTrader 4 et MQL4 - de grands changements en perspective - page 23
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
C'est juste l'ignorance d'Algotrader pour stocker le spread de la barre. Ils ne le remplaceraient que par Low_Ask. Et la précision aurait été considérablement améliorée.
J'en doute. Low_Ask pourrait être à n'importe quel moment de cette période, à cet égard, les diables sont les mêmes.
Question suivante pour tout le monde : comment est calculé l'écart historique utilisé par le testeur ?
J'en doute. Low_Ask peut se trouver à n'importe quel endroit de ce segment, à cet égard, la bite est la même que la bite.
Il ne s'agit pas d'une histoire de tique super précise. Pour presque tous les TC, l'exécution avec M1_Bid+Ask et l'historique des tics donnera un écart misérable. Il est très stupide de dépenser d'énormes quantités de temps et de ressources informatiques pour le plaisir de le faire.
En tant que praticien, pour presque tous les CTs, l'historique M1_Bid+Ask est plus que suffisant. Et il importe peu que l'OHLC Bid soit antérieur ou postérieur à l'OHLC Ask.
L'ajout de l'historique des demandes au testeur se fait en deux lignes pour les développeurs. Il n'affecte en rien la vitesse des tests. Seulement la précision s'améliore et de nombreuses régularités du marché apparaissent. La rentabilité des TS est ajustée de manière plus précise et devient même plus rentable qu'elle ne le serait si elle était ajustée sur un simple historique des offres.
Question suivante : comment est calculé l'écart historique utilisé par le testeur ?
Il ne peut y avoir de rancune. Respectons nous les uns les autres. Quelqu'un fait quelque chose d'utile pour les autres pour des raisons purement idéologiques. Arrêtez de vous taire.
Ce n'est pas drôle d'avoir l'impression d'être un idiot que personne ne comprend. C'est une déception totale d'être écouté juste à cause de quelques pourcentages stupides montrés quelque part.
Il doit y avoir une logique. Il y a des gens qui parlent logiquement, ne les dénigrez pas sans comprendre.
Si quelqu'un ne comprend pas l'importance de l'histoire de l'ascension, il suffit de dire qu'il ne la comprend pas. Ne commencez pas à dire que ce n'est pas nécessaire.
Si quelqu'un ne comprend pas que les méta-testers sont nuls en matière de précision - encore une fois, dites que vous ne comprenez pas.
Peut-être que quelqu'un viendra vous expliquer le raisonnement, et vous comprendrez enfin.
Mais les praticiens qui se taisent sont des connards paresseux, c'est un euphémisme. Seul un petit nombre d'entre eux disposent de leur propre infrastructure de recherche. Tous les autres testent stupidement tout sur des métathéâtres bruts, passant ainsi à côté d'un grand nombre de modèles de marché simples.
Oui nous avons tout compris, vous ne comprenez pas que le testeur n'est pas fait pour tester le HFT. Et ce n'est pas l'histoire qui va arranger ça.
Pour ces algorithmes dont vous parlez, vous devez immerger MT complètement dans un environnement virtuel avec un serveur DC virtuel, et tout tester sur l'historique sauvegardé du tumblr.
Je ne sais plus quand j'ai dit que ce testeur n'est pas pour les programmeurs, pas pour vérifier l'exactitude de l'algorithme, et certainement pas pour le HFT, mais pour une estimation approximative du TC.
Quant à moi, au lieu d'un testeur, nous pourrions créer quelque chose comme UML pour vérifier les stratégies et c'est tout, ce serait suffisant. Vous pouvez calculer sur le genou dans l'indicateur où vous ouvrez à quel prix et où vous fermez la somme, et tout cela sur un historique de 10 ans pendant 1,5 seconde.
Quoi qu'il en soit, vous aurez beau gratter ce testeur, vous ne croirez pas que toutes les fonctionnalités "Événements, objets graphiques et toute autre nouvelle fonction" n'échoueront pas.
D'où la morale, nous avons un testeur fonctionnel, qui coûte une tonne de temps (lisez de l'argent), qui satisfait 99% des utilisateurs, et seulement 1% n'est pas satisfait. Oui, le pourcentage le plus avancé, mais toujours 1%. Et ce pourcentage tente de convaincre qu'en chargeant le testeur du traitement de données supplémentaires et, par conséquent, en réduisant la vitesse de moitié, il y aura un gain de précision.
Il n'y aura pas ce gain, pourquoi j'ai écrit ici.
Qu'est-ce que le HFT ? J'ai gagné presque tout mon argent avec mon testeur, que j'ai construit sur mes genoux en un jour ou deux, et qui utilise le principe des "prix de clôture" avec l'historique des offres et des demandes en M1.
Et c'est grâce à ce testeur que mes résultats sont beaucoup plus solides que ceux des autres, même avec des idées plus avancées. La raison en est simple. Tu prends une idée et les métatesters montrent que ça ne marche pas, putain.
Et mon testeur montre que cela fonctionne. C'est tout. Certaines personnes gagnent de l'argent, d'autres continuent à chercher.
Parfois, c'est le contraire qui se produit : les métatesters montrent que l'idée fonctionne, alors que mon testeur ne le fait pas. Au final, l'utilisateur trompé, dans le pire des cas, se vide de son argent.
...
Pour moi, il était possible de créer quelque chose comme UML pour les stratégies de test au lieu de tester ...
...
Je suis sérieux, après des années j'ai réalisé que pour vérifier le TS il faut un calcul très simplifié où vous avez ouvert où vous avez fermé sur quel signal, tout est très léger et aussi rapide et simple que possible.
Pas besoin d'émuler l'exécution, tout est testé sur des démos et des micro-réalisations.
Mais la fonctionnalité des statistiques intégrées pourrait être vraiment délicate, en commençant par les réseaux neuronaux intégrés et en terminant par la formulation d'hypothèses statistiques. Un tel testeur serait un véritable coup de feu dans l'arsenal.
Vous connaissez très bien mon opinion sur l'histoire de l'asc, et elle n'est pas négative, ce que j'ai d'ailleurs souligné dans ce fil, seulement ci-dessus. A propos du testeur, je suis également silencieux, montrez-moi où j'exprimerais ma pleine satisfaction à son égard. Je suis juste un partisan des solutions réelles, pas des grands rêves. Parce que le "si seulement" peut attendre longtemps, presque indéfiniment.
Oui, il n'est pas question d'une histoire de tique super précise. Pour presque tous les CTs, une exécution sur M1_Bid+Ask et sur l'historique des ticks donnera un écart négligeable. Il est très stupide de dépenser d'énormes quantités de temps et de ressources informatiques pour le plaisir de le faire.
En tant que praticien, pour presque toutes les CU, l'historique M1_Bid+Ask est plus que suffisant. Et peu importe quelle offre OHLC se trouvait avant ou après la demande OHLC.
L'ajout de l'historique des demandes au testeur se fait en deux lignes pour les développeurs. Il n'affecte en rien la vitesse des tests. Seulement la précision s'améliore et de nombreuses régularités du marché apparaissent. La rentabilité des TS est ajustée plus précisément et devient même plus rentable que si elle était ajustée sur un simple historique des offres.
Chez le testeur, la notion de propagation ne devrait pas exister du tout.Oui, je suis d'accord dans ce contexte.
La raison pour laquelle les prix Ask sont si défavorisés est triviale et absurde, ils ne sont pas moins importants que les prix Bid.
Je suis sérieux, après des années j'ai réalisé que pour vérifier le TS il faut un calcul très simplifié de où vous avez ouvert où vous avez fermé sur quel signal, tout est très léger et aussi rapide et simple que possible.
Vous n'avez pas besoin d'émuler l'exécution, tout est testé sur les démos et les micro-recettes.
Mais la fonctionnalité des statistiques intégrées pourrait vraiment être améliorée, en commençant par les réseaux neuronaux intégrés et en terminant par les hypothèses statistiques. Un tel testeur serait un véritable coup de feu dans l'arsenal.
N'oubliez pas qu'il existe des TS "subtiles", qui ne se construisent pas uniquement sur le croisement des lingettes et autres bêtises.
Il ne s'agit pas d'une histoire de tique super précise. Pour presque toutes les barres de M1_Bid+Ask et l'historique des tics donnera une déviation misérable. Il est très stupide de dépenser d'énormes quantités de temps et de ressources informatiques pour le plaisir de le faire.
En tant que praticien, pour presque toutes les CU, l'historique M1_Bid+Ask est plus que suffisant. Et peu importe quelle offre OHLC se trouvait avant ou après la demande OHLC.
L'ajout de l'historique des demandes au testeur se fait en deux lignes pour les développeurs. Il n'affecte en rien la vitesse des tests. Seulement la précision s'améliore et de nombreuses régularités du marché apparaissent. La rentabilité des TS est ajustée plus précisément et devient même plus rentable que si elle était ajustée sur un simple historique des offres.
Chez le testeur, la notion de propagation ne devrait pas exister du tout."C'est comme ça que c'était ici avant les Soviets"(c).
Tout ce que vous dites est dans MT5, il y a la comptabilité Ask, elle (Ask) peut être reçue à tout moment, les niveaux correspondants sont déclenchés par Ask.
Oui, le prix est calculé à partir de l'enchère et de l'écart, et quelle est la différence si vous ne vous souciez pas de ce qu'était l'enchère la plus basse ou l'enchère la plus haute auparavant ?