[PARADOX] Perte de précision avec SQL SUM dans TQuery

**freud** · 23/10/2019, 23h57

Bonsoir à tous,

Faire un SELECT SUM(CHAMP) FROM TABLE GROUP BY etc... dans une TQuery pour une table paradox ne donne pas le même résultat que de faire un SELECT CHAMP FROM TABLE et de sommer le champ dans une boucle WHILE la différence est par exemple :

1) pour SUM : 32456.23
2) pour WHILE: 32456,24 //est le chiffre exact que je devrais obtenir

Avec SUM même les fonctions d'arrondis n'ont pas d'effet.
Le champ est de type CURRENCY
Il me semble c'est un problème connu car y a des années je suis tombé, enfin si je me souviens bien,
sur des gens qui en parlent sur les forums es-ce que vous pouvez me confirmer cela SVP ?
Merci

**ALWEBER** · 24/10/2019, 09h01

Je pense qu'il s'agit de deux fonctions d'arrondi différentes. L'une qui tronque la décimale, l'autre qui arrondi cette valeur en n'oubliant pas que sous Paradox le nombre flottant (ce qui est le cas de currency) est stocké sur 32 bits. Regardes l'aide sur les fonctions ROUND et FLOOR transposées à la décimale choisie dans ton cas.
Rappel : Défaut du calcul sur les flottants.
L'exemple ci-dessous n'est pas particulier à Delphi. Le processeur effectue les calculs en base 2. On sait donc exprimer un demi, un quart, un huitième, etc. soit 1 / 2^n mais on ne sait pas décrire 1/10 ou 1/100 qui sont des nombres incommensurables en base 2. Voilà donc un résultat surprenant. Bien mettre le readln dans l'exemple DOS suivant afin que la valeur de i2 ne soit pas connue au moment de la compilation sinon le compilateur optimise. L'exemple est reproductible avec n'importe quel compilateur ou tableau excel par exemple (voir fichier ci-joint)

Code :

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

1
2
3
4
5
6
7
8
9
var
  i1, i2: Extended ;
 
begin
  readln (i2) ;
  i1 := i2 + i2 + i2 + i2 + i2 - 0.05 ;
  writeln (FloatToStr(i1));
  readln ;
end.