[Datatype] limite des types float, double et decimal

Version imprimable

19/03/2013, 17h24
yolepro

[Datatype] limite des types float, double et decimal
Bonjour,

Pour des raisons d'harmonisation dans notre système d'information, nous mettons en place un format pivôt sous forme d'object XSD (ComplexType).

j'essaie de fournir des bonnes pratiques pour les éléments de grammaire commune (montant, taux, date, période, code,...).

J'ai un problème de compréhension de la notice WC3 sur les datatypes:
http://www.w3.org/TR/2001/REC-xmlsch...10502/#decimal
http://www.w3.org/TR/2001/REC-xmlsch...0010502/#float
http://www.w3.org/TR/2001/REC-xmlsch...010502/#double

Je ne comprends pas bien les limites lié au type double et decimal?
- Combien peut-on avoir au final de chiffre dans un decimal (avant et après la virgule)?
- Est-ce qu'un double est aussi précis qu'un decimal?
- Est-ce que le double authorise la transmission de fraction (1/3, 2/3,...) notamment pour les % (ratio)
- Si non, existe-t-il un autre type le permettant?
- Quel sont les contraintes en termes d'implémentation en Java lié à l'utilisation d'un double plutôt que d'un decimal?
En vous remerciant par avance pour vos réponses eclairées.

Cordialement,

Yolepro.
20/03/2013, 09h59
thelvin

Bonjour,

Citation:

Envoyé par yolepro

Combien peut-on avoir au final de chiffre dans un decimal (avant et après la virgule)?

Autant qu'on veut. Il n'y a pas de limite.

Citation:

Envoyé par yolepro

Est-ce qu'un double est aussi précis qu'un decimal?

Ben du coup non, decimal ayant une précision théorique infinie, alors que double est le classique IEEE 754. Mais ça reste sacrément précis.

Citation:

Envoyé par yolepro

Est-ce que le double authorise la transmission de fraction (1/3, 2/3,...) notamment pour les % (ratio)

Nope. Notation scientifique seulement.

Citation:

Envoyé par yolepro

Si non, existe-t-il un autre type le permettant?

Pas à ma connaissance, mais ça pourrait exister sans que je le sache. Sans doute pas dans les versions de XML Schema gérées actuellement, par contre.

Citation:

Envoyé par yolepro

Quel sont les contraintes en termes d'implémentation en Java lié à l'utilisation d'un double plutôt que d'un decimal?

Le double me semble en fait plus simple, puisqu'il correspond directement au type double Java (avec quelques propriétés différentes, mais l'ensemble des valeurs possibles est le même, lui.)

decimal correspond au type Java BigDecimal, moins souvent intégré, plus compliqué d'emploi et moins performant. En général il n'y a pas de problème, mais bon, il y a plus de chances d'en avoir de ce côté-là.
20/03/2013, 17h19
yolepro

Bonjour thelvin et merci beaucoup pour ta réponse qui me donne un eclairage certain.

Concernant la gestion des fractions, la question se pose notamment dans l'utilisation des pourcentages. Exemple lorsque l'on affiche 33%, il sagit en faite de 1/3 de 100%. Comment gérer ce type de problématique grace a un datatype?

Merci.
20/03/2013, 18h22
thelvin

Je dirais, comme on veut :).

Une autre manière d'écrire 33%, c'est 0.33
Ou alors, juste 33, le programme chargé de lire la valeur étant pertinemment au courant du fait que c'est un pourcentage, et le transformant en valeur décimale par lui-même, sans indice.

Enfin, il reste la méthode de créer son propre data type, permettant donc une suite de chiffres suivie de '%', ou bien deux suites de chiffres séparées de '/'.
Bien sûr, concernant l'intégration avec Java, il faudra enseigner au moteur de sérialisation, comment transformer ce nouveau data type en type Java. Je n'en connais pas les facilités ou difficultés, n'ayant pas l'habitude des sérialiseurs XML.
26/03/2013, 12h07
yolepro
Bonjour Thelvin et merci pour ta réponse même si elle ne me satisfait pas pleinement ;)

