Discussion :

[User]

Bonjour,

Je vous propose un nouvel article : « Représentation des nombres en machine : précision, limites et pièges ».

L'objectif est d’expliquer les différences entre les nombres en mathématiques et leur représentation en machine, en mettant l’accent sur les nombres à virgule flottante, la norme IEEE 754 et les erreurs numériques associées.

Il s’adresse à des développeurs ayant des bases en programmation et vise à rendre accessibles des notions souvent sources de confusion (par exemple : pourquoi 0.1 + 0.2 ≠ 0.3).



Le contenu couvre :

• les bases de la représentation binaire ;
• le fonctionnement des nombres flottants ;
• la structure IEEE 754 ;
• les erreurs d’arrondi et leurs conséquences ;
• ainsi que quelques notions plus avancées (cancellation catastrophique, perte de précision, somme de Kahan).

Tous les exemples sont réalisés en Python, mais les concepts présentés sont transposables à la plupart des langages.

Bonne lecture

[Guesset]

Bonjour,

Très bonne idée, car c'est un sujet intéressant assez négligé.

Il y avait un bouquin de Philippe Darche "Architecture des ordinateurs - représentation des nombres et codes" chez Gaétan Morin éditeur. Je ne sais pas, s'il est toujours disponible (il date de 2000), mais les normes restent des normes.

Par exemple, c'est ainsi que j'ai découvert que 0 en double a la même représentation que 0 en entier 64 bits alors que la norme lui donne théoriquement une valeur infime, mais non nulle (il y a toujours un 1 implicite devant la mantisse).

Pour les comparaisons, il faut cependant remarquer que la norme est suffisamment bien faite pour que la relation d'ordre soit respectée même en pratiquant une comparaison comme si c'était entre entiers (donc rapide).

Salutations

[User]

Bonjour et merci !

Il y avait un bouquin de Philippe Darche "Architecture des ordinateurs - représentation des nombres et codes" chez Gaétan Morin éditeur. Je ne sais pas, s'il est toujours disponible (il date de 2000), mais les normes restent des normes.

Oui apparemment dans son livre Philippe Darche explique comment créer des architectures qui puissent s'adapter au flottants (niveau matériel), tandis que pour nous développeurs c'est comment gérer au mieux les problèmes rencontrés avec les flottants (les bonnes pratiques, ..) pour concevoir des programmes fiables (niveau logiciel). Mais bien sûr toute la partie représentation binaire des flottants ça doit être la même chose.

Par exemple, c'est ainsi que j'ai découvert que 0 en double a la même représentation que 0 en entier 64 bits alors que la norme lui donne théoriquement une valeur infime, mais non nulle (il y a toujours un 1 implicite devant la mantisse).

Ah oui à cause du 1 implicite, je l'ignorais ..

Cordialement

[OuftiBoy]

à toutes et tous,

L'article est très bien fait, et explique pourquoi les float et les double dans un langage comme le C peuvent être dangereux et produire des résultats avec une précisions difficilement maîtrisable.

Lorsque que l'auteur dit que le type décimal de Python est moins performant qu'un type flottant, il a raison, mais il manque une information.

Sur de vieux µC, certains avaient un type BCD (Binary Coded Decimal), et leur utilisation était bien pratique, car ces vieux µC n'avaient pas de FPU (Floating Point Unit) hardware, et que leur lenteur rendait impossible une émulation software d'un FPU.

Les BCD sont utilisés non pas pour avoir "la meilleur précision possible", mais avoir la "précision désirée". C'est une nuance importante, car les arrondis dans le domaine de la finance (par exemple) impose de faire des arrondis d'une certaine manière.

De nos jours, on ne parle plus trop des BCD, mais on parle de FPN (Fixed Point Number), qui sont une manière simple et performante pour effectuer des calculs sur des nombres réels en ayant la précision désirée. Les FPN utilisent un type entier, font toutes leurs opérations uniquement avec des entiers et sont donc bien plus performants que l'utilisation de type float ou double.

Dans un FPN utilisant un entier 16-bits, le MSB (Most Significiant Bit) représente le signe. Il reste donc 15 bits pour représenter la valeur du réel. Une partie de ces 15-bits (disons 11) peuvent être utilisés comme représentant la partie entière du réel, et les 4-bits restant représentent la partie fractionnaire. Ceci est possible car dans ce cas, on définit OU SE TROUVE LA VIRGULE qui sépare la partie entière de la partie fractionnaire. Elle n'occupe aucun 'bit'.

