std.complex

[Stewart Gordon]

On 01/01/2014 19:55, Joseph Rushton Wakeling wrote:
<snip>
> 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,

Then why not just disable division if it's a non-float type, rather than 
preventing the whole complex template from being used with that type? 
This is like cutting off somebody's arm because they have a sore thumb.

Moreover, we have no way in the general case of determining whether T is 
an integral type, a library float-esque type, or (for example) a Galois 
field type.  So disabling it _just in case_ division doesn't work is 
crazy.  There must be better ways to do it.

> exponentiation even more so.

Exponentiation by a non-negative integer is straightforward.  So we 
should at least support this case for Gaussian integers.

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

What do you mean by "in the context of", exactly?  Restricting it to 
some float-esque type that is in Phobos would still be overly restrictive.

>> Or even more exotically, use Complex!(Complex!real) to implement
>> hypercomplex numbers.
>
> Perhaps best implemented as a type in its own right?

It would, but removing the restriction would simplify the implementation 
of Hypercomplex(T) by enabling it to be a wrapper for Complex!(Complex!T).

Stewart.