Supprimer les zéros à droite d'une valeur flottante

Version imprimable

09/01/2016, 23h10
ChPr

Supprimer les zéros à droite d'une valeur flottante

Bonsoir à toutes et à tous,

Je ne m'y retrouve plus. Je voudrais supprimer de l'affichage d'un nombre flottant tous les zéros à droite.

Exemple :

1.2300000000 --> 1.23
0.0000005400 --> 0.00000054
563.000 --> 563

Je souhaite utiliser la structure suivante :

Code:

public static DecimalFormat frm = new DecimalFormat("?.???");

où vous voudrez bien m'indiquer par quel signe remplacer les '?' car je n'y arrive pas.

Merci de votre aide.

Pierre

Salut,

Par défaut les zéro à droite ne sont pas affichés, sauf celui qui se trouve immédiatement après la virgule (point) :

System.out.println( 1.53000 ); affiche 1.53
System.out.println( 1.0 ); affiche 1.0
System.out.println( 1.000 ); affiche 1.0

Les caractères dans le motif de DecimalFormat, pour les positions numériques peuvent être 0 ou # : 0 pour le nombre minimium de chiffres, # pour le maximum. On ne peut donc pas s'en servir pour supprimer les 0 à droite.
Pour DecimalFormat df = new DecimalFormat("#.###", DecimalFormatSymbols.getInstance(Locale.US)); // on prend la Locale.US pour avoir des . au lieu de ,,
Code:

1 2 3 4 5 System.out.println( df.format(1.53000) ); System.out.println( df.format(1.0) ); System.out.println( df.format(1.000) );
affichera
1.53
1
1
ça ressemble à ce que tu veux, mais non, parce que System.out.println( df.format(1.54321) ); affichera 1.543 (3 chiffres maximum après la virgule)

On peut s'en sortir avec une bidouille (en utilisant un format sans chiffre derrière la virgule, mais en forçant leur nombre à être maximal) :
Code:

1 2 DecimalFormat df = new DecimalFormat("0", DecimalFormatSymbols.getInstance(Locale.US)); df.setMaximumFractionDigits(340); // 340 correspond à la valeur de la constante malheureusement non visible DOUBLE_FRACTION_DIGITS

Citation:
Envoyé par joel.drigo
... On peut s'en sortir avec une bidouille (en utilisant un format sans chiffre derrière la virgule, mais en forçant leur nombre à être maximal) :
Code:

1 2 DecimalFormat df = new DecimalFormat("0", DecimalFormatSymbols.getInstance(Locale.US)); df.setMaximumFractionDigits(340); // 340 correspond à la valeur de la constante malheureusement non visible DOUBLE_FRACTION_DIGITS
J'avais déjà essayé cette méthode, mais je m'étais retrouvé avec 340 décimales ???

J'ai réessayé avec le code que tu m'as donné, j'obtiens des chose bizarres :

à l'affichage de la valeur 1.4 ("float") j'obtiens : 1.39999997615814 ???

Autre exemple : -8.6 --> -8.60000038146973 ???

Ces résultats me font penser que la traduction binaire par le noyau de calcul de ces valeurs donne la valeur la plus approchante et que la retranscription en décimal prend cette nouvelle valeur. Le formatage prend donc en compte ces données.

Bref, quelque soit la valeur que j'essaie, l'exception de valeurs entières), je me retrouve avec 15 chiffres significatifs qui, autre bizarrerie correspond au nombre de chiffre significatifs des "double" et des "float" !

Cordialement.

Pierre

Ça ne fonctionne qu'avec des doubles. Pas avec des float.

Avec des float, il faudra faire quelque comme ça par exemple :
Code:

1 2 3 4 5 6 7 8 public static String toString(float nb) { if ( nb==(int)nb ) { return String.valueOf((int)nb); } else { return String.valueOf(nb); } }

10/01/2016, 14h13
ChPr
Citation:

Envoyé par joel.drigo

Ça ne fonctionne qu'avec des doubles. Pas avec des float. ...

J'obtiens le même résultat, que j'utilise des float ou des double !
Citation:
Envoyé par joel.drigo

... Avec des float, il faudra faire quelque comme ça par exemple :

Code:

1 2 3 4 5 6 7 8 public static String toString(float nb) { if ( nb==(int)nb ) { return String.valueOf((int)nb); } else { return String.valueOf(nb); } }
Dans cette méthode, valueOf() me retourne le forme générale, c'est-à-dire avec exposant pour les grandes ou petites valeurs. C'est un formatage qui me conviendrait ... sauf que lorsqu'on ouvre le clavier virtuel sur un EditText qui a été préalablement formaté pour des nombres décimaux et signés, le "e" de l'exposant a disparu ; on ne sait plus à quoi correspond la valeur affichée dans la clavier virtuel.

La parade, si on peut appeler cela une parade, est de formater le EditText au format "texte". On retrouve bien dans le clavier virtuel la valeur avec son exposant. Le problème est que c'est pénible d'avoir à re-choisir la partie "chiffre" du clavier pour modifier une valeur ... effaçant du coup tout l'avantage de pouvoir prédisposer le clavier à ce que l'on veut saisir.

