GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Casting complex number to float · Issue #1141 · python-control/python-control

Casting complex number to float #1141

New issue
Copy link
New issue
Copy link
Closed
#1142
Closed
Casting complex number to float#1141
#1142
Copy link
Assignees
murrayrm

Description

@ethanmc22
ethanmc22
opened on Mar 21, 2025
Issue body actions

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

Activity

  1. roryyorke commented on Mar 23, 2025

    @roryyorke
    roryyorke
    on Mar 23, 2025
    Contributor
    More actions

    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.

  2. ethanmc22 commented on Mar 23, 2025

    @ethanmc22
    ethanmc22
    on Mar 23, 2025
    Author
    More actions

    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.

  3. murrayrm
    self-assigned this
    on Mar 24, 2025
  4. murrayrm
    linked a pull request that will close this issueAdd type error checks, unit tests, documentation for real-valued systems #1142on Mar 24, 2025
  5. bnavigator
    closed this as completedin #1142on Mar 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

  • @murrayrm
    murrayrm

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402520 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.