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? :-)
