Skip to content

Casting complex number to float #1141

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Master-Pr0grammer opened this issue Mar 21, 2025 · 2 comments · Fixed by #1142
Closed

Casting complex number to float #1141

Master-Pr0grammer opened this issue Mar 21, 2025 · 2 comments · Fixed by #1142
Assignees

Comments

@Master-Pr0grammer
Copy link

Code to reproduce the problem:

sys = ctrl.zpk([], [1j], 1)

plt.figure(figsize=(8, 6))
ctrl.root_locus(sys, color='red') #<-- Problem is here

plt.xlabel('Real Axis (σ)')
plt.ylabel('Imaginary Axis (jω)')
plt.grid(True)
plt.show()

In the diagram, you can see the pole is placed at the wrong location. but I looked into it and found a quick solution (though I am not familiar with the code, and it might be deeper than I found)

in the files xferfcn.py (lines 1068, and 1072) there are two arrays that are created of type float, that could later assigned to complex numbers if the input is of type complex. the fix is to just change the type of the array to complex

Then another issue arises in plocus.py (line 267), if the coefficients are complex, it is again casted into a float. I am not sure what this value is used for, but I believe this can be fixed by casting the input type to complex if it isn't already, then using the magnitude of the complex number instead of casting it, which I believe the abs() function will do for default python complex types.

Should be an easy fix, hope this helps

@roryyorke
Copy link
Contributor

Thanks for the report. Supporting complex coefficients for TFs, and equivalently complex matrices for SS, is brought up now and then. It's unfortunately not such an easy change: see gh-371.

@Master-Pr0grammer
Copy link
Author

ah I see now, Might be worth looking into adding type checking to throw errors for such a case since the complex type is a default type in python, and the client is likely going to try to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants