Ils ont mis un paquet de 40 kg sur un âne, puis ils se sont aperçus qu'ils avaient oublié une gourde de 1 kg - ce n'est pas un problème, c'est plus de 1 kg en moins, alors ils ont mis la gourde sur l'âne aussi. Ainsi, en mettant un kilo chacun sur un âne (une chose si insignifiante pour un âne), il peut être chargé de charges de taille infinie.
Dmitry Fedoseev: Nous mettons un poids de 40 kg sur un âne, puis nous nous apercevons que nous avons oublié un flacon de 1 kg, ce n'est pas un problème, nous mettons un poids de 1 kg en moins - ce n'est pas un problème non plus. Ainsi, vous pouvez mettre une charge infinie d'un kilogramme chacun sur un âne (une chose si insignifiante pour un âne).
Pas de crédit.
Ils accrochent 20 grammes de flacons vides à un âne. Et il s'en fiche complètement.
C'est dur pour lui à cause de l'eau qui y est versée (fonctions lourdes).
Mieux vaut ne pas être un balayage, mais un polymorphisme OOP.
Dans cet exemple particulier, vous pouvez insérer au moins 10 ifs et cela n'affectera pas la vitesse de fonctionnement (ainsi que la vitesse de test et d'optimisation) (<1% de ralentissement).
En effet, dans la fonction adjacente, il y aura l'analyse des commandes ou au moins la demande de OrdersTotal, et l'autre fonction sera la vérification de l'heure en tenant compte du décalage de l'heure GMT.
Dans notre exemple, vous pouvez insérer au moins 10 ifs et cela n'affectera pas la vitesse de fonctionnement (ainsi que la vitesse de test et d'optimisation) (<1% de ralentissement).
La raison en est que la fonction adjacente énumérera les ordres ou au moins la demande orderTotal, et l'autre fonction vérifiera l'heure en tenant compte du décalage de l'heure GMT.
Insérer à cet endroit, insérer à un autre, insérer à un autre, etc... et l'âne s'en va.
L'opportunité d'un contrôle supplémentaire dans cet exemple est minime. Quelqu'un veut, au contraire, que l'ordre soit ouvert juste après le lancement de l'EA, même si l'EA travaille sur des barres. Mais notre conseiller expert est super compétent pour définir le code de merde et tout ce qui est faux à son avis est un code de merde.
Tu m'expliques tout comme ça, comme si je n'avais pas vu une seule évaluation environnementale que je n'avais pas écrite. Il s'avère que je ne sais même pas comment écrire correctement une condition if.
Ce n'est pas difficile pour un âne, on ne verse pas l'eau dans les flacons d'un seul coup, mais un par un. Il est prouvé qu'un âne peut être chargé d'une quantité infinie de poids.
Arrêtez. Le programme le plus rapide est un OnTick() ; et c'est tout.
Tout ce qui contient plus de code sera plus lent. Et si vous devez penser à la vitesse, ce n'est certainement pas une question de si.
Un if peut être crucial dans le code OpenCL où il crée une logique de branchement conduisant à la désynchronisation des threads. Mais encore une fois, ce n'est pas if en soi qui cause le ralentissement, mais le fait que les threads travaillent à des vitesses différentes en raison de logiques différentes. Même dans ce cas, il ne faut pas essayer de réduire le nombre de ifs mais "unifier" les opérations dans des blocs if et else, par exemple
au lieu de
if(a>0.0)
a = b;
besoin d'utiliser
if(a>0.0)
a = b;
else
a = a;
alors le nombre d'opérations dans les différents threads est préservé et il n'y a pas de désynchronisation et la vitesse d'exécution est plus élevée, bien qu'il y ait plus de code.
Mettre à un endroit, mettre à un autre, mettre à un autre et ainsi de suite... et l'âne s'envolera.
L'opportunité d'un contrôle supplémentaire dans cet exemple est minime. Quelqu'un veut, au contraire, que l'ordre soit ouvert juste après le lancement de l'EA, même si l'EA travaille sur des barres. Mais notre conseiller expert est super-autoritaire par définition 00000 et tout ce qui n'est pas comme lui est xxxxxx.
Vous m'expliquez tous les choses comme ça, comme si je n'avais pas vu une seule évaluation environnementale, même si je n'en ai jamais écrit une. Il s'avère que je ne sais même pas comment écrire la condition if correcte.
Ils ne versent pas l'eau dans les flacons d'un seul coup, mais un par un. Il est prouvé que l'âne peut être chargé de charges infinies.
Le programme n'est pas le seul à pouvoir être poussé à l'extrême. Ce qui est exactement ce que vous faites.
Si vous dites que vous savez comment faire, vous devez comprendre le principe de l'opérateur if. Ou pas ?
Et ne comparez pas un opérateur if avec un âne, un âne s'assoit dans votre cerveau et écrit des bêtises. Et ne comparez pas l'opérateur if à un âne assis dans son cerveau qui écrit des bêtises.
Si vous n'avez pas de compte, veuillez vous inscrire
Autorisez l'utilisation de cookies pour vous connecter au site Web MQL5.com.
Veuillez activer les paramètres nécessaires dans votre navigateur, sinon vous ne pourrez pas vous connecter.
Vous êtes connecté. L'authentification à deux facteurs a été désactivée. Configurez-la à nouveau et scannez un nouveau code QR, ou continuez avec l'authentification à deux facteurs désactivée.
Je pense que seul toi, Dima, tu parlais de "ça" ici.)
Les gens discutaient du code de travail dans lequel if est la partie la plus rapide.
Le commutateur fonctionne presque instantanément, vous pouvez l'utiliser pour l'EA universelle. Mais je ne vois pas l'intérêt.
C'est parti d'ici.
Mieux vaut ne pas être un commutateur, mais un polymorphisme OOP.
Nous mettons un poids de 40 kg sur un âne, puis nous nous apercevons que nous avons oublié un flacon de 1 kg, ce n'est pas un problème, nous mettons un poids de 1 kg en moins - ce n'est pas un problème non plus. Ainsi, vous pouvez mettre une charge infinie d'un kilogramme chacun sur un âne (une chose si insignifiante pour un âne).
Pas de crédit.
Ils accrochent 20 grammes de flacons vides à un âne. Et il s'en fiche complètement.
C'est dur pour lui à cause de l'eau qui y est versée (fonctions lourdes).
C'est parti d'ici.
Mieux vaut ne pas être un balayage, mais un polymorphisme OOP.
Dans cet exemple particulier, vous pouvez insérer au moins 10 ifs et cela n'affectera pas la vitesse de fonctionnement (ainsi que la vitesse de test et d'optimisation) (<1% de ralentissement).
En effet, dans la fonction adjacente, il y aura l'analyse des commandes ou au moins la demande de OrdersTotal, et l'autre fonction sera la vérification de l'heure en tenant compte du décalage de l'heure GMT.
...
Dans notre exemple, vous pouvez insérer au moins 10 ifs et cela n'affectera pas la vitesse de fonctionnement (ainsi que la vitesse de test et d'optimisation) (<1% de ralentissement).
La raison en est que la fonction adjacente énumérera les ordres ou au moins la demande orderTotal, et l'autre fonction vérifiera l'heure en tenant compte du décalage de l'heure GMT.
Insérer à cet endroit, insérer à un autre, insérer à un autre, etc... et l'âne s'en va.
L'opportunité d'un contrôle supplémentaire dans cet exemple est minime. Quelqu'un veut, au contraire, que l'ordre soit ouvert juste après le lancement de l'EA, même si l'EA travaille sur des barres. Mais notre conseiller expert est super compétent pour définir le code de merde et tout ce qui est faux à son avis est un code de merde.
Tu m'expliques tout comme ça, comme si je n'avais pas vu une seule évaluation environnementale que je n'avais pas écrite. Il s'avère que je ne sais même pas comment écrire correctement une condition if.
Ce n'est pas difficile pour un âne, on ne verse pas l'eau dans les flacons d'un seul coup, mais un par un. Il est prouvé qu'un âne peut être chargé d'une quantité infinie de poids.
Je n'aurais pas dû commencer par ma propre ingéniosité :
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
Au secours !
Dmitry Fedoseev, 2015.11.03 20:44
La vitesse de fonctionnement est réduite.On vient de le découvrir ! ;)
Arrêtez. Le programme le plus rapide est un OnTick() ; et c'est tout.
Tout ce qui contient plus de code sera plus lent. Et si vous devez penser à la vitesse, ce n'est certainement pas une question de si.
Un if peut être crucial dans le code OpenCL où il crée une logique de branchement conduisant à la désynchronisation des threads. Mais encore une fois, ce n'est pas if en soi qui cause le ralentissement, mais le fait que les threads travaillent à des vitesses différentes en raison de logiques différentes. Même dans ce cas, il ne faut pas essayer de réduire le nombre de ifs mais "unifier" les opérations dans des blocs if et else, par exemple
au lieu de
besoin d'utiliser
alors le nombre d'opérations dans les différents threads est préservé et il n'y a pas de désynchronisation et la vitesse d'exécution est plus élevée, bien qu'il y ait plus de code.
Mettre à un endroit, mettre à un autre, mettre à un autre et ainsi de suite... et l'âne s'envolera.
L'opportunité d'un contrôle supplémentaire dans cet exemple est minime. Quelqu'un veut, au contraire, que l'ordre soit ouvert juste après le lancement de l'EA, même si l'EA travaille sur des barres. Mais notre conseiller expert est super-autoritaire par définition 00000 et tout ce qui n'est pas comme lui est xxxxxx.
Vous m'expliquez tous les choses comme ça, comme si je n'avais pas vu une seule évaluation environnementale, même si je n'en ai jamais écrit une. Il s'avère que je ne sais même pas comment écrire la condition if correcte.
Ils ne versent pas l'eau dans les flacons d'un seul coup, mais un par un. Il est prouvé que l'âne peut être chargé de charges infinies.
Le programme n'est pas le seul à pouvoir être poussé à l'extrême. Ce qui est exactement ce que vous faites.
Si vous dites que vous savez comment faire, vous devez comprendre le principe de l'opérateur if. Ou pas ?
Et ne comparez pas un opérateur if avec un âne, un âne s'assoit dans votre cerveau et écrit des bêtises. Et ne comparez pas l'opérateur if à un âne assis dans son cerveau qui écrit des bêtises.
au lieu de
vous devez utiliser