[Numpy-discussion] Numpy complex types, packing and C99
Wed Jul 1 18:47:13 CDT 2009
On Thu, Jul 2, 2009 at 5:25 AM, Charles R
> On Wed, Jul 1, 2009 at 1:57 PM, Pauli Virtanen <firstname.lastname@example.org> wrote:
>> On 2009-07-01, Charles R Harris <email@example.com> wrote:
>> > On Wed, Jul 1, 2009 at 1:59 AM, David Cournapeau
>> > <firstname.lastname@example.org> wrote:
>> >> I would like to add an explicit configuration test to check that our
>> >> complex type is compatible with the C99 complex type (when available).
>> >> Is this ok?
>> Seems OK to me.
>> >> As currently defined, complex c types (npy_cfloat, etc...) are not
>> >> defined in a way such as they are binary compatible with the C99
>> >> complex
>> >> type. Strictly speaking, packing the complex type is an ABI break, but
>> >> we already make the assumption in ufunc, so we would have wrong
>> >> results/crashes currently if it were not packed, so I believe the check
>> Is there a reason not to pack our complex number struct? I think
>> if we bump the ABI version, changing this should be OK.
> This bothers me a bit. Since the two forms should normally be compatible
> maybe we can use a union or some other way to preserve the current ABI. It
> would be nice to have a deprecation warning too, but I can't figure out how
> to deprecate a struct declaration. A compiler warning perhaps?
I think it is a non issue, because we already rely on the assumption.
I was just thinking about checking that sizeof(complex) ==
sizeof(double) * 2 at configuration check as a safeguard (and deal
with it on platforms where it fails, using compiler-dependent pragma).
Currently, if it is not packed, the complex ufunc are horribly wrong
I don't see how using a union would help preserving anything: the only
way to force packing would be to define complex as double (as fftw
does for fftw_complex), but this is not practical because you can't
return an array in C.
More information about the Numpy-discussion