Données avec décimales : DECIMAL ou FLOAT ?

Version imprimable

19/09/2017, 12h39
splifferwolf

Données avec décimales : DECIMAL ou FLOAT ?

Bonjour à tous,

Je viens vers vous pour un problème de chiffres avec décimales.

Habituellement je met ma colonne en FLOAT, mais étrangement un chiffre tel que 95.47 se transforme en 95.50, ce qui est assez compliquer puisque c'est pour un module de comptabilité.

Donc ma question est : Est-ce normal cet arrondi à l'entier (0.47 -> 0.50)
Est-ce que si je configure mon champ en DECIMAL plutôt que FLOAT règlerai le problème ?
Si oui quel est exactement la différence entre FLOAT et DECIMAL puisque il sont sensé tout les deux enregistré des nombres avec décimales.

D'avance merci
Bien à vous
Spliffer
19/09/2017, 13h31
rawsrc

Salut,

tout est expliqué dans la doc MySQL par ici
Quand tu codes de la compta, tu dois garder une représentation exacte et non arrondie de tes valeurs numériques, donc exit le format FLOAT et bonjour le format DECIMAL.
19/09/2017, 13h36
Celira

Est-ce que le problème se produit uniquement avec une insertion depuis PHP ou également si tu essayes de faire la modification en direct sur la base (par PhpMyAdmin par exemple) ?

Si c'est uniquement en PHP, pourrais-tu nous montrer le code qui fait l'enregistrement ?
19/09/2017, 13h51
Invité

Citation:

Envoyé par rawsrc

donc exit le format FLOAT et bonjour le format DECIMAL.

Ah bon ? :koi:
J'avais cru le contraire... :weird:
Il va falloir que je revois certains de mes scripts.....
19/09/2017, 13h57
splifferwolf

Bonjour,

Actuellement la colonne est mit en FLOAT, et depuis phpmyadmin je modifie une ligne qui contient 47.50, j’introduis à la place 47.47 et une fois l'enregistrement effectué il m'affiche 47.50...

Merci pour le lien où tout est dit, sauf que je comprend pas l'anglais et que la traduction google translate est vraiment pas top, d'où le fait que je demande une explication sur les différence entre FLOAT et DECIMAL en français :p
19/09/2017, 14h08
Celira

Citation:

MySQL supports all standard SQL numeric data types. These types include the exact numeric data types (INTEGER, SMALLINT, DECIMAL, and NUMERIC), as well as the approximate numeric data types (FLOAT, REAL, and DOUBLE PRECISION).

De ce que je comprends de la phrase, DECIMAL est une valeur exacte alors que FLOAT est une valeur approchée.
Le problème étant que lorsque tu définis un champ DECIMAL en base, il faut que tu indiques le nombre de décimales et que ça a l'air de faire des arrondis si tu dépasses le nombre de décimales autorisées :koi:

Pour tester, je viens d'insérer 10 dans un champ DECIMAL (à 3 chiffres après la virgule) et dans un champ FLOAT. J'ai ensuite passé deux requêtes SQL : une qui divise les deux champs par 3 et une qui re-multiplie les deux champs par 3.
Au final, j'obtiens 9.999 pour le champ DECIMAL et 10 pour le champ FLOAT.

Donc, empiriquement, j'aurais tendance à dire que FLOAT est plus précis. :koi:

Amis de la rubrique SGDB, un avis sur la question ?

A noter que tout ça, c'est sans prendre compte le problème dans PHP...

Bonjour Celira,
j'ai tendance à penser comme toi... et je pense savoir pourquoi.

La confusion vient des expressions et COMPREHENSION de :

"valeur exacte" (Exact Value)
et "valeur approximative" (Approximate Value)

"valeur EXACTE" NE VEUT PAS DIRE "valeur JUSTE" !

En reprenant ton exemple :

