Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Not a number problem

 
 
jacob navia
Guest
Posts: n/a
 
      04-04-2008
Walter Roberson wrote:
> 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.
>


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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      04-04-2008
http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca (Walter Roberson) writes:
> 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;
>>}


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) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
istillshine@gmail.com
Guest
Posts: n/a
 
      04-05-2008
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 <(E-Mail Removed)> wrote:
> (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/informatiquehttp://www.cs.virginia.edu/~lcc-win32


 
Reply With Quote
 
istillshine@gmail.com
Guest
Posts: n/a
 
      04-05-2008
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, (E-Mail Removed) 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 <(E-Mail Removed)> wrote:
>
> > (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/informatiquehttp://www.cs.virginia.edu/~lcc-win32


 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      04-05-2008
In article <05adnaK7WogAh2ranZ2dnUVZ_qiinZ2d@internetamerica> ,
Gordon Burditt <(E-Mail Removed)> wrote:

>> 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
 
Reply With Quote
 
istillshine@gmail.com
Guest
Posts: n/a
 
      04-05-2008
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.


 
Reply With Quote
 
istillshine@gmail.com
Guest
Posts: n/a
 
      04-05-2008
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, (E-Mail Removed) (Richard Tobin) wrote:
> In article <05adnaK7WogAh2ranZ2dnUVZ_qiinZ2d@internetamerica> ,
>
> Gordon Burditt <(E-Mail Removed)> wrote:
> >> 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


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-05-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) 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.h> in 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) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
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