This looks like a really nice language. I browsed through the online documentation and stopped at the Basic Data Types. I am more into the numerical bits of programming and nothing really take FORTRAN regarding number crunching. Anyway if i happened to write something in D, the first thing i had to do was to redefine the complex type. As it is it is totally useless in any real life applications. No one will use extended floating point precision for complex numbers other than in some very few extreme cases. 99% would be single or double.

Complex number should have type definition of two floats (2 * 32 bit), then a double complex type consisting of two doubles, and last a extended precision. This would be the "natural" way of doing it since complex numbers are afterall, only numbers. This would also make the complex type usable in real applications without having to modify it or make new classes of numbers.

Anyway, i have to download it and try it since it looks very apealing.

Ok, why is 80 bit complex types not useful?

"Bjornar Svingen" <bjornar.svingen@ktv.no> wrote in message news:av9gju$20pd$1@digitaldaemon.com...
> This looks like a really nice language. I browsed through the online documentation and stopped at the Basic Data Types. I am more into the numerical bits of programming and nothing really take FORTRAN regarding number crunching. Anyway if i happened to write something in D, the first thing i had to do was to redefine the complex type. As it is it is totally useless in any real life applications. No one will use extended floating point precision for complex numbers other than in some very few extreme cases. 99% would be single or double.
>
> Complex number should have type definition of two floats (2 * 32 bit),
then
> a double complex type consisting of two doubles, and last a extended precision. This would be the "natural" way of doing it since complex
numbers
> are afterall, only numbers. This would also make the complex type usable
in
> real applications without having to modify it or make new classes of numbers.
>
> Anyway, i have to download it and try it since it looks very apealing.
>
>

I would personally rather have the ability to build my own complex type (or matrix, or whatever algebraic type) than have one built in that won't suit the needs of most users.

Now that D has operator overloading, one could define a struct that represents complex numbers fairly easily.  The only thing really missing is a way to construct them.  D structs don't have constructors last I checked.

If complex is built into the language, may as well build in quaternions as well.  Taken to the logical extreme, this would end up being a huge burden on compiler vendors, and would only be used by a fraction of the potential D programmers.  Who would decide how much functionality to build into the types anyway?  You need exp and log, all kinds of rotations.  Would we be able to add new properties or member functions to complex?

I'd rather see some fundamental support for doing dot products and outer products on arrays.  D arrays are pretty powerful; we could almost use float[2] as our complex type and float[4] as our quaternion type!

Sean

"Bjornar Svingen" <bjornar.svingen@ktv.no> wrote in message news:av9gju$20pd$1@digitaldaemon.com...
> This looks like a really nice language. I browsed through the online documentation and stopped at the Basic Data Types. I am more into the numerical bits of programming and nothing really take FORTRAN regarding number crunching. Anyway if i happened to write something in D, the first thing i had to do was to redefine the complex type. As it is it is totally useless in any real life applications. No one will use extended floating point precision for complex numbers other than in some very few extreme cases. 99% would be single or double.
>
> Complex number should have type definition of two floats (2 * 32 bit),
then
> a double complex type consisting of two doubles, and last a extended precision. This would be the "natural" way of doing it since complex
numbers
> are afterall, only numbers. This would also make the complex type usable
in
> real applications without having to modify it or make new classes of numbers.
>
> Anyway, i have to download it and try it since it looks very apealing.

For starters, the same reason people use float instead of extended: storage!  An array of many complex types takes 2.5 times as much storage if extended is the underlying float type instead of single.  Not to mention that FPU's run faster for many operations if placed into single precision mode.

You could probably templatize complex so the user could choose how much precision they require.

Another practical concern for vendors is that since they're specified as 80 bit,  the compiler cannot choose to utilize the SSE2 registers (a pair of double-precision floating point numbers) to acceleration operations using SIMD on Pentium 4.

D should either have a full suite of customizable numeric types, or the capability for programmers to make their own.  Don't add them in just because they're in C99 and C++... I don't find those types useful either.  I might use them if I did 2D graphics, but for 3D graphics and other higher applications complex is just not good enough.  In any case I prefer to label my axes X and Y instead of Real and Imaginary.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:avb525$2sku$3@digitaldaemon.com...
> Ok, why is 80 bit complex types not useful?

