www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Wht std.complex is needed?

reply Sam Hu <samhu.samhu gmail.com> writes:
Hello everyone!

Doesn't  D already has the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal?What's the advantage having complex class instead?

Thanks and best regards,
Sam
Apr 06 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sam Hu:

 Doesn't  D already has the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal?What's the advantage having complex class instead?


Some people have discussed/complained that complex types aren't worth being
built-ins, so the *struct* Complex of std.complex of D2 will replace them. (I
am not sure such complex struct is as good as the current built-ins, but it
seems most D1 users don't use complex numbers much, so they don't care).

Bye,
bearophile
Apr 06 2009
next sibling parent reply Sam Hu <samhu.samhu gmail.com> writes:
Thank you!
Anothe silly question then:What's the disadvantage to have the built-in type of
i-type?

Regards,
Sam
Apr 06 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sam Hu Wrote:

What's the disadvantage to have the built-in type of i-type?<


I think the answer is: It's another type added to the language, with its
specific semantics, so it adds a bit of complexity to the language. And most
people today don't seem to use complex types in D1 much, so they think they
don't want to pay for such extra complexity.

A better question can be: "What's the advantage of having a built-in imaginary
type?" :-)
You can find an answer here, from page 11:
http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
But maybe those ideas aren't much true anymore today.

Bye,
bearophile
Apr 06 2009
parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
bearophile wrote:

 A better question can be: "What's the advantage of having a built-in imaginary
type?" :-)
 You can find an answer here, from page 11:
 http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
 But maybe those ideas aren't much true anymore today.


Why could you not make a struct imaginary, with complex defined by
something like:

	struct complex(T) {
		T re;
		imaginary(T) im;
		…
	}

This can get you all the benefits Kahan talks about.

—Joel Salomon
Apr 06 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Sam Hu wrote:

 Thank you!
 Anothe silly question then:What's the disadvantage to have the built-in type
of i-type?
 
 Regards,
 Sam


It's a very nasty type. It supports *, but isn't closed under *.
Which is really annoying for generic programming.

idouble x = 2i;
x *= x; // oops, this isn't imaginary. (BTW this currently compiles :o).
Apr 06 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 06 Apr 2009 08:36:18 -0400, Don <nospam nospam.com> wrote:


 Sam Hu wrote:

 Thank you!
 Anothe silly question then:What's the disadvantage to have the built-in  
 type of i-type?
  Regards,
 Sam


 It's a very nasty type. It supports *, but isn't closed under *.
 Which is really annoying for generic programming.

 idouble x = 2i;
 x *= x; // oops, this isn't imaginary. (BTW this currently compiles :o).


This may be a dumb question, but aren't all real numbers also technically  
imaginary numbers with a 0i term?  that is, I would expect the above to  
evaluate to:

-4 + 0i

Which I would view as an imaginary number.  Am I completely wrong here?

That being said, I hope I never have to deal with imaginary numbers in my  
career, I had enough of them in school ;)  So I don't really care whether  
it's a builtin or not.

-Steve
Apr 06 2009
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Steven Schveighoffer wrote:

 On Mon, 06 Apr 2009 08:36:18 -0400, Don <nospam nospam.com> wrote:
 

 Sam Hu wrote:

 Thank you!
 Anothe silly question then:What's the disadvantage to have the
 built-in type of i-type?
  Regards,
 Sam


 It's a very nasty type. It supports *, but isn't closed under *.
 Which is really annoying for generic programming.

 idouble x = 2i;
 x *= x; // oops, this isn't imaginary. (BTW this currently compiles :o).


 
 This may be a dumb question, but aren't all real numbers also
 technically imaginary numbers with a 0i term?  that is, I would expect
 the above to evaluate to:
 
 -4 + 0i
 
 Which I would view as an imaginary number.  Am I completely wrong here?


You're thinking of "complex".  -4 is real, 2i is imaginary, -4+2i is
complex.

Regarding Don's example, imaginary*imaginary always yields a real,
real*imaginary always yields an imaginary.  It's the only builtin type I
know of that changes type under multiplication with itself.

  -- Daniel
