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.

"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.

> > 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?

"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.

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.

> 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). ;-)

"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.

"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

"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.