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