précision, math et Bigdecimal

Bonjour,

je cherche à obtenir les fonctions élémentaires (cos, asinh, log, exp, ...) avec une précision donnée.

Je me suis aperçus que les méthodes de la classe java.lang.math retournaient généralement des doubles et donc que je ne pouvais obtenir une bonne précision. La classe java.lang.StrictMath ne semble pas apporter grand chose de plus.

Je me suis alors tourner vers le paquetage java.math. Les BigDecimal gèrent bien la précision mais les fonctions mathématiques sont quasiment restreintes aux opérations arithmétiques élémentaires (+, -, *, /).

Une idée ?

Les méthodes sin, cos,... dans java.lang.Math sont natives (écrites dans un autre langage que java) pour une question de performances. Je ne sais pas si tu travailles dans un domaine sensible mais l'implémentation fournie est suffisante dans la plupart des cas (un double a déjà une grande précision 64bit). Si tu veux une autre API plus précise alors développe la tienne :lol: en utilisant le développement limitée de ces fonctions ou un autre algorithme sur ce lien http://www.trigofacile.com/maths/tri...dic/cordic.htm..

Mon but est de faire une calculette.

> l'implémentation fournie est suffisante dans la plupart des cas (un double a
> déjà une grande précision 64bit.

Une bonne précision soit, mais voici une simple soustraction de deux doubles :)

12.34 - 12.0 = 0.33999999999999986 :(

Il est impensable qu'une calculatrice affiche un tel résultat !
Et, on image la suite si l'on essaye de faire plusieurs opérations de suite.

Il est clair que l'utilisation des BigDecimal resouds le problème.

Faudrais t-il alors implémenté avec des BigDecimal l'algorithme proposé sur la page http://mathsetcalculs.perso.neuf.fr/Maths/cordic.htm ? (merci pour l'url).

Je suis étonné qu'il n'existe pas déjà une bibliothèque répondant à ce soucis !

Même un bigDecimal ne ferai pas l'affaire :mouarf:

Code:

---

System.out.println(new BigDecimal(12.34).subtract(new BigDecimal(12.0)));

---

résultat:

Code:

---

0.339999999999999857891452847979962825775146484375

---

On a une précision limitée quoiqu'on fasse (regarde la représentation des nombre flottant sur un PC qui est une puissance de 2!).

Citation:

---

Envoyé par hibour

Même un bigDecimal ne ferai pas l'affaire :mouarf:

Code:

---

System.out.println(new BigDecimal(12.34).subtract(new BigDecimal(12.0)));

---

résultat:

Code:

---

0.339999999999999857891452847979962825775146484375

---

On a une précision limitée quoiqu'on fasse (regarde la représentation des nombre flottant sur un PC qui est une puissance de 2!).

---

Convertie ts float ou double en chaine de caraterespar exemple comme ca:

Code:

---

1 2	new BigDecimal(""+12.34).subtract(new BigDecimal(""+12.0));

---

avec ca tu devrai bien obtenir 0.34.

Le souci a été evoqué à de multiple reprise... suffit de chercher

Citation:

---

Envoyé par hibour

Même un bigDecimal ne ferai pas l'affaire :mouarf:

Code:

---

System.out.println(new BigDecimal(12.34).subtract(new BigDecimal(12.0)));

---

résultat:

Code:

---

0.339999999999999857891452847979962825775146484375

---

On a une précision limitée quoiqu'on fasse (regarde la représentation des nombre flottant sur un PC qui est une puissance de 2!).

---

Non les BigDecimal résolvent bien son problème. Comme le nom l'indique il ne reposent sur une représentation en base dix contrairement aux float/double en base 2.
Si ton exemple ne marche pas, c'est parce que tu passes d'abord par des floats qui sont ensuite convertis en BigDecimal.

Si tu fais :

Code:

---

System.out.println(new BigDecimal("12.34").subtract(new BigDecimal("12.0")));

---

le résultat est correct.

Citation:

---

Envoyé par Uther

Non les big décimal résolvent bien son problème. Si tton exemple ne marche pas, c'est parceque tu passes d'abord par des floats(approximations) qui sont ensuite convertis en BigDecimal.

Si tu fais :

Code:

---

System.out.println(new BigDecimal("12.34").subtract(new BigDecimal("12.0")));

---

le résultat est correct.

---

:mrgreen: Il faudrai mettre le BigDecimal comme un type natif en java ça résoudra quelque soucis :ccool:
quand on écrira :

Code:

---

BigDecimal x = 12.34;

---

cela se traduira automatiquement par

Code:

---

BigDecimal x = new BigDecimal("12.34");

---

Il faut pas oublier que question performance les opération avec des BigDecimal est beaucoup plus lente que les type float, double..:?

Finalement, pour créer une calculette,

les calculs avec les nombres à virgules flottant ne répondant pas aux besoins,
(ce qui rends désuet plusieurs API telles que JSCience :?) ,

il faudrais implémenter des algorithmes tels que CORDIC (http://mathsetcalculs.perso.neuf.fr/Maths/cordic.htm) avec les BigDecimal en essayant de gérer au mieux la précision.

Si l'un d'entre vous pense avoir une meilleure solution, qu'il hésite pas à en faire part !

Merci.

Citation:

---

Envoyé par hibour

:mrgreen: Il faudrai mettre le BigDecimal comme un type natif en java ça résoudra quelque soucis :ccool:
quand on écrira :

Code:

---

BigDecimal x = 12.34;

---

cela se traduira automatiquement par

Code:

---

BigDecimal x = new BigDecimal("12.34");

---

Il faut pas oublier que question performance les opération avec des BigDecimal est beaucoup plus lente que les type float, double..:?

---

Au vu du resultat sur les String, ce genre d'idée farfelue est plus une source d'emmerde qu'autre chose.
Et pour ce qui est des perfomance, on travail sur un objet, pas sur une primitive donc oui c'est plus lent... a toi d'utiliser ce qui est adapté au problème.

Citation:

---

Envoyé par Torg666

Au vu du resultat sur les String, ce genre d'idée farfelue est plus une source d'emmerde qu'autre chose.
Et pour ce qui est des perfomance, on travail sur un objet, pas sur une primitive donc oui c'est plus lent... a toi d'utiliser ce qui est adapté au problème.

---

En quoi est ce une source d'emmerde?!
Avoir un pseudo type natif BigDecimal (ou decimal) aura pour effet de faire des calcul plus précis qui sera transparent pour le programmeur puisque c'est le compilateur qui traduira toutes les opérations complexes derrières je m'explique par un exemple simple
imaginons l'opération (12.34 - 12)/0.34 = 1
Si on fait :

Code:

---

1 2	double x = (12.34d - 12)/0.34d ; //x = 0.9999999999999996

---

si on a un type decimal par exemple
on écrira

Code:

---

decimal x = (12.34b - 12)/0.34b; //le suffixe b pour le BigDecimal

---

qui se traduira par le compilateur

Code:

---

BigDecimal x = new BigDecimal("12.34").substract(new BigDecimal("12")).divide(new BigDecimal("0.34"));

---

On voit clairement qu'on aura moins de chose a taper :ccool: