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

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

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

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

On Sat, May 16, 2009 at 4:04 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> 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.


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