[Numpy-discussion] Numpy complex types, packing and C99

David Cournapeau cournape@gmail....
Wed Jul 1 19:02:02 CDT 2009

On Thu, Jul 2, 2009 at 5:34 AM, Pauli Virtanen<pav@iki.fi> wrote:

> Don't know, probably we can?

yes, they are functions (the builtins are __real__ and __imag__)

> I think that for scipy.special this would be useful. Of course,
> the operator semantics for complex numbers can't be used there,
> but still sticking closer to C99 could be useful.

that's one reason I was interested in getting this started  :) The
current state of scipy.special really saddens me. I also needs some of
those functions at the C level for windows x64.

> A separate question is whether we want to implement Numpy's
> complex ufuncs using the C99 ones when they are available.
> I had a branch for this:
>    http://github.com/pv/numpy-work/tree/c99-complex-umath

I even went further: I used the C99 complex type (npy_cdouble is a
typedef to complex if C99 complex is available).

> This has some risks: the system-provided complex-valued functions
> may be broken in different ways, or suffer from some subtle
> flaws. This is likely more common than having broken real-valued
> functions that have been around quite a while longer. (To give an
> example: casinh(1e-20) == 0 with GNU Libc 2.9.)

True, but we can deal  with this once we have tests: we can force to
use our own, fixed implementations on broken platforms. The glibc
complex functions are indeed not great, I have noticed quite a few
problems for special value handling (e.g. cabs(inf + I * NAN) is nan,
but should be inf, etc....).

I think you will agree that having tests for the edge cases is an
acceptable solution :)


More information about the Numpy-discussion mailing list