468,503 Members | 2,219 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,503 developers. It's quick & easy.

Not a number problem

In my code I used NAN and isnan(x). I found they were convenient to
use. I also noticed that
older C standard does not support NAN and isnan(x).

When I compiled my program using:

gcc -Wall -c

it was fine.
But when I compiled my program using:

gcc -Wall -ansi -pedantic -c

it reported some errors, reporting NAN and isnan(x) not supported.

I knew the options -ansi and -pedantic make things conform to the
older C standard (C90?).

My question are:

1. Is it fine to compile my program using "gcc -Wall -c" instead of
using the more conservative "gcc -Wall -ansi -pedantic -c"?

2. Dose including NAN and isnan(x) hurt the portability of a program,
given high version of gcc is available in both Linux and Windows
(MinGW)?
Apr 4 '08 #1
16 5071
On 4 Apr, 15:43, istillsh...@gmail.com wrote:
In my code I used NAN and isnan(x). *I found they were convenient to
use. *I also noticed that
older C standard does not support NAN and isnan(x).
only C99 supports IEEE floating point, and even then
only if a particular macro is defined (
When I compiled my program using:

gcc -Wall -c

it was fine.

But when I compiled my program using:

gcc -Wall -ansi -pedantic -c

it reported some errors, reporting NAN and isnan(x) not supported.

I knew the options -ansi and -pedantic make things conform to the
older C standard (C90?).

My question are:

1. Is it fine to compile my program using *"gcc -Wall -c" instead of
using the more conservative "gcc -Wall -ansi -pedantic -c"?

2. Dose including NAN and isnan(x) hurt the portability of a program,
given high version of gcc is available in both Linux and Windows
(MinGW)?
Apr 4 '08 #2
oops! last post sent in error

On 4 Apr, 15:43, istillsh...@gmail.com wrote:
In my code I used NAN and isnan(x). *I found they were convenient to
use. *I also noticed that
older C standard does not support NAN and isnan(x).
as I said... only c99 offers IEEE support and even then it
is optional.

When I compiled my program using:

gcc -Wall -c

it was fine.

But when I compiled my program using:

gcc -Wall -ansi -pedantic -c

it reported some errors, reporting NAN and isnan(x) not supported.
as they aren't part of the standard

I knew the options -ansi and -pedantic make things conform to the
older C standard (C90?).
probably c90
My question are:

1. Is it fine to compile my program using *"gcc -Wall -c" instead of
using the more conservative "gcc -Wall -ansi -pedantic -c"?
only you can answer this. What is more important to you, IEEE
support or maximal portability?

2. Dose including NAN and isnan(x) hurt the portability of a program,
yes
given high version of gcc is available in both Linux and Windows
(MinGW)?
where is your software likely to run? If you going to
do lots of floating point you may decide to only support
systems that have IEEE support (a lot these days).

You might try putting gcc into its (almost) C99 mode.

The world is NOT confined to Linux and Windows
--
Nick Keighley
Apr 4 '08 #3
On Apr 4, 5:55 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 4 Apr, 15:43, istillsh...@gmail.com wrote:
In my code I used NAN and isnan(x). I found they were convenient to
use. I also noticed that
older C standard does not support NAN and isnan(x).

only C99 supports IEEE floating point, and even then
only if a particular macro is defined (
Hmm.. something went wrong here? :-)
The macro is __STDC_IEC_559__
<snip>
Apr 4 '08 #4
Nick Keighley wrote:
oops! last post sent in error

On 4 Apr, 15:43, istillsh...@gmail.com wrote:
>In my code I used NAN and isnan(x). I found they were convenient to
use. I also noticed that
older C standard does not support NAN and isnan(x).

as I said... only c99 offers IEEE support and even then it
is optional.
This is true but misleading. C99 does only offer optional IEEE support,
but the isnan() macro is not part of the IEEE extension.

See n1256 7.12.3.4 - isnan() is defined in math.h in all C99
implementations. (more below)
>But when I compiled my program using:

gcc -Wall -ansi -pedantic -c

it reported some errors, reporting NAN and isnan(x) not supported.

as they aren't part of the standard
NaN values and the isnan() macro are part of the standard. To be
precise, the standard allows but does not require NaNs to exist. If NaNs
don't exist the isnan() macro must still be provided and always returns
zero. The NAN macro is defined if and only if quiet NaN values are
supported by the float type.
>I knew the options -ansi and -pedantic make things conform to the
older C standard (C90?).

probably c90
Yes, -ansi corresponds to C90. (AFAIK it is equivalent to -std=c90)
>My question are:

1. Is it fine to compile my program using "gcc -Wall -c" instead of
using the more conservative "gcc -Wall -ansi -pedantic -c"?

only you can answer this. What is more important to you, IEEE
support or maximal portability?
Again, there are more NaN-supporting systems than just IEEE.
>2. Dose including NAN and isnan(x) hurt the portability of a program,

yes
Probably.

Apr 4 '08 #5
Then I wonder how people deal with NAN or INFINITY numbers in a
portable manner? I guess this situation arises frequently in
developing numerical softwares. In my program, I need to do something
like the following:
while (1) {
...
x = some expression; /* may cause problem */
if (x is neither NAN nor INFINITY) { /* make sure x is a useful
number */
break;
} else {
/* deal with the problem */
}
}

On Apr 4, 11:02 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
oops! last post sent in error

On 4 Apr, 15:43, istillsh...@gmail.com wrote:
In my code I used NAN and isnan(x). I found they were convenient to
use. I also noticed that
older C standard does not support NAN and isnan(x).

as I said... only c99 offers IEEE support and even then it
is optional.
When I compiled my program using:
gcc -Wall -c
it was fine.
But when I compiled my program using:
gcc -Wall -ansi -pedantic -c
it reported some errors, reporting NAN and isnan(x) not supported.

as they aren't part of the standard
I knew the options -ansi and -pedantic make things conform to the
older C standard (C90?).

probably c90
My question are:
1. Is it fine to compile my program using "gcc -Wall -c" instead of
using the more conservative "gcc -Wall -ansi -pedantic -c"?

only you can answer this. What is more important to you, IEEE
support or maximal portability?
2. Dose including NAN and isnan(x) hurt the portability of a program,

yes
given high version of gcc is available in both Linux and Windows
(MinGW)?

where is your software likely to run? If you going to
do lots of floating point you may decide to only support
systems that have IEEE support (a lot these days).

You might try putting gcc into its (almost) C99 mode.

The world is NOT confined to Linux and Windows

--
Nick Keighley
Apr 4 '08 #6
is*********@gmail.com wrote:
Then I wonder how people deal with NAN or INFINITY numbers in a
portable manner? I guess this situation arises frequently in
developing numerical softwares. In my program, I need to do something
like the following:
while (1) {
...
x = some expression; /* may cause problem */
if (x is neither NAN nor INFINITY) { /* make sure x is a useful
number */
break;
} else {
/* deal with the problem */
}
}

Just use isnan() and be done with it. It is standard C.
And if you find a compiler that doesn't support isnan()
throw it away and get a better one.

P.S.
I think

int isnan(double x)
{
if (x != x)
return 1;
return 0;
}
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Apr 4 '08 #7
In article <ft**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>P.S.
I think
>int isnan(double x)
{
if (x != x)
return 1;
return 0;
}
Though what happens if x is a signalling NaN? Signalling NaNs trigger
when their value is used. Just testing isnan(x) is not a use of the
value (it's test of the properties), but x != x would be a use of
the value and so would (if I understand correctly) trigger the signal.

--
"It's a hard life sometimes and the biggest temptation is to let
how hard it is be an excuse to weaken." -- Walter Dean Myers
Apr 4 '08 #8
Walter Roberson wrote:
In article <ft**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>P.S.
I think
>int isnan(double x)
{
if (x != x)
return 1;
return 0;
}

Though what happens if x is a signalling NaN? Signalling NaNs trigger
when their value is used. Just testing isnan(x) is not a use of the
value (it's test of the properties), but x != x would be a use of
the value and so would (if I understand correctly) trigger the signal.
The signal would be triggered anyway. It is up to you to
hide that signal using the fesetenv() (if you use C99) or
whatever. In ANY case, if you have a signaling NAN as a
result of a computation and the processor has that signal unmasked
your program will crash anyway.

I do not see the point of your objection.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Apr 4 '08 #9
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <ft**********@aioe.org>, jacob navia <ja***@nospam.orgwrote:
>>P.S.
I think
>>int isnan(double x)
{
if (x != x)
return 1;
return 0;
}
Why not this?

int isnan(double x)
{
return x != x;
}

(Just a minor style point.)

(Either way, the equivalent of isnan() is easy enough to implement
even in C90 that there's no point in rejecting a non-C99 compiler just
for this reason.)
Though what happens if x is a signalling NaN? Signalling NaNs trigger
when their value is used. Just testing isnan(x) is not a use of the
value (it's test of the properties), but x != x would be a use of
the value and so would (if I understand correctly) trigger the signal.
C99 explicitly doesn't define the behavior of signaling NaNs, even in
the optional Annex F (IEC 60559 floating-point arithmetic). The
isnan() function presumably tests for a quiet NaN. As jacob points
out, invoking ``isnan(x)'' if x is a signalling NaN has to evalute x
first, which could result in a trap.

In effect, signalling NaNs are just trap representations.

Note that the language could have provided, and an implementation can
provide, a function that tests for signalling NaNs:

int is_signalling_nan(double *x);

It could, for example, convert the double* argument to unsigned char*
and examine the representation, using system-specific knowledge of
what a signalling NaN looks like. As long as it doesn't access the
value *as floating-point*, it won't invoke UB. (Either this would
have to be a macro, probably using ``sizeof *x'' to determine what
type it points to, or there would have to be versions for float,
double, and long double.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 4 '08 #10
I got the following message when I compiled my program using "gcc -
Wall -c -ansi -pedantic"

tr.c:1246: warning: implicit declaration of function `isnan'

min.o(.text+0x36d):minimize.c: undefined reference to `isinf'

It seemed isnan() is not there by default. And, how to determine if a
number is infinite (negative or positive)?

Will the following function work?

int isinf(double x)
{
return x == -DBL_MAX || x == DBL_MAX;
}
On Apr 4, 6:12 pm, jacob navia <ja...@nospam.comwrote:
istillsh...@gmail.com wrote:
Then I wonder how people deal with NAN or INFINITY numbers in a
portable manner? I guess this situation arises frequently in
developing numerical softwares. In my program, I need to do something
like the following:
while (1) {
...
x = some expression; /* may cause problem */
if (x is neither NAN nor INFINITY) { /* make sure x is a useful
number */
break;
} else {
/* deal with the problem */
}
}

Just use isnan() and be done with it. It is standard C.
And if you find a compiler that doesn't support isnan()
throw it away and get a better one.

P.S.
I think

int isnan(double x)
{
if (x != x)
return 1;
return 0;

}

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32
Apr 5 '08 #11
I just tried the isinf() function I wrote previously, it did not
work. However, I found somewhere in clc an alternative:

static int isinf(double x)
{
return (x == x) && (x != 0) && (x + 1 == x);
}

And tested it using isinf(log(0) and isinf(1.0/0.0). It seemed
working.
On Apr 5, 12:18 am, istillsh...@gmail.com wrote:
I got the following message when I compiled my program using "gcc -
Wall -c -ansi -pedantic"

tr.c:1246: warning: implicit declaration of function `isnan'

min.o(.text+0x36d):minimize.c: undefined reference to `isinf'

It seemed isnan() is not there by default. And, how to determine if a
number is infinite (negative or positive)?

Will the following function work?

int isinf(double x)
{
return x == -DBL_MAX || x == DBL_MAX;

}

On Apr 4, 6:12 pm, jacob navia <ja...@nospam.comwrote:
istillsh...@gmail.com wrote:
Then I wonder how people deal with NAN or INFINITY numbers in a
portable manner? I guess this situation arises frequently in
developing numerical softwares. In my program, I need to do something
like the following:
while (1) {
...
x = some expression; /* may cause problem */
if (x is neither NAN nor INFINITY) { /* make sure x is a useful
number */
break;
} else {
/* deal with the problem */
}
}
Just use isnan() and be done with it. It is standard C.
And if you find a compiler that doesn't support isnan()
throw it away and get a better one.
P.S.
I think
int isnan(double x)
{
if (x != x)
return 1;
return 0;
}
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32
Apr 5 '08 #12
>I just tried the isinf() function I wrote previously, it did not
>work. However, I found somewhere in clc an alternative:

static int isinf(double x)
{
return (x == x) && (x != 0) && (x + 1 == x);
}
I have serious doubts that this will work correctly for large but
non-infinite numbers. For example, consider 1.0e+300. This fits
in an IEEE double. It compares equal to itself. It does not compare
equal to zero. And 1.0e+300 is going to compare equal to 1.0e+300
+ 1 because you don't have nearly enough mantissa bits in an IEEE
double to distinguish the two.
>And tested it using isinf(log(0) and isinf(1.0/0.0). It seemed
working.
Ok, but I think it comes up with lots of false positives.

Also, is there a reason you need that (x != 0) condition in there?
isinf(0.0) should fail the (x + 1 == x) condition.

Apr 5 '08 #13
In article <05adnaK7WogAh2ranZ2dnUVZ_qiinZ2d@internetamerica> ,
Gordon Burditt <go***********@burditt.orgwrote:
> return (x == x) && (x != 0) && (x + 1 == x);
>I have serious doubts that this will work correctly for large but
non-infinite numbers. For example, consider 1.0e+300. This fits
in an IEEE double. It compares equal to itself. It does not compare
equal to zero. And 1.0e+300 is going to compare equal to 1.0e+300
+ 1 because you don't have nearly enough mantissa bits in an IEEE
double to distinguish the two.
Perhaps x == x/2 would work better. You would need the x != 0 in that
case.

-- Richard
--
:wq
Apr 5 '08 #14
It is very good for me to learn this point. Thanks.
And 1.0e+300 is going to compare equal to 1.0e+300
+ 1 because you don't have nearly enough mantissa bits in an IEEE
double to distinguish the two.
Apr 5 '08 #15
Collecting ideas from you, I wrote a header file to handle the isnan
and isinf problem.

#ifndef _NAN_H
#define _NAN_H

#ifndef isnan
#define isnan(x) ((x) != (x))
#endif

#ifndef isinf
#define isinf(x) (((x) == (x)) && ((x) != 0) && ((x)/2 == (x)))
#endif

#endif /* _NAN_H */

Will the above work in most cases? I tried log(0), 1.0/0.0, and 1.0e
+300. They seemed to work fine.
On Apr 5, 5:45 am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <05adnaK7WogAh2ranZ2dnUVZ_qiinZ2d@internetamerica> ,

Gordon Burditt <gordonb.rm...@burditt.orgwrote:
return (x == x) && (x != 0) && (x + 1 == x);
I have serious doubts that this will work correctly for large but
non-infinite numbers. For example, consider 1.0e+300. This fits
in an IEEE double. It compares equal to itself. It does not compare
equal to zero. And 1.0e+300 is going to compare equal to 1.0e+300
+ 1 because you don't have nearly enough mantissa bits in an IEEE
double to distinguish the two.

Perhaps x == x/2 would work better. You would need the x != 0 in that
case.

-- Richard
--
:wq
Apr 5 '08 #16
is*********@gmail.com writes:
Collecting ideas from you, I wrote a header file to handle the isnan
and isinf problem.

#ifndef _NAN_H
#define _NAN_H

#ifndef isnan
#define isnan(x) ((x) != (x))
#endif

#ifndef isinf
#define isinf(x) (((x) == (x)) && ((x) != 0) && ((x)/2 == (x)))
#endif

#endif /* _NAN_H */

Will the above work in most cases? I tried log(0), 1.0/0.0, and 1.0e
+300. They seemed to work fine.
I don't know of any problems, but as Gordon Burditt pointed out, you
need to check for corner cases. However, I'd suggest picking
different names, since "isnan" and "isinf" are defined as macro names
in <math.hin C99. Also, the identifier "_NAN_H" is reserved to the
implementation. In general, it's best to avoid identifiers that start
with underscores.

If you're going to be posting here, you should learn some of the
guidelines. Please don't top-post; your response goes after, or
interspersed with, the text you're responding to. See:
http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

Trim quoted material down to what's necessary for your response to
make sense. It's usually not necessary to quote the entire previous
article. In particular, don't quote signatures (the stuff following
the "-- " line) unless you're actually commenting on them.

And please don't delete attribution lines (you didn't do so this time,
but you did in another article in this thread). Attribution lines are
the lines of the form "So-and-so write:"; they make it easier to
follow the discussion. (Gordon Burditt sets a bad example, though
he's been posting here long enough to know better.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Apr 5 '08 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Mike N. | last post: by
40 posts views Thread by RadiationX | last post: by
9 posts views Thread by =?Utf-8?B?TWlrZTk5MDA=?= | last post: by
reply views Thread by NPC403 | last post: by
3 posts views Thread by gieforce | last post: by
reply views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.