Implémentations alternatives de fonctions/approches standard - page 7

 
pavlick_:

Parce que convertir un double en entier (de cette façon) est un code merdique. Round with friends n'est pas conçu pour obtenir un type entier à partir d'un type flottant.

Qui vous empêche de changer le type de fonction en double.
Et contrôlez votre discours, s'il vous plaît.
 
Nikolai Semko:
Eh bien, qui vous empêche de changer le type de fonction en double.
Et contrôlez votre discours, s'il vous plaît.

Sans vouloir vous offenser. Il existe toutes sortes de rint, lrint, llrint pour la conversion en nombre entier. Ils ne sont pas apparus par hasard alors qu'il est beaucoup plus facile de faire du long(double). La conversion des flottants en entiers est une erreur conceptuelle.

 
pavlick_:

Sans vouloir vous offenser. Il existe toutes sortes de rint, lrint, llrint pour convertir en entier. Ils ont été inventés pour une raison, alors que vous pouvez faire beaucoup plus facilement que long(double). La conversion des flottants en entiers est une erreur conceptuelle.

Oh, tu es juste hors du coup...
 
Nikolai Semko:
Oh, tu es juste déconnecté...

OK, l'UB est entre vos mains.

 
fxsaber:
Interprétation ambiguë donc. Il a été décidé de publier le temps du cycle, et non le temps moyen d'un appel de fonction.

Le gain est compris entre 3 et 8 fois.

La méthode de calcul du temps de fonctionnement n'est peut-être pas sans faille, mais elle est tout à fait objective. Mais si quelqu'un suggère une meilleure méthode, plus impartiale, ce serait bien.

Je l'ai changé en type double pour une analogie complète.

double Ceil (double x) { return double((x-(long)x>0)?(long)x+1:(long)x);}
double Round(double x) { return double((x>0)?(long)(x+0.5):(long)(x-0.5));}
double Floor(double x) { return double((x>0)?(long)x:((long)x-x>0)?(long)x-1:(long)x);} 
2018.08.25 22:16:01.309 TestRound (EURUSD,M10)  Время цикла без округления = 1.315 наносекунд, сумма = 5249993749.98145962
2018.08.25 22:16:01.309 TestRound (EURUSD,M10)  Время выполнения функции sqrt = 0.628 наносекунд, сумма = 81969849.90928555  // даже квадратный корень вычисляется в несколько раз быстрее чем штатные функции округления
2018.08.25 22:16:01.313 TestRound (EURUSD,M10)  Время выполнения функции ceil =  2.037 наносекунд, Контрольная сумма = 5250492895.0
2018.08.25 22:16:01.315 TestRound (EURUSD,M10)  Время выполнения функции Ceil =  0.587 наносекунд, Контрольная сумма = 5250492895.0
2018.08.25 22:16:01.318 TestRound (EURUSD,M10)  Время выполнения функции floor = 2.247 наносекунд, Контрольная сумма = 5249492896.0
2018.08.25 22:16:01.320 TestRound (EURUSD,M10)  Время выполнения функции Floor = 0.385 наносекунд, Контрольная сумма = 5249492896.0
2018.08.25 22:16:01.323 TestRound (EURUSD,M10)  Время выполнения функции round = 1.610 наносекунд, Контрольная сумма = 5249992896.0
2018.08.25 22:16:01.324 TestRound (EURUSD,M10)  Время выполнения функции Round = 0.181 наносекунд, Контрольная сумма = 5249992896.0

Je suggère aux développeurs d'utiliser cet algorithme dans des fonctions régulières.

Dossiers :
TestRound.mq5  7 kb
 
)). Cela peut avoir une place uniquement dans les métiers personnels avec une connaissance exacte de la plage de valeurs, mais pas dans la bibliothèque standard. Les fonctions intégrées ne sont pas écrites par des imbéciles, ne pensez pas que vous êtes le plus intelligent. Voici un ami qui écrit également un comportement indéfini et non spécifié et qui s'étonne ensuite que cela ne fonctionne pas de cette façon https://www.linux.org.ru/forum/development/14422428#comments. Toutes ces économies de plusieurs nanosecondes ne seront même pas visibles dans un algorithme réel (pas en boucle nue).
 

Je ne comprends pas non plus pourquoi les fonctions d'arrondi doivent retourner le double. À mon avis, c'est l'intérêt des arrondis - il faut définir comment obtenir un nombre entier à partir d'une valeur flottante.

Ce que l'on appelle "erreur conceptuelle" de conversion n'est pas non plus très clair pour moi.

 
Georgiy Merts:

Je ne comprends pas non plus pourquoi les fonctions d'arrondi doivent retourner le double. À mon avis, c'est l'intérêt des arrondis - il faut définir comment obtenir un nombre entier à partir d'une valeur flottante.

Ce que l'on appelle "erreur conceptuelle" de conversion n'est pas non plus très clair pour moi.

Pensez à ce que vous obtenez en dehors d'un nombre entier.
 
fxsaber:

NormalizeDouble

Le résultat est de 1123275 et 1666643 en faveur de MyNormalizeDouble (Optimize=1). Sans optimisation, il est quatre fois plus rapide (en mémoire).


J'ai toujours voulu vous demander si vous pouvez programmer beaucoup de choses dans votre style de code.

Si vous avez pour tâche de concevoir et de créer un mécanisme très complexe par vous-même, cela vaut-il la peine d'utiliser votre façon d'écrire le code ? Et vous devez vérifier les performances de chaque enregistrement à chaque étape.

Combien de temps faudra-t-il à un développeur pour lire/écrire/vérifier le code, si vous abordez ce processus dans votre style et à votre niveau ?

Je parie que je vieillirais sans avoir écrit la moitié de ce que j'avais en tête.


zy. Désolé pour le hors-sujet. Le style de programmation est une affaire personnelle. Mais à un certain moment, vous commencez à réaliser que le code doit être aussi lisible que possible, précisément à des fins de productivité.

Productivity - США - MetaTrader 5
Productivity - США - MetaTrader 5
  • www.metatrader5.com
Индекс производительности труда показывает изменение объема выпущенной продукции, приходящегося на одного работника. Этот показатель полезен для предсказания инфляции и прироста объема производства. Если стоимость труда увеличивается соответственно увеличению производительности, и, кроме того, маловероятно увеличение производственных издержек...
 
Реter Konow:

J'ai toujours voulu vous demander : combien pouvez-vous programmer dans votre style de code ?

Un exemple de mon style ?

Raison: