Question pour les MATHÉMATIQUES - page 8
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
Je n'ai pas lu le fil de discussion. Flubbing.
Il y a un métier associé à la programmation en MQL. Prenons une tâche assez simple pour un EA - croiser deux baguettes (bon, peut-être que je suis trop cool, mieux vaut bien sûr un couple ou trois indicateurs et avec une "approche" différente du marché). Je suis sûr que même avec un EA aussi simple, les codes des différents progers seront différents. Mais moi, en tant que client, je ne serai guère intéressé, même par un code compact. Je ferai attention :
1. la précision du traitement de ma tâche (généralement - idiote), par exemple - les signaux de passage réel seulement ou un toucher et ensuite un élan, c'est-à-dire si le codeur a réussi à fournir au moins une sorte de sécurité pour mon idiosyncrasie ? Sinon, ce n'est pas moi que je blâmerai, mais le codeur pour mon idiotie.
2. Le nombre d'ordres de transaction et le nombre d'échecs du serveur - il s'agit d'un élément plus important, à savoir si le codeur a été capable de traiter correctement les ordres de transaction et de les faire exécuter par le concessionnaire. Je ne me soucie pas des requotes, de l'interdiction de négocier pendant les heures d'information, des retards pendant le temps moteur et d'autres choses - sinon vous n'avez pas travaillé avec mon argent.
Et puis ce à quoi je n'ai même pas pensé - optimisation des lots, stoploss dynamique, trawl et autres choses bizarres...
Que pensez-vous de ça ? Cela déterminera l'aptitude du codeur pour le MQL ? Seulement, cela ne coûtera pas un petit centime (de Winnie l'ourson). Et le nombre de commandes diminuerait considérablement, car quelle que soit la qualité de l'exécution du code, mon idiotie ne peut être annulée par le codeur.
Je suis tout à fait d'accord. Cela fait référence à la "connaissance du sujet du codage", il me semble. Le codeur de haut niveau doit produire un produit fiable, en connaissant les nuances du trading réel et peut-être en identifiant les particularités du trading dans le DC particulier spécifié par le client. Alors l'idiotie du commerçant ne jouera pas un rôle fatal. Et le prix du produit doit être approprié, en dépit de son apparente simplicité visuelle.
Et la valorisation du travail, d'ailleurs.
Cette formule est connue depuis plus de mille ans - le rapport entre l'offre et la demande. Quel que soit votre génie, si la demande est faible, vous serez codé pour des cacahuètes. Et si la demande est élevée, alors même l'écolier d'hier, ayant lu la préface du livre sur le MQL, demandera/recevra beaucoup. Et aucune formule ne le changera.
Pourquoi Integer code-t-il pour les pennies ? Et regardez les clients locaux : "Je suis prêt à payer 10 dollars, ce travail ne vaut pas plus".
D'autre part, les programmeurs MQL ont une certaine spécificité, il me semble. Là-bas, 95% du travail est une répétition de ce qui a été fait précédemment pour quelqu'un d'autre. Ainsi, il n'y a pratiquement pas de codage - il suffit d'assembler des blocs prêts à l'emploi.
Cette formule est connue depuis plus de mille ans - le rapport entre l'offre et la demande. Quel que soit votre génie, si la demande est faible, vous serez codé pour des cacahuètes. Et si la demande est élevée, alors même l'écolier d'hier qui lit l'introduction du livre sur le MQL ne demandera pas/recevra de façon puérile. Et aucune formule ne le changera.
Pourquoi Integer code-t-il pour les pennies ? Et regardez les clients locaux : "Je suis prêt à payer 10 dollars, ce travail ne vaut pas plus".
D'un autre côté, les programmeurs MQL ont une certaine spécificité, il me semble. Là-bas, 95% du travail est une répétition de ce qui a été fait précédemment pour quelqu'un d'autre. C'est-à-dire qu'il n'y a pratiquement pas de codage - il suffit d'assembler des blocs prêts à l'emploi.
Donc c'est ça le truc, il n'y a pas de marché où l'offre et la demande naissent. Il y a des souches... Et il y a de plus en plus de commerçants...
95% du travail déjà effectué est de la propriété intellectuelle... Mais bien sûr, il peut être volé en décodant le produit.
Le Djurica a été décodé (il repose tranquillement dans la Code Base), mais on ne voit pas d'artisans qui comprennent son algorithme... Un filtre unique, en fait.
Djuric a été décodé (il repose tranquillement dans la Code Base), mais on ne voit pas d'artisans qui comprennent son algorithme...
Peut-on le comprendre de manière à ce qu'il se comporte de manière imprévisible lorsqu'il est intégré dans une EA à un moment donné ? Eh bien, d'une manière primitive.
En théorie, oui. Certains la considèrent comme "obscure". Il n'est certainement pas sorti du bac à sable et il est en principe possible de réaliser des expériences à grande échelle pour tester décemment son imprévisibilité.
Pourquoi pas ? Le splitter est assez décent, si le fichier "source" se compile ensuite. Et le splitter ne peut pas faire plus, car l'information sur les noms n'est pas stockée dans ex4 - où l'obtenir ?
Pourquoi pas ? Le splitter est assez décent, si le fichier "source" se compile ensuite. Et le splitter ne pourra pas faire plus, parce que l'info sur le nom n'est pas stockée dans ex4 - où la trouve-t-il ?
Correction... Je ne faisais pas référence au programme décodeur, mais au produit décodé, la source.