Un peu surpris :) J'ai pensé que je devais partager et poser une question NON rhétorique. - page 15
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
Nous parlons d'un optimiseur, pas d'un grand nombre de tests individuels. Le concept d'un optimiseur est tout à fait différent. Là, des gains de vitesse importants sont obtenus au prix de petites erreurs dans les résultats. L'optimiseur n'a pas du tout besoin de modèles basés sur les ticks. Tout au plus, ils sont basés sur les prix d'ouverture. Un optimiseur n'est pas un testeur, c'est tout à fait autre chose. Votre approche est différente, et assez logique aussi.
En faisant un testeur peu fiable (et il n'y a aucune chance que la marge d'erreur soit de 1%), le développeur obtiendra une tache à vie. Et le discours sur "100 fois plus rapide" semblera peu impressionnant comparé à "comment a-t-on vu qu'un optimiseur a le droit de charger quelque chose" ?
Au contraire, nous nous battons pour une précision et une rapidité maximales de l'optimiseur en raison de
- algorithmes optimisés
- performance et fonctionnalité maximisées du langage MQL5
- agents multithreads, distants et basés sur le cloud computing
- Historique détaillé du M1 avec support des écarts
- utilisation des versions 64 bits
La parallélisation de l'optimisation des stratégies a immédiatement conduit à une accélération linéaire du nombre de cœurs de calcul et MQL5 a fait un bond en avant par rapport à MQL4.En faisant un testeur peu fiable (et il n'y aura pas d'erreur de 1%), le développeur obtiendra une tache à vie.
J'ai l'impression que nous parlons des langues différentes. Je ne vous reproche rien. De plus, j'ai dit que les développeurs ont pris la seule bonne voie.
Mais ne critiquez pas tous les autres développements qui ne vous concernent pas. Mon Conseiller Expert est 100 fois plus rapide que MT4-tester et son erreur est <1% SUR MON EA SEULEMENT. Je n'en ai pas besoin pour les autres conseillers experts.
Vous voyez, je devais le faire, et je l'ai fait pour moi, et je n'impose cette voie à personne. Je dis seulement que, si nécessaire, il est toujours possible d'écrire une calculatrice non UNIVERSELLE muette, mais très rapide. Ensuite, ses résultats doivent être peaufinés sur un testeur MT4-MT5 bien conçu, qui n'est pas ennuyeux mais un véritable simulateur de trading.
Il faut être idiot pour reprocher aux développeurs que l'optimiseur n'est pas aussi rapide que la calculatrice. Et il faudrait être très têtu pour affirmer qu'une calculatrice spécialement écrite pour un cas particulier n'est pas plus rapide qu'un testeur universel dans ce cas particulier.
Là encore, les développeurs sont nourris par leurs clients - les sociétés de courtage, représentées par une armée de traders. MTS fournit de la nourriture à ses clients - les marchés. Chacun fait ses affaires. Mais ne vous critiquez pas mutuellement. Vous pouvez vous traiter mutuellement avec respect et sans manquer de respect.
Le topikstarter a presque commencé par attaquer les développeurs. Plusieurs fois, il a dit que ce n'était pas autorisé. Les développeurs ont aussi commencé à exagérer à la fin, en disant leur propre truc. Respectons nous les uns les autres.
Pour résumer, ce que j'ai fait pour moi-même, c'est que le testeur/optimiseur MT5 est un MUST, peu importe s'il n'est pas applicable pour certains cas particuliers (tant personnels qu'appliqués), car rien n'est parfait. Tk.
Pour moi personnellement, la discussion a été utile. Au moins, il m'est apparu clairement que, du point de vue des développeurs, la solution qu'ils ont mise en œuvre est la meilleure. Le fait que quelqu'un puisse avoir besoin de faire des milliards de courses est une autre question. Vous pouvez le faire vous-même. C'est tout. Nous ne pouvons pas modifier l'optimiseur MT5 dans le sens d'une augmentation des performances (vers des valeurs exorbitantes), ce n'est pas réel. Ils ont fait beaucoup, presque tout ce qui est possible en termes de performance. Tant mieux pour eux.
J'ai donc obtenu une réponse à ma question non rhétorique.
À hrenfx : Quelle réponse voulez-vous de Renat ? Il répond comme un développeur devrait le faire. IMHO, il comprend tout ce que vous dites. Mais il ne vous répond pas personnellement - mais à tous ceux qui le lisent. Vous devez donc toujours lire les réponses des développeurs.
Nous nous plaignons de la vie, alors qu'ils créent des logiciels non pas pour nous personnellement, mais pour les consommateurs. Apparemment, si on les payait des millions, ils feraient des logiciels pour nous personnellement.
Alors, merci. Réponse reçue. :)
À hrenfx : quelle réponse attendez-vous de Renat ? Il répond comme un développeur devrait le faire. IMHO, il comprend très bien tout ce que vous dites. Mais il ne vous répond pas personnellement - mais à tous ceux qui le lisent. C'est ainsi que vous devez toujours lire les réponses des développeurs.
À la lumière du sujet ci-dessus concernant la qualité et la vitesse des différents testeurs universels, j'ai oublié de mentionner le véritable concurrent de MQL5 - Stock#.
En fait, la création d'un broyeur de données ou d'un analyseur syntaxique, comme vous l'appelez, n'est pas une chose simple.
Comme vous l'avez déjà remarqué ci-dessus - il est raisonnable de passer des prix exprimés sous forme de nombres flottants aux prix sous forme d'entiers, car tout d'abord cela réduit l'espace mémoire d'au moins 4 fois, car USHORT n'occupe que deux octets et a une plage de valeurs de 0 à 65535, ce qui même pour cinq chiffres est en principe suffisant. Il s'avère donc que 6553 anciens points sont plus que suffisants, alors que DOUBLE prend 8 octets.
C'est-à-dire que si nous avons 50 millions de ticks par exemple sur un symbole (en tenant compte du fait que nous codons également le temps en USHORT, nous obtenons la taille du tick 3*2 = 6 bytes) Par conséquent, 50 * 6 correspond à environ 300 mégaoctets. Et dans un cas, si nous stockons le tick en tant que DOUBLE et même si le temps est USHORT, nous obtenons 2 * 8 + 2 = 20 octets, puis 20 * 50 est au moins un gigaoctet.
Eh bien, si les caractères disons 7, il est dans une version de 7 * 300 = 2,1 gigaoctets et la seconde 7 giga. OP. Si nous prenons comme norme 4 gigas de RAM pour les machines 64 bits, il s'avère que nous sommes déjà passés à 100% au swap.
Eh bien, si vous ne stockez pas les ticks pendant l'optimisation et les générez avant une exécution, cela prendra certainement moins de place :)). Mais il ne s'agira plus d'un robot numérique.
OK - allons plus loin. Supposons que nous soyons malins et que nous ayons généré des ticks. Et ils prennent 2 gigas de mémoire, mais si nous sommes intelligents et diligents, mais manquons d'expérience et connaissons peu les hautes performances - alors nous créerons notre propre "fil" pour chaque exécution du début à la fin de l'histoire, et il fonctionnera. Mais seulement sur la dernière "stupidité", nous perdrons environ quatre fois en productivité. Pensez-y ! Quatre fois plus - je suis pour le C, bien sûr. Donc, si plus d'une personne souhaite avoir un optimiseur de super-performances (et non un testeur), je suis prêt à créer un tel programme. Mais cela prendra du temps et c'est pourquoi je veux de l'argent. :)
Je veux dire, ici je viens de compter une accélération de SEPT fois.
C'est environ 150 millions de ticks en 12 secondes sur DOUBLE en nombres entiers ; même quatre fois plus vite, c'est-à-dire 4 secondes pour tous les ticks sur trois caractères de 1999 à aujourd'hui.
J'ai un tel testeur (pour l'environnement MT4 même avec le support du compilateur avec MT4 et celui natif de C++) avec multidevise. Il est facile de le refaire pour le commerce net. Je ne compilerai pas avec MT5, je suis paresseux. Au fait, il supporte le débogage MT4 :)) Directement dans le studio. Je peux y joindre le traitement distribué sur des machines voisines, mais y aura-t-il un gain de performance, nous devrons voir.
Avec des graphiques, des compteurs de performance, le chargement de n'importe quel historique ... Il ne s'agit donc pas d'un petit projet - 10 000 lignes à vue de nez. :)
Si les modérateurs n'y voient pas d'inconvénient, postez ici des captures d'écran d'exemples de votre testeur. Prenez un EA standard, convertissez-le en "tout-en-un" (sans indicateurs) et exécutez-le dans différents optimiseurs, y compris le vôtre. Les résultats, du moins sous forme de captures d'écran.
Cela n'a aucun sens de me montrer mon décompte (je l'ai déjà dit plus haut), car il ne peut être appelé autrement que par le mot "décompte". D'après vos déclarations, vous avez presque (je ne sais pas tous) un optimiseur à part entière. Les développeurs ont mis en place leur optimiseur (même deux d'entre eux - MT4 et MT5). Nous pouvons en discuter et la critiquer. Montre-nous quelque chose de ton cru. Il y a peut-être des acheteurs potentiels.
Peut-être même les développeurs auront-ils des doutes si votre optimiseur universel calcule vraiment beaucoup plus vite et avec une erreur acceptable.
Il y a aussi une question d'indicateurs. Personnellement, je n'en ai pas besoin pour écrire des EA, mais 99% des Expert Advisors les utilisent, donc l'architecture de leur testeur-optimiseur a été personnalisée en fonction des réalités de la majorité. Il peut donc y avoir une certaine perte de vitesse architecturale pour le "tout en un" (cela pourrait être plus rapide), mais il y a un grand avantage pour les variantes avec indicateurs (que cela pourrait être).
P.S. Vos chiffres sont manifestement inexacts : vous ne pouvez pas avoir l'historique en INT qui occupe 2,1 Go, et en DOUBLE qui occupe 7 Go. La différence doit toujours être exactement 2 fois (USHORT n'est pas suffisant). Le passage à l'arithmétique entière avec les prix donne un avantage significatif lorsque toute la logique d'un EA peut être remplacée par une logique entière. Cela ne se produit pas très souvent.
Si les modérateurs n'y voient pas d'inconvénient, postez ici des captures d'écran d'exemples de votre testeur. Prenez un EA standard, convertissez-le en "tout-en-un" (sans indicateurs) et exécutez-le dans différents optimiseurs, y compris le vôtre. Les résultats, du moins sous forme de captures d'écran.
Cela n'a aucun sens de me montrer mon décompte (je l'ai déjà dit plus haut), car il ne peut être appelé autrement que par le mot "décompte". D'après votre déclaration, vous avez presque (je ne sais pas tous) un optimiseur à part entière. Les développeurs ont mis en place leur optimiseur (même deux d'entre eux - MT4 et MT5). Nous pouvons en discuter et la critiquer. Montre-nous quelque chose de ton cru. Il y a peut-être des acheteurs potentiels.
Peut-être même les développeurs auront-ils des doutes si votre optimiseur universel calcule vraiment beaucoup plus vite et avec une erreur acceptable.
Il y a aussi une question d'indicateurs. Personnellement, je n'en ai pas besoin pour écrire des EA, mais 99% des Expert Advisors les utilisent, donc l'architecture de leur testeur-optimiseur a été personnalisée en fonction des réalités de la majorité. Il peut donc y avoir une certaine perte de vitesse architecturale pour le "tout en un" (cela pourrait être plus rapide), mais il y a un grand avantage pour les variantes avec indicateurs (que cela pourrait être).
P.S. Vos chiffres sont manifestement inexacts : vous ne pouvez pas avoir une histoire en INT qui occupe 2,1 Go et une histoire en DOUBLE qui occupe 7 Go. La différence doit toujours être exactement 2 fois (USHORT n'est pas suffisant). Le passage à l'arithmétique entière avec les prix donne un avantage significatif lorsque toute la logique d'un EA peut être remplacée par une logique entière. Cela ne se produit pas très souvent.
Si vous pensez que USHORT n'est pas suffisant, alors oui. Mais à mon avis, ce sera suffisant. De plus, vous n'avez pas besoin du double - FLOAT est moitié moins et plus rapide.
Et que dire des peaux - alors :
Oui, ok - je les montrerai si j'ai le temps, mais pas les skins - car ce n'est pas une application fenêtrée, mais je montrerai quelque chose comme une vidéo.
Acheteurs Je pense qu'il n'y en aura pas. :) Et en été, le temps viendra peut-être, je le convertirai en filet et le mettrai "à vendre". Je vais créer un site web en anglais et le mettre en ligne. Je pense que c'est la vente :) ( En fait, je suis déjà en train de rire - ici je n'ai pas engagé dans la vie sharavara toloko) sera pour 30-50 livres. Mais c'est intéressant - pensez-y : vous l'écrivez sur MT4 et le déboguez en studio :) :)
S'il existe un tel indicateur sur un symbole avec les mêmes paramètres, il n'est pas recalculé. Mais pour être honnête, je ne me souviens pas exactement de ce qui n'est pas là, mais tout est là, ce qui est nécessaire dans MT4. Et les ticks proviennent de chaque symbole dans l'EA où le test est exécuté, et pas seulement du symbole sur lequel l'EA est exécuté comme dans MT5 maintenant.
Cela me fait penser - il y a même des bibliothèques et des exportations ... Eh bien, il y a tout. :)
Les données entières (et même si elles sont courtes) ne peuvent être utilisées dans aucune opération de division et de multiplication. Où stocker les valeurs fractionnaires de 15 chiffres ? De même, il est dangereux et suicidaire d'utiliser le flotteur, qui manque absolument de précision. La quantité d'erreurs accumulées dans le flottant est telle que vous ne devriez jamais l'utiliser pour calculer des indicateurs.
Les développeurs débutants n'en sont pas conscients. Ils ne voient pas encore toute l'étendue des complexités.
Il n'y a pas d'avantage particulier à convertir les prix en nombres entiers. Oui, il réduit effectivement les volumes, mais il perd souvent de la vitesse en raison de la conversion inévitable en double. C'est inévitable, car il n'est pas possible de rendre tout le système entier, les mathématiques calculables doivent toujours être faites en double (dont la précision n'est même pas suffisante).
Les données entières (et même si elles sont courtes) ne peuvent être utilisées dans aucune opération de division et de multiplication. Où stocker les valeurs fractionnaires de 15 chiffres ? De même, il est dangereux et suicidaire d'utiliser le flotteur, qui manque totalement de précision. La quantité d'erreurs accumulées dans le flottant est telle que vous ne devriez jamais l'utiliser pour calculer des indicateurs.
Les développeurs débutants n'en sont pas conscients. Ils ne voient pas toute l'étendue des complications.