Discussion :

[polymorphisme]

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 ?

[hibour]

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

[polymorphisme]

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 !

[hibour]

Même un bigDecimal ne ferai pas l'affaire

Code :

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

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

résultat:

Code :

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

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

[Torg666]

Même un bigDecimal ne ferai pas l'affaire

Code :

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

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

résultat:

Code :

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

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 :

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

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

[Uther]

Même un bigDecimal ne ferai pas l'affaire

Code :

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

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

résultat:

Code :

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

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 :

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

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

le résultat est correct.

[hibour]

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 :

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

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

le résultat est correct.

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

Code :

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

BigDecimal x = 12.34;

cela se traduira automatiquement par

Code :

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

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

[polymorphisme]

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.

[Torg666]

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

Code :

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

BigDecimal x = 12.34;

cela se traduira automatiquement par

Code :

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

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.

[hibour]

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 :

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

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

si on a un type decimal par exemple
on écrira

Code :

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

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

qui se traduira par le compilateur

Code :

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

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