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.
