I noticed that D has both imaginary and complex primitive types? What is the motivation behind this. Is the goal to perform better optimizations for numerical computations? Why couldn't the types be part of a standard library?

nick wrote:
> I noticed that D has both imaginary and complex primitive types? What is the motivation behind this. Is the goal to perform better optimizations for numerical computations? Why couldn't the types be part of a standard library?
> 

I think it's to simplify writing code that uses this kind of computation.
The same reason that multiplication is a built-in operation, and not a function implemented in a library!!

"nick" <nick.atamas@gmail.com> wrote in message news:drhcqv$h8s$1@digitaldaemon.com...
>I noticed that D has both imaginary and complex primitive types? What is the motivation behind this. Is the goal to perform better optimizations for numerical computations? Why couldn't the types be part of a standard library?

This should help: www.digitalmars.com/d/cppcomplex.html

On 2006-01-28 21:14:53 -0800, Hasan Aljudy <hasan.aljudy@gmail.com> said:

> nick wrote:
>> I noticed that D has both imaginary and complex primitive types? What is the motivation behind this. Is the goal to perform better optimizations for numerical computations? Why couldn't the types be part of a standard library?
>> 
> 
> I think it's to simplify writing code that uses this kind of computation.
> The same reason that multiplication is a built-in operation, and not a function implemented in a library!!

Perhaps I should elaborate on my original question.

The point Guy Steele makes in "Growing a Language" is that languages should be simple and elegant while providing tools to grow the language for specific niches. He points out that a really large segment of applications doesn't use imaginary numbers. Making imaginary and complex part of the spec. begs the question of "why not have more things." I may argue that vec2 (a 2 dimensional vector) is also really useful, and should thus be a primitive; this sort of logic can escalate out of control. (Hey, that's how OOP came about and operator overloading)

I am asking why the decision was made to include imaginary and complex numbers directly in the language when operator overloading already provides a method to accomplish an almost identical result in a library. If having imaginary numbers in a library is not satisfactory, I would like to know why. Thus, my original question.

In article <drhkto$13uq$1@digitaldaemon.com>, Walter Bright says...
>
>
>"nick" <nick.atamas@gmail.com> wrote in message news:drhcqv$h8s$1@digitaldaemon.com...
>>I noticed that D has both imaginary and complex primitive types? What is the motivation behind this. Is the goal to perform better optimizations for numerical computations? Why couldn't the types be part of a standard library?
>
>This should help: www.digitalmars.com/d/cppcomplex.html
>
Thanks, that's exactly what I was looking for. I'm going to go read more so that
I am not asking stupid
questions.

"nick" <nick.atamas@gmail.com> wrote in message news:drhm8t$16vk$1@digitaldaemon.com...
> Perhaps I should elaborate on my original question.
>
> The point Guy Steele makes in "Growing a Language" is that languages should be simple and elegant while providing tools to grow the language for specific niches. He points out that a really large segment of applications doesn't use imaginary numbers. Making imaginary and complex part of the spec. begs the question of "why not have more things." I may argue that vec2 (a 2 dimensional vector) is also really useful, and should thus be a primitive; this sort of logic can escalate out of control. (Hey, that's how OOP came about and operator overloading)
>
> I am asking why the decision was made to include imaginary and complex numbers directly in the language when operator overloading already provides a method to accomplish an almost identical result in a library. If having imaginary numbers in a library is not satisfactory, I would like to know why. Thus, my original question.

It's a good question. I'll reply here in general, the specifics for complex numbers I gave a link to in the other message.

It certainly is a tempting idea to have a small core language, with everything else user definable. A consequence of this is that tokens are user definable, syntax is user definable, and of course semantics are user definable. It doesn't take much of this to make code in such a language completely unmaintainable. If you look at a piece of code, there is no touchstone, no common reference point of view, to what the code does, it can be or do *anything*.

A simple example of the trouble one can get into with this is the C++ overloading of << and >> in iostreams. If one wasn't already familiar with iostreams, what would one think when seeing all those <<? He'd think it would be shifting, when it is doing nothing of the sort.

