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