Discussion :

[yolepro]

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.

[thelvin]

Bonjour,

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.

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.

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

Nope. Notation scientifique seulement.

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.

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à.

[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.

[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.

[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).

[thelvin]

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.

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

En ce qui me concerne ça me surprendrait beaucoup.

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.

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.

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.

• 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.

[yolepro]

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.

[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.