Problème avec le float

"456.700012 est le nombre exact le plus proche de 456,7"
Je ne comprend pas cette affirmation... : 456.700001 est encore plus proche de 456.7...

As tu lu l'article?

En reprenant l'écriture hexadécimale suivante : 9A 59 E4 43
En base 10 ce nombre est égal à :
somme(
9*16^7
10*16^6
5*16^5
9*16^4
14*16^3
4*16^2
4*16^1
3*16^0 )
= 2 589 582 403
Pourquoi vous trouvez que c'est égal à 456.700012207031?

9A 59 E4 43 = 2 589 582 403 si on considère des entiers où chaque bit représente une puissance de 2, or ici on parle d'un float, donc de la norme IEEE 754 comme indiqué dans l'article Wikipedia donné par Whismeril.

Il faut donc décomposer cette valeur en binaire pour en extraire, le signe S, l'exposant E et la mantisse M puis faire le calcul

(-1)^S * M * 2^(E-127)

pour en avoir un équivalent en décimal...

2 589 582 403 base 10
= 10011010010110011110010001000011 en base 2
Et que faire après?
Je suis désolé mais c'est la première fois que j'aborde ces termes...
Pouvez vous m'aider à résoudre un exemple puis cela m'aidera à généraliser?

Je suis pour l'instant en L1 info (je ne comprend pas les termes comme little ou big endian..).
Je pense que pour l'instant je vais laisser cela de côté car on n'a pas encore touché aux bits etc...
J'espère que tout cela sera abordé par la suite puisque c'est bien dommage de ne pas comprendre le fonctionnement des commandes :/

Merci quand même pour avoir essayer de m'expliquer le fonctionnement des nombres à virgule flottante :)

"Little endian octet de poids faible à gauche."
Penses-tu franchement que cela m'avance en quelque chose?
Maintenant cela m'oblige de voir ce qu'est un octet de poids faible.
On est dans des termes informatiques qui impliqueront de nouveaux.
Il est plus facile de traiter cette question lorsqu'on a des bases..

"Il est plus facile de traiter cette question lorsqu'on a des bases"
À toi de les acquérir ces bases → https://fr.wikipedia.org/wiki/Endianness

En gros ce que Whismeril veut dire, c'est que si tu ne lis pas les octets dans le bon ordre, ta décomposition en bits est fausse, donc tout le reste aussi.

12345 et 54321 ça n'a rien à voir... idem pour 9A59E443 et 43E4599A

Si je reprends l'impression écran de XVI32 ci dessous on voit que le fichier lit les 4 octets 9A 59 E4 43 en little indian, donc de droite à gauche, ce qui signifie que la valeur hexadécimale à lire est 0x43E4599A et c'est ce nombre qui vaut 456.7

C'est seulement si le fichier avait été lu en big indian qu'on aurait pu avoir une valeur hexadécimale correspond à 0x9A56E443 mais qui vaudrait -4.44E-23

Faut quand même savoir ce que tu veux, je te réponds, qu'en float, vu comment c'est code 456.7 n'existe pas et qu'en le plus proche est 456.70001.... et cette réponse ne te suffit pas.
Quand je détaille, la reponse est trop spécifique!

En plus tu as fait par toi même une conversion de d'hexa vers décimal, conversion pour laquelle la notion de poids fort et de poids faible est un pré requis, donc je ne voyait pas la nécessité de revenir dessus.
Donc le poids faible est le digit qu'en l'on multiplie par la base à la puissance 0, au final c'est celui qui à la plus petite influence sur le nombre global, en général, sur un entier le digit de poids faible influe sur +/- 1. À l'inverse, le digit de poids fort est celui à qui on appliquer la puissance la plus élevée, qui aura donc une forte influence sur le résultat.

Un octet est l'unité de base informatique, c'est 8 bits (d'ou le préfixe oct), il est majoritairement représenté sous forme d'un nombre hexadécimal de 2 caractères.

Le fait que le digit de poids faible soit à droite ou à gauche tient du fait que ce qui lu (flux ou fichier) sera placé octet par octet dans la mémoire vive et ce qui est lu en premier aura une adresse plus petite que ce qui,est lu en suivant. Ensuite c'est juste une histoire de convention, est ce qu'on calcul dans un ordre ou dans l'autre.