On Thu, Jul 2, 2009 at 5:25 AM, Charles R Harris<[email protected]> wrote: > > > On Wed, Jul 1, 2009 at 1:57 PM, Pauli Virtanen <[email protected]> wrote: >> >> On 2009-07-01, Charles R Harris <[email protected]> wrote: >> > On Wed, Jul 1, 2009 at 1:59 AM, David Cournapeau >> > <[email protected]> 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 _______________________________________________ Numpy-discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
