Skip to content

Fix inconsistencies in frequency response at poles #542

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

Merged
merged 5 commits into from
Feb 24, 2021

Conversation

murrayrm
Copy link
Member

This PR addresses issue #532 regarding inconsistencies in the return values for various frequency response functions. The changes fixes a number of previous inconsistencies, where state space and transfer function representations could return different values and evaluating the frequency response at the "origin" gave different values depending on whether you evaluated at 0 or 0j.

The changes here only affect results when evaluating the system at a pole of the system.

In this PR:

  • State space systems and transfer functions return the same values when evaluated at poles (including poles at the origin):
    • Evaluation at 0 with pole at the origin: returns (inf + nanj)
    • Evaluation at non-origin pole with nonzero numerator: returns (inf + infj)
    • Evaluation at pole with cancellation by a zero: returns (nan + nanj)
  • State space systems and transfer functions interpret argument as a complex number, so that G(0) and G(0j) return the same value.
  • Computing the DC gain is (exactly) the same as evaluating at 0

A few other small changes:

  • Added a warn_infinity flag to all functions used to evaluate frequency response. By default this is set to True, in which case you get a divide by zero warning or singular matrix warning when evaluating at a pole. Setting it to False suppresses this warning. (Also, dcgain sets warn_infinity to False by default).
  • Updated docstrings and unit tests

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.009%) to 88.293% when pulling 598058c on murrayrm:infinite_gain into eb62d80 on python-control:master.

Copy link
Contributor

@sawyerbfuller sawyerbfuller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me! Nice to have these corner cases doing the right thing

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 this pull request may close these issues.

Inconsistent evaluation of tf/ss systems with pole at the origin
3 participants