std.complex

[Lars T. Kyllingstad]

On Friday, 20 December 2013 at 16:26:00 UTC, Joseph Rushton 
Wakeling wrote:
> On 26/11/13 17:28, Andrei Alexandrescu wrote:
>> On 11/26/13 3:22 AM, Joseph Rushton Wakeling wrote:
>>> So, as other people have suggested, really the only thing we 
>>> can
>>> reasonably do is to define a separate Imaginary type
>>
>> I agree. Let's move forward with this.
>
> Provisional code:
> https://github.com/D-Programming-Language/phobos/pull/1797
>
> I also realized there was no explicit issue report, so created 
> one:
> https://d.puremagic.com/issues/show_bug.cgi?id=11787

I'm not 100% convinced that a pure imaginary type is the way to 
go.  You may be interested in reading a previous discussion, 
where the subject of pure imaginary number support is brought up:

   http://forum.dlang.org/thread/flsf9u$jf$1@digitalmars.com

Let me quote some of the replies in that thread:

On Monday, 7 January 2008 at 08:05:48 UTC, Don Clugston wrote:
> I think the argument for pure imaginary types is extremely 
> weak. They are very annoying to work with, because they aren't 
> closed under multiplication. This is a nasty property to have 
> in a built-in type.
>
> Suppose you're writing a generic function product(T)(T[]) which 
> returns T[0]*T[1]*T[2]*... What's the return type?
> Suppose T is idouble. Then if the number of elements in T is 
> odd, the return type should be idouble, but if it's even, the 
> return type should be double!
> You could promote it to complex with a construction like 
> typeof(1?T*T:T), but that's inefficient, and negates most of 
> the benefits of having a imaginary type.


On Tuesday, 8 January 2008 at 03:13:34 UTC, Bill Baxter wrote:
> The bottom line is that there really is no useful mathematics 
> that can be performed using only imaginary numbers.  If to do 
> anything more than add, subtract, or multiply by a (real!) 
> scalar they become complex.  If you have any imaginary numbers 
> in a numerical code it means you're working in the complex 
> plane.