Flotteur supérieur ou inférieur à zéro

J'ai le code suivant qui, parfois, de retour en tant que vrai et n'a parfois pas.

Une idée de ce que pourrait être la cause de la variation de résultat?

L'0.00 chaîne vient d'un objet JSON.

(code simplifié)

if(new Float("0.00")>0){
    //do something
}

EDIT:

Ce que j'ai est certains chars que je veux déterminer si son zéro, à moins de zéro ou plus de zéro. Les valeurs peuvent être des choses comme 0.00, de 0,001 ou -0.001. Comment puis-je déterminer si les si elles sont positives, négatives ou nulles?

EDIT:

Peut-être que je me dois de préciser la façon dont je reçois les valeurs. Je suis peut-être totalement autre chose qui est à l'origine du problème, car j'ai lu sur BigDecimal et a essayé de l'utiliser en vain.

Les valeurs sont extraites à partir d'un flux JSON (qui a ce format LT:0.000) à l'aide de ce code:

price = new BigDecimal(stocksJSONArray.getJSONObject(i).getString("LT"));

Ensuite tester si le prix est supérieur ou inférieur à zéro, j'ai utilisé suivant les instructions conditionnelles:

if(price.compareTo(BigDecimal.ZERO)==1){
    //greater than zero
}
else if(price.compareTo(BigDecimal.ZERO)==-1){
    //less than zero
}

Ce code est lu en boucle sur le nombre de valeurs lues sur les flux JSON. Et à partir des résultats, certains price qui est à zéro est traitée comme supérieur à zéro et une partie est traitée comme moins que zéro. Je suis à soupçonner que quelque chose d'autre est à l'origine du problème?

J'ai aussi fait un test pour voir si le problème était avec la précision des données. J'ai donc fait ceci:

DecimalFormat frmt = new DecimalFormat("0.000000000000000000000000");
String formatted = frmt.format(stock.change);

Et pour les zéros qui les a reconnus comme étant des aspects positifs et négatifs, la trace de la valeur pour elle était encore 0.000000000000000000000000, pas 0.000000000000000000000001 ou quelque chose comme ça.

Les réponses données sont correctes, mais pas dans votre situation dans laquelle le résultat ne doit pas varier. Êtes-vous sûr que 0.00 est toujours analysée comme il est? Et êtes-vous sûr que la valeur à laquelle le flotteur est initialisé n'est pas le résultat d'autres flottent des opérations?
Voir Ce que Tout informaticien Devez Savoir à Propos de l'Arithmétique à virgule Flottante pour plus de détails. Notez que j'ai supprimé ma réponse, puisque j'ai été apparemment mal en plus de ce que je disais. Il y a des gens beaucoup plus expert en la matière.

