[phobos] std.complex: updates, bugs, and questions

[Don Clugston]

On 28 March 2010 17:35, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> I've committed an update of my std.complex proposal:
>
>  http://github.com/kyllingstad/ltk/blob/master/ltk/complex.d
>
> The current status is as follows:
>
> - Changed mod() to abs(), like Don requested.  I'll implement abs() with
> std.math.hypot() as soon as bug 4023 is fixed.

Yup, that's an embarrassing one. I'll get it fixed ASAP.

>
> - Added overloads for the exponentiation operator:
>    complex^^complex
>    complex^^real
>    complex^^integer, w/special cases for 0,1,2,3
>
> - Arithmetic operations now work between different-width complex types, as
> well as between complex and different FP and integer types.
>
> - I tried to make the opOpAssign() functions return by ref, but got hit by
> bug 2460.  This really ought to be fixed now that operator overloading is
> done with function templates, but if it's not a priority then I'll use the
> workaround (i.e. write template(T) { ... }).
>
> - I've used FPTemporary!T where appropriate.
>
>
> Two questions:
>
> I had a look at the implementation of std.numeric.FPTemporary, and noted
> that it's just an alias for real, regardless of the specified type. (Also,
> the std.math.hypot() function is just defined for the real type.)  Can we be
> sure this is always what the user wants?  Won't using double be faster in
> some cases, or is it so that calculations are done with 80-bit precision
> anyway?

On x86, real is always better. On other architectures, the definition
of FPTemporary will be different.

>
> As you may have seen, I've put in two different multiplication formulae.  I
> did this because I read that multiplication is slow on some architectures,
> and the first formula has fewer multiplications.  On my machine, however,
> the second (and "standard") one is slightly faster. Do you know which
> architecures this refers to, and are any of them relevant for D?

I don't think that would be true of any architectures made in the last
twenty years.
Worrying about that would be premature optimisation.

WRT both these last two points, array operations on complex types is
the place where optimisation really matters.