Ok
On 2 Dec 2013 12:32, "Julian Taylor" <notifications@github.com> wrote:

> In numpy/core/src/umath/loops.c.src:
>
> > @@ -2014,21 +2108,104 @@ HALF_ldexp_long(char **args, npy_intp *dimensions, npy_intp *steps, void *NPY_UN
> >   * #C = F, , L#
> >   */
> >
> > +static void
> > +pairwise_add_@TYPE@(@ftype@ *rr, @ftype@ * ri, @ftype@ * a, npy_uintp n,
>
> e.g. the loop would look like this:
>
> // templates 0 or 1 for real and vice versa for complex
>         r[0] = a[0 * stride];
>         r[1] = a[(0 + @notcmplx@) * stride + @cmplx@];
>         r[2] = a[2 * stride];
>         r[3] = a[(2 + @notcmplx@) * stride + @cmplx@];
>         r[4] = a[4 * stride];
>         r[5] = a[(4 + @notcmplx@) * stride + @cmplx@];
>         r[6] = a[6 * stride];
>         r[7] = a[(6 + @notcmplx@) * stride + @cmplx@];
>
> the other two branches would probably need to be duplicated with ifdefs
> anyway as the accumulate into two or one variable.
> Possibly one can assign both the same size 2 variable and use a template
> stride of zero for real types, saves lines but probably makes even less
> readable than ifdef duplication:
>
>         for (i = 0; i < n; i += 1) {
>             res[i % @oneifcomplex@] += a[(i + @notcmplx@) * stride + @cmplx@];
>         }
>
> I favor just having two similar looking functions.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/numpy/numpy/pull/3685/files#r8038912>
> .
>