On me déconseille à mon boulot d'utiliser les float car ils sont moins précis que les double.
Du coup je me demandais si quelque part les float n'étaient pas complètement à proscrire et s'il ne valait pas mieux les remplacer systématiquement par des double ?
Tout dépend ce que tu veux faire et les contraintes.
Si tu veux calculer 1,5x2, tu n'as pas besoin de double. Si tu veux représenter une couleur RGB avec des réels, tu n'as pas besoin de double. Si tu fais de la 3D sur GPU, tu n'as pas besoin de double. Etc.
On pourrait pousser l'argument plus loin : pourquoi ne pas utiliser les long double plutôt que les doubles, puisque c'est plus précis ? Si tu poses la question à ceux qui te disent de ne pas utiliser float te diront probablement qu'ils n'utilisent pas long double. La raison est que le choix du type est un compromis entre précision de calculs (et donc besoin en précision en fonction de ton contexte) et performances (et donc conso mémoire, conso memoire cache, etc)
Bref, non, on supprime pas complètement les float. (Par contre, avoir comme pratique dans ton entreprise d'utiliser les double par défaut, pourquoi pas)
Les floatn'existent pas pour rien. Leur intérêt est essentiellement leur taille. Sinon les double ont des avantages et sont à préférer: - ils sont plus précis que les float - ils sont la plupart du temps plus rapide car les coprocesseurs ne travaillent normalement qu'en double. - il y a souvent des conversions cachés de float/double/float quand on utilise les float.
Un exemple où les floatsont une perte:
extern float x;
float y = 2 * x; // le copro converti x en double, effectue le produit et le reconverti en float
std::cout << y; // tous les float sont convertis transmis double et reconverti float quand ils sont passés en paramètre
Un exemple où les floatpeuvent être plus optimums:
for ( int i = 0 ; i < 32 ; ++i )
tab[i] *= 3.14; // possibilité de paralléliser 4, 8 ou 16 multiplications de float, ou 2, 4 ou 8 multiplications de double
Ici l'optimisation peut vectoriser les calculs flottants, et la bande passante se trouve alors améliorée avec des float. Donc un moyen simpliste de choix : pour des tableaux le float est à considérer (taille et parallélisation meilleure), pour les autres cas le double est très souvent gagnant.
Mais pour certains micro-processeurs, ils peuvent être optimisés pour les float(le copro est plus lent sur les double, les paramètres ne sont pas convertis en doublebien que non conforme avec la norme.) Dans ce cas le doubleest à éviter.
En résumé, comme d'habitude, la réponse est qu'il n'y a pas de réponse absolue et qu'il faut voir
pour quoi faire
avec quelles contraintes (précision, vitesse, espace occupé).
peut être que dans le cadre de ton boulot, il est effectivement préférable d'utiliser les doubles.
Ca ne te coûtera pas cher de demander innocemment si les inconvénients de la vitesse de calcul plus lente et de l'occupation mémoire plus importante ne sont pas des soucis dans le cadre des applications que vous développez.
Souvent, quand ces problèmes de précision apparaissent, il y a des soucis de méthode de calcul derrière. Si on ne fait pas gaffe, la somme 1/1. + 1/2. + 1/3. + ... 1/n a l'air de converger quand on l'additionne de gauche à droite (les 1/k deviennent négligeables par rapport à ce qu'on a déjà cumulé), alors qu'en vrai c'est la série harmonique dont tout le monde sait qu'elle diverge.
Pour se sortir de ce genre d'embrouille, il ne suffit pas de décréter qu'on remplace les float par des double, il faut regarder beaucoup plus loin, dans la manière de calculer.
- Edité par michelbillaud 4 décembre 2021 à 19:07:11
Les floatn'existent pas pour rien. Leur intérêt est essentiellement leur taille. Sinon les double ont des avantages et sont à préférer: - ils sont plus précis que les float - ils sont la plupart du temps plus rapide car les coprocesseurs ne travaillent normalement qu'en double. - il y a souvent des conversions cachés de float/double/float quand on utilise les float.
Un exemple où les floatsont une perte:
extern float x;
float y = 2 * x; // le copro converti x en double, effectue le produit et le reconverti en float
std::cout << y; // tous les float sont convertis transmis double et reconverti float quand ils sont passés en paramètre
Les floatn'existent pas pour rien. Leur intérêt est essentiellement leur taille. Sinon les double ont des avantages et sont à préférer: - ils sont plus précis que les float - ils sont la plupart du temps plus rapide car les coprocesseurs ne travaillent normalement qu'en double. - il y a souvent des conversions cachés de float/double/float quand on utilise les float.
Un exemple où les floatsont une perte:
extern float x;
float y = 2 * x; // le copro converti x en double, effectue le produit et le reconverti en float
std::cout << y; // tous les float sont convertis transmis double et reconverti float quand ils sont passés en paramètre
Ça n'est pas le 2 le plus gros problème, et mon chiffre est très mal choisi. si on écrit 2, il doit y avoir conversion constante en 2.f. Si on écrit 2. l'effet est une conversion de x en double, puis conversion du résultat en float. Mais le compilateur "voit" qu'il peut ici simplifier par une addition et ôter les conversions. Avec d'autres valeurs, on voit le problème apparaître dans ta seconde fonction fd() qui elle doit faire la double conversion. Le processeur x64 peut effectuer directement des opérations sur des float, et il transmet les float comme double par xmm0. ça limite la pollution. De même l'optimiseur peut simplifier la conversion float/double/float au moment du std::cout mais ça n'est pas toujours le cas. Sur d'autres processeurs comme l'ARM32 l'effet peut être plus flagrant avec beaucoup d'appel à vcvt.
En recherche d'emploi.
Faut-il éviter le type float au profit des double?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
En recherche d'emploi.
En recherche d'emploi.