www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Imaginary and Complex

reply nick <nick.atamas gmail.com> writes:
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?
Jan 28 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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!!
Jan 28 2006
parent reply nick <nick.atamas gmail.com> writes:
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.
Jan 28 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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.)
Jan 28 2006
parent reply nick <nick.atamas gmail.com> writes:
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.

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

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

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.
Jan 29 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"nick" <nick.atamas gmail.com> wrote in message 
news:dri35u$1o0f$1 digitaldaemon.com...
 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.

math types into the language. Right?

Yes. But I would never suggest replacing the 'int' type with a class, and I've never heard even the die hard C++ "do it all in the library" people suggest going that far.
  > 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>.

nontrivial variant of this: printf("Hello, %s", std::string("World")); //No c_str() -> SegFault; I would certainly like to hear the details.

The big problem is everyone produces their own string package. This means that 3rd party libraries can't interoperate with each other - each is its own, incompatible ecosystem. The answer I hear from that is to standardize std::string. Ok, but then one is stuck with the inflexibility of a core string type with the clumsiness of a library string type - the worst of both worlds. For some more thoughts on this, see www.digitalmars.com/d/cppstrings.html. The lack of decent built in strings has been a serious problem for C++ since the beginning. With core strings that work, then 3rd party libraries won't bother inventing their own, and they can pass strings between each other as easilly as ints.
 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.)

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.

Dropping support for it astounded me.
Jan 29 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 "nick" <nick.atamas gmail.com> wrote in message 
 news:dri35u$1o0f$1 digitaldaemon.com...
 
Walter Bright wrote:


 [snip]

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.

The big problem is everyone produces their own string package. This means that 3rd party libraries can't interoperate with each other - each is its own, incompatible ecosystem. The answer I hear from that is to standardize std::string. Ok, but then one is stuck with the inflexibility of a core string type with the clumsiness of a library string type - the worst of both worlds. For some more thoughts on this, see www.digitalmars.com/d/cppstrings.html. The lack of decent built in strings has been a serious problem for C++ since the beginning. With core strings that work, then 3rd party libraries won't bother inventing their own, and they can pass strings between each other as easilly as ints.

But then, doesn't this mean that D should have a standard String class too? just like Java? I mean, think about java, how silly would it be for someone to invent their own String class? really silly I'd say. But for D, I think there are good reasons for inventing one's own string class: - True OOP tends to never use arrays, always use objects, (strings, collections .. etc). You may disagree with them, but the fact is there are people who would go about wrapping wchar[] in a class. For instance, I know one of my professors who would do that (if he ever used D). Frankly, he's the one who made me hate C++, and that's pretty much the reason why I decided to start using D. When I told him about D, he said that he didn't look deeply into it, but he noticed that alot of the "features" (he put it in quotes) use completely procedural constructs (i.e. arrays); I'm under the impressions that if the language doesn't provide enough OO support, he won't use it. (If he ever had to use D, he would probably invent a String class!) And guess what, if that's his opinion, it's probably the opinion of many others. So please, for the sake of attracting these people to D, let D have a standard String class!!! - Another thing is dealing with char, wchar, dchar inconsistencies? (sorry, I don't know much about that, but I assume there will be some conflicts if I use wchar[] and someone else uses dchar[] somewhere else).
Jan 29 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Hasan Aljudy wrote:
 When I told him about D, he said that he didn't look deeply into it, but 
 he noticed that alot of the "features" (he put it in quotes) use 
 completely procedural constructs (i.e. arrays);

Ironically, the C++ standard library is designed to encourage the use of procedural constructs over OO ones.
 I'm under the
 impressions that if the language doesn't provide enough OO support, he 
 won't use it. (If he ever had to use D, he would probably invent a 
 String class!)
 And guess what, if that's his opinion, it's probably the opinion of many 
 others.

I'm sure it is. So what would you suggest? As a fan of the procedural/C++ style I can't really conceive a design I find acceptable. I'd much rather do everything via free functions (and that nifty trick that allows free functions to pretend they're member functions when used with arrays).
 - Another thing is dealing with char, wchar, dchar inconsistencies? 
 (sorry, I don't know much about that, but I assume there will be some 
 conflicts if I use wchar[] and someone else uses dchar[] somewhere else).

Explicit conversion is required, but that's it. Sean
Jan 29 2006
prev sibling parent reply nick <nick.atamas gmail.com> writes:
Hasan Aljudy wrote:
 But then, doesn't this mean that D should have a standard String class 
 too? just like Java?

 [..SNIP..]
 
 - Another thing is dealing with char, wchar, dchar inconsistencies? 
 (sorry, I don't know much about that, but I assume there will be some 
 conflicts if I use wchar[] and someone else uses dchar[] somewhere else).

You are right, a lot of people would not like /char[]/. I think the real reason they won't like it is because /char[]/ is because they like to see the word STRING and be reassured as to the purpose of an entity; the same logic applies to having a /bool/ instead of /int/. With that said, I can't think of too many instances where people would be thoroughly confused by this because an array of characters is USUALLY a string unless it's an array of bytes. However, since D has a type /byte/ it shouldn't be a problem. Finally, I think that string and/or String should be aliased to char[] to prevent people from writing their own classes.
Jan 29 2006
parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:
 Hasan Aljudy wrote:
 But then, doesn't this mean that D should have a standard String class 
 too? just like Java?

 [..SNIP..]

 - Another thing is dealing with char, wchar, dchar inconsistencies? 
 (sorry, I don't know much about that, but I assume there will be some 
 conflicts if I use wchar[] and someone else uses dchar[] somewhere else).

