Arbitrage - page 19
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
Puis-je demander, juste par curiosité, quelles méthodes sont utilisées pour évaluer l'efficacité du code source ?
Je prépare un article à ce sujet depuis un certain temps déjà. C'est exactement de cela qu'il s'agit, c'est-à-dire des Grails mécaniques et semi-mécaniques à 90-95% qui apparaissent périodiquement sur les forums de commerçants. Il y a quelques semaines, je pensais qu'il pourrait déjà être publié, mais récemment, grâce à Rosh, j'ai constaté des problèmes inattendus et j'ai décidé de freiner l'article pour le moment. Dans 2 ou 3 mois, j'espère pouvoir le reprendre et le terminer enfin (j'aimerais le croire). Cette "longue construction" est entièrement basée sur mes propres recherches et l'article progresse donc lentement. Je ne voudrais pas donner un produit trop grossier. Mais je peux déjà le dire en toute confiance : l'article sera très pessimiste.
J'ai besoin du code source pour voir réellement comment le système de trading génère des signaux. Bien sûr, vous ne pouvez pas le voir dans une boîte noire. Et même les résultats les plus optimistes des tests de la boîte noire ne me convaincront pas plus de la qualité du système que l'étude du code source.
Je n'ai jamais pu comprendre la raison du succès frénétique de ce conseiller.
Je ne suis pas assez compétent pour argumenter sur l'arbitrage-non arbitrage et je ne suis pas assez confiant
pour prouver aux professionnels qu'un autre graal a été trouvé.
Je continue à tester la toute première version pour voir comment elle va mourir.
En même temps, j'applique des filtres d'entrée au code avec mes petites mains maladroites et je le teste aussi sur des programmes de démonstration.
Par exemple, la variante n°7 a augmenté mon dépôt de 2586$ depuis le 17.04, aujourd'hui mon profit par les positions ouvertes est de +210$ (les valeurs actuelles ont atteint +1200).
Et j'ai de grands espoirs en vous, cher Mathemat, car je ne sais pas, par exemple, comment tester correctement le conseiller expert finalisé.
Les résultats sont bons sur la démo et je peux attendre sa chute et ensuite j'ai peur de l'utiliser sur le trading réel mais je regrette de le jeter.
Pour prendre une décision, nous avons besoin d'une méthodologie de test.
Je prépare un article à ce sujet depuis un certain temps déjà. C'est exactement de cela qu'il s'agit, c'est-à-dire des 90 à 95 % de Grails mécaniques et semi-mécaniques qui apparaissent périodiquement sur les forums de commerçants.
Eh bien, vous avez besoin du code source afin de voir réellement comment les signaux sont générés dans un système de trading. Bien sûr, on ne peut pas le voir dans une boîte noire. Et même les résultats les plus optimistes des tests de la boîte noire ne me convaincront pas plus de la qualité du système que l'étude du code source.
Et j'ai de grands espoirs pour vous, cher Mathemat, car je ne vois pas très bien comment, par exemple, tester correctement une EA finalisée.
maksaa a écrit : Et je voudrais aussi remettre en question la nécessité d'utiliser des indicateurs et des conseillers "compliqués" dans le trading. Est-ce vraiment nécessaire ? Quelle est la probabilité qu'une erreur fatale ne se glisse pas derrière la complexité des formules ?
Montrez-moi un exemple de système "simple", réellement stable et rentable - et je serai d'accord avec vous. Mais veuillez noter que je suis extrêmement sceptique quant à de telles "preuves" de sa stabilité comme les résultats de tests sur l'historique et même l'optimisation. Le seul point de vue dans lequel je suis prêt à le considérer est son code source ouvert. Demandez à kompostera, qui a écrit 300 EA personnalisés, ou à Rosha, qui semble avoir expérimenté tout ce qui existe sous ce soleil. Les outils originaux sont peut-être "simples", mais leur interprétation (c'est-à-dire les signaux) ne l'est pas.Je pense que le Barispolz SC est un système stable, vous devez en avoir entendu parler. Il me semble aussi que le système de Reshetov sera stable, lorsque chacun s'y mettra à son niveau.
Lorsque vous écrirez un article, faites-le moi savoir ici.
Si je comprends bien, vous pouvez analyser ce code pour conclure que le système est stable et robuste, et vous n'avez même pas besoin de le tester ?
Je n'ai pas de critères univoques et globaux en matière de durabilité. Il n'existe que quelques hypothèses sur les conditions nécessaires de la stabilité ("si un système est stable, alors il a telle ou telle propriété"). Mais aucune d'entre elles n'est suffisante ("si le système possède cette propriété, le système est stable").
Par exemple, j'ai pris une BD de citations d'une minute et j'ai réécrit le code de Reshetov dans Builder pour avoir une image objective des événements. Mais même en étudiant la minutie des événements, je constate que je perds encore beaucoup d'informations. Et le résultat du test ne sera qu'estimé et préliminaire.
Ainsi, votre article sera effectivement intéressant.
Salutations, Fed.
Le fait qu'il soit instable lorsqu'il ne travaille qu'avec une seule paire donnée est évident d'après les résultats des tests publiés par l'auteur lui-même. Mais cela ne signifie pas nécessairement qu'une combinaison de systèmes instables ne deviendra pas stable.
P.S. Eh, Yuri, quel style tu as. Était-il vraiment si difficile de diviser un énorme start() en plusieurs petits blocs logiquement fermés ? C'est 172 cordes sanglantes...
P.P.S. Yuri, cela vous dérangerait-il que j'intègre soudainement l'analyse de votre conseiller expert dans mon article ? Je ne garantis pas que cette analyse sera nécessairement intégrée à l'article, mais cette possibilité existe. Il n'y aura pas de jurons dans votre direction, ne vous inquiétez pas. Mais si l'analyse porte un jugement sur l'EA, ne soyez pas désolé... Si vous ne voulez pas répondre sur le forum, écrivez à mon adresse postale, elle se trouve dans mon profil.
En fait, je suis sincèrement contrarié par le fait que la publication de l'article sera probablement encore retardée. Je vous suggère de publier d'abord la partie 1 - sans test multivariable, puis les suivantes. Franchement, il y a une grande pénurie de packs compétents sur ce sujet. Personnellement, j'avance maintenant sur ma propre culpabilité lors du développement d'un testeur. C'est-à-dire que j'ai de l'expérience dans la programmation et le travail avec la base de données, y compris sur les données de positionnement par satellite. Les citations sont encore pires. Le matériel est le suivant : j'ai pris les principales paires de devises, les cotations minute, j'obtiens les crosses par calcul (les cotations initiales des crosses ont des trous pour 15 minutes), le prix Close est un prix minute. J'imite Ask comme Close+spred, et Bid est vice versa. Eh bien, il y a déjà un obstacle et une erreur.
Les commandes mql, telles que OrderCloseBy, doivent être réécrites en utilisant des fonctions propres. Heureusement, Yuri n'a pas d'indicateurs et le code est simple. Si j'avais traité les tests de manière professionnelle, les commandes mql auraient dû être transférées à dll.
Le code de Yuri est simple, mais loin d'être primitif. D'un côté, c'est clair, mais d'un autre côté, il est difficile de comprendre comment tout cela fonctionne dans un groupe. Je mets toutes les variables calculées (chaque minute) dans le tableau de logs et je regarde ces tableaux avec mes yeux pour voir ce qui se passe à l'intérieur. Mais je n'ai pas encore fini de transférer son code à la fin. Quand je l'aurai maîtrisé à fond, bien sûr, je réduirai le journal à un état lisible. Mais pour l'instant, j'ai peur de faire une erreur quelque part. Il est important pour moi de sélectionner le groupe optimal de paires de devises, puis je l'améliorerai pour moi-même directement dans Builder, et seulement ensuite je transférerai mes développements à mql. Mais mes décisions réelles (sur l'amélioration du code et l'évaluation de la composition des groupes) seront prises sur la base de données historiques, ce qui ne garantit pas..... etc. Alors, que faire ? Un autre inconvénient - il me faut beaucoup de temps pour calculer les multidevises (j'ai essayé un autre système auparavant). 60 minutes - 1 minute est calculée (+ échange de temps en temps de données pour les calculs, de sorte que tout va plus vite et qu'il s'agit toujours d'une minute). Je connais bien SQL et tout semble être fait de manière optimale dans les calculs. Mais je n'ai pas la patience de tester constamment, j'ai des portions de 10-20 jours.
Mais s'il existait une bonne pratique en matière de tests, je l'utiliserais. Peut-être que je réduirais certaines choses, que je ferais plus attention à quelque chose, ou même que je ferais les choses différemment.
Donc : J'attends l'article !
Le code de Reshetov est en effet intéressant. Peut-être n'ai-je pas vu grand-chose dans ma vie, mais l'approche est vraiment innovante et inhabituelle. Même si mon test montrera que cela ne vaut pas la peine de se risquer en vrai, je suis quand même très reconnaissant à Yuri - il génère beaucoup d'autres pensées.
Salutations, Fed
Yuri, cela vous dérangerait-il que j'inclue soudainement une analyse de votre Expert Advisor dans mon article ?