Les deux parties d'un FPN sont exploités en Base 10 (Décimal). La seule contrainte est que pour que les opérations faites sur les entiers qui représentent ces FPN soient corrects, il faut que la POSITION DE LA VIRGULE soit la même pour les variables participant à une expression. On parle ici de Scaling. On peut trouver des références au sujet des BCD (qui étaient effectués en HARDWARE) et des FPN (qui sont effectués en SOFTWARE) sur le net.

Je me suis intéressé à ce sujet car je développe un langage qui inclus des entiers et des FPN (qui peuvent faire le même travail que les BCD d'autrefois). Il existe peut-être des CPU pouvant travailler nativement (gravé dans leur sicilium) avec des BCD et/ou des FPN, mais je n'en ai pas connaissance (et je n'ai pas cherché non plus...).

Pour étendre le sujet, il y a beaucoup d'erreurs qui restent possibles même si on ne travail qu'avec des types CLASSIQUES, hérités des types MACHINES, comme des erreurs TYPE UNDERFLOW ou OVERFLOW. Mon langage (Home) apporte des solutions et son compilateur permet de bien mieux sécuriser l'utilisation de simples entiers. Mais c'est un autre sujet...

BàV, merci pour l'article et Peace & Love.

[Guesset]

Bonjour,

Il reste, dans les processeurs x86 et amd64, des reliquats de BCD avec les instructions d'ajustement (AAA, AAD, AAM, AAS, DAA, DAS). L'un des A signifie ASCII, car l'un des avantages du BCD était sa lisibilté sans conversion sur un dump hexadécimal. C'est un avantage qui, jadis, était important.

Aujourd'hui, pour les calculs financiers, il existe le type currency. C'est un entier 64 bits qui représente l'unité de compte en 1/10000^e (autrement dit en virgule fixe à 4 digits après la virgule).

Salutations

[OuftiBoy]

Guesset,

Aujourd'hui, pour les calculs financiers, il existe le type currency. C'est un entier 64 bits qui représente l'unité de compte en 1/10000^e (autrement dit en virgule fixe à 4 digits après la virgule).

Merci pour l'info. Dans quel langage ce type currency est-il disponible svp ? Cela m'intéresserait d'y jeter un oeil. Et ce langage, permet-il de créer d'autres types (en virgule fixe) pour qui soient adapté à un usage dans un domaine bien précis ? Si oui, j'aimerai regarder la syntaxe utilisée pour ce faire.

BàV et Peace & Love.

[XeGregory]

Bonjour,
Merci pour le partage !

Pour compléter : même en EduCode, on retrouve exactement le même phénomène, car les nombres décimaux sont représentés en machine sous forme de flottants binaires (approximation), d’où le fait que 0.1 + 0.2 ne tombe pas forcément exactement sur 0.3.

Voici un petit code EduCode qui le montre, et surtout la bonne méthode de comparaison (à epsilon près), car comparer des flottants avec = est une source classique d’erreurs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// --- Demonstration : nombres en machine (EduCode) ---
 
aa, bb, cc est un nombre
somme, diff, diff_abs, epsilon est un nombre
 
aa vaut 0.1
bb vaut 0.2
cc vaut 0.3
 
somme vaut aa + bb
diff vaut somme - cc
 
affiche 'aa + bb = ' + somme
affiche 'cc      = ' + cc
 
// Comparaison stricte (souvent FAUX avec des flottants)
si somme = cc alors
  affiche 'Egalite stricte : VRAI'
sinon
  affiche 'Egalite stricte : FAUX (approximation binaire)'
fin si
 
// Valeur absolue
si diff < 0 alors
  diff_abs vaut -diff
sinon
  diff_abs vaut diff
fin si
 
epsilon vaut 0.0000001
 
// Bonne pratique : comparaison avec tolérance
si diff_abs < epsilon alors
  affiche 'Comparaison epsilon : VRAI (≈)'
sinon
  affiche 'Comparaison epsilon : FAUX'
fin si

Il est essentiel, et le rappel "ne pas comparer naïvement des flottants" est un vrai réflexe de développeur.

Comparer avec une tolérance manuelle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var
  a, b, c, s, eps: Double;
begin
  a := 0.1; b := 0.2; c := 0.3;
  s := a + b;
  eps := 1E-12;
 
  if Abs(s - c) < eps then
    Writeln('Comparaison epsilon : VRAI (≈)')
  else
    Writeln('Comparaison epsilon : FAUX');
 
  Readln;
end.

[Guesset]

...Dans quel langage ce type currency est-il disponible svp ?...

En type natif, il existe en Pascal (Delphi et FreePascal), mais il y a des équivalents en C++ (COle Currency class - MS, System.Currency - Embarcadero...). Les autres langages ont certainement un équivalent, mais je ne pratique pas suffisamment les calculs financiers pour l'assurer.

Pour les arrondis, et simplifier les choses , les banques pratiquent souvent l'arrondi variable pour xyz.5 cent à xyz+1 si z impair et xyz si z pair (ou l'inverse). Le but étant d'éviter un biais statistique et non d'avoir une précision accrue.

Comme les calculs monétaires sont majoritairement linéaires, on pourrait imaginer un type fractionnaire (i.e. 2 entiers P/Q). Chaque calcul intermédiaire donne une nouvelle fraction, toujours normalisée en fraction irréductible. Seul l'affichage présente un calcul arrondi (ou une demande expresse d'arrondi).
Il y a un risque de croissance excessive des deux entiers si les renormalisations n'ont pas d'effet (P et Q déjà premiers entre eux), mais c'est assez facile à détecter quitte à forcer un arrondi. Les erreurs existent toujours, mais leur présence diminue sensiblement. Prenons l'exemple d'un article à 1087.05 sur lequel s'applique un rabais de 11% puis une TVA de 20%. S = 108705/100 = 21741/20, R = 11/100, T = 20/100 = 1/5. S_R = S*(1-R) = 21741/20 * 89/100 = 1934949/2000, S_RT = 1934949/2000 * 6/5 =5804847/5000. Sous cette forme, le résultat est exact. Une forme I + P'/Q (1160+4847/5000) peut reporter les limites, mais au prix d'une place mémoire encore accrue.