Apr 06 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:

 On Mon, 06 Apr 2009 08:36:18 -0400, Don <nospam nospam.com> wrote:
 

 Sam Hu wrote:

 Thank you!
 Anothe silly question then:What's the disadvantage to have the 
 built-in type of i-type?
  Regards,
 Sam


 It's a very nasty type. It supports *, but isn't closed under *.
 Which is really annoying for generic programming.

 idouble x = 2i;
 x *= x; // oops, this isn't imaginary. (BTW this currently compiles :o).


 
 This may be a dumb question, but aren't all real numbers also 
 technically imaginary numbers with a 0i term?  that is, I would expect 
 the above to evaluate to:
 
 -4 + 0i
 
 Which I would view as an imaginary number.  Am I completely wrong here?


It's a complex number.
(real OP real OP real) is real.
(complex OP complex OP complex) is complex.
BUT
(imaginary OP imaginary OP imaginary) is imaginary, or real, or complex.




 
 That being said, I hope I never have to deal with imaginary numbers in 
 my career, I had enough of them in school ;)  So I don't really care 
 whether it's a builtin or not.
 
 -Steve
Apr 06 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 06 Apr 2009 09:50:35 -0400, Don <nospam nospam.com> wrote:


 Steven Schveighoffer wrote:

 On Mon, 06 Apr 2009 08:36:18 -0400, Don <nospam nospam.com> wrote:


 Sam Hu wrote:

 Thank you!
 Anothe silly question then:What's the disadvantage to have the  
 built-in type of i-type?
  Regards,
 Sam


 It's a very nasty type. It supports *, but isn't closed under *.
 Which is really annoying for generic programming.

 idouble x = 2i;
 x *= x; // oops, this isn't imaginary. (BTW this currently compiles  
 :o).


  This may be a dumb question, but aren't all real numbers also  
 technically imaginary numbers with a 0i term?  that is, I would expect  
 the above to evaluate to:
  -4 + 0i
  Which I would view as an imaginary number.  Am I completely wrong here?


 It's a complex number.
 (real OP real OP real) is real.
 (complex OP complex OP complex) is complex.
 BUT
 (imaginary OP imaginary OP imaginary) is imaginary, or real, or complex.


Yes, I meant to say complex, sorry.

Turns out I was not reading fully the previous posts.  I was not aware  
that there were two separate types for complex and imaginary.  I thought  
idouble was a complex number.

That's kind of... um weird?  Why do you need an imaginary AND a complex  
type?  Wouldn't just a complex type suffice?

Anyway, don't mind me, I just was confused.

-Steve
Apr 06 2009
parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:

 On Mon, 06 Apr 2009 09:50:35 -0400, Don <nospam nospam.com> wrote:
 

 Steven Schveighoffer wrote:

 On Mon, 06 Apr 2009 08:36:18 -0400, Don <nospam nospam.com> wrote:


 Sam Hu wrote:

 Thank you!
 Anothe silly question then:What's the disadvantage to have the 
 built-in type of i-type?
  Regards,
 Sam


 It's a very nasty type. It supports *, but isn't closed under *.
 Which is really annoying for generic programming.

 idouble x = 2i;
 x *= x; // oops, this isn't imaginary. (BTW this currently compiles 
 :o).


  This may be a dumb question, but aren't all real numbers also 
 technically imaginary numbers with a 0i term?  that is, I would 
 expect the above to evaluate to:
  -4 + 0i
  Which I would view as an imaginary number.  Am I completely wrong here?


 It's a complex number.
 (real OP real OP real) is real.
 (complex OP complex OP complex) is complex.
 BUT
 (imaginary OP imaginary OP imaginary) is imaginary, or real, or complex.


 
 Yes, I meant to say complex, sorry.
 
 Turns out I was not reading fully the previous posts.  I was not aware 
 that there were two separate types for complex and imaginary.  I thought 
 idouble was a complex number.
 
 That's kind of... um weird?  Why do you need an imaginary AND a complex 
 type?  Wouldn't just a complex type suffice?


