std.complex

[Joseph Rushton Wakeling]

On 03/01/14 00:33, Stewart Gordon wrote:
> Please be specific.

You know, I'm starting to find your tone irritating.  You are the one who's 
asking for functionality that goes beyond any Complex implementation that I'm 
aware of in any other language, and claiming that these things would be trivial 
to implement.  I would expect a person who claims with confidence that something 
is trivial, to actually know the internals of the code well enough to understand 
what parts of it would need to be modified.  On the basis of what you've 
written, I have no reason to believe that you do.

There are numerous places inside current std.complex.Complex where temporary 
values are used mid-calculation.  Those are all of type FPTemporary (which in 
practice means real).  So, to handle library types (whether library 
floating-point types such as a BigFloat implementation, or a Complex!T so as to 
support hypercomplex numbers) you'd either have to special-case those functions 
or you'd have to provide an alternative Temporary template to handle the 
temporary internal values in the different cases.

You'd also need to address questions of closure under operations (already an 
issue for the Imaginary type), and precision-related issues -- see e.g. the 
remarks by Craig Dillabaugh and Ola Fosheim Grøstad elsewhere in this thread.

While it could be done, I don't think it would be simple to get right and I 
would regard it as a major revision of std.complex.  I'd also be concerned that 
generalizing Complex in this way might lead to performance regressions for the 
standard Complex!T use-cases, due to the more complicated templates involved.

> Oh yes, some of the templated functions that take or return a complex would need
> this extra parameter adding.

No.  The internals would need significant rewriting, for reasons I've already 
elaborated.

> Another way it could be done is to have a Complex template that implements these
> rules and which programmers would normally use, and have this aliasing
> ComplexImpl which actually provides the implementation and which programmers can
> use directly if they want to bypass the restrictions.  The difficulty is
> documenting it in a way that would make sense to normal users....

If you want these things done in these ways, then I think the onus is on you to 
provide code which works and doesn't damage existing std.complex functionality.

I don't personally see any rationale for implementing hypercomplex numbers as a 
specialization of Complex given that they can be just as well implemented as a 
type in their own right.