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