La vraie difficulté me semble de se fixer une limite.

Salut

[laurent_ott]

Bonjour,
Le type Currency est disponible aussi en VBA (programmation Excel, Access, etc).
La documentation précise :
"Les variables monétaires sont stockées sous forme de nombres 64 bits (8 octets) au format entier, mis à l’échelle de 10 000 pour donner un nombre à point fixe avec 15 chiffres à gauche de la virgule décimale et 4 chiffres à droite.
Cette représentation fournit une plage de -922 337 203 685 477,5808 à 922 337 203 685 477,5807.
Le type de données Currency est utile pour les calculs impliquant de l’argent et pour les calculs à virgule fixe dans lesquels la précision est particulièrement importante."

[User]

Bonjour,

Le type monétaire a aussi ses défauts : par exemple, imaginons une remise de 1/3 sur 10,00 euros (le 3e gratuit). Si on cumule ce type de remise les comptes ne sont plus très justes avec 2 ou même 4 décimales.

[OuftiBoy]

User,

Le type monétaire a aussi ses défauts : par exemple, imaginons une remise de 1/3 sur 10,00 euros (le 3e gratuit). Si on cumule ce type de remise les comptes ne sont plus très justes avec 2 ou même 4 décimales.

Je fais peut-être erreur, mais cela dépend comment l'on compte cette remise.

Si on divise chaque article par 3, et que la "remise" est la somme de 3 * 1/3, on aura peut-être (a vérifier) une valeur différente que si la remise est de 1/3 de la somme du prix des 3 articles. Mais ici, ce n'est pas une erreur de calcul à cause du type monétaire, mais ce sont 2 manières différentes d'appliquer la remise, me semble-t-il.

Les 2 méthodes du calcul de la remise produiront un résultat peut-être différent, mais tous les deux avec la précision désirée par l'utilisation du type monétaire.

Mon raisonnement est-il juste ?

BàV et Peace & Love.

[Guesset]

Bonjour,,

Si le ratio est bien une cause d'erreur d'arrondi, je ne pense pas qu'il concerne une remise. Celle-ci est une offre commerciale qui présente un prix de vente réel même si il est le fruit d'un arrondi. A partir de là, c'est ce prix qui sera la référence, indépendamment de la manière dont il a été établi (rabais fixe, pourcentage, tirage au sort etc.). Il n'y a donc pas d'erreur d'arrondi. C'est juste un prix qui chasse l'autre, comme dans une remise négociée.

Salutations

[Informt2025]

