std.complex

[Joseph Rushton Wakeling]

On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon 
wrote:
> I don't understand.  At the moment Complex appears to me to be 
> type-agnostic - as long as a type supports the standard 
> arithmetic operators and assignment of the value 0 to it, it 
> will work.  The only thing preventing it from working at the 
> moment is this line
>
>     struct Complex(T)  if (isFloatingPoint!T)
>
> So 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.

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

However, I think relaxing the template constraints like this 
would best be done in the context of a library float-esque type 
(e.g. BigFloat) being implemented in Phobos, which could then be 
used to provide both proof-of-concept and the primary test case.

> Or even more exotically, use Complex!(Complex!real) to 
> implement hypercomplex numbers.

Perhaps best implemented as a type in its own right? :-)