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
"Apothéose" Je considère une expression de fxsaber, à propos de laquelle il n'a pas pu lui-même dire comment elle fonctionne, déclarant simplement que "le code a été testé à plusieurs reprises, et il fonctionne". À mon avis, cela ne devrait pas être le cas :
Ce code vérifie siun ordre otfFilingType peut êtreexécuté, et le renvoie s'il est disponible sur strSymbol, sinon il est correct.
Je n'ai absolument aucune idée de comment cela fonctionne. Et ne vous fiez qu'à l'autorité de Fxsaber.
Peut-être que quelqu'un peut expliquer ?
Pour le comprendre, il suffit de décomposer cette expression de retour encombrante en ses composantes.
Votre exemple de "la fin justifie les moyens".
d'ailleurs ce code ressemble à du spaghetti, mais vu que c'est probablement l'auteur le plus utile de kodobase en ce moment et que j'utilise moi-même ses codes tels quels, laissons quelqu'un d'autre critiquer
d'ailleurs ce code ressemble à du spaghetti, mais étant donné que c'est probablement l'auteur le plus utile de kodobase en ce moment et que j'utilise moi-même ses codes tels quels, laissons quelqu'un d'autre critiquer
il ne s'agit pas de critiquer, j'essaie de comprendre ce qu'il peut faire.... Mais comme le montre l'interview, et@fxsaber lui-même l'a admis - rien que des maux de tête.
SZZ : il est fort probable que la variante initiale du petit monstre soit plus claire ;)
ZS : forte probabilité que la version originale du petit monstre soit plus évidente ;)
Je l'ai pris de ZIP (contient la toute première version).
Mais après cela, de plus en plus de fonctionnalités étaient nécessaires, et le code s'étoffait lentement. C'était différent avec la fonction de remplissage. Rien n'a été étoffé là-bas, tout a été écrit d'un coup.
Seul le compilateur sait exactement ce qu'il va faire. Les compilateurs modernes ont une euristique stupéfiante. Ils s'adaptent au codeur moyen et savent déjà mieux ce dont il a besoin. La meilleure chose qu'un compilateur puisse faire est d'écrire un code simple et direct avec des fonctions courtes. Il est plus facile et plus efficace pour le compilateur d'analyser le graphe du code source composé de nombreux nœuds de fonction pour construire le programme résultant. Cela n'aura qu'un effet positif sur la productivité puisque les fonctions nécessaires seront verrouillées à tous les bons endroits.
Vous avez tout à fait raison.
Si nous parlons de MQL5, vous pouvez oublier les méthodes d'"optimisation" d'il y a 10-20-30 ans. Vous devez écrire le code le plus lisible. C'est ça, et pas les trucs de hacker et de pur esprit d'initiative.
Pourquoi ?
Comme le compilateur passe par 5 à 10 cycles de réorganisation du code, il est étonnamment clair et concis, sans parler de l'utilisation de dizaines de schémas d'optimisation.
Le compilateur MQL5 s'amuse des tentatives humaines de gagner +2% de vitesse.
C'est une œuvre d'art en fait. 8 racines ont été calculées en 4 appels de la commande assembleur. Deux numéros doubles ont été calculés en un seul appel.Si cela vous intéresse, regardez comment calculs mathématiques SQRT + se font sans branchement et une commande (128 bits de données) calcule deux racines à la fois
Ce code se transforme en code assembleur SSE suivant :
La conclusion générale : les mathématiques ont gagné dans MQL5 grâce à une optimisation parfaite. Ce ne sont pas les tableaux qui perdent ici, mais les mathématiques qui gagnent.
Pourquoi ça ?
Au contraire, c'est beaucoup plus facile avec deux "si" qu'avec l'opérateur "ou".
Il est plus facile de tracer une condition en premier, et de quitter la fonction si elle est vraie, puis de vérifier l'autre condition, et de la quitter également si elle est vraie, que de deviner le résultat d'une condition complexe avec un "ou" logique (qui peut être facilement confondu avec "et"), et de tracer les deux options de retour.
C'est assez drôle de lire plus bas que "la justification d'un tel code est le débogage", car cela signifie qu'un tel code est beaucoup plus compréhensible (sinon pourquoi est-il en débogage ?).
"Apothéose" Je considère une expression de fxsaber, à propos de laquelle il n'a pas pu lui-même dire comment elle fonctionne, déclarant simplement que "le code a été testé à plusieurs reprises, et il fonctionne". À mon avis, cela ne devrait pas être le cas :
Ce code vérifie siun ordre otfFilingType peut êtreexécuté, et le renvoie s'il est disponible sur strSymbol, sinon il est correct.
Je n'ai absolument aucune idée de comment cela fonctionne. Et ne vous fiez qu'à l'autorité de Fxsaber.
Peut-être quequelqu'un peut expliquer ?
Je me suis assis une fois et je l'ai démonté étape par étape, il semble que j'ai eu besoin d'un stylo et de papier).
J'ai compris qu'en cas de changement de la structure de l'énumération, tout serait cassé, puisque des relations entières entre les valeurs de l'énumération sont utilisées (qui, selon l'idée même des énumérations, devraient être encapsulées). J'essaie moi-même d'éviter cela, tout au plus le rapport plus-moins. Pour ceux qui s'occupent de WinAPI, elle est probablement familière.
Pour comprendre, il suffit de démonter cette expression difficile à manier qu'est le retournee.
Oui, c'est ce que j'ai essayé. Mais je n'étais pas assez motivé pour le démonter...
Tout à fait exact.
Si nous parlons de MQL5, vous pouvez oublier les méthodes d'"optimisation" d'il y a 10-20-30 ans. Vous devez écrire le code le plus lisible. C'est ça, et pas les trucs de hacker et de pur esprit d'initiative.
Exactement. Je suis arrivé à cette conclusion il y a longtemps. Mais pas parce que je pense que le compilateur le rendra meilleur. Mais parce que la principale source de problèmes dans le code est l'être humain lui-même, ce qui signifie qu'il faut écrire le code de manière à le rendre aussi simple et transparent que possible.
Si vous ne pouvez pas le rendre "transparent", vous devez écrire des commentaires détaillés expliquant pourquoi c'est comme ça et pas comme ça.
Et le compilateur... Même s'il ne le fait pas assez efficacement, c'est moins un problème qu'un bug potentiel dû au fait que vous ne prenez pas en compte certains aspects du programme.
Le code est très simple et court(description). Si vous l'écrivez sur FP, il serait intéressant de comparer.
S'il vous plaît. C# dans le style FP :
Le langage FP est bien sûr assez tordu (puisqu'il a été écrit par un codeur FP tordu, dans le langage FP incomplet C#), mais le but est de montrer qu'avec le jargon moderne de la POO, on peut aussi le faire en FP. Bien sûr, c'est limité, ce n'est pas F# ou Haskell, mais personne n'interdit d'écrire dans le style FP. Utilisez l'immuabilité, les fonctions d'ordre supérieur, les fermetures, les mappings, etc. - vous êtes le bienvenu pour tout faire. Mais cela ne rend pas le code parfait pour une raison quelconque.
s.w. La structure globale du code imite délibérément l'original. Bien que dans un bon sens il devrait être tout à fait différent dans FP, sans objets complexes et foreach imitant la carte, mais l'artiste a peint comme il pouvait.
S'il vous plaît. C# dans le style FP :
Je comprends que c'est une question d'habitude et de connaissance de la syntaxe, mais j'ai beaucoup de mal à entrer dans le code alors que je suis l'auteur original.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Opinion intéressante sur la POO
fxsaber, 2021.01.29 13:39
Une bagatelle.
Techniquement, c'est probablement un OOP. Mais la partie la plus primitive de tout ça. Je ne pouvais pas le faire sans, cependant. Possible, réarrangement stupide du cerveau et rivetage de ceci.