On 03/01/2014 00:03, Joseph Rushton Wakeling wrote:
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 wasn't asking for it to go beyond the existing complex implementation
or any other. I was proposing that the arbitrary restriction be removed
so that the implementation we already have would work on them. As I
said originally:
I don't understand. At the moment Complex appears to me to be
type-agnostic - as long as a type supports the standard arithmetic
operators and assignment of the value 0 to it, it will work. The
only thing preventing it from working at the moment is this line
struct Complex(T) if (isFloatingPoint!T)
So why do you need an appropriate application in order not to have
this arbitrary restriction? Or have I missed something?
OK, so division has now been mentioned. And you have now mentioned the
use of FPTemporary. However....
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.
I had read the code before I made that comment, and from reading it I
did believe at the time that the implementation was ready for types
other than float, real and double. So the use of FPTemporary is
something I missed, but it's taken you this long to point it out to me.
However....
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.
FPTemporary is a template. At the moment it's defined only for the
built-in floating point types. So what we really need is to define
FPTemporary for other types. For int and smaller integral types, we can
define it as real just as we do for float/double/real. Whether it's
adequate for long would be platform-dependent. For other types, I
suppose we can reference a property of the type, or just use the type
itself if such a property isn't present.
One possible idea (untested):
-----
template FPTemporary(F)
if (is(typeof(-F.init + F.init * F.init - F.init))) {
static if (isFloatingPoint!F || isIntegral!F) {
alias real FPTemporary;
} else static if (is(F.FPTemporary)) {
alias F.FPTemporary FPTemporary;
} else {
alias F FPTemporary;
}
}
-----
Of course, this isn't a completely general solution, and I can see now
that whatever type we use would need to have trigonometric functions in
order to support exponentiation. So unless we conditionalise the
inclusion of this operation....
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.
Oh yes, and it would be crazy to try and make it work for unsigned
integer types. But even if we were to resolve the issues with
FPTemporary and that, it would still fall under my earlier suggestion of
making it so that if people want to use Complex on an unsupported type
then they can explicitly suppress the type restriction, but should
understand that it might not work properly.
<snip>
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.
Really, I was just thinking that somebody who wants a quick-and-dirty
hypercomplex number implementation for some app might try to do it that way.
Stewart.
