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.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: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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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?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.
Except that I'm wrong, you can't even compare it with itself. nan == nan is false.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?
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.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
No, thankyou, I did not know infiity was signed.
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().I'd pretty much be happy with the sprintf() library if I could better control the e notation
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Which makesa good test for a nan in itself don't you think?Code:if (!(x == x))