Merci pour l'info. Dans quel langage ce type currency est-il disponible svp ?

C'est un type natif en Windows il est disponible dans le systeme pour formater un texte d’ailleurs on trouve dans les Optons Régionales le symbole monétaire utilisé dans ce sens, ce type supporté par tous les COM , ActiveX , si tu as Excel tu peux essayer VBA ou simple le VBS.

Et ce langage, permet-il de créer d'autres types (en virgule fixe) pour qui soient adapté à un usage dans un domaine bien précis ?

Pratiquement tous les langages modernes permettent le surcharge des opérateurs cela permet la création de nouveaux types qui n'existent pas et les configurer avec n'importe quels autres types.. parmi eux C++ C# Delphi Python

[User]

Bonjour,

User,

Je fais peut-être erreur, mais cela dépend comment l'on compte cette remise.

Si on divise chaque article par 3, et que la "remise" est la somme de 3 * 1/3, on aura peut-être (a vérifier) une valeur différente que si la remise est de 1/3 de la somme du prix des 3 articles. Mais ici, ce n'est pas une erreur de calcul à cause du type monétaire, mais ce sont 2 manières différentes d'appliquer la remise, me semble-t-il.

Les 2 méthodes du calcul de la remise produiront un résultat peut-être différent, mais tous les deux avec la précision désirée par l'utilisation du type monétaire.

Mon raisonnement est-il juste ?

BàV et Peace & Love.

Je pensais plutôt à la remise appliquée par article :

Prix de l'article après remise : 10 * 2/3 = 6.666.. euros, on arrondit à 6.67.

Pour 10 articles : 6.67 * 10 = 66.7 au lieu de 66.67

Mais en fait il s'agit plus d'une décision commerciale.

Edit :
Pour préciser ma réponse une info supplémentaire :

Dans des systèmes ERP (en finance ou en comptabilité) les prix après remise peuvent être stockés avec plus de 4 décimales pour garantir la précision des calculs internes.

Cdlt

[OuftiBoy]

Informt2025,

C'est un type natif en Windows il est disponible dans le systeme pour formater un texte d’ailleurs on trouve dans les Optons Régionales le symbole monétaire utilisé dans ce sens, ce type supporté par tous les COM , ActiveX , si tu as Excel tu peux essayer VBA ou simple le VBS.Pratiquement tous les langages modernes permettent le surcharge des opérateurs cela permet la création de nouveaux types qui n'existent pas et les configurer avec n'importe quels autres types.. parmi eux C++ C# Delphi Python

.

Ce que je désirais savoir, c'est si un type de base, natif "currency" existe et dans quel langage. Il est évidemment possible, dans tout langage, de créer ce genre de type, mais si cela est fait de la sorte, (via une classe en POO), il y a forcément un impact sur les performances. Ce que je cherche a savoir c'est si un "type de base" de genre "currency" (ou plus généralement BCD ou FPN), exploitant directement les instructions assembleurs d'une plate-forme existe. Dans le C/C++/Delphi (des langages qui se compilent en code machine) est-ce cas ?. Python étant un langage dynamique, il ne rentre pas en compte, me semble-t-il. De même, les COM, ActiveX, Excel, VBA ou VBS ne sont pas non plus compilés nativement..

BàV et merci de votre participation. Peace & Love.

[Guesset]

Bonjour,

Mettons de côté les langages interprétés, ceux travaillant sur machine virtuelle, ou avec un code intermédiaire, ils ne correspondent pas aux critères de code natif.

Les types générés au sein d'un langage objet d'un langage compilé seront bien en code natif, mais pourront pâtir des coûts d'appels de méthodes (mais pour les plus petites existe le mode inline qui peut faire disparaître une partie des coûts d'appel).

