Virgule Flottante : Un casse-tête

[maxencefr]

Bonjour à tous,

Je viens vers vous aujourd'hui car je suis en train de péter un boulon sur les virgules flottantes ...

J'ai bien compris comment coder un tel nombre et ce n'est pas le but de ma question.

Mais, en regardant les tailles en bits des float et des int en C++, j'ai remarqué que la taille allouée pour un int est de 32bits et que cela permet de coder une plage de -2 147 483 648 à 2 147 483 647 soit 2^32 nombres.
Jusque là tout va bien. Mais j'ai aussi remarqué que la mémoire allouée pour un float est également de 32bits et que la plage que cela permet de coder est de -3.4*10^-38 à 3.4*10^38. Là est mon problème : je ne vois pas comment un nombre codé sur 32 bits peut permettre autant de possibilité sachant que le nombre maximum de combinaison que l'on peut faire est de 2^32 !!
Est-ce que les floats permettent de coder plus que 2^32 nombres sur 32 bits ? Et si oui comment cela est-il possible ?!

Je vous en supplie aidez moi ma tête est en train de tourner très vite ...

Merci beaucoup !
-----

[Paraboloide_Hyperbolique]

Bonsoir,

Non, les flottants sur 32 bits ne peuvent coder plus de 2^32 nombres. La différence entre entiers et flottants tiens à la manière dont sont interprétés les bits de données.

Dans les flottants, les bits de données sont séparés en deux catégories: les bits de la mantisse et les bits de l'exposant: nombre flottant .

Plus d'informations sur: https://fr.wikipedia.org/wiki/Virgule_flottante

Si un nombre flottant peut décrire de plus grand nombre que les entiers avec un même nombre de bits, cela signifie simplement qu'il y a des nombres qui ne sont pas décrits par les flottants, mais bien par les entiers (et inversement).

Pour les entiers, l'intervalle entre deux nombres consécutifs vaut 1. Pour les flottants, l'intervalle entre deux nombres consécutifs varie. Dans l'intervalle [-1, 1] il est d'environ (epsilon machine). Dans l'intervalle il est supérieur à 50000...

L'existence d'un epsilon machine non nul génère tout un tas de problèmes lorsque l'on fait du calcul numérique. Par exemple, il y a perte de l'associativité. Essayez par exemple sur votre calculette (en général les calculettes fonctionnent en double précision): et . Vous n'aurez pas la même réponse (alors que ces deux nombres sont égaux...)

[polo974]

les float (à éviter) et les double permettent de représenter une approximation des nombres avec un certain nombre de chiffres significatifs (et un exposant), tout ça en binaire (pour les float et double usuels)...

donc il est impossible de représenter exactement 1/5 en float ou en double (un peu comme 1/3 qui devient 0,3333 au lieu de 0,3333... en représentation décimale).

les float sont à éviter car en C, les calculs se font normalement en double, et donc il faut perdre du temps à convertir avant et après chaque calcul...
les float sont à éviter car la précision et la dynamique sont assez dérisoires.

les double ne font pas de miracle, il faut s'interdire de les utiliser pour de la compta...

mais on est bien content de les avoir...

[Bluedeep]

les double ne font pas de miracle, il faut s'interdire de les utiliser pour de la compta...

C'est bien pour cela que les langages plus orientés "gestion" disposent de format décimaux sans stockage mantisse-exposant, comme le decimal en C# (je suppose qu'il y a un équivalent en Java); de plus cela permet de se conformer aux types existant sur les bases de données.

[A voir en vidéo sur Futura]

[Arzhur]

(je suppose qu'il y a un équivalent en Java)

A ma connaissance il s'agit de BigDecimal....mais c'est très ch**** à utiliser.

[Bluedeep]

A ma connaissance il s'agit de BigDecimal....mais c'est très ch**** à utiliser.

Ce qui n'est pas le cas de decimal en C# (peut être à cause du "péché originel" de Java qui differencie les types intrinsèques des objets instanciables - ex: a dualité int / Integer - contrairement à C# qui a règlé dès l'origine le problème en différenciant les types "valeurs" et les types "réferences" - mais je dis "peut être" car ma connaissance de Java est plus que limitée ).

[WizardOfLinn]

Lorsqu'on a besoin de précision supérieure aux 'double' du C/C++, il y a des bibliothèques de calcul en multiprécision, comme GMP en C/C++.
Maintenant, pour de la gestion, ou de l'interface utilisateur, sans vraie contrainte d'efficacité, les types étendus de certains langages (decimal, etc.) doivent être suffisants.

[Thomas markley]

la différence entre un entier et un flottant, ce n'est pas la position de la virgule

[Jack]

les float sont à éviter car en C, les calculs se font normalement en double, et donc il faut perdre du temps à convertir avant et après chaque calcul...
les float sont à éviter car la précision et la dynamique sont assez dérisoires.

C'est vrai pour nos ordis actuels et donc avec tous les processeurs équipés d'une FPU. En revanche, sans FPU, éviter les doubles et les float si possible.

[PA5CAL]

Il est préférable d'éviter d'utiliser les nombres à virgule flottante dès lors que les valeurs calculées ont un impact sur le déroulement du programme.

En effet, bien souvent les nombres obtenus ne sont pas ceux attendus, simplement parce qu'en pratique l'arithmétique de ces nombres n'est pas exacte.

La toute première erreur provient souvent du fait qu'on entre les nombres en base 10 dans le programme ou dans l'interface utilisateur, alors que derrière l'ordinateur les manipule en base 2. Par exemple, on tend à oublier (ou à ignorer) que l'écriture exacte du nombre 0,2 n'existe pas en base 2 (de la même manière que 1/3 ne peut pas s'écrire en base 10). Donc assez souvent l'ordinateur ne traite pas les nombres qu'on pense lui avoir donnés, pas plus qu'il nous présente toujours vraiment ceux qu'il a obtenus.

Ensuite, les opérations introduisent des erreurs d'arrondi qui peuvent se propager en s'amplifiant durant les calculs successifs, de sorte que les résultats théoriques et les résultats obtenus peuvent présenter des différences notables. Dès qu'on met en œuvre des fonctions de seuil ou des tests d'égalité ou d'inégalité entre nombres à virgule flottante, le déroulement des programmes peut parfois prendre une tournure inattendue. Il faut d'ailleurs avoir une certaine dose d'humour pour accepter que +0 et –0 puissent être considérés comme deux valeurs différentes.

D'autre part, les arrondis réalisés par la FPU peuvent être différents entre deux machines matériellement différentes, ou entre deux machines identiques configurées différemment. Or, ce réglage est souvent hors de portée de l'utilisateur et du développeur. Il peut donc arriver que, dans deux environnements matériels et logiciels distincts, un même programme traitant les mêmes données puisse produire des résultats dissemblables, et donc se comporter différemment.

À mon avis, le pire, ce sont les langages de programmation qui ne proposent pas de typage des nombres et qui imposent l'utilisation des nombres à virgule flottante même lorsqu'on ne traite que des entiers. JavaScript fait partie de ceux-là.

[Bluedeep]

C'est vrai pour nos ordis actuels et donc avec tous les processeurs équipés d'une FPU. En revanche, sans FPU, éviter les doubles et les float si possible.

Ah ! La bonne époque où il fallait rajouter le "87" pour pouvoir avoir des perf de calcul flottant acceptables. (8087, 80187, 80287, 80387 et même 80487 SX pour le 80486SX - le 80486 "normal" étant le premier à FPU intégré).

[WizardOfLinn]

...
D'autre part, les arrondis réalisés par la FPU peuvent être différents entre deux machines matériellement différentes, ou entre deux machines identiques configurées différemment. Or, ce réglage est souvent hors de portée de l'utilisateur et du développeur. Il peut donc arriver que, dans deux environnements matériels et logiciels distincts, un même programme traitant les mêmes données puisse produire des résultats dissemblables, et donc se comporter différemment.
...

Ca fait une trentaine d'années que l'IEEE-754 a normalisé les modes d'arrondis, il ne doit plus rester beaucoup de machines qui font autrement.
En Visual C++, on a accès à ce niveau par la fonction _controlfp() (mais cette fonction parait spécifique à MSVC, pas sur qu'on la retrouve sous d'autres compilateurs, ou avec un nom différent).
Mais de toute façon, en dehors de quelques cas très particuliers (si on veut se faire un module d'arithmétique d'intervalles par exemple), la bonne programmation utilisant des flottants ne dépend pas des modes d'arrondi...

[Bluedeep]

Ca fait une trentaine d'années que l'IEEE-754 a normalisé les modes d'arrondis, il ne doit plus rester beaucoup de machines qui font autrement.

Pour la norme oui, mais de facto dès la fin des années 70, les versions shortIEEE (32 bits) et longIEEE (64 bits) étaient d'usage courant sinon universel - il y avait juste un peu de résistance avec les machines travaillant en EBCDIC.
Une autre exception à l'époque : certaines implémentations du langage Basic utilisaient un format un peu différent.

Mais de toute façon, en dehors de quelques cas très particuliers (si on veut se faire un module d'arithmétique d'intervalles par exemple), la bonne programmation utilisant des flottants ne dépend pas des modes d'arrondi...

