Choisir entre float et double ne consiste pas simplement à prendre le type qui occupe le moins de mémoire. La précision, les erreurs d’arrondi, les performances et la nature des données changent réellement le résultat d’un programme. Je vous propose ici une comparaison concrète, avec des chiffres, des exemples de code et des critères simples pour faire le bon choix.
Le bon type dépend surtout de la précision réellement nécessaire
- Float utilise généralement 32 bits et offre environ 7 chiffres significatifs.
- Double utilise généralement 64 bits et conserve environ 15 à 16 chiffres significatifs.
- Float réduit la mémoire consommée dans les grands tableaux et certains calculs graphiques.
- Double est le choix prudent pour les calculs scientifiques, géométriques ou financiers intermédiaires.
- Aucun des deux ne représente parfaitement la plupart des décimales comme 0,1.
float vs double pour choisir la bonne précision
Dans la plupart des langages issus de la famille C, float correspond à une précision simple et double à une précision double. Sur une machine courante, cela signifie respectivement 32 bits et 64 bits, selon le format binaire IEEE 754 utilisé par le compilateur et le processeur.
| Critère | float | double |
|---|---|---|
| Taille courante | 4 octets | 8 octets |
| Précision décimale approximative | 7 chiffres significatifs | 15 à 16 chiffres significatifs |
| Valeur maximale courante | Environ 3,4 × 1038 | Environ 1,8 × 10308 |
| Usage typique | Graphismes, capteurs, grands tableaux | Sciences, géométrie, calculs généraux |
| Coût mémoire pour 1 million de valeurs | Environ 4 Mo | Environ 8 Mo |
Ces chiffres décrivent le cas le plus courant, pas une règle universelle valable dans tous les langages. Le standard C et le standard C++ imposent des propriétés minimales, tandis que Java définit plus strictement les formats float 32 bits et double 64 bits. Pour un code portable, je vérifie donc toujours la documentation du langage et du compilateur utilisés.
Le mot « double » ne signifie pas que toutes les opérations deviennent deux fois plus rapides ou deux fois plus exactes. Il indique surtout une représentation disposant de davantage de bits significatifs, ce qui réduit l’erreur d’arrondi et élargit la plage de valeurs représentables.
La précision n’est pas la même chose que la valeur maximale
Une confusion revient souvent. Une valeur peut être très grande tout en perdant les unités ou les décimales qui l’accompagnent. Pour un programme, conserver les chiffres importants est généralement plus utile que pouvoir représenter un nombre théoriquement gigantesque.
Pourquoi 0,1 devient parfois une valeur approximative
Les nombres flottants sont stockés en base 2, alors que nous écrivons habituellement les nombres en base 10. Des valeurs comme 0,5 sont faciles à représenter en binaire, mais 0,1 ne possède pas de représentation binaire finie. Le programme conserve donc la valeur la plus proche disponible.
double resultat = 0.1 + 0.2;
printf("%.17f\n", resultat);Sur de nombreux environnements, l’affichage produit une valeur proche de 0,30000000000000004. Ce résultat n’indique pas une panne du processeur. Il montre simplement que deux approximations binaires ont été additionnées, puis affichées avec suffisamment de chiffres pour révéler l’écart.
Passer de float à double réduit fortement cette erreur, mais ne la supprime pas. Les deux types utilisent une arithmétique flottante. Pour comparer deux résultats, j’utilise donc souvent une tolérance plutôt que l’opérateur d’égalité directe.
double difference = fabs(a - b);
if (difference < 1e-9) {
printf("Les valeurs sont suffisamment proches\n");
}La valeur de 1e-9 n’est pas magique. Elle doit dépendre de l’échelle des données et du niveau de précision attendu. Dans certains calculs, une tolérance absolue suffit. Dans d’autres, il faut aussi une tolérance relative pour traiter correctement des nombres très petits ou très grands.
Les valeurs spéciales font partie du problème
Les formats IEEE 754 savent aussi représenter l’infini, zéro négatif et NaN, qui signifie « Not a Number ». Une division par zéro, une racine carrée invalide ou une opération contaminée par un NaN peut donc propager une valeur inattendue dans toute une chaîne de calcul.
Je recommande de tester ces cas aux frontières d’un programme, surtout lorsqu’une donnée vient d’un capteur, d’un fichier ou d’une API. Une précision plus élevée ne corrige pas une entrée invalide.
Dans quels cas float est réellement pertinent
Le type float prend tout son sens lorsque le programme manipule de très nombreuses valeurs et que chaque valeur n’a pas besoin de 15 chiffres significatifs. Une matrice graphique, un nuage de points 3D ou un flux de mesures peut contenir plusieurs millions de nombres. Diviser la taille de chaque élément par deux réduit alors la pression sur la mémoire et les transferts.
Pour un tableau d’un million de valeurs, la différence théorique est d’environ 4 Mo contre 8 Mo. Sur un tableau isolé, ce gain semble modeste. Dans une application de rendu, de simulation ou d’intelligence artificielle qui conserve plusieurs buffers, il peut devenir déterminant.
Graphisme, audio et apprentissage automatique
Les moteurs 3D utilisent souvent float pour les positions, vecteurs, couleurs et matrices. La précision d’environ 7 chiffres significatifs suffit fréquemment pour une scène de taille raisonnable, tandis que le GPU peut traiter davantage de valeurs par transfert.
On retrouve aussi float dans certains traitements audio, les données de capteurs et les réseaux neuronaux. Dans ces domaines, le débit et la consommation mémoire peuvent compter davantage qu’une précision maximale. Il faut toutefois surveiller les scènes gigantesques, les coordonnées très éloignées de l’origine et les longues accumulations, où les erreurs deviennent visibles.
Un float n’est donc pas automatiquement plus rapide. Sur un processeur moderne, les opérations double peuvent être très efficaces, et le goulot d’étranglement peut venir du réseau, des accès mémoire ou des conversions. Je mesure toujours le programme avant de transformer uniformément tous les doubles en floats.
Quand double reste le choix le plus raisonnable
Pour un calcul généraliste, je choisis habituellement double par défaut lorsqu’aucune contrainte claire ne justifie float. Les 15 à 16 chiffres significatifs offrent une marge confortable pour les divisions, les coordonnées, les statistiques et les calculs répétés.
Cette marge est particulièrement utile lorsqu’un résultat est réutilisé plusieurs fois. Une petite erreur dans une première étape peut être amplifiée par une boucle, une interpolation ou une série d’additions. Double ne rend pas le calcul exact, mais il repousse beaucoup plus loin le moment où l’erreur devient gênante.
Géométrie, simulation et données scientifiques
Les calculs de distance, d’intersection, de trajectoire ou de transformation géométrique peuvent accumuler des écarts. Dans une simulation, une différence minuscule répétée sur des milliers d’itérations peut modifier l’état final. Double est souvent le compromis prudent entre coût et stabilité numérique.
Il est aussi préférable lorsqu’une application mélange des valeurs d’échelles très différentes. Un même algorithme peut manipuler une grande coordonnée, une petite variation et un seuil de comparaison. Une précision limitée risque alors de faire disparaître la petite variation pendant une opération.
Et pour les prix et les montants
Ni float ni double ne sont le choix idéal pour représenter directement une somme en euros. Pour une comptabilité, une facture ou un solde, j’utilise plutôt un type décimal lorsque le langage en propose un, ou des entiers exprimant les centimes.
Par exemple, 19,99 € peut être stocké comme 1999 centimes. Cette méthode évite qu’une approximation binaire transforme une règle d’arrondi commerciale en résultat contestable. Double peut convenir dans une étape intermédiaire d’analyse, mais je ne le traiterais pas comme une représentation monétaire exacte.
Les erreurs de code qui font perdre la précision
Le choix du type n’est qu’une partie du problème. Les conversions implicites, les littéraux et les comparaisons peuvent dégrader le résultat avant même que le calcul principal commence.
Comparer directement deux nombres flottants
Écrire a == b après plusieurs opérations est risqué. Deux calculs mathématiquement équivalents peuvent suivre des chemins d’arrondi différents. Une comparaison avec une tolérance adaptée au contexte est généralement plus fiable.
Convertir trop tôt vers float
Une conversion de double vers float élimine immédiatement une partie des chiffres significatifs. Revenir ensuite vers double ne les récupère pas. Le programme possède alors un double plus grand en mémoire, mais contenant déjà une information arrondie.
double valeur_precise = 12345678.123456;
float valeur_reduite = (float) valeur_precise;
double retour = valeur_reduite;La dernière variable est bien un double, mais elle ne retrouve pas la précision originale. Je conserve donc les données dans le type le plus précis jusqu’au moment où la réduction est réellement nécessaire.
Oublier le type par défaut des littéraux
Dans plusieurs langages, un nombre décimal écrit comme 1.5 est interprété comme un double par défaut. En Java, il faut généralement ajouter le suffixe f pour écrire explicitement un float, comme dans 1.5f. Cette règle évite certaines conversions implicites, mais elle peut aussi surprendre lors d’une affectation.
Lire aussi : Développement IoT - Du prototype au produit fiable et sécurisé
Additionner toujours dans le même ordre
Avec les flottants, l’addition n’est pas parfaitement associative. Selon l’ordre des opérations, le résultat final peut légèrement changer. Pour additionner un grand volume de mesures, une méthode de compensation comme l’algorithme de Kahan peut réduire la perte de petits termes, même si elle ne remplace pas un choix de type cohérent.
Une méthode simple pour décider entre les deux
Je prends ma décision avec quatre questions concrètes, plutôt qu’en partant d’une préférence générale pour la vitesse ou la mémoire.
- Combien de chiffres significatifs le résultat doit-il conserver ? Si sept chiffres suffisent, float peut convenir. Sinon, je pars sur double.
- Combien de valeurs seront stockées simultanément ? Des millions de valeurs peuvent rendre l’économie de mémoire de float intéressante.
- Le calcul est-il répété ou sensible aux seuils ? Les itérations, intersections et accumulations favorisent double.
- Les données représentent-elles de l’argent ou une quantité exacte ? Dans ce cas, je préfère decimal ou des entiers, pas un flottant binaire.
La règle pratique est assez nette. Utilisez float pour les volumes importants et la précision suffisante, notamment en graphisme, en traitement de signal ou dans certains modèles d’IA. Utilisez double pour le calcul général et les résultats sensibles. Utilisez enfin un type décimal ou entier pour les montants qui doivent respecter exactement les règles financières.
Dans un projet existant, je ne remplace pas tous les types à l’aveugle. Je mesure la mémoire, le temps d’exécution et surtout l’écart numérique sur des données réalistes. Un test avec des valeurs extrêmes révèle souvent plus qu’une optimisation théorique.
Le meilleur choix se confirme avec un test numérique ciblé
Entre float et double, le compromis oppose principalement mémoire et débit à précision et marge de sécurité. Dans le doute, double constitue le choix le plus confortable pour les calculs ordinaires, tandis que float devient très intéressant quand la taille des données ou les contraintes matérielles dominent.
Le test décisif consiste à comparer les deux versions sur vos propres entrées, vos boucles et vos seuils métier. Si l’écart reste acceptable et que la mémoire compte réellement, float est pertinent. Si le résultat influence une décision, une position ou une accumulation importante, je conserverais double.
