std.complex

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Thu Jan 2 11:32:31 PST 2014


On Thursday, 2 January 2014 at 18:12:56 UTC, Stewart Gordon wrote:
> 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.

Because that also seems to me to be an unpleasant option. A 
complex number implementation that fails to support ordinary 
arithmetic operations in all circumstances is pretty 
non-intuitive and will probably lead to unpleasant bugs in users' 
code.

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

I don't follow your point here. We can constrain T however we see 
fit. The point isn't to have some perfect representation of every 
mathematical possibility, it's to have useful code that serves a 
good range of use-cases while being robust and easy to maintain. 
Restricting T to floating point types is a useful simplification 
here that has few costs in terms of expected use-cases.

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

Again, I don't see it as being useful to have a Complex!T whose 
support for binary operations may vary depending on the type of T.

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

No, I mean that until you have at least one actual float-esque 
type to test with, it is probably unwise to relax the template 
constraints that currently mandate built-in FP types.

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

And complicate the implementation of Complex itself, for the sake 
of a likely very marginal special interest that could be 
supported quite well by an independent type.


More information about the Digitalmars-d mailing list