Add support for C99 complex type (_Complex) as ctypes.c_complex #61103
Comments
|
It would be nice if Python will be able to access variables with C99 complex types through ctypes module. |
|
libffi still has no support for _Complex. Did you try with a pure Python solution, like the one suggested in http://objectmix.com/python/112374-re-ctypes-c99-complex-numbers.html |
|
Yes, I managed to pass and operate with matrices of complex numbers to pure C and Fortran programs by using Numpy and their ctype adapters (only for whole matrices, they don't provide c_complex type; in general see http://www.scipy.org/Cookbook/Ctypes for details). I suppose pure python solution that suggested in provided by you link works too: class Complex64(Structure):
_fields_ = [("real", c_float), ("imag", c_float)]But I'm unsure is this is expected behavior or luck, and on some platform this code will not work due to different complex numbers internal representation. Any way this should be implemented in libffi first, and then in ctypes, so this feature request should be postponed, IMO. |
What platform? Isn't the complex number representation standard? E.g., C99 6.2.5p13 says: "Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number." |
|
Postponing as suggested. |
|
I'm trying to add support for this in cffi, which uses ctypes... apparently this is now supported in libffi (https://github.com/libffi/libffi, v3.2 Nov 2014). |
|
Thanks, Tom. Re-opening. |
|
|
I concur with rutsky. Complex numbers are essential in the physical sciences, and the complex type is part of the c99 standard. Trying to shoehorn complex support by a user-defined type makes use of 8000 the builtin methods for the standard complex type clunky. |
|
cffi supports complex numbers since release 1.11---for direct calls using the API mode. That means that neither CFFI's ABI mode, nor ctypes, can possibly work yet. The problem is still libffi's own support, which is still not implemented (apart on a very uncommon CPU architecture, the s390). |
|
Pure python approach works for me so far (recent gcc/clang with glibc): >>> import ctypes
>>> libm = ctypes.CDLL('libm.so.6')
>>> class c_complex(ctypes.Structure):
... _fields_ = [("real", ctypes.c_double),
... ("imag", ctypes.c_double)]
... @property
... def value(self):
... return complex(self.real, self.imag)
...
>>> libm.clog.argtypes = [c_complex]
>>> libm.clog.restype = c_complex
>>> libm.clog(c_complex(1, 1)).value
(0.34657359027997264+0.7853981633974483j)But I'm working on adding primitive data types for C complexes in the ctypes. Naming: |
|
My 2 cents: I'd go for |
Example:
```pycon
>>> import ctypes
>>> ctypes.__STDC_IEC_559_COMPLEX__
1
>>> libm = ctypes.CDLL('libm.so.6')
>>> libm.clog.argtypes = [ctypes.c_double_complex]
>>> libm.clog.restype = ctypes.c_double_complex
>>> libm.clog(1+1j)
(0.34657359027997264+0.7853981633974483j)
```
``ctypes.__STDC_IEC_559_COMPLEX__`` is ``0`` if compiler doesn't support
complex arithmetic (Annex G).
|
PR ready for review: #120894 |
Example:
```pycon
>>> import ctypes
>>> ctypes.__STDC_IEC_559_COMPLEX__
1
>>> libm = ctypes.CDLL('libm.so.6')
>>> libm.clog.argtypes = [ctypes.c_double_complex]
>>> libm.clog.restype = ctypes.c_double_complex
>>> libm.clog(1+1j)
(0.34657359027997264+0.7853981633974483j)
```
Co-authored-by: Nice Zombies <nineteendo19d0@gmail.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Co-authored-by: Victor Stinner <vstinner@python.org>
|
Implemented by change 6988ff0. |
|
Hmm, @vstinner, should this be closed? At least support for Also, the struct module can include an interface to |
|
I would prefer to only support double _Complex for now. I'm not sure that float and long double are popular enough. |
|
I'm not sure that is about popularity. It's not why there are float and long double types, not just double. |
|
It's up to you. I reopen the issue. |
|
I think this needs a What's New entry: #129129 |
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
@skirpichev: Can you document the new features in What's New in Python 3.14? |
|
@vstinner, did I miss something? I thought this was done in the Petr's pr. |
|
Oh nevermind, I missed Petr's PR! |
|
Now I think that @dalcinl was right and we shouldn't require Annex G support from compiler, when CPython is built. As a first step, we could avoid using Annex G types (i.e. replace them with appropriate 2-elements arrays) in helpers (like D_get/set()), as C standard provides some guaranties on memory layout for complex types. |
…ctypes * drop _complex.h header * use appropriate real arrays to replace complex types
…ctypes * drop _complex.h header * use appropriate real arrays to replace complex types
…-133237) According to the C standard, the memory representation of _Complex types is equivalent to 2-element arrays. Unlike _Complex, arrays are always available. - drop _complex.h header - use appropriate real arrays to replace complex types Co-authored-by: Lisandro Dalcin <dalcinl@gmail.com> Co-authored-by: Petr Viktorin <encukou@gmail.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
|
@skirpichev said in the now-merged #133237:
I'd welcome tests that compare Python's complex numbers to the compiler's Annex G implementation (if any), so the macro might still be useful for |
It was introduced in 3.14, thus backward compatibility is not a problem.
Lets keep it for a while. |
Ah, rigth! In that case, let's remove it (some time during the beta period). |
The Py_FFI_SUPPORT_C_COMPLEX check configure check imply support for complex types.
The Py_FFI_SUPPORT_C_COMPLEX check configure check imply support for complex types.
Py_HAVE_C_COMPLEX was added in 3.14 so the removal doesn't need a deprecation period even under a strict reading of PEP 387. The Py_FFI_SUPPORT_C_COMPLEX check configure check implies support for complex types in ctypes.
|
Thank you! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: