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

[David Cournapeau]

On Thu, Jul 2, 2009 at 5:25 AM, Charles R
Harris<charlesr.harris at gmail.com> wrote:
>
>
> On Wed, Jul 1, 2009 at 1:57 PM, Pauli Virtanen <pav at iki.fi> wrote:
>>
>> On 2009-07-01, Charles R Harris <charlesr.harris at gmail.com> wrote:
>> > On Wed, Jul 1, 2009 at 1:59 AM, David Cournapeau
>> > <david at ar.media.kyoto-u.ac.jp> 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[2] (as fftw
does for fftw_complex), but this is not practical because you can't
return an array in C.

cheers,

David