"Sean L. Palmer"
> For starters, the same reason people use float instead of extended: storage!  An array of many complex types takes 2.5 times as much storage
if
> extended is the underlying float type instead of single.  Not to mention that FPU's run faster for many operations if placed into single precision mode.
Exactly, storage and speed. In most engineering applications involving large matrix number crunching, like CFD (computational fluid dynamics) and FEM (finite element method, for calculation of just about everything, forces, structures etc), single precision is more than enough accuracy. The inaccuracies in those calculations does not come from round off errors, but from the methods themselves and simplifications/errors in modelling. Complex is used when calculating vibrations and resonance frequencies. Often clusters of PCs in parallel are used for these calculations to speed up things and to use as much memory as possible. To model correctly and to achieve more correct results require huge amount of memory, not huge amount of machine precision.

The back end fully supports complex types, it was a no-brainer to put it into D. The code also internally fully supports float and double precisions for complex, all it lacks is a name for it.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:avb71b$2ur3$1@digitaldaemon.com...
> I would personally rather have the ability to build my own complex type
(or
> matrix, or whatever algebraic type) than have one built in that won't suit the needs of most users.
>
> Now that D has operator overloading, one could define a struct that represents complex numbers fairly easily.  The only thing really missing
is
> a way to construct them.  D structs don't have constructors last I
checked.
>
> If complex is built into the language, may as well build in quaternions as well.  Taken to the logical extreme, this would end up being a huge burden on compiler vendors, and would only be used by a fraction of the potential
D
> programmers.  Who would decide how much functionality to build into the types anyway?  You need exp and log, all kinds of rotations.  Would we be able to add new properties or member functions to complex?
>
> I'd rather see some fundamental support for doing dot products and outer products on arrays.  D arrays are pretty powerful; we could almost use float[2] as our complex type and float[4] as our quaternion type!
>
> Sean

That's not a very good reason to add something to a language spec.  Sure it makes sense to add it to DMD, but not D necessarily.

If the backend doesn't emit SIMD, there's no reason for it to have anything special for complex.

Sean

----- Original Message -----
From: "Walter" <walter@digitalmars.com>
Newsgroups: D
Sent: Thursday, January 09, 2003 1:03 AM
Subject: Re: Why this strange complex type


> The back end fully supports complex types, it was a no-brainer to put it into D. The code also internally fully supports float and double
precisions
> for complex, all it lacks is a name for it.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:avkgcl$20i4$1@digitaldaemon.com...
> That's not a very good reason to add something to a language spec.  Sure
it
> makes sense to add it to DMD, but not D necessarily.

The good reason is for it to be an upgrade from C. One design goal of D is to not take away any C features without a really strong reason. I also happened to like type complex <g>.

In article <avqr6s$2l66$1@digitaldaemon.com>, Walter says...
>
>
>"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:avkgcl$20i4$1@digitaldaemon.com...
>> That's not a very good reason to add something to a language spec.  Sure
>it
>> makes sense to add it to DMD, but not D necessarily.
>
>The good reason is for it to be an upgrade from C. One design goal of D is to not take away any C features without a really strong reason. I also happened to like type complex <g>.
>
>
Surely a complex number is just a special case of a two dimensional floating point vector ? Why does it need its own built in type ?

Type complex is really just an array of two real numbers with some overloaded operators attached.

That can be done in the library, or should be able to be.  ;)

Complex numbers are just the tip of the iceberg.  Are you going to add quaternions, octonions, etc?

Even complex should have variants matching the available machine floating point precisions.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:avqr6s$2l66$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:avkgcl$20i4$1@digitaldaemon.com...
> > That's not a very good reason to add something to a language spec.  Sure
> it
> > makes sense to add it to DMD, but not D necessarily.
>
> The good reason is for it to be an upgrade from C. One design goal of D is to not take away any C features without a really strong reason. I also happened to like type complex <g>.