Mon approche. Le noyau est le moteur. - page 38
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
Eh bien, eh bien... Vas-y, Peter.
Vous avez raison pour ce qui est de la "dégradation", mais je pense que vous êtes présomptueux pour ce qui est de "tirer les utilisateurs".
Mais, allez-y. Il y a peut-être quelqu'un qui sait programmer, mais qui fait du commerce "sans intervention".
Je pense qu'il existe une célèbre plateforme américaine pour le trading manuel. Il a la possibilité d'automatiser partiellement des actions à l'intérieur de la plateforme, mais il faut savoir comment le faire. Il existe également une API. Mais combien seront en mesure de l'utiliser ?
Nous pouvons écrire des semi-automatiques pratiques et les proposer aux clients. Et pas seulement eux. Tous les traders qui négocient manuellement peuvent se voir proposer une automatisation partielle des actions, suivre le marché à partir de tableaux et interagir avec le programme à l'aide de fenêtres de dialogue. Afficher des messages sur les événements du marché. Bon, peut-être que je ne sais pas ou ne comprends pas quelque chose, mais en théorie ?
Nous, par contre, pouvons écrire des semi-automatiques pratiques et les proposer aux clients. Et pas seulement eux. Nous pouvons offrir à tous les traders qui négocient manuellement une automatisation partielle de leurs actions, observer le marché à partir de tables et interagir avec le programme par le biais de fenêtres de dialogue. Afficher des messages sur les événements du marché. Bon, peut-être que je ne sais pas ou ne comprends pas quelque chose, mais en théorie ?
Il n'y a qu'une seule façon de le savoir.
Enfin, publie au moins quelque chose.
Laissez-le être moins qu'idéal et sans peluches (si nécessaire, ajoutez-le plus tard), et voyez immédiatement la demande + le retour des utilisateurs ira et il sera plus clair dans quelle direction creuser ensuite.
Plus tôt vous le ferez, plus vous gagnerez du temps (ou plutôt, moins vous en perdrez...). :(
J'aurais donné beaucoup pour de tels conseils en mon temps :)
Eh bien, eh bien... Vas-y, Peter.
Vous avez raison pour ce qui est de la "dégradation", mais je pense que vous êtes présomptueux pour ce qui est de "tirer les utilisateurs".
Mais, allez-y. Il peut y avoir quelqu'un qui sait comment programmer, mais qui échange des "mains sur le terrain".
Ce n'est pas possible. Ceux qui savent programmer feront sûrement un assistant en MQL5 et ne passeront qu'une à deux semaines à étudier les opérations de trading en MQL5.
Quant au robot semi-automatique, dans quelques heures je ferai une vidéo et vous montrerai à quoi ressemble un robot automatisé moderne qui peut fonctionner en mode semi-automatique comme un Expert Advisor.
Et vous n'avez pas besoin d'inventer des panneaux compliqués pour cela, mais d'en faire un très simple pour que ce soit plus clair pour tout le monde.
Les utilisateurs d'aujourd'hui sont dégradés par le graal du testage. Ils ont besoin d'être tirés vers un peu de complexité et de responsabilité pour leurs actions. Sinon, une dégradation complète de l'algotradition.
Je ne vois pas d'autre avenir pour le créneau de l'algotrading. Honnêtement, je ne vois pas...
Tant de pathos... Je vois des mains levées de chagrin ;)))
Vous, Petya, aimez le rôle du messie.
Tout le monde est dégradé... Que devient le monde... votre mission, votre destin est de mener une humanité dégradée vers un futur brillant d'algotrading. Il y a déjà un diagnostic ici. Sur le dessus de votre tête...
Petya, ne fais pas l'idiot.
Il y a quelque chose dans mql oop que je n'aime pas personnellement. Tout objet "vide" prend 16 octets. De plus, son pointeur prend 8 octets, ce qui fait un total de 24 octets pour un objet, sans compter les données. Si vous utilisez une matrice de propriétés à la place, vous pouvez remplacer un objet "vide" par 6 ints, chacun pouvant stocker presque tout sauf des chaînes de caractères (pour l'heure ou le prix, un int est suffisant dans 99 % des cas).
Et l'opération de conversion de type dynamic_cast n'est pas bon marché en termes de vitesse. Donc la méthode du topicstarter (je ne l'ai pas vu, bien sûr, mais théoriquement) peut fonctionner plus rapidement et prendre moins de mémoire que l'analogie avec la POO.
Ilya Malev:
Donc la méthode de topikstarter (je ne l'ai pas vu, bien sûr, mais théoriquement) peut fonctionner plus rapidement et prendre moins de mémoire que les analogues OOP.
C'est impossible, le "noyau" du topicstarter est un tableau de chaînes de caractères de taille immense, et parler de l'efficacité d'une telle approche est irréaliste, même en théorie.
Et l'opération de conversion de type dynamic_cast n'est pas bon marché en termes de vitesse. Ainsi, la méthode du topicstarter (je ne l'ai pas vue, bien sûr, mais en théorie) peut fonctionner plus rapidement et occuper moins de mémoire que son analogue OOP.
Personne ne soutient donc que l'accès direct à un énorme tableau global est plus rapide que tous ces artifices d'interface et conversions de types. Nous pouvons également penser à des modèles de conception, par exemple Visiteur avec double répartition - il y a une sacrée quantité de surcharge dans ce cas.
Cependant, tout cela est compensé par la commodité du support et de la modification. Malheureusement, le transfert maximal de tout effort de réflexion à l'ordinateur est depuis longtemps le courant dominant de la programmation. On en arrive au point où la somme d'une progression arithmétique est calculée au moyen d'une boucle au lieu d'utiliser la formule de somme bien connue. En ce sens, je suis d'accord avec Peter pour dire que les gens sont "dégradants".
Mais, hélas, il n'y a pas le choix - soit vous vous "dégradez" avec tous les autres, en essayant de ne pas le faire si vite, soit vous êtes désespérément en retard. Et le fait que votre programme soit inefficace n'a que peu d'importance.
J'y vois même une analogie avec la compétition en biologie, dans les relations entre prédateurs et proies : le lièvre, qui fuit le loup, n'est en fait pas du tout en compétition avec le loup, mais avec d'autres lièvres. Il n'a pas besoin de s'éloigner du loup aussi vite que possible. Il est beaucoup plus important pour lui de ne pas être le dernier à fuir le loup. Parce que s'il est le dernier à s'enfuir - il sera mangé, mais s'il s'enfuit plus vite que tout le monde - il dépensera plus d'énergie que nécessaire, et celle-ci peut être dépensée dans des directions plus utiles.
Il en va de même pour toutes sortes de technologies de programmation... La manière la plus efficace de programmer en assembleur, mais elle demande tellement d'efforts qu'elle n'a aucun sens - l'énergie est mieux dépensée de manière plus productive, même si le code n'est pas si efficace que cela. Le tableau de Peter avec l'accès global est du même type. Y accéder est efficace, mais se souvenir de ce qui se trouve où et comment accéder à quoi demande trop d'efforts.
Ce n'est pas possible, le "noyau" du topicstarter est un réseau de cordes de taille immense, et il est irréaliste, même théoriquement, de parler de l'efficacité d'une telle approche.
S'agit-il vraiment d'un tableau de chaînes de caractères ou d'une figure de style ? Si les données sont représentées par des chaînes de caractères mql (string), il n'y a vraiment aucune chance...
Y accéder est efficace, mais se souvenir de ce qui se trouve où et comment y accéder prend trop de temps.
Lorsque le "noyau" est prêt, vous pouvez consacrer un effort relativement faible pour lui coller une interface pratique qui résout tous les problèmes de présentation et d'accès "maladroits" aux informations. Bien qu'il s'agisse de paroles en l'air, d'après ce que j'ai compris, TC n'a pas publié ses codes et qui sait s'ils sont dans la nature :) Ou les a-t-il postées ? Honnêtement, je n'ai pas pu aller au bout des 38 pages.
De même, une méthode qui se limite uniquement aux "semi-automatiques" n'a aucune valeur par définition. Bien qu'il puisse contribuer à occuper une niche locale et limitée sur le marché des produits et des freelances