www.digitalmars.com         C & C++   DMDScript  

D - == nan doesn't work

reply "Dario" <supdar yahoo.com> writes:
extern(C) int printf(char* format, ...);
extern(C) int getch();

int main()
{
    extended a;
    if(a == extended.init)
        printf("a is not a number");

    getch();
    return 0;
}
_______________________________
This doesn't work.
I noticed that operator== returns false if a == nan, no matter what we
compare it to: this is also documented in the language ref.
Maybe these expressions:
a == nan;
a == init;
a != nan;
a != init;
should be interpreted without nan-operator-testing, and expressions like:
a > nan;
should be invalid (this aren't actually...).

Another solution is to differentiate operator== and operator=== so that the
latter does the comparison without nan-operator-testing (like C operator==).
I don't like this solution anyway.
Jul 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Dario" <supdar yahoo.com> wrote in message
news:aghukc$1pg6$1 digitaldaemon.com...

 extern(C) int printf(char* format, ...);
 extern(C) int getch();

 int main()
 {
     extended a;
     if(a == extended.init)
         printf("a is not a number");

     getch();
     return 0;
 }
 _______________________________
 This doesn't work.
 I noticed that operator== returns false if a == nan, no matter what we
 compare it to: this is also documented in the language ref.


That's the way IEEE arithmetic is defined. It takes a bit of getting used
to.


 Maybe these expressions:
 a == nan;
 a == init;
 a != nan;
 a != init;
 should be interpreted without nan-operator-testing, and expressions like:
 a > nan;
 should be invalid (this aren't actually...).

 Another solution is to differentiate operator== and operator=== so that


the

 latter does the comparison without nan-operator-testing (like C


operator==).

 I don't like this solution anyway.


That could be done, but I'm not sure the utility and the special case
behavior would be worth it.
Jul 10 2002
parent reply "Dario" <supdar yahoo.com> writes:
 extern(C) int printf(char* format, ...);
 extern(C) int getch();

 int main()
 {
     extended a;
     if(a == extended.init)
         printf("a is not a number");

     getch();
     return 0;
 }
 _______________________________
 This doesn't work.
 I noticed that operator== returns false if a == nan, no matter what we
 compare it to: this is also documented in the language ref.





 That's the way IEEE arithmetic is defined. It takes a bit of getting used
 to.



 Maybe these expressions:
 a == nan;
 a == init;
 a != nan;
 a != init;
 should be interpreted without nan-operator-testing, and expressions




like:

 a > nan;
 should be invalid (this aren't actually...).

 Another solution is to differentiate operator== and operator=== so that


 the

 latter does the comparison without nan-operator-testing (like C


 operator==).

 I don't like this solution anyway.





 That could be done, but I'm not sure the utility and the special case
 behavior would be worth it.


Well, I had to check if a variable has ever been initialized. How can I do
this?
Jul 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Dario" <supdar yahoo.com> wrote in message
news:agklu0$2pfo$1 digitaldaemon.com...

 Well, I had to check if a variable has ever been initialized. How can I do
 this?


Good question. The flip answer is variables are guaranteed to be initialized
in D, so there's no need to check for it. The more practical answer is that
floating point values will need to be special cased because of the nan
behavior. You can use math.isnan() for instance. I hate special cases too,
but I think it's easier to live with IEEE behavior (especially since it is
coded into the FPU hardware) than to try and buck it like Java does.
Jul 12 2002
next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I've always thought 0.0 is a better default initializer than nan.
Especially since the binary representation of 0.0 is 0x00000000.  Some
hardware may not have a nan in their floating point representation (some
kind of non-IEEE float?)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:agoip9$1e82$1 digitaldaemon.com...

 "Dario" <supdar yahoo.com> wrote in message
 news:agklu0$2pfo$1 digitaldaemon.com...

 Well, I had to check if a variable has ever been initialized. How can I




do

 this?


 Good question. The flip answer is variables are guaranteed to be


initialized

 in D, so there's no need to check for it. The more practical answer is


that

 floating point values will need to be special cased because of the nan
 behavior. You can use math.isnan() for instance. I hate special cases too,
 but I think it's easier to live with IEEE behavior (especially since it is
 coded into the FPU hardware) than to try and buck it like Java does.
Jul 13 2002
next sibling parent reply "Dario" <supdar yahoo.com> writes:
 I've always thought 0.0 is a better default initializer than nan.
 Especially since the binary representation of 0.0 is 0x00000000.  Some
 hardware may not have a nan in their floating point representation (some
 kind of non-IEEE float?)


I agree with you.
I need floats to be initialized to 0.0 more often. IMO, a initialization to
NaN is useless in most applications.
Moreover, if I write a program using ints (init = 0), I would like to be
able to turn to floats without having to add explicit initializations.

My first experience with OpenGL in D resulted in a black screen because of
the NaN initializer. Changing this will avoid this kind of error (difficult
to find for a newbye). ;-)
Jul 13 2002
parent "anderson" <anderson firestar.com.au> writes:
"Dario" <supdar yahoo.com> wrote in message
news:agp3eg$2c2c$1 digitaldaemon.com...

 I've always thought 0.0 is a better default initializer than nan.
 Especially since the binary representation of 0.0 is 0x00000000.  Some
 hardware may not have a nan in their floating point representation (some
 kind of non-IEEE float?)


 I agree with you.
 I need floats to be initialized to 0.0 more often. IMO, a initialization


