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