Update evalfr() to be consistent with MATLAB usage #179
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 theevalfr()
function. Specifically, theevalfr
method takes a real argument (the frequency at which you want to evaluate the frequency response) and theevalfr
function takes a complex argument (consistent with MATLAB usage).This PR makes the following changes to the code base:
Renamed
evalfr()
in theFRD
,StateSpace
andTransferFunction
classes to_evalfr()
and put a deprecation warning for use of theevalfr()
method.Changed calls to
evalfr()
infrdata.py
andmargins.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 theevalfr()
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.