You are right, a lot of people would not like /char[]/. I think the real reason they won't like it is because /char[]/ is because they like to see the word STRING and be reassured as to the purpose of an entity; the same logic applies to having a /bool/ instead of /int/. With that said, I can't think of too many instances where people would be thoroughly confused by this because an array of characters is USUALLY a string unless it's an array of bytes. However, since D has a type /byte/ it shouldn't be a problem. Finally, I think that string and/or String should be aliased to char[] to prevent people from writing their own classes.

This might be the best approach. Simply add these aliases: alias char[] string; alias wchar[] wstring; alias dchar[] dstring; and then implement the rest as free functions (which, as I mentioned in my other post, can be called as if they were member functions in D). This would give D a string "class" of sorts, though it would not be inheritable. Sean
Jan 29 2006
parent reply nick <nick.atamas gmail.com> writes:
Could you explain the concept of a free function?
Jan 29 2006
parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:
 Could you explain the concept of a free function?

For whatever reason, DMD makes this possible: char[] str; // this is a "free function" int toInteger( char[] s ) { ... } int i = toInteger( str ), j = str.toInteger(); Both of the above calling conventions work for arrays (though not for primitives). By "free function" I merely meant a function that is declared at global scope. Sean
Jan 29 2006
parent reply nick <nick.atamas gmail.com> writes:
Sean Kelly wrote:
 nick wrote:
 Could you explain the concept of a free function?

For whatever reason, DMD makes this possible: char[] str; // this is a "free function" int toInteger( char[] s ) { ... } int i = toInteger( str ), j = str.toInteger(); Both of the above calling conventions work for arrays (though not for primitives). By "free function" I merely meant a function that is declared at global scope. Sean

My understanding is that this comes directly from how classes are implemented (/this/ gets passed in as the first parameter). I could be totally wrong though.
Jan 29 2006
parent reply Sean Kelly <sean f4.ca> writes:
nick wrote:
 Sean Kelly wrote:
 nick wrote:
 Could you explain the concept of a free function?

For whatever reason, DMD makes this possible: char[] str; // this is a "free function" int toInteger( char[] s ) { ... } int i = toInteger( str ), j = str.toInteger(); Both of the above calling conventions work for arrays (though not for primitives). By "free function" I merely meant a function that is declared at global scope.

My understanding is that this comes directly from how classes are implemented (/this/ gets passed in as the first parameter). I could be totally wrong though.

I think you're right. Though I don't understand why this wouldn't extend to primitives as well. Sean
Jan 29 2006
parent Dave <Dave_member pathlink.com> writes:
In article <drjodu$18oc$1 digitaldaemon.com>, Sean Kelly says...
nick wrote:
 Sean Kelly wrote:
 nick wrote:
 Could you explain the concept of a free function?

For whatever reason, DMD makes this possible: char[] str; // this is a "free function" int toInteger( char[] s ) { ... } int i = toInteger( str ), j = str.toInteger(); Both of the above calling conventions work for arrays (though not for primitives). By "free function" I merely meant a function that is declared at global scope.

My understanding is that this comes directly from how classes are implemented (/this/ gets passed in as the first parameter). I could be totally wrong though.

I think you're right. Though I don't understand why this wouldn't extend to primitives as well.

The transformation is done in expression.c: Expression *CallExp::semantic(Scope *sc) I doesn't look like there is any reason this can't be done with primitives either. I think it would be great if we could write functions that would then be called as a 'property' for primitives. For example, what we can do now with strings; char[] lowercase(char[] str) {...} char[] str = ...; str.lowercase(); One problem (inconsistency?) with that is currently 'str.lowercase()' has to be called with the parantheses, so doesn't have property or 'field' like syntax.
Sean

Jan 29 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 
 For some more thoughts on this, see www.digitalmars.com/d/cppstrings.html.
 

There's a doc bug inn "Filling a string": char[] str = "hello"; str[1..2] = '?'; // str is "h??lo" str is "h?llo" and not "h??lo". Dunno if there is a problem too with the C++ example. -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 01 2006
next sibling parent Yves Jacoby <kloune gmail.com> writes:
On Wed, 01 Feb 2006 13:49:57 +0000, Bruno Medeiros wrote:

 Walter Bright wrote:
 
 For some more thoughts on this, see www.digitalmars.com/d/cppstrings.html.
 

There's a doc bug inn "Filling a string": char[] str = "hello"; str[1..2] = '?'; // str is "h??lo" str is "h?llo" and not "h??lo". Dunno if there is a problem too with the C++ example.

Hi, I have another example for that, but same problem, somehow the end index is the real end index+1. I thought it was implemented like that in the language, so that if you wanted to fill the complete array you would do: str[0..length]='?'.
Feb 01 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
You're right, I'll fix it. 
Feb 01 2006
prev sibling next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"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
Jan 28 2006
parent nick.atamas gmail.com writes:
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

I am not asking stupid questions.
Jan 28 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 29 2006
parent reply nick <nick.atamas gmail.com> writes:
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

thread. It is a bit of a misnomer, but you could think of it as i*real which would be correct-ish, right?
Jan 29 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 29 2006