std.complex
Stewart Gordon
smjg_1998 at yahoo.com
Fri Jan 3 05:32:18 PST 2014
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.
More information about the Digitalmars-d
mailing list