Skip to content

Update evalfr() to be consistent with MATLAB usage #179

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
Jan 13, 2018

Conversation

murrayrm
Copy link
Member

@murrayrm murrayrm commented Jan 6, 2018

This PR addresses issue #22, in which it was pointed out that the evalfr() method in the TransferFunction and StateSpace objects takes different arguments than the evalfr() function. Specifically, the evalfr method takes a real argument (the frequency at which you want to evaluate the frequency response) and the evalfr function takes a complex argument (consistent with MATLAB usage).

This PR makes the following changes to the code base:

  • Renamed evalfr() in the FRD, StateSpace and TransferFunction classes to _evalfr() and put a deprecation warning for use of the evalfr() method.

  • Changed calls to evalfr() in frdata.py and margins.py to use _evalfr()

  • Added unit tests for the the new methods + warnings

These changes eliminate the inconsistency in the argument form between the (MATLAB compatible) evalfr() function and the evalfr() methods for LTI objects. The _evalfr() method retains the original functionality, since it is used for computing stability margins and for converting objects to FRD form.

Renamed evalfr() in the FRD, StateSpace and TransferFunction classes to
_evalfr() and put a deprecation warning for use of the evalfr() method.

Changed calls to evalfr() in frdata.py and margins.py to use _evalfr()

Added unit tests for the the new methods + warnings

These changes eliminate the inconsistency in the argument form between the
(MATLAB compatible) evalfr() function, which takes a complex argument, and
the evalfr() methods for LTI objects, which took a real number as argument
(representing the frequency).  The _evalfr() method retains the original
functionality, since it is used for computing stability margins and for
converting objects to FRD form.
@coveralls
Copy link

coveralls commented Jan 6, 2018

Coverage Status

Coverage decreased (-0.01%) to 77.615% when pulling 2915baf on murrayrm:update_evalfr into 92ccf2d on python-control:master.

@murrayrm murrayrm merged commit bb65f31 into python-control:master Jan 13, 2018
@murrayrm murrayrm deleted the update_evalfr branch January 13, 2018 06:35
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.

2 participants