Repository navigation
Unsupported NumPy datatype complex128 #1188
Description
Dear developers,
I've encountered what could be an unintentional exception (TypeError). This MWE codesnippet:
import numpy as np
import control as cm
P = cm.rss(5)
q1 = cm.zpk(zeros=P.zeros().astype(np.complex64),
poles=P.poles().astype(np.complex64),
gain=1, dt=0)
q2 = cm.zpk(zeros=P.zeros().astype(np.complex128),
poles=P.poles().astype(np.complex128),
gain=1, dt=0)
outputs (sometimes only on the 2nd execution):
Traceback (most recent call last):
File "...\scratch.py", line 9, in <module>
q2 = cm.zpk(zeros=P.zeros().astype(np.complex128),
poles=P.poles().astype(np.complex128),
gain=1, dt=0)
File "...\Local\Programs\Python\Python313\Lib\site-packages\control\xferfcn.py", line 1819, in zpk
return TransferFunction(num, den, *args, **kwargs)
File "...\Local\Programs\Python\Python313\Lib\site-packages\control\xferfcn.py", line 207, in __init__
num = _clean_part(num, "numerator")
File "...\Local\Programs\Python\Python313\Lib\site-packages\control\xferfcn.py", line 2005, in _clean_part
raise TypeError(
f"unsupported data type: {type(out[i, j][k])}")
TypeError: unsupported data type: <class 'numpy.complex128'>
From the top of my head, I can't think of a reason why 4 byte complex numbers are allowed, but 8 bytes aren't. If there is, please enlighten me!
However, I think there are more incompatibilities between NumPy and this xferfcn.py file, because executing
print(q1)
yields
File "...\scratch.py", line 13, in <module>
print(q1)
~~~~~^^^^
File "...\Local\Programs\Python\Python313\Lib\site-packages\control\xferfcn.py", line 447, in __str__
denstr = _tf_polynomial_to_string(
self.den_array[no, ni], var=var)
File "...\Local\Programs\Python\Python313\Lib\site-packages\control\xferfcn.py", line 1366, in _tf_polynomial_to_string
coeffs = eval(repr(coeffs))
File "<string>", line 2, in <module>
NameError: name 'float32' is not defined. Did you mean: 'float64'?
Package versions:
numpy==2.2.6
control==0.10.2
Kind regards,
Sachin
Activity
murrayrm commentedon Nov 29, 2025
Thanks for pointing out these issues. The python-control toolbox doesn't support complex numbers are coefficients for transfer functions (see #484, among others), but the code should catch those cases earlier.
marko1olo commentedon Aug 14, 2026
Opened PR #1244 to fix both issues:
_clean_partnow casts complex coefficient arrays to real floats when imaginary parts are within zero tolerance (np.allclose(imag, 0)), preventingTypeErroroncomplex64/complex128arrays fromzpk._tf_polynomial_to_stringnow usesnp.asarray(coeffs).tolist(), eliminating the brittleeval(repr(coeffs))that failed withNameError: name 'float32' is not defined.