Discussion :

[xso]

Voici un bout de code tout simple :

Code :

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

1
2
3
4
5
 
double a = 0.815;
double b = 26130.3;
double c = a * b;
System.err.println(c);

J'obtiens le résultat suivant : 21296.194499999998 au lieu de 21296.1945.

Quelqu'un aurait-il une solution pour résoudre ce problème sans passer par les BigDecimal et sans utiliser une précision qui pourrait introduire une erreur dans mes calculs?

[BiM]

C'est la précision éternelle de java....

Je pense que tu peux regarder dans le package java.math (que je n'ai jamais essayé).

Il y a les classes BigInteger et BigDecimal.

Dans BigDecimal tu as une méthode multiply.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
import java.math.BigDecimal;
 
public class Multiplication
{
	public static void main (String [] telsArgs)
	{
		BigDecimal monBigDecimal1 = 0.815;
		BigDecimal monBigDecimal2 = 26130.3;
		BigDecimal monBigDecimal3 = monBigDecimal1.multiply(monBigDecimal2);
		System.out.println(monBigDecimal3.toString());
	}//main()
}//class Multiplication

[Sebounet19]

Sinon, tu peux toujours passer par une méthode d'arrondi à x chiffres aprés la virgule.

Ou encore, ne faire que des multiplications sur des entiers. C'est plus sur

Dans ton cas, tu multiplie tout par 1000 et tu redivises le résultat par 1000 à la fin ...

[jowo]

Ce sujet a déjà été traité cette semaine (addition de double)

[xso]

J'ai cherché sur le forum avant de poster mon message, mais j'ai cherché à "multiplication double" et pas à "addition double"...

Pour les BigDecimal, ça marche pas non plus car j'obtiens :
21296.19449999999801450734082663988613836786099092128303478244077950876089744269847869873046875
donc c'est toujours pas ce que je veux...

Quand à arrondir la valeur, ça me fait perdre de la précision, parce que dans cet exemple, je peux arrondir à 4 chiffres après la virgule, mais dans un autre cas ça peut être 5 ou 6 (voir plus) chiffres après la virgule...

Bon en tout cas merci pour vos réponses.

[Sebounet19]

Ca depend de quoi ton nombre de chiffres aprés la virgule ?

[xso]

le nombre de chiffres après la virgule ne dépend pas de moi, ça s'est sur
Ce sont des données extraites d'un fichier xml (que l'on me fournit...).

Pour en revenir au sujet déjà traité cette semaine, je tiens quand même à préciser qu'aucune solution n'a été trouvée, donc le sujet reste ouvert...

[Sebounet19]

Tu peux assez facilement retrouver le nombre de chiffres après la virgule pour un double donnée. Tu convertie en String et tu comptes le nombre de caractères de la virgule (ou du point) jusqu'à la fin.

Après, tu peux tout multiplier par 10 x le nombre de chiffres après la virgule,
faire la multiplication des 2 entiers (des long) et rediviser par 10 x le nombre de chiffres après la virgule

Ca reste une solution possible et sûr

[jowo]

J'ai cherché sur le forum avant de poster mon message, mais j'ai cherché à "multiplication double" et pas à "addition double"...

Pour les BigDecimal, ça marche pas non plus car j'obtiens :
21296.19449999999801450734082663988613836786099092128303478244077950876089744269847869873046875
donc c'est toujours pas ce que je veux...

Quand à arrondir la valeur, ça me fait perdre de la précision, parce que dans cet exemple, je peux arrondir à 4 chiffres après la virgule, mais dans un autre cas ça peut être 5 ou 6 (voir plus) chiffres après la virgule...

Bon en tout cas merci pour vos réponses.

MOI, j'obtiens 21296.1945 en utilisant correctement la classe BigDecimal.

Code :

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

1
2
3
4
5
 
    BigDecimal monBigDecimal1 = new BigDecimal(0.815d);
    BigDecimal monBigDecimal2 = new BigDecimal(26130.3d);
    BigDecimal monBigDecimal3 = monBigDecimal1.multiply(monBigDecimal2);
    System.out.println(monBigDecimal3.setScale(4, BigDecimal.ROUND_CEILING));

[xso]

Bé tu fais un arrondi à la quatrième décimale :

Code :

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

1
2
 
    System.out.println(monBigDecimal3.setScale(4, BigDecimal.ROUND_CEILING));

Ducoup je vois pas l'interêt de passer par des BigDecimal...
:

Pour ce qui est de la solution de compter le nombre de décimal en passant par des String, j'ai peur de perdre énormént de perfomance sur mon appli parce que j'ai pas qu'une seule valeur à analyser, non?

[jowo]

De toute façon, tu devras arrondir pour afficher ton nombre.

Je peux me tromper mais un nombre avec 30 décimals, ça n'a pas de sens physique. Tout instrument a une certaine précision...

[xso]

En effet, je vais me résoudre à arrondir mes résultats à la douzième décimale...

Mais je trouve quand même étrange que Java ne permette pas de faire un calcul aussi simple que 0.815 * 26130.3 sans se tromper...

Merci Jowo et Sebounet19 pour votre aide et votre patience ;-)

[BiM]

Java n'est pas vraiment fait pour le calcul, je pense que tu peux ajouter des librairies spécialisées qui te rendent un meilleur résultat.

[alheim]