Some C++ people have taken this much, much further with the Spirit library, which uses operator overloading to create an *entirely new and distinct* language for building parsers. Unfortunately, this new language winds up looking exactly like regular C++, so there's no way for the poor maintainer to distinguish it.

Another example is back in the 80's when macro assemblers were popular, many companies undertook to essentially write a new language using the macro processor, and then write 'assembler' files in that new language. One maintainer saddled with this mess told me he finally figured out a way to deal with it - he assembled it into a .obj file, then *disassembled* the .obj file back into assembler, and then replaced the original macro assembler source file with the disassembled source file, and worked from there.

So, practically, one is stuck with not allowing user defined tokens or user defined syntax. Unfortunately, then one must give up hope of *seamlessly* integrating new types into the language via libraries, as C++'s <complex> demonstrates.

Since user defined types cannot be seamlessly integrated in, the most practical approach is to hardwire in the most common types. Hence, D has the integer types, character types, floating point types, arrays, strings, and associative arrays hardwired in. That gets us the seamless integration.

As an aside - do we *really* need strings to be a user defined type? I believe the C++ experience with that shows it to be a disaster. I can expound on that in detail if anyone cares <g>.

Guy Steele says that few C++ users use imaginary and complex numbers. True. But I attribute that to the poor support for such in C++, which is why numeric programmers tend to stick with FORTRAN. The C and C++ committees and compiler vendors have historically neglected the interests of numeric programmers. (For example, look at the abandonment of 80 bit reals! Incredible.)

nick wrote:

> I noticed that D has both imaginary and complex primitive types?

Even better, D has an "imaginary real" type. (that would be ireal)

:-P

See http://www.digitalmars.com/d/archives/digitalmars/D/24116.html

--anders

Walter Bright wrote:

> It's a good question. I'll reply here in general, the specifics for complex numbers I gave a link to in the other message.
> 
> So, practically, one is stuck with not allowing user defined tokens or user defined syntax. Unfortunately, then one must give up hope of *seamlessly* integrating new types into the language via libraries, as C++'s <complex> demonstrates.
But D's operator overloading allows for *almost* seamlessly integrating math types into the language. Right?

 > As an aside - do we *really* need strings to be a user defined type? I
> believe the C++ experience with that shows it to be a disaster. I can expound on that in detail if anyone cares <g>.
I have experienced a bit of unpleasantness with C++ strings, including a nontrivial variant of this:
printf("Hello, %s", std::string("World")); //No c_str() -> SegFault;

I would certainly like to hear the details.


> Guy Steele says that few C++ users use imaginary and complex numbers. True. But I attribute that to the poor support for such in C++, which is why numeric programmers tend to stick with FORTRAN. The C and C++ committees and compiler vendors have historically neglected the interests of numeric programmers. (For example, look at the abandonment of 80 bit reals! Incredible.) 
Well, I thought Steele's point was more along the lines of "Java needs operator overloading", and complex numbers was just an example targeted at his audience. The link you sent me removed all doubt.

The 80bit float issue is ridiculous, of course; especially because 80 bit floats are supported by both AMD and Intel.

Anders F Björklund wrote:
> nick wrote:
> 
>> I noticed that D has both imaginary and complex primitive types?
> 
> Even better, D has an "imaginary real" type. (that would be ireal)
> 
> :-P
> 
> See http://www.digitalmars.com/d/archives/digitalmars/D/24116.html
> 
> --anders
Yes, I saw that when I search for 'imaginary' before posting this thread. It is a bit of a misnomer, but you could think of it as i*real which would be correct-ish, right?

nick wrote:

> Yes, I saw that when I search for 'imaginary' before posting this thread. It is a bit of a misnomer, but you could think of it as i*real which would be correct-ish, right?

I don't like the real type either, so... Think it should be an alias.
(my suggestion was to rename real to extended, and fix it at 80 bits)

--anders