Est-ce discriminant ? Ce n'est pas sûr. Il y a des types de base qui sont déjà des objets sans que cela ne perturbe personne (les chaînes de caractères et les types heure-date par exemple). Il y a aussi des fonctions qui n'en sont pas réellement (les "intrinsics" de MS et les "not a real function" de Delphi et d'autres).

Dans le cas d'un type nouveau déclaré dans langage compilé, la perte de performances sera de quelques % par rapport à un type natif ce qui est très faible comparé aux langages de scripts.

La solution d'inventer un nouveau langage (compilé bien sûr ) ayant ce type currency s'inscrit dans un calendrier long avant d'avoir un compilateur efficient.

Pour répondre à la question, le currency de Delphi/FreePascal est un type natif de ce langage compilé.

Salutations

[Informt2025]

Ce que je désirais savoir, c'est si un type de base, natif "currency" existe et dans quel langage.

Puisque d’après qu'il parait que tu es débutant en programmation si tu cherche un syntaxe clair donc comme indiqué regarde tu coté Delphi ou son équivalent libre Lazarus.

mais si cela est fait de la sorte, (via une classe en POO), il y a forcément un impact sur les performances.

Les types passés par valeur sont créés sous forme de record qui sont nettement plus rapide, il est également possible d'utiliser des fonctions inline qui place le code directement à l'invocation et évite les appels aux fonctions.

[OuftiBoy]

Informt2025,

Puisque d’après qu'il parait que tu es débutant en programmation

Pas vraiment, j'ai 35 ans d'expériences dans le développement de firmware pour des petits µC, aux ressources très limitées. Je m'intéresse aux anciens systèmes qui avaient ce type BCD dans leur assembleur, dans leur cpu. Je m'y intéresse pour des raisons de documentation pour un langage que je développe (et son compilateur), j'ai écrit un RTOS, et l'assembleur je connais assez bien aussi. J'ai fais mes gammes sur un C64 ;-) ça remonte déjà.

BàT et Peace & Love.

[Informt2025]

Probablement tu n'étais pas très impliqué dans le développement applicatif ce qui explique que tu connaisses moins sur ce type et les langages qui le supportent. Si le but est d'implémenter un type du genre float16 ou float24 pour un compilateur que tu développes, il n'est pas nécessaire de changer de langage de programmation. Il suffit de créer une structure (ou une classe) et d'y intégrer le code gérant les opérations visées. Même si le temps d'exécution de ces opérations est "lent" cela n'impactera que la phase de compilation (lors d'évaluation des expressions constantes) et l'exécution finale aura lieu sur le uC, sachant que dans une source le nombre d'expressions constantes ou statiques à évaluer est très limité.

Un exemple de la creation d'un type TFixed à deux chiffres sur 16bits
le code est sous Lazarus mode Delphi

Code pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
type   {Grande partie Gemeni}
   TFixed2 = record
   private
     RawValue: SmallInt; // Stocke la valeur * 100
   public
     // Conversion depuis et vers Double
     class operator Implicit(a: Double): TFixed2; overload;
     class operator Implicit(a: TFixed2): Double;  overload;
 
     // Opérateurs arithmétiques
     class operator Add(a, b: TFixed2): TFixed2;
     class operator Subtract(a, b: TFixed2): TFixed2;
     class operator Multiply(a, b: TFixed2): TFixed2;
     class operator Divide(a, b: TFixed2): TFixed2;
 
     function ToString: string;
   end;
 
 { Implémentation des opérateurs }
 
 class operator TFixed2.Implicit(a: Double): TFixed2;
 begin
   Result.RawValue := Round(a * 100);
 end;
 
 class operator TFixed2.Implicit(a: TFixed2): Double;
 begin
   Result := a.RawValue / 100.0;
 end;
 
 class operator TFixed2.Add(a, b: TFixed2): TFixed2;
 begin
   Result.RawValue := a.RawValue + b.RawValue;
 end;
 
 class operator TFixed2.Subtract(a, b: TFixed2): TFixed2;
 begin
   Result.RawValue := a.RawValue - b.RawValue;
 end;
 
 class operator TFixed2.Multiply(a, b: TFixed2): TFixed2;
 begin
   // On multiplie, puis on divise par 100 pour garder l'échelle
   Result.RawValue := Round((a.RawValue * b.RawValue) / 100);
 end;
 
 class operator TFixed2.Divide(a, b: TFixed2): TFixed2;
 begin
   // On multiplie le numérateur par 100 avant de diviser
   Result.RawValue := Round((a.RawValue * 100) / b.RawValue);
 end;
 
 function TFixed2.ToString: string;
 begin
   Result := FloatToStrF(Self.RawValue / 100, ffFixed, 8, 2);
 end;
 
procedure TForm1.Button1Click(Sender: TObject);
var
  f1, res: TFixed2;
  D: Double;
begin
  D := 15;
  f1 := 10;
  res := f1+ D ; // 10.00 * 15
  showmessage(res.ToString);// affiche 25
  res := res / f1;   // 25.00 / 10.00
  showmessage(res.ToString);// affiche 2.5
end;