Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Not a number problem

Reply
Thread Tools

Not a number problem

 
 
istillshine@gmail.com
Guest
Posts: n/a
 
      04-04-2008
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)?


 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      04-04-2008
On 4 Apr, 15:43, (E-Mail Removed) 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)?


 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      04-04-2008
oops! last post sent in error

On 4 Apr, 15:43, (E-Mail Removed) 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


 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      04-04-2008
On Apr 4, 5:55 pm, Nick Keighley <(E-Mail Removed)>
wrote:
> On 4 Apr, 15:43, (E-Mail Removed) 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>
 
Reply With Quote
 
Philip Potter
Guest
Posts: n/a
 
      04-04-2008
Nick Keighley wrote:
> oops! last post sent in error
>
> On 4 Apr, 15:43, (E-Mail Removed) 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.

 
Reply With Quote
 
istillshine@gmail.com
Guest
Posts: n/a
 
      04-04-2008
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 <(E-Mail Removed)>
wrote:
> oops! last post sent in error
>
> On 4 Apr, 15:43, (E-Mail Removed) 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


 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      04-04-2008
In article <(E-Mail Removed)>,
<(E-Mail Removed)> 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.


NaN and Infinity do not occur in all floating point systems.
For example it was not uncommon for single precision floating point
numbers to be in some native format that used the entire value
space instead of reserving some of the potential value space as
special values such as infinity or the various types of NaN.

Thus, "dealing with NaN or infinity numbers in a portable manner"
is dubious -- unless, that is, you choose to restrict your
portability to systems that have defined support for them built in.


A classic test for a NaN, by the way, is

(!(x==x) && !(x!=x))

That is, a NaN does not compare equal to itself, and also does not
compare -not equal- to itself. And hope that the compiler doesn't
optimize the test away thinking that "of course x==x" . A compiler
that doesn't know that NaN's exist might make that mistake, so code
carefully.


If you are working with NaN and infinity, then chances are that you
are also concerned with rounding modes; the manipulation of rounding
modes is usually fairly system-specific before C99 (and
from what I remember, C99 does not capture the full flavour of
rounding modes.)
--
"Walter exemplified class." -- Paul Tagliabue
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-04-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      04-04-2008
In article <ft693m$88u$(E-Mail Removed)>, jacob navia <(E-Mail Removed)> wrote:

>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
 
Reply With Quote
 
christian.bau
Guest
Posts: n/a
 
      04-04-2008
On Apr 4, 10:35*pm, (E-Mail Removed)-cnrc.gc.ca (Walter Roberson)
wrote:

> A classic test for a NaN, by the way, is
>
> * (!(x==x) && !(x!=x))
>
> That is, a NaN does not compare equal to itself, and also does not
> compare -not equal- to itself.


NaN _always_ compares not equal to itself, that is x != x is _always_
true for NaNs. And (x != y) will _always_ give the same result as ! (x
== y), even with one or more NaNs and/or Infinities involved.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OT: Number Nine, Number Nine, Number Nine FrisbeeŽ MCSE 37 09-26-2005 04:06 PM
The number name 'System.Web.UI.WebControls' contains more than the maximum number of prefixes. The maximum is 3. mayur ASP .Net 2 07-02-2004 10:35 AM
real number to 16 bit signed number hari VHDL 6 05-02-2004 04:10 PM
IE 6.0 sockets number (TCP/IP channels number) for the same Site ??? taras ASP .Net 1 04-17-2004 04:51 AM
Convert decimal number in binary number makok VHDL 1 02-23-2004 06:04 PM



Advertisments