Discussion :

[Jipété]

Bonjour,

Suite à des tests faits pour un autre problème (n'ayant rien à voir avec Lazarus), j'ai quand même découvert un truc bizarre dont je voulais vous faire part.

Posons le décor avec un extrait de l'aide (en rouge un truc rajouté par moi) :


Ce qui m'intéresse c'est la 3^e colonne, "Significant digits" : vous traduisez ça comment ? "Chiffres significatifs" ? Et les autres chiffres on en fait quoi ?
Et puis d'abord, pourquoi deux valeurs ? 7-8 pour le type Single, ça dépend de quoi ? De l'air du temps ? De l'âge du capitaine ? D'autre chose ?

Parce que ce matin, j'avais le nez dans des tests de divisions, et je vous laisse regarder les résultats de ShowMessage(FloatToStr(la_division)); en fonction du Type de la_division :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
avec 841.0 / 108.0    
 single 7.787036896           9 chiffres décimaux
 double 7.78703703703704     14 chiffres décimaux 
 
avec  16.0 / 116.0      
 single 0.137931034           9 chiffres décimaux
 double 0.137931034482759    15 chiffres décimaux 
 
avec 216.0 / 24389.0     
 single 0.00885645207        11 chiffres décimaux
 double 0.00885645167903563  17 chiffres décimaux

J'avoue ne pas comprendre cette 3^e colonne (c'est pas un film, ça ? )

[DomDA91]

Bonjour,

Ce qui m'intéresse c'est la 3^e colonne, "Significant digits" : vous traduisez ça comment ? "Chiffres significatifs" ? Et les autres chiffres on en fait quoi ?
Et puis d'abord, pourquoi deux valeurs ? 7-8 pour le type Single, ça dépend de quoi ? De l'air du temps ? De l'âge du capitaine ? D'autre chose ?

Je ne doute pas qu'un mathématicien ne puisse nous donner une explication dans un langage que seul un "matheux" pourrait comprendre mais à mon modeste niveau je vais tenter une explication fondée sur l'implémentation binaire des réels en point flottant et en simplifiant au maximum.

