Juste pour donner la raison de ce que tout le monde dit.
La représentation binaire d'un flotteur est plutôt ennuyeuse.
En binaire, la plupart des programmeurs connaissent la corrélation entre 1b = 1d, 10b = 2d, 100b = 4d, 1000b = 8d
Eh bien, cela fonctionne aussi dans l'autre sens.
.1b = .5d, .01b = .25d, .001b = .125, ...
Le problème est qu'il n'y a pas de moyen exact de représenter la plupart des nombres décimaux tels que .1, .2, .3, etc. Tout ce que vous pouvez faire est une approximation en binaire. Le système fait un peu de fudge-arrondi lorsque les nombres s'impriment pour afficher 0,1 au lieu de .10000000000001 ou .999999999999 (qui sont probablement aussi proches de la représentation stockée que .1)
Edit from comment: La raison pour laquelle c'est un problème est nos attentes. Nous nous attendons à ce que 2/3 soit truqué à un moment donné lorsque nous le convertissons en décimal, soit 0,7, 0,67 ou 0,666667 .. Mais nous ne nous attendons pas automatiquement à ce que 0,1 soit arrondi de la même manière que 2/3 - et c'est exactement ce qui se passe.
Au fait, si vous êtes curieux, le nombre qu'il stocke en interne est une pure représentation binaire utilisant une "notation scientifique" binaire. Donc, si vous lui dites de stocker le nombre décimal 10,75d, il stockera 1010b pour le 10 et .11b pour la décimale. Donc, il stockerait .101011 puis il économisait quelques bits à la fin pour dire: Déplacez le point décimal de quatre places vers la droite.
(Bien que techniquement ce ne soit plus un point décimal, c'est maintenant un point binaire, mais cette terminologie n'aurait pas rendu les choses plus compréhensibles pour la plupart des gens qui trouveraient cette réponse de n'importe quelle utilité.)