Yes, in 99.999999999999998% of cases. (1-real.epsilon <g>)
I think the argument is that a pure imaginary type means "the real part 
is exactly zero", whereas a complex type with z.re == 0 means "the real 
part is zero OR too small to represent". Which makes a difference when 
you multiply by infinity. Since dealing with this very obscure case 
requires THREE keywords, the bang-per-buck for each keyword is 
unbelievably low.

I strongly believe that ifloat, idouble, ireal should not be in the 
language. I like the fact the cfloat, cdouble, creal are -- but I 
recognize I'm in the minority.


 Anyway, don't mind me, I just was confused.


It's intrinsically confusing. Imaginary types don't make much sense. No 
wonder there are so many compiler bugs with it.
(It's kind of like a 'fraction' type, where the fraction is not allowed 
to be an integer... The arithmetic's insane).


 
 -Steve
Apr 06 2009
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Sam Hu:

 Doesn't  D already has the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal?What's the advantage having complex class instead?




The intention is that cfloat, cdouble,... will be deprecated eventually.

I don't think std.complex should be part of Phobos yet, it needs some 
major work -- in particular, polar coordinates are just asking for 
trouble, especially as currently implemented. The angle 'arg' needs to 
be fixed point, otherwise you get a roundoff nightmare.
Even assert(z == - (-z)) can fail!


 
 Some people have discussed/complained that complex types aren't worth being
built-ins, so the *struct* Complex of std.complex of D2 will replace them. (I
am not sure such complex struct is as good as the current built-ins, but it
seems most D1 users don't use complex numbers much, so they don't care).
 
 Bye,
 bearophile
Apr 06 2009
parent reply "MikeWh" <cf725b-0 yahoo.com> writes:
Why in the world would complex types be dropped from D?  That's what drew me 
and my collegues to the language in the first place! Our heritage 
electromagnetics analysis code and antenna design software is all written in 
FORTRAN for that reason.  I've been writing our new antenna algorithms in D, 
and I just finished a very clean FFT routine that leverages D's built-in 
cdouble.  Sure, there's work-arounds if complex weren't built in, but you 
could make that same statement about almost any feature of the language. 
Built-in complex type is a huge selling point in my field - I don't know 
that I would stop using D if complex types went away, but I can say with 
certainty we would not have adopted D in the first place without it.

Mike

"Don" <nospam nospam.com> wrote in message 
news:grclgp$2kj3$1 digitalmars.com...

 bearophile wrote:

 Sam Hu:

 Doesn't  D already has the built-in types cfloat, cdouble, creal, 
 ifloat, idouble, and ireal?What's the advantage having complex class 
 instead?




 The intention is that cfloat, cdouble,... will be deprecated eventually.

 I don't think std.complex should be part of Phobos yet, it needs some 
 major work -- in particular, polar coordinates are just asking for 
 trouble, especially as currently implemented. The angle 'arg' needs to be 
 fixed point, otherwise you get a roundoff nightmare.
 Even assert(z == - (-z)) can fail!


 Some people have discussed/complained that complex types aren't worth 
 being built-ins, so the *struct* Complex of std.complex of D2 will 
 replace them. (I am not sure such complex struct is as good as the 
 current built-ins, but it seems most D1 users don't use complex numbers 
 much, so they don't care).

 Bye,
 bearophile
May 16 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
MikeWh:

 Why in the world would complex types be dropped from D?


Andrei wants to cut them away from the language. And his power in the design of
the language is great. So saying such things here isn't going to help much. So
you can send him an email, for example. He will probably answer you that with a
library complex you can do (almost) the same things.

Bye,
bearophile
May 16 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, May 16, 2009 at 4:04 PM, bearophile <bearophileHUGS lycos.com> wrot=
e:

 MikeWh:

 Why in the world would complex types be dropped from D?


 Andrei wants to cut them away from the language. And his power in the des=


ign of the language is great. So saying such things here isn't going to hel=
p much. So you can send him an email, for example. He will probably answer =
you that with a library complex you can do (almost) the same things.


I believe the goal is to get the language to a point where a complex
library can do exactly the same things as the current built-ins.  The
only difference should be that you need to import std.complex (if that
even).   If changing to a library introduces any reduction in
functionality beyond that I don't think it would go through.

--bb
May 17 2009