N'existe-t-il donc pas une spécialisation sur le formatage scientifique ?
Je vais voir si je trouve quelque chose.

Cordialement.

Pierrre
10/01/2016, 14h20
joel.drigo

Sur les spécificités Android, je ne peux pas te répondre.
12/01/2016, 21h51
nicroman

Citation:

Envoyé par ChPr

J'ai réessayé avec le code que tu m'as donné, j'obtiens des chose bizarres :
à l'affichage de la valeur 1.4 ("float") j'obtiens : 1.39999997615814 ???
Autre exemple : -8.6 --> -8.60000038146973 ???

Rien de bizarre ici... c'est le comportement "normal" de float / double (quelque soit le langage, puisque c'est le comportement interne des FPU).

La mantisse vaut toujours une valeur entre 1 et 2... le tout multiplié par 2 à une certaine puissance....
0.25 sera donc 1 * 2(-2) et aura pour mantisse 1
1.4 sera 1.4 * 2(0) et aura pour mantisse 1.4

Reste à coder la mantisse, qui est donc ou 0 (pour zero) ou 1 + une somme de puissances de 1/2
1.5 et 1.25 (et donc 1.75) seront donc codés "juste", par contre, 1.4 sera codé sous forme de 1 + 0.25 + 0.125 + ... jusqu'à obtenir la valeur la plus proche.

La valeur "float" de 1.4 est donc 1.399999976158142

Un bon endroit pour voir le codage exacte d'un flottant:
http://www.h-schmidt.net/FloatConverter/IEEE754.html

C'est aussi la raison pour laquelle on ne compare *jamais* deux nombres flottants entre eux, et / ou à zéro. Mais qu'on vérifie si ils sont "assez" proches l'un de l'autre (à noter que la précision décimale diminue en fonction de la taille du nombre flottant....). Ou que sauf dans les cas spécifiques ou on recherche la vitesse de calculs (1 millions de calculs par seconde par exemple, en 3D), on essaye de toujours utiliser "double" (la précision de "float" étant vraiment trop faible).

Si tu veux conserver des valeurs décimales précises, il existe BigDecimal qui conservera absolument *toutes* les décimales, avec la nécessité lors des divisions (par exemple) de spécifier une précision maximale et une méthode d'arrondi.

Mais peu importe finalement, tant que le résultat est "suffisamment juste". Il faut donc évaluer l'erreur "acceptable" à la fin de tes calculs, et reporter cette erreur tout le long de la chaine de calcul pour trouver la précision nécessaire des nombres en entrée. Enfin, ce sont des Math Appliquées quoi ! :D
13/01/2016, 12h23
ChPr

Citation:

Envoyé par nicroman

Rien de bizarre ici... c'est le comportement "normal" de float / double (quelque soit le langage, puisque c'est le comportement interne des FPU). ... :D

Tu as oublié de citer/voir les deux paragraphes suivant ma remarque :

Ces résultats me font penser que la traduction binaire par le noyau de calcul de ces valeurs donne la valeur la plus approchante et que la retranscription en décimal prend cette nouvelle valeur. Le formatage prend donc en compte ces données.

Bref, quelque soit la valeur que j'essaie, l'exception de valeurs entières), je me retrouve avec 15 chiffres significatifs qui, autre bizarrerie correspond au nombre de chiffre significatifs des "double" et des "float" !

J'ai donc bien conscience que ces chiffres sont la traduction binaire de ma valeur décimale. Ce que je trouve toutefois bizarre, c'est qu'utilisant des "float", je me retrouve avec 15 décimales qui ne devraient apparaître que pour les "double".

Cordialement.

Pierre
14/01/2016, 15h30
nicroman

Citation:

Envoyé par ChPr

Ce que je trouve toutefois bizarre, c'est qu'utilisant des "float", je me retrouve avec 15 décimales qui ne devraient apparaître que pour les "double".

Tu veux dire après le formatage ?

D'abord rien ne dit que celui-ci (le formater) ne fonctionne pas en "double"... (comme je disais, personne n'utilise "float" sauf pour des cas spécifiques ou la rapidité de calcul est primordial et j'ai du mal à imaginer deux paths de code pour le formater).
15/01/2016, 16h37
ChPr

Citation:

Envoyé par nicroman

Tu veux dire après le formatage ?

D'abord rien ne dit que celui-ci (le formater) ne fonctionne pas en "double"...

Oui, mais bon, le problème n'est pas là. Je veux bien penser qu'il n'y a qu'un chemin qu'utilise le formater et il affiche systématiquement les 15 chifrres, qu'on soit en float ou en double.

Citation:

Envoyé par nicroman

... (comme je disais, personne n'utilise "float" sauf pour des cas spécifiques ou la rapidité de calcul est primordial ...

J'ai dû rater l'endroit où tu le disais. Je suis de la vieille école et pour moi, un octet de gagné, c'est toujours bon. Va falloir que je me soigne ;) . As-tu une idée de la perte de gain en performance entre l'utilisation des float et des double ?

Cordialement.

Pierre