Wht std.complex is needed?

[Don]

Steven Schveighoffer wrote:
> On Mon, 06 Apr 2009 09:50:35 -0400, Don <nospam at nospam.com> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Mon, 06 Apr 2009 08:36:18 -0400, Don <nospam at 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