Mon approche. Le noyau est le moteur. - page 44
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
Pourquoi n'est-il pas possible de mettre en place une semi-automatisation par le biais de la fenêtre des propriétés ? Quelle différence cela fait-il d'activer ou de désactiver quelque chose par la fenêtre des propriétés, ou par une interface supplémentaire (sauf que dans le second cas, les coûts augmentent) ? Donc la question se répète - qu'est-ce qui peut être fait par votre gui qui ne peut pas être fait par une fenêtre normale de propriétés ?
Et pourquoi avez-vous écrit une bibliothèque gui ? Qu'est-ce qui peut être fait par votre interface graphique et qui ne peut pas être fait par la fenêtre des propriétés ?
Pourquoi n'est-il pas possible de mettre en place une semi-automatisation par le biais de la fenêtre des propriétés ? Quelle différence cela fait-il d'activer ou de désactiver quelque chose par la fenêtre des propriétés, ou par une interface supplémentaire (sauf que dans le second cas, les coûts augmentent) ? La question se répète : qu'est-ce qui peut être fait à travers votre interface qui ne peut pas être fait à travers la fenêtre normale des propriétés ?
Je vais vous donner mon avis : l'interface graphique est plus agréable à utiliser. C'est plus pratique - il suffit de s'asseoir et d'appuyer sur les boutons. L'interface graphique peut être utilisée par le testeur pour se familiariser avec elle - pour apprendre à drainer l'argent de la démo.
Mais, en ce qui me concerne, Peter ne s'est pas trompé de sujet - il n'a pas mené d'étude sur la demande, n'a pas écrit pendant des années sur la demande (et en fait ils commandent fondamentalement les mêmes + / -), et ne connaît pas les statistiques sur la demande de GUI dans les programmes. Et une seule beauté (n'est-ce pas ?) ne mènera pas loin (en termes de moyens de subsistance).
Ça pourrait juste être plus pratique, Dimitri.
Je comprends très bien l'interface graphique de Peter. Parfois, il est judicieux de placer certains paramètres dans des panneaux séparés, pour placer les boutons de curseur et autres contrôles de manière pratique. Et de le faire d'une manière différente de celle proposée par les interfaces standard.
Le problème, tel qu'il me semble, est quelque peu différent - la complexité du support (se rappeler où et quels indices, dans quel ordre et ce qu'ils signifient est très difficile), et le public cible (les personnes qui connaîtraient suffisamment bien la programmation, mais qui préfèrent négocier manuellement, à mon avis, sont très peu nombreuses).
Peter pense que les semi-automatiques sont l'avenir. C'est exactement ce sur quoi il compte en publiant une bibliothèque comme celle-ci.
Mais, personnellement, j'ai de grands doutes, à la fois sur le fait que "l'avenir est aux semi-automatiques" et sur le fait qu'il y aura un nombre illimité de personnes qui savent programmer, mais qui feraient du commerce manuellement.
George, je t'ai dit beaucoup, beaucoup de fois
VOUS N'AVEZ PAS BESOIN D'APPRENDRE MON APPROCHE.
Pas d'index, pas de noyau, pas de moteur.
Juste un langage de balisage.
Je vous ai montré un exemple de code. J'ai expliqué que le constructeur crée le moteur et les fichiers. L'un d'eux ne fait que remplir.
...Et on ne peut pas aller loin en se contentant de la beauté (n'est-ce pas ?) (en ce qui concerne les moyens de subsistance).
Quelle beauté ? Nous parlons de tableaux de données, de statistiques, de boîtes de dialogue, de réglages semi-automatiques, de nombreuses possibilités qui s'ouvrent.
Quelle beauté ? Nous parlons de tableaux de données, de statistiques, de boîtes de dialogue, de réglages semi-automatiques, de nombreuses possibilités qui s'ouvrent.
Quelles données, quels tableaux ?
Quelles données, quels tableaux ?
TOUTES LES DONNÉES. Autant que l'utilisateur le souhaite.
Ça pourrait juste être plus pratique, Dimitri.
Je comprends très bien l'interface graphique de Peter. Parfois, il est judicieux de placer certains paramètres dans des panneaux séparés, pour placer les boutons de curseur et autres contrôles de manière pratique. Et de le faire d'une manière différente de celle proposée par les interfaces standard.
Le problème, tel qu'il me semble, est quelque peu différent - la complexité du support (se rappeler où et quels indices, dans quel ordre et ce qu'ils signifient est très difficile), et le public cible (les personnes qui connaîtraient suffisamment bien la programmation, mais qui préfèrent négocier manuellement, à mon avis, sont très peu nombreuses).
Peter pense que les semi-automatiques sont l'avenir. C'est exactement ce sur quoi il compte en publiant une bibliothèque comme celle-ci.
Mais, personnellement, j'ai des doutes, tant sur " l'avenir des semi-automatiques " que sur le fait qu'il y a beaucoup de gens qui savent programmer, mais qui font du commerce manuellement.
C'est peut-être plus pratique, mais seulement un peu, si l'on ne tient pas compte du travail que cela implique.
Quant aux semi-automatiques. Dans quelle mesure sa bibliothèque est-elle adaptée aux tâches de semi-automatisation ? Pas du tout. D'environ 5 pour cent, pour être exact.
L'idée même de la semi-automatisation n'est pas divulguée, ni ses principales tâches, ni son essence.
====
C'est à peu près comme ça que je comprends le fonctionnement semi-automatique : j'ai regardé le graphique, j'ai épinglé les indicateurs au graphique, j'ai regardé... et a décidé que ce serait probablement une bonne idée d'ouvrir si l'indicateur cci traverse le niveau 100 de bas en haut. J'ai mis en place le système de notification... me pencher en arrière dans mon fauteuil... La notification a fonctionné, je regarde le graphique et je pense - non, il vaut mieux aller dans une autre direction, mais quand l'indicateur csi traverse le niveau 200 du haut vers le bas... Alors, par exemple, j'ai ouvert, mais je ne l'ai pas touché. J'ai configuré le système pour qu'il ferme lorsque deux moyennes mobiles se croisent, mais en cas de profit, j'activerai le trailing... Quelque chose comme ça - pour automatiser ces pensées qui surgissent dans le processus... En outre, chacun a des pensées différentes. Et ce que Peter propose est juste un gui, et il n'est même pas clair pourquoi il est proposé comme moyen d'automatisation. Mais l'AutoGraph de Sergei Kovalev est en réalité un système de travail semi-automatique. Mais Peter ne connaît probablement pas l'Aftograf ?
Je vais vous dire ce que je pense - l'interface graphique est plus agréable à utiliser. C'est plus pratique - il suffit de s'asseoir et d'appuyer sur les boutons. L'interface graphique peut être utilisée par le testeur pour s'y habituer - pour apprendre à drainer l'argent de la démo.
Mais, pour ma part, Peter s'est engagé dans le mauvais domaine - il n'a pas mené d'étude sur la demande, n'a pas écrit depuis des années pour commander (et en fait il commande pratiquement la même chose +/-), et ne connaît pas les statistiques de la demande d'interface graphique dans les programmes. Et une seule beauté (n'est-ce pas ?) ne mènera pas loin (en termes de moyens de subsistance).
Si vous vous entraînez dans le testeur, il n'y a pas d'autre option. Je veux dire le cas habituel - un Conseiller Expert est en train de planer sur un graphique...
N'IMPORTE QUOI. Autant que l'utilisateur le souhaite.
Toutes les statistiques se trouvent dans la section historique du terminal, et elles ne sont pas consultées une fois par jour, il n'est donc pas nécessaire de gaspiller des ressources. Ou s'agit-il d'une mauvaise statistique ?
Ce que je vois maintenant, c'est que vous ne pouvez pas voir le prix derrière toutes les fenêtres, et cela tue complètement le trading manuel, donc ce n'est définitivement pas semi-automatique.