Il y a eu néanmoins un bug sur les premières versions de l'Intel Pentium concernant les nombres à virgules flottantes

[WizardOfLinn]

...
Il y a eu néanmoins un bug sur les premières versions de l'Intel Pentium concernant les nombres à virgules flottantes

Je m'en souviens ! Branle-bas de combat à l'époque dans la société dans laquelle je travaillais, sur du logiciel de simulation scientifique, appels des clients inquiets, etc.
Pirouette pour les rassurer : d'éventuelles erreurs sont noyées dans le bruit statistique intrinsèque à nos méthodes de calcul (du Monte-Carlo)

[lou_ibmix_xi]

Je pense que tout est dit ou presque...

3 petit compléments
- la virgule fixe est en générale une alternative préférable à la virgule flottante lorsque la dynamique est bornée
- la lecture de cette doc me semble indispensable dès qu'on joue sérieusement avec la virgule flottante
- un outils pour tester la conformité IEEE754 de la plateforme (matériel + compilateur) ici, j'encourage d'ailleurs la lecture de son site et de son bouquin "Safer C" qui devrait être le 2nd bouquin à trôner sur l'étagère de tout développeur C un peu sérieux, juste à côté du K&R

[Jack]

Ah ! La bonne époque où il fallait rajouter le "87" pour pouvoir avoir des perf de calcul flottant acceptables. (8087, 80187, 80287, 80387 et même 80487 SX pour le 80486SX - le 80486 "normal" étant le premier à FPU intégré).

En effet, mais c'est à quelque chose de plus moderne que je pensais: tous les processeurs, notamment les microcontrôleurs, ne possèdent pas de FPU. Certains d'ailleurs possèdent tellement peu de ressources mémoire que l'on ne peut même pas déclarer un float.

PS: déclarer et évidemment tenter de faire la moindre opération avec.

[Bluedeep]

En effet, mais c'est à quelque chose de plus moderne que je pensais: tous les processeurs, notamment les microcontrôleurs, ne possèdent pas de FPU. Certains d'ailleurs possèdent tellement peu de ressources mémoire que l'on ne peut même pas déclarer un float.

En effet; mais j'avoue que ce domaine m'est totalement étranger.

[PA5CAL]

Ca fait une trentaine d'années que l'IEEE-754 a normalisé les modes d'arrondis, il ne doit plus rester beaucoup de machines qui font autrement.
En Visual C++, on a accès à ce niveau par la fonction _controlfp() (mais cette fonction parait spécifique à MSVC, pas sur qu'on la retrouve sous d'autres compilateurs, ou avec un nom différent).
Mais de toute façon, en dehors de quelques cas très particuliers (si on veut se faire un module d'arithmétique d'intervalles par exemple), la bonne programmation utilisant des flottants ne dépend pas des modes d'arrondi...

Le fait qu'on ait normalisé les options d'arrondi ne signifie pas qu'on utilise forcément les mêmes, toujours et partout. Il est un fait que depuis trente ans, et même encore très récemment, dans mes projets j'ai souvent été amené à traiter ces différences de configuration entre les plateformes à cause des problèmes qu'elles pouvaient entraîner.

Le choix de ces modes reste souvent inaccessible pour les logiciels, soit parce que le langage de programmation ne prévoit pas d'y donner accéder, soit parce que leur niveau d'exécution ne les autorise pas à effectuer les vérifications ou les réglages nécessaires.

La "bonne programmation" est donc parfois tout bonnement impossible à réaliser, faute d'avoir un contrôle suffisant sur les environnements d'exécution (ou de développement) présents (ou futurs) du code source qu'on écrit.

Une "meilleure" programmation consiste, comme je le suggérais, à éviter autant que faire se peut de recourir aux nombres à virgule flottante lorsque les résultats sont susceptibles de modifier le comportement du système. Et quand on ne peut pas faire autrement, il faut savoir anticiper et contourner les problèmes, même si pour cela on doit transformer ce qui aurait dû être un petit programme simple en une monstrueuse usine à gaz .

[WizardOfLinn]

Je suis tout à fait d'accord, et il n'est pas surprenant d'arriver à des codes assez complexes lorsqu'on gère correctement les erreurs d'arrondis, ce sont des problèmes que je rencontre tous les jours.
Je voulais dire que dans un code de haut niveau, le flot d'exécution principal ne devrait pas dépendre du mode d'arrondi actif à un instant donné, ce serait une indication que les erreurs d'arrondi n'ont pas été gérées correctement. L'influence des modes d'arrondi devrait rester confinée à des fonctions de bas niveau.