Printable View
it has come to my attention that when it comes to doubles, there is a representation for infinity or "not a number" in the environment I am using.
In C, is there a way to detect this or is this implimentation specific? It would also be good if in comparisons, when it is nan that it would be greater than the number I was comparing it to instead of needing a special case to test for it. Does nan work as infinity in comparisons also?
Thanks in advance
I think the new C standard defines an isnan() macro, but older C doesn't.
I don't think you're supposed to expect nan to compare with anything since it's technically not a number.Quote:
It would also be good if in comparisons, when it is nan that it would be greater than the number I was comparing it to instead of needing a special case to test for it.
If it could not be compared, at least for equality/inequality, there would be no point in having it. Just do this:Quote:
Originally Posted by Noir
Now you've got a variable loaded with the NaN value and can compare against it.Code:double NaN = 0.0 / 0.0;
Apart from isnan(), all comparisons with a nan fail, so
if ( x > nan || x <= nan ) is false, whereas it would be true for any real numbers.
Any mathematical operation with a nan results in another nan.
Infinities are different from nan's as well, like x < inf is always true.
A nan usually means the code has blown up somewhere.
Fine fine, I don't think you're supposed to expect nan to compare with anything other than another nan, because it's technically not a number. Geez, can't you even pretend you knew what I meant without having to spell it out? :rolleyes:Quote:
If it could not be compared, at least for equality/inequality, there would be no point in having it.
Ick, you're right. I figured nan == nan at least would work, but it doesn't. I think that's dumb.Quote:
Originally Posted by Salem
Except that I'm wrong, you can't even compare it with itself. nan == nan is false.Quote:
Originally Posted by Noir
If you're looking for a number that will be larger than all other numbers, NaN won't work but positive infinity will. (Infinity is signed: there is positive infinity and negative infinity.) No doubt you already know this.
No, thankyou, I did not know infiity was signed.Quote:
Originally Posted by dwks
Actually, I just wanted to know how to deal with these unusual double representations.
I think some of my routines need to take this into account.
Would fabs() work on infinity?
Yes, Infinity works like any other real number although there are some exceptions, involving operations with 0 and Infinity like 0*Infinity being undefined (I guess it would return NaN in C, haven't tested though.)
http://en.wikipedia.org/wiki/Infinit...ty_with_itself
Okay, I hope you don't mind me going off topic a little bit, but it is what forced me to consider things like nan and infinity.
I am working on a routine to decompile a double to text sort of like you'd do with sprintf() or something in that family, but I would like a little better control of when it pops into e notation. I'd pretty much be happy with the sprintf() library if I could better control the e notation, but since I can't I've started thinking on how to decompile a double. I figure I am not the first to have this problem, so could somebody point me to some reading or something on either a better control of the library function or perhaps an algorithm on converting the double to a text representation.
Thank you.
What do you want to do? There are an amazing number of obscure format specifier modifiers for printf().Quote:
I'd pretty much be happy with the sprintf() library if I could better control the e notation
Quote:
Originally Posted by dwks
Well, essentially, I have a routine which is basically a "field" for entering numbers. When it is not entering a number, it displays the value of the field. With this field you can also edit the existing value, and this is where the problem becomes appearant. When in double mode (value stored is a double) and trying to edit the existing value, in decompiling the value, some numbers come out in e-notation format. I do not care for this behaviour. Indeed, my routine for converting the string back to double does not allow (nor do I want it to allow) e-notation. It's okay to truncate some of the lower valued digits. That would be acceptable.
Use the "%g" format, with a large precision value. That will suppress the exponent format.
Which makesQuote:
Originally Posted by brewbuck
a good test for a nan in itself don't you think?:cool:Code:if (!(x == x))