www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.complex MAY I REMIND YOU?

reply S <S s.com> writes:
http://www.digitalmars.com/d/2.0/cppcomplex.html

Why are we removing it from the language when it was just FINALLY added to
C?!?!?!

-S.
Feb 22 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"S" <S s.com> wrote in message news:fpmui8$aj$1 digitalmars.com...
 http://www.digitalmars.com/d/2.0/cppcomplex.html

 Why are we removing it from the language when it was just FINALLY added to 
 C?!?!?!

 -S.
To be different!
Feb 22 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
S wrote:
 http://www.digitalmars.com/d/2.0/cppcomplex.html
 
 Why are we removing it from the language when it was just FINALLY added to
C?!?!?!
I'm not sure if it was conclusively decided to remove it or not. But anyway, the code in std.complex is capable of representing complex numbers in polar format which is a trick that the built-in complex numbers can't do. So that somewhat justifies its existence regardless of whether the built-in types are removed. --bb
Feb 22 2008
parent reply Don Clugston <dac nospam.com.au> writes:
Bill Baxter wrote:
 S wrote:
 http://www.digitalmars.com/d/2.0/cppcomplex.html

 Why are we removing it from the language when it was just FINALLY 
 added to C?!?!?!
I'm not sure if it was conclusively decided to remove it or not. But anyway, the code in std.complex is capable of representing complex numbers in polar format which is a trick that the built-in complex numbers can't do. So that somewhat justifies its existence regardless of whether the built-in types are removed. --bb
Agreed, although I wonder if supporting polar format is going to create headaches later. The set of numbers representable in x+iy format with IEEE numbers is not exactly the same as for polar format. Algorithms for precise computations in polar format are quite hard to find (although in a great many cases they are simpler). So I have a vague fear that this might create a lot of work in the future - I hope I'm wrong. We might just need to dampen expectations about which operations will be supported.
Feb 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:
 So I have a vague fear that this might create a lot of work in the 
 future - I hope I'm wrong. We might just need to dampen expectations 
 about which operations will be supported.
std.complex is more of a placeholder for the future. I want to remove the core complex types, but the necessary compiler optimizations aren't implemented yet, and there are more important things to be done at the moment.
Feb 24 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Don Clugston wrote:
 So I have a vague fear that this might create a lot of work in the 
 future - I hope I'm wrong. We might just need to dampen expectations 
 about which operations will be supported.
std.complex is more of a placeholder for the future. I want to remove the core complex types, but the necessary compiler optimizations aren't implemented yet, and there are more important things to be done at the moment.
And I really really hope that when it does happen, the old code will keep working without much more than an "import std.complex;". --bb
Feb 24 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 22/02/2008, S <S s.com> wrote:
 http://www.digitalmars.com/d/2.0/cppcomplex.html

  Why are we removing it from the language when it was just FINALLY added to
C?!?!?!
C doesn't have templates.
Feb 22 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 22/02/2008, S <S s.com> wrote:
 http://www.digitalmars.com/d/2.0/cppcomplex.html
Hmm... On that on that web page. It says: "A streamline goes astray when the complex functions SQRT and LOG are implemented, as is necessary in Fortran and in libraries currently distributed with C/C++ compilers, in a way that disregards the sign of 0.0 in IEEE 754 arithmetic and consequently violates identities like SQRT( CONJ( Z ) ) = CONJ( SQRT( Z ) ) and LOG( CONJ( Z ) ) = CONJ( LOG( Z ) ) whenever the COMPLEX variable Z takes negative real values." The thing is, every complex number has /two/ square roots, not one. (If y is a square root of x, then so is -y). As soon as you invent some arbitrary way of choosing one of them over the other, then the identity ceases to be an identity. Likewise, every complex number has an infinite number of logarithms. (If y is a log of x, then so is y+2*pi*k*i, for all integers k). Again, the moment you decide that log can only return one value, then why be surprised when the identity no longer holds? The function CONJ() turns x+iy into x-iy, so /obviously/, if y is zero, then conj leaves a complex number unchanged. That little "cheat" of using the "sign of zero" to decide which of the multivalues is the primary one is just that - a cheat. Mathematical zero has no sign.
Feb 22 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
S wrote:
 http://www.digitalmars.com/d/2.0/cppcomplex.html
 
 Why are we removing it from the language when it was just FINALLY added to
C?!?!?!
Because advancing compiler technology is pretty much erasing the advantages of making complex a core type.
Feb 22 2008
parent reply JMNorris <nospam nospam.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote in
news:fpn4a3$bd9$2 digitalmars.com: 

 Because advancing compiler technology is pretty much erasing the 
 advantages of making complex a core type.
Okay, I'll bite. What compiler advances are erasing what advantages? I'm quite ignorant of the issues involved. -- JMNorris
Feb 24 2008
parent reply Matti Niemenmaa <see_signature for.real.address> writes:
JMNorris wrote:
 Walter Bright <newshound1 digitalmars.com> wrote in
 news:fpn4a3$bd9$2 digitalmars.com: 
 
 Because advancing compiler technology is pretty much erasing the 
 advantages of making complex a core type.
Okay, I'll bite. What compiler advances are erasing what advantages? I'm quite ignorant of the issues involved.
http://www.digitalmars.com/d/1.0/cppcomplex.html seems to be a good summary. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 24 2008
parent reply JMNorris <nospam nospam.com> writes:
Matti Niemenmaa <see_signature for.real.address> wrote in
news:fptoso$24mc$1 digitalmars.com: 

 JMNorris wrote:
 Walter Bright <newshound1 digitalmars.com> wrote in
 news:fpn4a3$bd9$2 digitalmars.com: 
 
 Because advancing compiler technology is pretty much erasing the 
 advantages of making complex a core type.
Okay, I'll bite. What compiler advances are erasing what advantages? I'm quite ignorant of the issues involved.
http://www.digitalmars.com/d/1.0/cppcomplex.html seems to be a good summary.
This is a good summary of the advantages of making complex a core type. I thought Walter was saying that compiler advances are erasing those advantages, and that is why it complex numbers will no longer be a core type. But that is what I don't understand. -- JMNorris
Feb 25 2008
parent reply Matti Niemenmaa <see_signature for.real.address> writes:
JMNorris wrote:
 Matti Niemenmaa <see_signature for.real.address> wrote in
 news:fptoso$24mc$1 digitalmars.com: 
 http://www.digitalmars.com/d/1.0/cppcomplex.html seems to be a good
 summary. 
This is a good summary of the advantages of making complex a core type. I thought Walter was saying that compiler advances are erasing those advantages, and that is why it complex numbers will no longer be a core type. But that is what I don't understand.
Well, it appears to be all about optimization: everything else can be done in a library. Some "syntactical aesthetics" will be lost, but nothing else should be. So all it really takes is a compiler smart enough to optimize the operations on complex numbers, which I guess is what Walter meant when he mentioned "compiler advances" --- compilers these days are smarter, especially when it comes to optimization, than they used to be. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 25 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Matti Niemenmaa wrote:
 JMNorris wrote:
 Matti Niemenmaa <see_signature for.real.address> wrote in
 news:fptoso$24mc$1 digitalmars.com:
 http://www.digitalmars.com/d/1.0/cppcomplex.html seems to be a good
 summary.
This is a good summary of the advantages of making complex a core type. I thought Walter was saying that compiler advances are erasing those advantages, and that is why it complex numbers will no longer be a core type. But that is what I don't understand.
Well, it appears to be all about optimization: everything else can be done in a library. Some "syntactical aesthetics" will be lost, but nothing else should be.
There's the bit from that Kahan guy about operations being handled improperly too. (1 - infinity*i) * i should be (infinity + i). I'm not sure how an optimizer is going to deal with that. Seems like the only way to deal with that is to de-optimize by introducing many conditionals in complex math operations. Or maybe he's just going to keep the pure imaginary type. A recent discussion made it sound like it was on the way out too, but maybe not.
 So all it really takes is a compiler smart enough to optimize the 
 operations on complex numbers, which I guess is what Walter meant when 
 he mentioned "compiler advances" --- compilers these days are smarter, 
 especially when it comes to optimization, than they used to be.
But the fact that smarter compilers exist does not magically make DMD any smarter. I suspect "compiler advances" are mostly the result of throwing lots of engineering time at the problem, analyzing piles of test cases, comparing generated code with ideal assembly code, and figuring out transformation rules that can be used to get closer to that ideal assembly. I.e. not theoretical breakthroughs, but just plain hard work. Anyway, sounds like nothing's going to change for a while. --bb
Feb 25 2008
parent Matti Niemenmaa <see_signature for.real.address> writes:
Bill Baxter wrote:
 Matti Niemenmaa wrote:
 JMNorris wrote:
 Matti Niemenmaa <see_signature for.real.address> wrote in
 news:fptoso$24mc$1 digitalmars.com:
 http://www.digitalmars.com/d/1.0/cppcomplex.html seems to be a good
 summary.
This is a good summary of the advantages of making complex a core type. I thought Walter was saying that compiler advances are erasing those advantages, and that is why it complex numbers will no longer be a core type. But that is what I don't understand.
Well, it appears to be all about optimization: everything else can be done in a library. Some "syntactical aesthetics" will be lost, but nothing else should be.
There's the bit from that Kahan guy about operations being handled improperly too. (1 - infinity*i) * i should be (infinity + i). I'm not sure how an optimizer is going to deal with that. Seems like the only way to deal with that is to de-optimize by introducing many conditionals in complex math operations. Or maybe he's just going to keep the pure imaginary type. A recent discussion made it sound like it was on the way out too, but maybe not.
Just about everything on that page does refer to only the pure imaginary type, so one would think it is to be kept at least in some form. Or, as you say, some sort of flag or conditional against a zero real part.
 So all it really takes is a compiler smart enough to optimize the 
 operations on complex numbers, which I guess is what Walter meant when 
 he mentioned "compiler advances" --- compilers these days are smarter, 
 especially when it comes to optimization, than they used to be.
But the fact that smarter compilers exist does not magically make DMD any smarter.
True, which is why it hasn't been done yet, as Walter said in fpsj89$2p0h$1 digitalmars.com: "I want to remove the core complex types, but the necessary compiler optimizations aren't implemented yet, and there are more important things to be done at the moment."
 Anyway, sounds like nothing's going to change for a while.
Agreed. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 25 2008