Je précise bien "en point flottant": Single, Double et Extended en sont (alors que Currency est un réel "point fixe" et Comp est une variante d'int64 spécifique au co-processeur arithmétique Intel). Avec FPC, le type Real lui est un allias pour Single, Double ou Extended selon la plateforme ciblée.

La représentation binaire d'un réel point flottant comprend trois champs :

• Un bit de signe
• Quelques bits pour l'exposant qui est en quelque sorte un facteur d'échelle par lequel doit être multiplié le significande.
• Les bits restants pour le significande (ou mantisse) qui représente les chiffres significatifs du nombre, indépendamment de la position de la virgule décimale (qui elle dépend de la valeur de l'exposant, d'où l'appellation "point flottant"). Le significande est en principe cadré de façon à ce que son premier bit à 1 de poids le plus fort coïncide avec le bit de plus haut rang de la zone.

Ce préalable étant posé prenons l'exemple du type Single :

Dans un Single le significande est codé sur 23 bits (avec 8 pour l'exposant et 1 pour le signe, celà fait 32 bits).

Par conséquent la valeur binaire des significandes utilisant la plage de précision maximale, c'est à dire la totalité des 23 bits disponibles, peut aller de (2 puissance 23) à (2 puissance 24)-1 ce qui en décimal représente un intervalle allant de 8 388 608 (7 chiffres décimaux) à 16 777 215 (8 chiffres décimaux), d'où le 7-8 figurant dans la 3ème colonne du tableau.

Raisonnement similaire pour Double (significande sur 52 bits) et Extended (significande sur 63 bits).

En conclusion, les tests de divisions présentés ne présentent pas pour moi d'anomalie flagrante en ce sens que c'est bien au niveau du 7ème ou 8ème chiffre significatif qu'apparait une divergence entre Single et Double (les zéros de tête, avant ou après le point décimal, doivent être considérés comme non significatifs). Tout au plus pourrait-on reprocher à FloatToStr(single) de générer trop de chiffres (9 ou 10) alors que l'on peut s'interroger sur leur exactitude au delà du 7ème ou 8ème.

[Jipété]

Bonsoir et merci pour cette réponse détaillée.

Il me reste un soupçon de brouillard, caché entre parenthèses :

(les zéros de tête, avant ou après le point décimal, doivent être considérés comme non significatifs).

Si ça ne t'ennuie pas, tu me feras un chèque de 0,9 € plutôt qu'un de 0,00000009 €, : ça sera plus vite écrit et tu feras des économies d'encre,

Ou je n'ai pas compris ce que tu veux dire (j'ai un peu wikipédié, mais les maths et moi, à ce niveau-là, je commence à avoir du mal...)

[DomDA91]

Désolé de n'avoir pas été clair. Ce que je voulais dire c'est que ces zéros à gauche ne s'imputaient pas sur l'encodage du significande, mais cela ne voulais pas dire qu'ils étaient complètement ignorés. En effet les zéros situés entre la virgule décimale et le premier chiffre non-zéro sont bel et bien pris en compte pour le calcul de l'exposant. C'est très apparent par exemple si on exprime ton exemple (0,9 et 0,0000009) en notation scientifique :

0,9 ---> 9E-1
0,00000009 --> 9E-8

Le 9 avant le E est le significande et est identique dans les deux cas.
C'est seulement l'exposant qui change et si on fait leur différence : (8 - 1 = 7) on à bien le nombre de zéros entre la virgule et le 9.

Par conséquent la précision du significande n'est pas diminuée par la présence des zéros et reste dans les deux cas à 7-8 chiffres décimaux pour un Single.

C'est à la routine de conversion qu'il incombe de correctement analyser le significande et l'exposant afin de re-générer les zéros qui manquent.

A ce propos, j'ai essayé le code suivant :

Code :

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

Edit1.Caption:= FloatToStr(Single(1 / 3));

et ça me renvoie : 0,3333333433

Curieux ce 4 au milieu des 3 ! Et en huitième position justement !
Pour Double c'est correct, il y a décidément quelque chose qui cloche dans cette routine.

[Jipété]

Désolé de n'avoir pas été clair.

Pas de souci.
Allez hop !,

C'est à la routine de conversion qu'il incombe de correctement analyser le significande et l'exposant afin de re-générer les zéros qui manquent.

A ce propos, j'ai essayé le code suivant :

Code :

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

Edit1.Caption:= FloatToStr(Single(1 / 3));

et ça me renvoie : 0,3333333433

Curieux ce 4 au milieu des 3 ! Et en huitième position justement !
Pour Double c'est correct,

Confirmé dans mon vieux 2.6.2/1.4

il y a décidément quelque chose qui cloche dans cette routine.

Au secours !


EDIT :
Bon, j'ai fait un test ultra-rapide en C, ça donne ça :

Code :

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

1
2
3
0.33333334326744079589843750000000
0.33333333333333331482961625624739
0.33333333333333331482961625624739

Le code :

Code C :

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
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
 
int main(int argc, char **argv)
{
//        taille mémoire --  précision (décimal)
  float f;  // 4 octets  --  6 chiffres après la virgule
  double d; // 8 "       -- 15 " "
  long double l; // 10 " -- 19 " "
 
  f = 1.0 / 3.0;
  d = 1.0 / 3.0;
  l = 1.0 / 3.0;
 
  printf( "%.32f\n",  f );
  printf( "%.32f\n",  d );
  printf( "%.32Lf\n", l );
 
	return 0;
}

Maintenant, si je respecte les infos de mon petit bouquin (C précis et concis, chez O'Reilly, pas tout jeune), je réécris avec

Code C :

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

1
2
3
  printf( "%.6f\n",  f );
  printf( "%.15f\n",  d );
  printf( "%.19Lf\n", l );

et tout va bien :

Code :

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

1
2
3
0.333333
0.333333333333333
0.3333333333333333148

Il faudrait peut-être s'astreindre à tronquer les résultats de FloatToStr en fonction du tableau que j'ai posté, non ?

[Pierre le Grand]

En utilisant ce code qui sert à évaluer la précision numérique, je n'ai pas été en mesure d’observer une différence significative entre les divers type de réels. C'était prévisible par ce que quelque soit le type de la variable x, elle subit une promotion en float lors de l'appel de la fonction LN.

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
 
TypeReel=single;
 
Function VerifierPrecisionNumerique:Extended;
 
CONST
  Limite= 1000000;
VAR
  x: TypeReel;
  Delta: Extended;
  i: Cardinal;
Begin
  Delta:=0.0;
  Randomize;
 
  FOR i:= 1 To Limite DO
  BEGIN
     x:=Random*10000+0.0000001;
     Delta+= ABS(TAN(ArcTAN2(SQRT(SQR(EXP(LN(x)))),1))-x);
  End;
 
  Result:=Delta
End;