en DECIMAL ("valeur exacte"), (10 / 3) affiche 3.333 exactement : la valeur a été ARRONDIE DEFINITIVEMENT à la 3ème décimale, sans plus rien derrière (la VALEUR est "EXACTE", mais le calcul n'est pas JUSTE !)
en FLOAT ("valeur approximative"), (10 / 3) affiche 3.333 MAIS vaut en réalité 3.3333333.... : donc 3.333 est "approximatif" !

Lorsqu'on re-multiplie par 3 :

en "valeur exacte", ((10 / 3) * 3) affiche 9.999 (exactement)
en "valeur approximative", ((10 / 3) * 3) affiche 10 (MAIS vaut en réalité 9.999999.... ARRONDI à 10, donc "approximatif") !

Sauf erreur de ma part,

il est plus correct de traiter/calculer les données en FLOAT qu'en décimal...
MAIS ATTENTION aux COMPARAISONS : en "valeur approximative", l'affichage "3.333" peut valoir en réalité 3.3331 ou 3.3330612 -> PAS POSSIBLE d'établir alors une EGALITE STRICTE.

On peut reproduire le phénomène en PHP :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 <?php $number = 10; $float = ($number/3); // float (par défaut) echo $float.' '; echo ($float*3) .' '; echo ' '; $decimal = (number_format( ($number/3), 3 ) ); // nombre à 3 décimales (arrondi : valeur EXACTE mais PAS JUSTE) echo $decimal.' '; echo ($decimal*3) .' '; ?>
on obtient :

Citation:

3.3333333333333
10

3.333
9.999

CONCLUSION :

l'EXACTITUDE d'un nombre n'a rien à voir avec la JUSTESSE (du calcul).

CQFD !
Ce Qu'un Fou Dirait :fou:

19/09/2017, 15h45
Invité
Citation:

Envoyé par rawsrc

Quand tu codes de la compta, tu dois garder une représentation exacte et non arrondie de tes valeurs numériques, donc exit le format FLOAT et bonjour le format DECIMAL.

C'est pour ça que pour les impôts, on nous demande la somme ARRONDIE à l'ENTIER le plus proche, mais pas à la 2ème décimale...

Quant au TTC, TVA, HT, il faut utiliser une des formules :
- (TVA) = (HT) * (tva%)
- (TTC) = (HT) + (TVA)
ou (en partant du TTC) :
- (TVA) = (TTC) * (1-tva%/100)
- (HT) = (TTC) - (TVA)
En clair : on ne calcule pas séparément la TVA et le HT, en espérant que la somme fasse le TTC...
19/09/2017, 15h46
splifferwolf

Voilà des explications bien claires, merci.

En revanche je ne comprend toujours pas pour quoi (directement dans phpmyadmin), quand je tape 47.47 il se transforme en 47.50 dans la colonne FLOAT à l'affichage alors qu'il n'y a aucuns calcul derrière ou formule mathématique.

Pour mon soucis j'ai tout mis en DECIMAL, et là quand je rentre 47.47 il m'affiche bien 47.47

Donc soucis résolu, maintenant pourquoi la colonne FLOAT transforme un 47.47 en 47.50, vos explications n'explique pas cela :D

Encore merci pour votre temps et ces explications qui m’ont fait comprendre certains mécanismes.

Bien à vous
Spliffer
19/09/2017, 15h51
rawsrc

tous les calculs doivent être faits en valeur décimale stricte arrondie (d'où le format DECIMAL) selon les règles d'arrondis définies par le ministère des finances par ici
L'utilisation de 6 décimales s'expliquent par le système international des taux de change.
C'est la raison pour laquelle lors du passage à l'euro, la conversion était de 1,000000 € = 6,559570 FRF

Comptablement, le cas des résultats à nombre irrationnel est clairement défini :
On applique un arrondi pendant les calculs :
10 / 3 = 3,333333 (représentation DECIMAL) et pas 3.333333333333333333 (représentation FLOAT)
Pour la suite du calcul on utilise : 3,333333 et pas 3.333333333333333333
L'écart de conversion est pris en compte par la comptabilité dans des comptes spécifiques.

Par ailleurs, ils est fortement recommandé (mais pas obligatoire) de calculer les éléments sur des agrégats. Par exemple pour la TVA : il est préférable de la calculer sur le total HT et pas individuellement sur les lignes HT de la facture. En vertu de l'application des règles d'arrondi, le calcul ligne par ligne propage une arrondi qui peut s'avérer être au détriment de l'administration.
19/09/2017, 15h51
Invité
Si tu ne nous montres pas la structure précise de ton champ en bdd, on ne peut pas en dire plus.

Je viens de faire un test avec un champ "test" en FLOAT (sans rien préciser de plus) : 50.47 affiche bien... 50.47 (dans phpMyAdmin) !
Tu as certainement autre chose....

Citation:

Envoyé par rawsrc

...L'utilisation de 6 décimales....

On est d'accord :
- on stocke en bdd à 6 décimales,
- on arrondi à 2 décimales A LA FIN des CALCULS (pour affichage)
19/09/2017, 16h23
SQLpro

Citation:

Envoyé par Celira

Pour tester, je viens d'insérer 10 dans un champ DECIMAL (à 3 chiffres après la virgule) et dans un champ FLOAT. J'ai ensuite passé deux requêtes SQL : une qui divise les deux champs par 3 et une qui re-multiplie les deux champs par 3.
Au final, j'obtiens 9.999 pour le champ DECIMAL et 10 pour le champ FLOAT.

Lorsque vous divisez par 3 un décimal doté d'une précision de 3 décimales après la virgule il respecte à la lettre les décimales indiquées. Or 10 / 3 = 3.333. Donc 3 * 3.333 = 9.999. Le résultat est parfaitement correct et totalement exact eut égard au respects des types de données.
En revanche, l'utilisation du FLOAT dont les nombres sont encodés en puissance de 2, donne des résultats approximatifs dès que l'on calcule avec des décimales et ceci parce qu'un chiffre à virgule exact en puissance de 10 peut s'avérer a virgule infinie en base 2. Un exemple est 0,2 qui en base deux s'écrit :
0.001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001001...

Malheureusement, la machine ayant 32 ou 64 bits commet une approximation et arrête son calcul à :
0.001001001001001001001001001001001001001001001001001001001001001 (64 bits)
Cette toute petite erreur, lorsqu'elle est cumulée donne des résultats faux et les comptables passent des nuits blanches a essayer en vain de récupérer les erreurs imbéciles que les informaticiens ignares ont fait trainer en modélisant mal leurs bases de données !

Citation:

Donc, empiriquement, j'aurais tendance à dire que FLOAT est plus précis. :koi:

Amis de la rubrique SGDB, un avis sur la question ?

A noter que tout ça, c'est sans prendre compte le problème dans PHP...

A +

PS : aujourd’hui les autorités financières exigent des logiciels certifiés capable de travailler avec au moins 12 décimales après la virgule. Compte tenu de certaines monnaies (dollar zimbabwéen par exemple...) il faut donc mettre du DECIMAL(50,12).
19/09/2017, 17h40
SQLpro

Citation:

Envoyé par rawsrc

Par ailleurs, ils est fortement recommandé (mais pas obligatoire) de calculer les éléments sur des agrégats. Par exemple pour la TVA : il est préférable de la calculer sur le total HT et pas individuellement sur les lignes HT de la facture. En vertu de l'application des règles d'arrondi, le calcul ligne par ligne propage une arrondi qui peut s'avérer être au détriment de l'administration.

Il n'y a aucune obligation de procéder ainsi, mais il est obligatoire que la règle de calcul soit la même appliquée partout. D’où l'intérêt de créer des vues de calcul et d'interdire l'accès aux tables pour les développements.

A +
19/09/2017, 23h38
JPLAROCHE

sur un calcul de masse j'ai eu ce problème

bonjour,

nous avons été confronté a un problème (nous travaillons en Décimal 11,15 pour chaque zones et une zone de travaille 15,21)
700 factures et faire une recape qui comporte 4 articles.
avec les arrondies

résultats les articles devait représenter la sommes total des articles de chaque factures . ainsi que le pied de facture.

normalement le client doit selon la loi toujours être avantagé.

le choix du client a été autre , voulant supprimer du personnel utilisait une machine qui enregistrait les factures et contrôlait avec le pieds de facture.

donc le client nous a imposée de refaire le pied de facture à partir de la récape. en tronquant touts les chiffres articles et pieds de facture de la récape.

je lui est signaler qu'il pouvait être perdant. Ok cela permettait de retomber sur ses chiffres (mais ce n'était pas la réalité)

mais le pieds de facture lui avait une dérive de 3 centimes en plus ou en moins ça c'était la réalité . plus le nombre est grands dans la masse traiter plus il peut y avoir
une dérive ,

sur l'ensemble de la conversion du Franc a € sur toute la compta nous avons eu 4 centimes d'écart sur le résultats du bilan, pour éviter les grands écarts nous avons travaillé avec des zones de tampon de base 11,2 et en traitement nous sommes passé a 18,10 pour la conversion et fait un arrondi sur de la zone de traitement sur 11,2 nous avons contrôler et sorti des états avec les deux chiffres F/€ car nous étions étonnés....
je précise le bilan était calculé à partir de la compta et pas fait dans un fichier en parallèle des écritures comptables, donc toujours cohérent avec la comptabilité.

la base du decimal sur cette machine était de trente et un chiffre significatif le float est beaucoup plus petit .

sur pc IBM a communiqué la possibilité de travaillé en DCML avec une possibilité de beaucoup plus je me suis limité dans cette exercice a une zone contenant 35 chiffres significatif .
mais elle permet de sortir un string donc .... à vous de voir .

autre exemple un compagnie achetait 3 tonnes de boulons en cuivre ,
il était impossible de valorisé le stock en boulons si l'on divisait le poids (car ils achetaient au poids ....) bref pas le prix que vous achetez le boulon.(sans valeurs marchandes €)
les décimales on bien montrés les incidents , et cette société vous facture le boulon et le travail de mise en place du boulon , quand j'ai refais les calcules ils ont tiré un jackpot et personne n'y voie rien ....
je ne faisait pas parti de cette société mais l'on m'avait posé cette colle pour expliquer le pourquoi du comment....

tout ça pour étayer la données décimal réel ne ce limite pas a 64 bit mais peut aller bien au delà , de toutes façons là on sort du traditionnel et on ce tourne vers la mathématique pure et dure , des lib vous sont mise a dispo dans GNU elles fonctionnes sur linux et windows personnellement j'ai choisi la solution IBM c'est aussi le choix d'un mathématicien allemand dont j'ai repris la class et adapter pour retrouver l’équivalence avec les gros system
si vous voulez avoir des renseignements sur une base de données consulter postgresql elle est bien fournie .....

@bientôt

juste un petit truc les banques travaille eux avec les virgules et ramasse tous ce qui n'est pas quantifiable pour l'être humain vous êtes vous posez la question pourquoi leurs formules ne sont pas divisible en € (soit avec 2 chiffre après la virgule qui tombe juste), maintenant pensez sur des millions de millions de traitement ce que l'on peux gagner .... je vous laisse rêver ou cauchemarder....
ils emploient des mathématiciens de haut niveau ..... pour vous en rendre compte analysez un prêt et regarder comment l'assurance calcul ses revenues il y a un vrais bémols. j'en ai parler avec ma banque seul réponse froide vous les informaticiens il est impossible de discuter vous fait C.... en plus admis par la loi , alors qu'il suffirait de faire remonter le problème... (entre parenthèse ça vous coûte un bras).
20/09/2017, 00h56
rawsrc

1 pièce(s) jointe(s)

@SQLpro

à la vache (comme celle en filigrane), je suis allé voir le dollar zimbabwéen et beeeehhh !!!
Tu m'étonnes qu'il faille un format décimal à 12 chiffres après la virgule, ils ont été capables de sortir un billet de cet acabit :

Pièce jointe 313024

je vous laisse compter les zéros ... Ce qui nous donne : cent mille milliards de dollars soit 10^14 $

C'est pas ça que l'on appelle sobrement du PQ ??? :ptdr:
20/09/2017, 10h06
Artemus24

Salut splifferwolf.

Citation:

Envoyé par splifferwolf

Donc ma question est : Est-ce normal cet arrondi à l'entier (0.47 -> 0.50)

Déjà, il ne faut pas confondre la représentation en mémoire des nombres et les arrondis. Ce sont deux choses différentes !

Citation:

Envoyé par splifferwolf

Est-ce que si je configure mon champ en DECIMAL plutôt que FLOAT règlerai le problème ?

La réponse a été donnée par rawsrc :

Citation:

Envoyé par rawsrc

Quand tu codes de la compta, tu dois garder une représentation exacte et non arrondie de tes valeurs numériques, donc exit le format FLOAT et bonjour le format DECIMAL.

Juste une petite précision, ce n'est pas une représentation arrondie mais une représentation approximative.

La différence est dans la représentation du nombre qui est stockée en mémoire.
Dans le cas du décimal sous mysql, la représentation est codé DCB pour décimal codé binaire (ou packed).
Un nombre code 3.14159 sera stockée selon le format que vous lui indiqué, par exemple ici, 5 chiffres après la virgule et au total 7 chiffres.
Comment cela se code en mémoire ? On remplace chaque chiffre par sa représentation hexadécimale.
Je rappelle qu'un hexadécimal, c'est du binaire qui est codifié que sur quatre bits, soit un valeur allant de 0 à 15.

1 --> 0001
2 --> 0010
3 --> 0011
...
7 --> 0111
8 --> 1000
9 --> 1001

Chaque chiffre utilise donc pour sa représentation quatre bits.
Votre nombre comprenant 6 chiffres aura une occupation mémoire de 6x4 bits soit 24 bits + le signe.

En ce qui concerne le flottant, la représentation mémoire est approximative car on cherche à représenter ce nombre sous la forme de puissance de 2.
Et vos puissances peuvent être négative. Ainsi votre nombre 0.5 a comme représentation 2^-1 soit 1/2. Votre exemple tombe juste
Mais si nous prenons 0.47, la représentation de ce nombre est infinie si on l'exprime sous forme de puissance de 2.
Où 0.47 = somme des 2 puissance i allant de + l'infinie à - l'infinie telle que cette somme soit inférieure ou égale à votre nombre, ce qui donne :
--> 1/4 + 1/8 + 1/16 + 1/1024 + ...
--> 0.4697265625

Et comme le stockage en mémoire est limitée à un certain nombre de bits, le nombre que vous obtenez est approximatif.
Pour l'exemple admettons que le stockage se fasse sur quatre chiffres après la virgule, ce qui donne : 0.4697.
Et qu'à l'affichage cela se fasse sur trois chiffres après la virgule.
L'arrondi au plus près, va se faire sur ce quatrième décimal et donne donc : 0.4697 + 0.0005 soit 0.4702
Et à l'affichage, vous aurez 0.470 soit 0.47.

Remarque : il y a toujours un arrondi qui se fait sur la représentation flottante.
A l'inverse aucun arrondi ne se fait sur la représentation décimale.

En résumé, quand vous faites un calcul genre comptable ou la précision est de rigueur, vous devez utiliser le type décimal.
Par contre, dans la notation scientifique où le résultat est approximatif, vous devez utiliser float ou double.

P.S.: avant le passage à l'euro, nous utilisions des devises comme la lire italienne.
En gros système, dans la représentation decimal (packed), nous stockions des nombres allant jusqu'à 8 octets, soit 16 héxadecimals.
Je rappelle que cela comprend la partie décimal (2 digits) et la partie entière (13 digits) et le signe (1 digit), soit un total de 16 chiffres digits (ou hexadécimal).
Or il se trouve que nous rencontrions des problèmes de stockage car nous étions confrontés à des montants gigantesques où le nombre pouvaient s'exprimer en millions de milliard de lire italienne, soit 15 chiffres en partie entières or nous en disposions que de 13.
Dans ce cas là, nous devions stocker le nombre en partie entière.

@+
22/09/2017, 16h50
JPLAROCHE

Citation:

Envoyé par Artemus24

Salut splifferwolf.

P.S.: avant le passage à l'euro, nous utilisions des devises comme la lire italienne.
En gros système, dans la représentation decimal (packed), nous stockions des nombres allant jusqu'à 8 octets, soit 16 héxadecimals.
Je rappelle que cela comprend la partie décimal (2 digits) et la partie entière (13 digits) et le signe (1 digit), soit un total de 16 chiffres digits (ou hexadécimal).
Or il se trouve que nous rencontrions des problèmes de stockage car nous étions confrontés à des montants gigantesques où le nombre pouvaient s'exprimer en millions de milliard de lire italienne, soit 15 chiffres en partie entières or nous en disposions que de 13.
Dans ce cas là, nous devions stocker le nombre en partie entière.

@+

ce n'est pas une critique

c'est pour cela par exemple qu'IBM a proposé sur 128 bit et un codage sur plus de 256 chiffres(et plus beaucoup plus) pour limité les dérives sur des nombres pas quantifiables mais significatif avec une autre définition que float ou double, dcml par défaut 31 chiffres (pour l'AS400) mais j'ai exploré sur PC et même as400 en c++ on peut aller beaucoup plus loin mais sur d’énorme calcul de masse après cela a un impacte sur le temps .
un prof de math Prof. Richard Kaiser avec son site http://www.rkaiser.de/ c'est servit de la mise a dispos gratuitement de cette lib pour expliquer les math...