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

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

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

Regards,
Sam

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

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

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

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

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

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

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