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.
