comme dans Cette question est dit, il y a des différences entre zéro négatif et positif dans des nombres de points flottants. Je sais que c'est à cause de certaines raisons importantes. Ce que je veux savoir, c'est un code court pour éviter tout zéro négatif en sortie.
Par exemple dans le code suivant: p> "- 0.000" est imprimé. mais je veux "0.000". p> Remarque Tous les autres nombres négatifs (par exemple -0.001) doivent toujours être imprimés avec le signe moins précédant, donc simplement * -1 code> ne fonctionnera pas . p> p>
3 Réponses :
Essayez selon votre précision. P>
COUT << ((ABS (ABS) <0,0005)? 0.000: ANS) << Endl; Code> P>
Il devrait être: 'Cout << (ABS (ANS) <0,0005)? 0.000: ans << endl; '
@Wallyk: Vous ne pouvez pas retourner différents types d'une expression conditionnelle en C ++.
@wallyk, ce n'est pas nécessaire. Parce que SetPrecision (3) est appelé avant cela.
@nneonneo: Oh, oui. Je fais trop de JavaScript et PHP ces derniers temps.
Ce code ne compile pas. <<< / code> a une priorité supérieure à celle
?: code>, il est donc analysé avec
ANS << endl code> comme une sous-contre-expression. Cela échoue à la résolution car
ANS code> est probablement un type de point flottant, et aucun opérateur d'insertion (
<<< / code>) est déclaré avec le type de
endl code>.
Ajouter des parenthèses autour de la () ?: Combinaison, ça devrait fonctionner bien !!
@ Scientifique: il devrait être analysé comme (Cout.Opérator << (()? :)). Opérateur << (endl); Pourquoi cela se comporte-t-il comme vous le dites ?!
@Aladdin: <<< / code> a une priorité supérieure à celle
?: Code>. Dans la grammaire formelle C ++,
<<< / code> est analysé avec
SHIFT-expression → Expression de quart << Additive-expression code>, et
?: Code> est analysé avec
expression conditionnelle → logique-ou expression? Expression: expression d'affectation code>. À cause des autres règles de la grammaire,
ans << endl code> peut être un
affectation-expression code>, mais un
non parrainé ... ... ...: ...: ...: ...: ...: ...: ... ne peut pas être un
shift-expression code>. Par conséquent, la règle
<<< / code> doit être utilisée pour réduire
ans << endl code> avant le
?: Code> L'expression peut être réduite.
Que diriez-vous:
cout << (value == 0.0 ? abs(value) : value) << endl;
Il y a beaucoup de ressources en ligne expliquant pourquoi valeur == 0.0 code> est une mauvaise idée. docs.oracle.com/cd/e19957-01/806- 3568 / ncg_goldberg.html est bon
Cette réponse serait correcte (et une bonne idée) si le questionneur n'a vraiment voulu pas attraper négatif 0. Mais le corps de la question montre que ce n'est pas le cas.
@Ironmensan - Qu'est-ce que "la norme IEEE définit la comparaison pour que +0 = -0" ... donc je suis véritablement intéressé - pouvez-vous me signaler quelque chose qui explique plus explicitement le problème? Steve Jessop - Cela me semble que le corps de la question posée spécifiquement sur Négatif 0 seulement. Ai-je oublié quelque chose?
Oui, le corps de la question indique que le questionneur veut "0.000" code> à imprimé au lieu de
"- 0.000" code> pour la valeur
-0.0001 code> . Donc, ce n'est pas seulement zéro négatif qui doit être traité spécialement,
-0.0001 code> aussi. Fondamentalement, le questionneur fait référence à toute sortie de
"- 0.000" code> à partir de
COUT code> comme "zéro négatif", ils ne veulent pas simplement dire un zéro négatif IEEE dans
Valeur code>.
Si vous vous souciez d'une précision arbitraire, par opposition à une fixe fixe à 3, vous aurez besoin d'un petit travail. Fondamentalement, vous devrez faire une vérification de préconception avant de voir si le numéro sera formaté d'une manière que vous n'aimez pas.
Vous devez trouver l'ordre de grandeur du numéro à voir s'il Les chiffres imprécis seront perdus, laissant uniquement le bit de signalisation. p>
Vous pouvez le faire à l'aide du logarithme de base 10 de la valeur absolue du nombre. Si le négatif du résultat est supérieur à la précision que vous avez définie, le numéro montrera de manière à ne pas vouloir. P>
log10 de 0,0001 est -4. P>
négatif de ( -4) est 4. P>
4> 3 (la précision arbitraire) Ainsi, la valeur apparaîtra malheureusement. P>
en très mauvais pseudocode: p>
@Tonythelion Et si mon numéro est -0.001? Il devrait être imprimé -0.001 et je ne devrais pas * -1.
AFAIK Un numéro moins multiplié par un autre numéro moins produit un nombre positif. C'est des mathématiques de base. À quoi veux-tu en venir?
Vous devrez vérifier que votre numéro n'est pas positif avant de faire * -1, sinon vous obtiendrez un nombre négatif en tant que sortie.
@Tonythelion Je devrais multiplier par -1 uniquement lorsque le résultat est -0.000. Tous les nombres négatifs comme vous l'avez dit "Vous devrez vérifier que votre numéro n'est pas positif avant de faire le * -1"
Vous semblez parler de deux choses distinctes: zéro négatif et un nombre négatif suffisamment petit qu'il arrondit à zéro lorsqu'il est imprimé de manière précise. Que voulez-vous empêcher?