OriginalL'auteur mushroom | 2012-04-30

  1. 3

    Votre expression sera fiable de produire un résultat de false en Java.

    Cependant, supposons que le zéro est, par exemple, le résultat de -1 divisé par l'infini positif. Dans ce cas, il sera représenté en interne comme, à peu près dit, -0.00. Dans certaines circonstances, il sera toujours imprimé en tant que zéro (sans le signe moins), dans d'autres, il va se comporter différemment de 0.00.

    Flotteurs peuvent généralement être comparé pour moins de la même façon que les nombres entiers - il y a un risque d'une erreur d'arrondi, mais que l'erreur n'est pas aidé par l'ajout ou la soustraction d'un aléatoires de faible valeur. Il est différent avec comparaison pour l'égalité.

    Je vous suggère de vérifier vos faits et faire plus de lecture sur virgule flottante comportement.

    Modifier: je suis grandement simplifier ci-dessus pour répondre à la question d'origine. Pour répondre à la modifier pour la question, nous devons aller plus loin.

    Pour toute opération sur des nombres à virgule flottante il convient de connaître et d'envisager la précision et précision des intrants, et la précision désirée de la sortie. Parfois, la tâche est résoluble et parfois il ne l'est pas - la précision de l'entrée peut ne pas être suffisante pour produire la réponse.

    Dans votre cas, le précision est de 32 bits, dont 24 bits de la mantisse et 8 bits d'exposant. Cela signifie que ce type de données en toute sécurité distingue de 0,001 à partir de 0.00100001 mais pas de 0.001000001 comme vous pouvez le voir facilement:

     System.out.println((float)0.001 < (float)0.001000001);

    (Notez que vous obtiendrez un résultat différent si vous n'avez pas la force de simple précision de la comparaison par le jette. Dans ce cas, le calcul pourrait être fait en double précision, et les chiffres seront en toute sécurité distingué - jusqu'à ce que vous apporter encore plus rapprochés.)

    Donc, la précision est déterminée par le type de données. Pas donc la précision. Précision d'entrée est souvent beaucoup plus difficile à déterminer que la précision parce qu'il n'a rien à voir avec le type de données, à l'exception que la précision ne peut jamais être mieux que la précision.

    Mathématique du nombre réel peut se trouver dans l'une des quatre circonstances à l'égard de représentabilité dans un type à virgule flottante, et ceux qui correspondent à différents traitements qu'il reçoit lorsqu'il se produit comme un littéral, dans la lisible par l'homme de la notation décimale.

    • Il pourrait être représentable exactement en binaire. Par exemple, 0 ou 0,25. Ensuite, il est aussi précis qu'un entier serait dans une variable de type entier.
    • Ou il est environ représentable avec précision correspondant au type de précision. Par exemple, 1/3 ou 0,1 ou 0,001. Cela se produit lorsque l'exposant nécessaire s'inscrit dans le nombre de bits d'exposant disponible, mais lorsque le binaire de l'expansion du nombre est plus long que la mantisse, ou carrément à l'infini.
    • Ou il est environ représentable avec considérablement déformée de précision. Ce sont nombres dénormalisés (subnormale). Ce n'est pas seulement erronée, l'arithmétique sur il peut ralentir à une exploration, ce qui est généralement documentée comportement correct, et même un respectable compilateur Java peut transpirer un peu en voyant les littéraux de ce genre qui est cependant un bug.
    • Ou il ne convient pas à tous et compilateurs refuser le littéral comme trop grand.

    Donc, dans votre cas, nous avons seulement trois entrées valides: 0 (précis), de 0,001 (approximative) et -0.001 (approximatif), et ce qui rend votre problème résoluble. Il suffit de comparer vos chiffres avec un 0 littérale (ce qui est exact, par la voie) et vous obtiendrez toujours les attendus des valeurs booléennes (entièrement de sortie précise).

    Toutefois, cela dépend de vos entrées directement dérivé de littéraux. Si vos données ont été l'un de 0,001, -0.001 et (float)1000 * (float)0.001 - 1, ce serait une autre question et que vous auriez à obtenir les réponses, par exemple comme ceci:

    if (-0.00001 < x && x < 0.00001) //then x is zero

    Et si vous vous permettez de toutes les entrées que ce soit, et pas seulement ceux de trois magie des valeurs, et n'ont aucune idée de l'entrée de la précision, alors que c'est juste mission impossible. Même un littéral de départ comme 0.000000000... avec certaines des ordures chiffres jusqu'à la fin sera converti par un compilateur Java parfaitement neutre zéro, et après cela se produit, aucun code Java va jamais dire de la précision et de beaux 0.00, ou de ce qui se passe si vous ajoutez un signe moins pour le underflowing valeur. Il est tout de même, inexactes zéro, le même modèle de bits dans votre variable, plutôt que 3 valeurs distinctes.

    J'ai décidé de "downgrade" ma réponse à un commentaire (& trim à la seule utiles bits). +1 pour votre plus considéré comme la réponse. 🙂
    Merci pour votre geste que je ne pense pas que je mérite (je suis un ardent à virgule flottante d'esquive), et pour les puissants no-nonsense de référence que vous avez offert. Le mien est plutôt une feuille de triche.
    "cheat sheet" j'ai de la valeur de telles choses. Ils peuvent résoudre la majorité des problèmes de base. 🙂
    Merci pour votre bien expliqué réponse. Cependant, je commence à soupçonner le problème que j'ai n'est pas peut-être liée à l'exactitude des float ou double valeur. J'ai ajouté quelques précisions à la question sur le dessus et j'espère que ça peut nous mettre à la racine du problème? Merci encore.
    Vous avez raison quand vous dites que mon expression sera fiable de produire une suite de faux en Java. Après beaucoup d'essais, je crois que le problème était quelque chose sans rapport avec flotteurs. Mais merci pour votre réponse, j'ai appris, tout à fait un peu de lui (:

    OriginalL'auteur Jirka Hanika

  2. 1

    Les flotteurs sont inexactes. Vous devez spécifier une marge d'erreur, comme:

    float result = new Float("0.00");
float expected = 0;
if (Math.abs(result - expected) < 0.00001)
...

    OriginalL'auteur dhaag23

  3. 0

    Vous pouvez utiliser les Mathématiques.signum() pour vérifier si la valeur est égal à, inférieur ou supérieur à zéro.

    OriginalL'auteur Jouni Aro

  4. 0

    J'ai fait le mien un peu différent. Je m'attendais à un capteur de montrer une lecture de 1. C'est ce que je suis venu avec.

    double a = y1;
                if((a-0)<1){
                    a=(1-a)+a;
                }

    OriginalL'auteur Tim Flinn