Le problème de pourcentage est un problème récurrent je pense, et je ne connais du coup pour l'instant pas de moyen d'y remédier (au pire j'ouvrirais un autre post dédié). Typiquement si l'on considère que le ratio est 1/3, par abus de language on va dire 33%. Sauf que quand on doit faire des additions de pourcentage, ca donne parfois de drole de résultat (33%, 66%, 99% alors qu'il faudrait avoir 100%)

Par contre j'ai avancé dans mon étude sur les types numériques et j'en conclus que dans l'incertitude, il vaut mieux toujours utiliser decimal pour les raisons suivantes:
- Depuis JEE5, BigDecimal est un type natif (pas besoin de récupérer une librairie ailleurs. Cela signifie qu'il comporte les méthodes de transformation qui vont bien. De plus les librairies JDBC fournissent ce type nativement également. Il n'y a donc maintenant quasiment plus de raison d'avoir à le transformer entre la couche de service XML et la couche de persistence,
- C'est le seul type qui ne perd pas précision. Même si c'est un cas potentiellement rare, on peut se retrouver dans une situation ou l'on doivent gérer des nombres à 11 chiffres sans avoir à arrondir,
- Enfin le decimal permet de gérer aussi bien des entiers que des décimales, et ce avec un nombre infini de chiffre.
Je pense que pour la plupars des applications de gestions, c'est le plus simple. La question du coup pourra se poser, s'il faut des performances très importante (ce qui est rarement le cas pour les applications de gestion).
26/03/2013, 15h08
thelvin
Citation:

Envoyé par yolepro

Bonjour Thelvin et merci pour ta réponse même si elle ne me satisfait pas pleinement ;)

Je t'en prie, le forum est là pour ça.

Citation:

Envoyé par yolepro

Le problème de pourcentage est un problème récurrent je pense,

En ce qui me concerne ça me surprendrait beaucoup.

Citation:

Envoyé par yolepro

Typiquement si l'on considère que le ratio est 1/3, par abus de language on va dire 33%. Sauf que quand on doit faire des additions de pourcentage, ca donne parfois de drole de résultat (33%, 66%, 99% alors qu'il faudrait avoir 100%)

En situation réelle, les pourcentages sont plutôt retranchés de 100% et la portion restante se retrouve donc implicite : après tout il n'existe pas de manière d'imposer une somme de 100%, et puis même si c'était le cas quel intérêt ? ... Faire une erreur parce que la dernière portion a été mal calculée, ce qu'on sait puisque justement on peut la déduire sans problème, ça n'a pas l'air très intéressant.

Maintenant si l'idée c'est, genre, de forcer quelqu'un sur cette planète, à bien indiquer toutes les parts qu'il veut répartir, et lui remonter une erreur si ça ne s'additionne pas pile à 100%, alors dans ce cas c'est une logique métier spécialisée, dont XML ne s'occupe pas. Il va donc falloir la concevoir à ta manière. Vu que le but est d'être exact, il ne faudra donc en effet pas utiliser de type flottant, et donc plutôt decimal.

Citation:

Envoyé par yolepro

Depuis JEE5, BigDecimal est un type natif (pas besoin de récupérer une librairie ailleurs. Cela signifie qu'il comporte les méthodes de transformation qui vont bien.

Pas très clair tout ça. BigDecimal fait partie de la bibliothèque de base Java depuis le JDK1.3 (ou peut-être avant.)
Il a depuis le début des méthodes de construction et de sérialisation adaptées. C'est pour ça qu'il existe.
Le JDK 1.5 lui a ajouté une arithmétique en virgule flottante permettant de s'interfacer avec les types en virgule flottante de manière raisonnable... Mais en principe ça ne te concerne pas.

Citation:

Envoyé par yolepro

De plus les librairies JDBC fournissent ce type nativement également. Il n'y a donc maintenant quasiment plus de raison d'avoir à le transformer entre la couche de service XML et la couche de persistence,

Oui. Mais encore faut-il que tous les acteurs en présence aient géré correctement cette intégration. Avec double la question ne se pose pas, avec BigDecimal elle s'est posée longtemps, et certains trucs pas très utilisés continuent d'avoir des problèmes.
C'est ce que je voulais dire. Mais ça fait des années que je n'ai plus de problème, c'est vrai.
Citation:
Envoyé par yolepro

C'est le seul type qui ne perd pas précision. Même si c'est un cas potentiellement rare, on peut se retrouver dans une situation ou l'on doivent gérer des nombres à 11 chiffres sans avoir à arrondir,
Enfin le decimal permet de gérer aussi bien des entiers que des décimales, et ce avec un nombre infini de chiffre.
Alors ok, si on ne veut pas perdre de précision, la question ne se pose pas. C'est decimal et BigDecimal, et puis c'est tout.

Mais attention, ils ne sont pas capables de représenter des nombres comme 1/3, racine carrée de 2 ou pi. Or tu avais l'air de tenir au 1/3.
26/03/2013, 17h12
yolepro

Citation:

Envoyé par thelvin

Alors ok, si on ne veut pas perdre de précision, la question ne se pose pas. C'est decimal et BigDecimal, et puis c'est tout.

Mais attention, ils ne sont pas capables de représenter des nombres comme 1/3, racine carrée de 2 ou pi. Or tu avais l'air de tenir au 1/3.

C'est vrai que decimal n'est pas capable de representer des nombres de type fraction, racine carrée et autre, mais comme ni float, double, int long ne le sont non plus, c'est la moins pire des solutions.

Merci.
27/03/2013, 10h41
thelvin

La différence étant que si tu cherches à calculer 1/3 en double, tu obtiens la valeur approchée 0.3333333333333333, sa précision maximale.
Si tu cherches à calculer 1/3 en BigDecimal, il te dit qu'il ne peut pas réaliser ce calcul à moins que tu lui indiques la précision jusqu'à laquelle il est censé aller.