• 04-25-2007
FOOTOO
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?

• 04-25-2007
Noir
I think the new C standard defines an isnan() macro, but older C doesn't.
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.
I don't think you're supposed to expect nan to compare with anything since it's technically not a number.
• 04-25-2007
brewbuck
Quote:

Originally Posted by Noir
I don't think you're supposed to expect nan to compare with anything since it's technically not a number.

If it could not be compared, at least for equality/inequality, there would be no point in having it. Just do this:

Code:

`double NaN = 0.0 / 0.0;`
Now you've got a variable loaded with the NaN value and can compare against it.
• 04-25-2007
Salem
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.
• 04-25-2007
Noir
Quote:

If it could not be compared, at least for equality/inequality, there would be no point in having it.
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:
• 04-25-2007
brewbuck
Quote:

Originally Posted by Salem
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.

Ick, you're right. I figured nan == nan at least would work, but it doesn't. I think that's dumb.
• 04-25-2007
brewbuck
Quote:

Originally Posted by Noir
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:

Except that I'm wrong, you can't even compare it with itself. nan == nan is false.
• 04-25-2007
dwks
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.
• 04-25-2007
FOOTOO
Quote:

Originally Posted by dwks
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.

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?
• 04-25-2007
OnionKnight
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
• 04-25-2007
FOOTOO
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.
• 04-25-2007
dwks
Quote:

I'd pretty much be happy with the sprintf() library if I could better control the e notation
What do you want to do? There are an amazing number of obscure format specifier modifiers for printf().
• 04-25-2007
FOOTOO
Quote:

Originally Posted by dwks
What do you want to do? There are an amazing number of obscure format specifier modifiers for printf().

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.
• 04-25-2007
Salem
Use the "&#37;g" format, with a large precision value. That will suppress the exponent format.
• 04-26-2007
iMalc
Quote:

Originally Posted by brewbuck
Except that I'm wrong, you can't even compare it with itself. nan == nan is false.

Which makes
Code:

`if (!(x == x))`
a good test for a nan in itself don't you think?:cool: