Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
murrayrm merged 5 commits intopython-control:masterfrommurrayrm:infinite_gain
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 awarn_infinity flag to all functions used to evaluate frequency response. By default this is set toTrue, in which case you get a divide by zero warning or singular matrix warning when evaluating at a pole. Setting it toFalse suppresses this warning. (Also,dcgain setswarn_infinity to False by default).
  • Updated docstrings and unit tests

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.009%) to 88.293% when pulling598058c on murrayrm:infinite_gain intoeb62d80 on python-control:master.

Copy link
Contributor

@sawyerbfullersawyerbfuller 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 freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@sawyerbfullersawyerbfullersawyerbfuller approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.9.0
Development

Successfully merging this pull request may close these issues.

Inconsistent evaluation of tf/ss systems with pole at the origin
3 participants
@murrayrm@coveralls@sawyerbfuller

[8]ページ先頭

©2009-2025 Movatter.jp