c'est pas une question de qualité de calcul c'est une question de gestion mémoire.
La JVM alloue 64 bits pour un double...Il faut bien les remplir.
Passes par un float qui lui est codé sur 32 bits.

Tu auras une précision plus grossière.

Tchou !

[vincent63]

'soir,

Pour en revenir au sujet déjà traité cette semaine, je tiens quand même à préciser qu'aucune solution n'a été trouvée, donc le sujet reste ouvert...

En fait, aucune solution n'a été trouvé parce qu'il n'en existe pas.

A priori, il n'est pas possible de représenter certaines valeurs décimales avec des types primitifs (double, float, etc...) sans avoir recours à une approximation.

Du coup, lors de certains calculs, les résultats peuvent être mathématiquement faux et être pourtant ce qu'il y a de plus proche avec une représentation informatique.

De la même manière, (cf. un expert Java de ma boite), la valeur affichée par un System.out ne correspond pas toujours à la valeur exact retenue en mémoire. Par exemple :

BigDecimal

public BigDecimal(double val)

Translates a double into a BigDecimal. The scale of the BigDecimal is the smallest value such that (10scale * val) is an integer.

Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances notwithstanding.

The (String) constructor, on the other hand, is perfectly predictable: new BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.

Parameters:
val - double value to be converted to BigDecimal.
Throws:
NumberFormatException - val if val is infinite or NaN.

Voir : http://java.sun.com/j2se/1.4.2/docs/api/

Voilà tout...

[bouye]

Code :

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

Java n'est pas vraiment fait pour le calcul, je pense que tu peux ajouter des librairies spécialisées qui te rendent un meilleur résultat.

Je soupconne un probleme equivalent en C, C++, Pascal, ... et n'importe quel language qui utilise la norme IEEE ou equivalent pour la representation et les calculs sur nombres flottants (l'assembleur egalement alors ?).
Mais de la a tous se mettre a programmer en FORTRAN, en Scheme/LISP ou en ML.........................

Sinon il faut trouver (ou se faire) une librairie numerique specialisee. Mais la on peut alors perdre en performances et en general ca coute cher.

[FFF]

d'accord avec bouye !

D'une façon générale si tu n'obtiens pas le résultat attendu par ton ordi ben c que tu lui dis pas de faire les choses correctement (et c pas facile) !
La manipulation des doubles (cf le poste sur l'addition de double) est très délicate, on utilises cette précision pour des calculs scientifiques (pas pour aditionner des sous ou des carottes !)
Un nombre double ne s'écrit pas n'importe comment non plus, par exemple en info il se peut très bien que ces deux doubles ne soient pas égaux :
d1=8.1
d2=8.1000

Bref en gros si tu n'as pas à déterminer l'âge de l'univers ou résoudre l'équation de schrödinger (donc t'as pas besoin d'être très précis) n'utilise pas les double (en plus ton appli ira sûrement plus vite !) !

Si par contre tu dois résoudre une équation par différences finies en mode implicite allant au 5ème ordre, bon là tu peux envisager les doubles et un conseil avant d'écrire koi que ce soit c'est de lire des bouquins sur "les méthodes numériques" ou informatique numérique...

[vincent63]

La manipulation des doubles (cf le poste sur l'addition de double) est très délicate, on utilises cette précision pour des calculs scientifiques (pas pour aditionner des sous ou des carottes !) ....
Bref en gros si tu n'as pas à déterminer l'âge de l'univers ou résoudre l'équation de schrödinger (donc t'as pas besoin d'être très précis) n'utilise pas les double (en plus ton appli ira sûrement plus vite !) !

Oulala... Fouilhouilhou...
Mais pas du tout!!!

Les deux postes sur les doubles montrent justement les limites de ce type primitif. Ils ne permettent pas de représenter PRECISEMENT certaines valeurs. Donc pas question de les utiliser dans des calculs nécessitant une extrême précision.

[FFF]

La manipulation des doubles (cf le poste sur l'addition de double) est très délicate, on utilises cette précision pour des calculs scientifiques (pas pour aditionner des sous ou des carottes !) ....
Bref en gros si tu n'as pas à déterminer l'âge de l'univers ou résoudre l'équation de schrödinger (donc t'as pas besoin d'être très précis) n'utilise pas les double (en plus ton appli ira sûrement plus vite !) !

Oulala... Fouilhouilhou...
Mais pas du tout!!!

Les deux postes sur les doubles montrent justement les limites de ce type primitif. Ils ne permettent pas de représenter PRECISEMENT certaines valeurs. Donc pas question de les utiliser dans des calculs nécessitant une extrême précision.

ben ils servent à quoi alors ?? C'est bien avec ceux ci que tu peux avoir des 10E-350 ou 10E+241... non pour toi c'est pas assez précis ?? Un double ça s'écrit de façon précise dans un programme : 1.200000000000000 s'il le faut.

[vincent63]

ben ils servent à quoi alors ?? C'est bien avec ceux ci que tu peux avoir des 10E-350 ou 10E+241... non pour toi c'est pas assez précis ?? Un double ça s'écrit de façon précise dans un programme : 1.200000000000000 s'il le faut.

Je te renvoie à la page précédente et sur le lien vers la java doc. Toutes les valeurs ne peuvent pas être représentées EXACTEMENT avec les doubles. Par exemple, 0,1 n'a pas de représentation PRECISE avec ce type primitif.

Pour des calculs qui demandent une grande précision, un léger décalage multiplié plusieurs fois peut donner des valeurs fausses.