to

 NaN is useless in most applications.
 Moreover, if I write a program using ints (init = 0), I would like to be
 able to turn to floats without having to add explicit initializations.

 My first experience with OpenGL in D resulted in a black screen because of
 the NaN initializer. Changing this will avoid this kind of error


(difficult

 to find for a newbye). ;-)


Yes it makes sense to make floats initialise to 0.0 as everything else
practically does. Often you decide to change a "float into a int" or an "int
into a float", and that can cause problems with nan.
Jul 13 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:agol37$1hpj$1 digitaldaemon.com...

 I've always thought 0.0 is a better default initializer than nan.
 Especially since the binary representation of 0.0 is 0x00000000.  Some
 hardware may not have a nan in their floating point representation (some
 kind of non-IEEE float?)


I beg to differ! Nan is a great default initializer, because it has the
wonderful property of percolating through all the calculations that depend
on it, setting the result to nan. This property, when used properly, is both
a great way for finding bugs and a great way to represent unknown values in
a data matrix and know which results are not dependent on those unknown
values.

I wish there was a hardware nan for integers, too.

Yes, it's true that there is floating point hardware that doesn't support
Nan (Vax and pdp-11 come to mind), but I am not aware of any modern fpu that
doesn't. If someone wants to put D on such obsolete hardware, they'll have
to include documentation that explains the non-standard floating point
behavior.

As you can guess, I don't like the C standard method of underspecifying
floating point in order to accommodate obsolete hardware. I also object to
the Java method of overspecifying floating point behavior so that it won't
work on 95% of the fpu hardware in the wild.
Jul 15 2002
prev sibling parent "Robert M. Münch" <robert.muench robertmuench.de> writes:
"Walter" <walter digitalmars.com> schrieb im Newsbeitrag
news:agoip9$1e82$1 digitaldaemon.com...


 The more practical answer is that
 floating point values will need to be special cased because of the nan
 behavior. You can use math.isnan() for instance. I hate special cases too,
 but I think it's easier to live with IEEE behavior (especially since it is
 coded into the FPU hardware) than to try and buck it like Java does.


IMO that's the right way to go even if it's not very programmer friendly.
But this behaviour reminds you each time that floating point stuff needs to
be cared about. A lot of people don't know about the hassels with FP
things... I need 0.0 most of the time too but using an explicit
initialization is OK.

--
Robert M. Münch
IT & Management Freelancer
Mobile: +49 (0)177 2452 802
Fax   : +49 (0)721 8408 9112
Web   : http://www.robertmuench.de
Jul 14 2002