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, theevalfrmethod takes a real argument (the frequency at which you want to evaluate the frequency response) and theevalfrfunction takes a complex argument (consistent with MATLAB usage).This PR makes the following changes to the code base:
Renamed
evalfr()in theFRD,StateSpaceandTransferFunctionclasses to_evalfr()and put a deprecation warning for use of theevalfr()method.Changed calls to
evalfr()infrdata.pyandmargins.pyto 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.