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
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.
Eh bien, qui vous empêche de changer le type de fonction en double.
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.
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 déconnecté...
OK, l'UB est entre vos mains.
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.
Je suggère aux développeurs d'utiliser cet algorithme dans des fonctions régulières.
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.
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.
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é.
J'ai toujours voulu vous demander : combien pouvez-vous programmer dans votre style de code ?
Un exemple de mon style ?