Discussion:Virgule flottante

calcul de l'exposant

-18,75 en 32 bits:
18d = 10010b
0,75d = 2**-1 + 2**-2 = 1/2 + 1/4 = 0,11b
---> 18,75d = 10010,11b =  1,001011 * 2**4
Signe: Négatif      = 1
Exposant: 4        = 4d + 7Fh = 83h = 100 000 11 b     
Mantisse: 001011   = 001 0110 0000 0000 0000 0000
DONC, -18,75 = 1 10000011 001011 000 000 000 000 000 00(binary) ou  C196000(hexa)
bit number      =1 23456789 012345 678 901 234 567 890 12 = 32bits              

Pourquoi ajouter 7Fh (0111 1111b) ?

• Non signé le 17 août 2006 à 15:09 par 195.167.202.147

Cette explication se trouve dans IEEE 754. PolBr (discuter) 1 mai 2021 à 10:12 (CEST)

Problème dans l'article

Je cite : "Il est aujourd'hui très rare que des programmes utilisent la simple précision".

A mes yeux ça me semble une chose complètement fausse. Les cartes graphiques n'utilisent que des flottants simples, toute la programmation graphique se base sur les flottants simples, faites donc des recherches dans les libraries, vous verrez que dans 95% des cas, on se contente des flottants simples. Sans oublier bien sûr l'aspect non thread-safe des double sur les architectures 32 bits qui rend leur utilisation plus dangereuse. Dans des langages à la syntaxe proche du C (C++, C#, ...), ce type est désigné par le mot-clef "float", et dire qu'il est "très rare", c'est n'avoir jamais touché à une librairie comme DirectX ou OpenGL par exemple. Emmanuel Bossière ^→Contact, le 30 juillet 2007 à 12:16 (CEST)

Phrase obscure

"En revanche, le format à virgule flottante occupe un peu plus de place, car il est nécessaire d'encoder la position de la virgule (représentée par l'exposant). Pour le même espace disponible, la virgule flottante offre donc une étendue de nombres plus grande au détriment de la précision."

La première phrase semble être en contradiction avec la deuxième. Il faudrait expliciter un peu plus la raison du "donc". Maïeul (discuter) 8 août 2014 à 13:39 (CEST)

binades / octaves

Binades me semble un terme propre à la norme IEEE. Octave, en musique et en acoustique, correspond à un rapport de 2 entre fréquences. Il me semble donc naturel de l'employer en informatique pour une plage de valeurs [n 2n]. --Lf69100 (discuter) 3 octobre 2016 à 01:03 (CEST)

Non, le terme binade n'est pas propre à la norme IEEE et n'est même utilisé nulle part dans la norme. Il y a des articles qui emploient ce terme sans être dans le cadre de la norme IEEE, e.g. Nombre de solutions dans une binade de l'équation A^2+B^2=C^2+C. Le terme octave est utilisé en musique et en acoustique, mais je ne l'ai jamais vu utilisé en informatique dans le domaine de l'arithmétique des ordinateurs. Vincent Lefèvre (discuter) 3 octobre 2016 à 01:29 (CEST)

réels vs virgule flottante

Présenter la virgule flottante comme représentation des nombres réels est problématique (ou, si l'on veut plus commercial que mathématique) : une virgule flottante donnée ne code strictement qu'une famille finie de rationnels, dépendant de sa base, qu'on peut voir comme représentations au sens de Hurwitz des autres rationnels et irrationnels du même domaine. Il s'agit alors de codages toujours précis sans être exacts, et l'écriture d'un nombre lu n'est jamais loin du nombre initial. (peut-être faudrait-il utiliser comme base une primorielle comme 30 ?)

Les mises en garde de la version anglaise sont justifiées, et les réserves de la version allemande plus profondes.

--Lf69100 (discuter) 9 janvier 2017 à 11:19 (CET)

Supprimé cette assimilation très abusive, avec les justifications nécessaires. PolBr (discuter) 29 avril 2021 à 20:40 (CEST)

@PolBr Il fallait garder la référence aux réels, en rephrasant: le but de la virgule flottante est bien d'approcher des réels, par opposition à l'arithmétique entière, qui est de calculer sur des entiers, à l'arithmétique rationnelle, qui est de calculer sur des rationnels, et quand on parle simplement de virgule flottante, on considère que les valeurs sont des réels (particuliers), par opposition aux nombres complexes. Juste dire "nombre" est beaucoup trop vague. Il faudrait aussi revoir la définition de "mantisse" (significande): ce n'est pas forcément un entier; on peut l'écrire sous différentes formes. — Vincent Lefèvre (discuter) 29 avril 2021 à 23:44 (CEST)

1. J'ai créé une section pour préciser le rapport entre la notation en virgule flottante (ensemble fini et valeurs discontinues) et les nombres réels (ensemble infini et valeurs continues), en m'efforçant de trouver des sources — abondantes dans les années de l'introduction de ce format. Je crois que personne ne pensera, en lisant les premières lignes, que cette notation est une approximation de nombres complexes.
2. Seuls les logiciel de maths, capables de transformer des expressions sans transformer un symbole (x, π) en valeur approchée traitent des réels. Les calculs informatiques concernent le plus souvent des grandeurs pourvues d'une dimension et d'une incertitude, résultats (entiers) de comptage ou de mesure.
3. La relation avec la notation scientifique est bien plus pertinente. Complète, elle comprend une incertitude (dans le Vocabulaire international de métrologie, 1.2345e6(2) désigne une valeur située entre 1234300 et 1234700), par défaut, 1.2345e6 signifie 1.23450e6(5), et suivant la même norme 1.0000e6 ne signifie pas la même chose que 1.0e6.
4. La mantisse est un entier. L'informatique ne traite que des entiers, comme l'indiquent tous les ouvrages mathématiques consacrés aux conditions de convergence des séries, de stabilité des algorithmes, de décidabilité, de calculabilité, qui ont à s'occuper de l'influence des arrondis. D'ailleurs, Stella Baruk, Dictionnaire de mathématiques élémentaires [détail des éditions] dit la même chose des décimaux, et il s'agit d'enseignement au niveau collège.
5. On peut bien entendu écrire la mantisse comme on veut, « douze mille trois cent quarante cinq », 12345e0, 0.12345e5 , 1.2345e4, 12.345e3 sont des écritures valides dans différents systèmes, mais la mantisse est toujours une valeur entière, quelle que soit la convention pour l'exposant.

Cordialement, PolBr (discuter) 30 avril 2021 à 09:18 (CEST)

Si on écrit les flottants sous la forme 1.2345e4, la mantisse est 1.2345, donc pas un entier. Pour info, voici la définition de significand (le terme anglais standard pour mantisse) par la norme IEEE 754: "A component of a finite floating-point number containing its significant digits. The significand can be thought of as an integer, a fraction, or some other fixed-point form, by choosing an appropriate exponent offset. A decimal or subnormal binary significand can also contain leading zeros, which are not significant." Donc tout d'abord, c'est vu comme une suite de chiffres; après, cela peut être vu comme un entier, une fraction ou forme en virgule fixe (par exemple, avec un chiffre avant la virgule). — Vincent Lefèvre (discuter) 30 avril 2021 à 13:04 (CEST)

« can be thought of » : c'est exactement ce que je vous dis. Le codage en virgule flottante est un fait de la machine, et celle-ci n'a pas de virgule. La mantisse est un entier, et l'exposant dit par quel nombre ou quelle fraction il convient de le multiplier. Dire que la mantisse peut être vue ne dit pas qu'il faut ajouter à l'explication simple, rigoureuse et valable pour tous les types de notation virgule flottante des interprétations compliquées pour s'adapter à la présentation de diverses conventions sur l'exposant (« appropriate exponent offset »).

Cordialement, PolBr (discuter) 30 avril 2021 à 14:05 (CEST)

Il n'est dit nulle part que c'est un entier. — Vincent Lefèvre (discuter) 30 avril 2021 à 19:22 (CEST)

Que si. Déjà cités. PolBr (discuter) 30 avril 2021 à 19:54 (CEST)

Et non seulement un entier, mais un entier naturel PolBr (discuter) 30 avril 2021 à 20:38 (CEST)

Relisez la norme IEEE 754. Vous racontez n'importe quoi. — Vincent Lefèvre (discuter) 30 avril 2021 à 21:04 (CEST)

Les textes d'analyse précisent que la notation en virgule flottante désigne un rationnel, autant dire un quotient de deux entiers. La mantisse est un entier naturel. L'exposant détermine un coefficient multiplicateur ou diviseur, c'est un entier relatif qu'un algorithme relie à la puissance à laquelle il faut élever la base. Un multiplicateur supplémentaire affecte le signe. Tout ça est parfaitement clair, général, et il n'y a pas lieu de vous laisser aller à l'invective.

Franchement, n'y a-t-il pas des choses plus importantes à faire remarquer sur les nombres en virgule flottante ? Les questions d'arrondi et de précision sont loin d'être simples, quand on regarde le détail. C'est sur ce sujet que les requêtes aux moteurs de recherche produisent. PolBr (discuter) 30 avril 2021 à 22:09 (CEST)

Je répète: relisez la norme IEEE 754. Il y a aussi la norme C, qui définit la mantisse simplement comme une suite de p chiffres, où p est la précision. — Vincent Lefèvre (discuter) 30 avril 2021 à 22:25 (CEST)

Quelle rédaction proposez-vous ? PolBr (discuter) 1 mai 2021 à 07:34 (CEST)

Diagramme

Le diagramme donne la formule 1,3254 = 13254 * 10^-4

avec mantisse et exposant corrects pour une représentation virgule flottante A MANTISSE ENTIERE, style Burroughs/CDC, contraire à la norme.

Elle suggèrerait plutôt 1325,4 = 1,3254 * 10^3, de mantisse 1,3254 et d'exposant 3.

--Lf69100 (discuter) 16 février 2017 à 16:49 (CET)

Oui, le diagramme est ambigu. Mais il n'est pas contraire à la norme, qui spécifie les deux conventions: virgule juste après le premier chiffre du significande et significande entier. Et il y a une troisième convention (utilisée par le C et par GNU MPFR): virgule juste avant le premier chiffre du significande. Vincent Lefèvre (discuter) 18 février 2017 à 12:19 (CET)

Sommation par algorithme de Kahan

 Vincent Lefèvre : Bonjour, À propos de l'algorithme de Kahan pour la sommation de listes de nombres en virgule flottante, vous me corrigez en écrivant «, de sorte que l'erreur finale est en général beaucoup plus petite. » à la place de « de sorte qu'elle ne s'accumule pas ». Cela me paraît inapproprié.

1. « de sorte qu'elle ne s'accumule pas » décrit le raisonnement, pas son effet ;
2. je n'y connais pas assez pour oser affirmer quoi que ce soit, mais je demande à voir le cas où l'erreur finale n'est pas beaucoup plus petite avec l'algorithme de Kahan, que sans compensation de l'erreur, ce que semble indiquer votre formule. L'article en anglais dit assez clairement que la compensation de l'erreur obtient toujours de meilleurs résultats que rien du tout.

Cordialement, PolBr (discuter) 21 décembre 2021 à 16:34 (CET)

Bonjour PolBr ,

1. Si on considère la somme s+c de l'algorithme de Kahan modifié (qui doit être s−c dans l'algorithme de Kahan d'origine, à vérifier), la borne d'erreur est en O(n·u²). Il y a bien accumulation des erreurs, mais au second ordre. Le 2u correspond au fait que le terme d'erreur approchée c n'est pas retourné par l'algorithme.
2. Dans chacun des algorithmes, il y a en pratique une compensation partielle des erreurs, car en général elles ne sont pas du même signe. Je pense qu'on doit pouvoir construire un cas où le résultat exact serait proche du milieu de deux nombres machine consécutifs (cas typique pour construire des contre-exemples liés aux arrondis), et où l'algorithme de base renverrait le résultat correctement arrondi, mais l'algorithme de Kahan reverrait l'autre nombre machine. À noter que dans un tel cas, les valeurs absolues des erreurs de ces deux algorithmes seraient très proches l'une de l'autre, toutes deux approximativement ½ulp.

Cordialement, — Vincent Lefèvre (discuter) 21 décembre 2021 à 21:58 (CET)

Bonjour

1. Je ne sais à quel texte vous faites allusion.
2. Dans le cas que vous évoquez, qui est optimal pour l'addition naïve puisque les erreurs se compensent spontanément, les deux algorithmes sont à égalité, et désigneront au hasard l'un des deux floats encadrants, selon la disposition générale de la liste. Mais ce cas est parfaitement artificiel. Il rappelle ce qu'on pratique pour obtenir des valeurs moyennes sur un grand nombre de mesures, avec une précision supérieure à celle de la mesure elle-même, en ajoutant délibérément du bruit au signal (dither). Mais il s'agit de somme de nombres entiers, pour lesquels on dispose de formats de précision illimitée, et tout ce que montre l'exemple, c'est que les floats ne sont pas appropriés pour cet usage.

• J'ai cru bon d'indiquer que la somme par l'algorithme de Kahan était bien plus fiable que la sommation naïve. Il s'agit d'un article d'introduction aux nombres en virgule flottante, dont un des problèmes est que la présentation de ces nombres comme des réels persiste dans l'esprit de nombreuses personnes qui ont fait leur apprentissage en physique avec la calculette. Avec des raffinements, des « mais » et des « il se peut », on ne réfute pas l'idée que la sommation naïve introduit ou amplifie des erreurs ; en traitant celles-ci à égalité avec celles qui subsistent après l'application de l'algorithme de Kahan (alors qu'on a élevé au carré la borne d'erreur, passant de 10^-15 à 10^-30), on insinue qu'il ne fonctionne pas. Si on veut examiner dans le détail ses performances, il faut laisser dans l'article Virgule flottante une simple mention, et écrire l'article Somme de nombres en virgule flottante, alias algorithme de sommation de Kahan. Respectueusement, PolBr (discuter) 22 décembre 2021 à 11:14 (CET)

 PolBr : Bonjour,

1. Je me référais à notre Handbook of Floating-Point Arithmetic. Mais il suffit de remplacer s par sum pour obtenir les notations de l'article Kahan summation algorithm; j'y ai ajouté la version avec Fast2Sum (présente dans notre Handbook), qui a l'avantage d'être nettement plus compréhensible (les calculs sont les mêmes au signe de c près). Pour l'erreur ci-dessus, par rapport à l'article WP, j'ai utilisé u (définition standard) au lieu de ε (qui a deux définitions possibles, avec un facteur 2 entre les deux, donc à éviter).
2. Un contre-exemple fabriqué pour serait effectivement artificiel, mais il me semble qu'il n'est pas prouvé que l'algorithme de Kahan fonctionne nécessairement mieux que l'algorithme naïf sur des cas particuliers qui n'auraient rien d'artificiel: il arrive que pour certains problèmes, la somme exacte soit très petite, voire nulle, du fait des données du problème (noter que celui qui conçoit un tel code n'est pas forcément au courant). Dans un tel cas, il n'est pas du tout certain que l'algorithme de Kahan diminue nécessairement l'erreur. Attention, dans l'analyse d'erreur, la borne d'erreur a en facteur la somme des valeurs absolues; si cette somme est beaucoup plus grande que la somme des valeurs signées, on ne peut plus affirmer grand chose avec cette analyse.

Cordialement, — Vincent Lefèvre (discuter) 23 décembre 2021 à 01:44 (CET)