std.complex

[Lars T. Kyllingstad]

On Wednesday, 1 January 2014 at 19:55:58 UTC, Joseph Rushton 
Wakeling wrote:
> On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon 
> wrote:
>> [...] why do you need an appropriate application in order not 
>> to have this arbitrary restriction?  Or have I missed 
>> something?
>
> There are binary operations on complex numbers where the only 
> sensible outcome seems to be non-integral real and imaginary 
> parts. Addition, subtraction and multiplication are OK with 
> integral types, but division really seems unpleasant to 
> implement absent floating point, exponentiation even more so.
>
> I imagine there are ways to resolve this, but it certainly 
> simplifies implementation to assume floating-point, and absent 
> a compelling application there is not much reason to avoid that 
> simplification.

I agree completely.  This is the main reason why I chose to 
explicitly disallow integral types when I wrote std.complex.

>> It isn't just integer types.  Somebody might want to use 
>> complex with a library (fixed-point, arbitrary precision, 
>> decimal, etc.) numeric type.
>> Fractal generators, for example, are likely to use this a lot.
>
> I agree that such any numeric type that effectively models a 
> real number should be supported. In principle it ought to be 
> sufficient to check that the required "floating-point-ish" 
> operations (including sin and cos) are supported, plus maybe 
> some tweaks to how internal temporary values are handled.

Agreed.  Any "floating point-like" library type which is to be 
supported by std.complex must either have cos(), sin(), hypot(), 
etc. as member functions (since std.complex cannot import non-std 
modules), or the type needs to be supported by std.math as well.  
If so, std.math is the place to start, not std.complex.