Skip to content
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

TransferFunction _common_den rewrite - issue #194 #206

Merged
merged 13 commits into from Jul 2, 2018
Merged

TransferFunction _common_den rewrite - issue #194 #206

merged 13 commits into from Jul 2, 2018

Conversation

repagh
Copy link
Member

@repagh repagh commented May 29, 2018

On my machines I got a consistent issue #194 error. (Mac OSX and Linux).

After playing around with the seed in convert_test.py, I got slightly different results for the tests. I inspected _common_den (xferfcn.py) with the debugger, and found that in some cases a lot of cancelling poles would be added; the sorting for pole comparison did not consistently work.

I then re-thought and re-worked the _common_den function, instead of sorting, cycling through all known poles, comparing to poles in the current denominator, marking which ones are found -- to prevent accepting double poles, and remembering which ones are not found.

The whole thing is a lot shorter, and I believe also a lot more robust. I hope this eliminates the elusive #194

@coveralls
Copy link

coveralls commented May 29, 2018

Coverage Status

Coverage decreased (-12.7%) to 65.133% when pulling 732c924 on repagh:tf-combination into 601b581 on python-control:master.

@repagh
Copy link
Member Author

repagh commented May 30, 2018

Average coverage actually decreased, simply because I made xferfcn.py 58 lines shorter and that file had a coverage wel above average.

@repagh repagh requested a review from murrayrm May 30, 2018 11:34
@repagh
Copy link
Member Author

repagh commented May 31, 2018

Please do not merge yet. I now realise that only poles common to an input can be removed from the tf's, (thanks to issue #111). I will try to resolve that over the next week or so.

@murrayrm
Copy link
Member

@repagh It would be great to add a unit test that catches issue #111 while you are at it.

# pre-calculate the poles for all num, den
# has zeros, poles, gain, list for pole indices not in den,
# number of poles known at the time analyzed
self2 = self.minreal()
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure about this; I think tf([1,1],[1,2,1]).pole() should return [-1, -1].

# are the same size as the denominator.
currentpoles = poleset[i][j][1]
nothave = ones(currentpoles.shape, dtype=bool)
for ip, p in enumerate(poles):
Copy link
Contributor

@roryyorke roryyorke Jun 2, 2018

Choose a reason for hiding this comment

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

is this supposed to be enumerate(poleset)? I can't see any modification to poles after the initial assignment to [].

edit: ah, never mind, I see the poles.append() a bit later.

@repagh
Copy link
Member Author

repagh commented Jun 20, 2018

I think I got it this time.

  • The convert_test.py smoothly runs
  • test case for Too few poles for MIMO tf #111 also works
  • I modified/corrected a test case in xferfcn_test.py, same issue, deleted poles

Note that this relies on my fixes to Slycot; these fix a number of edge cases

@repagh repagh mentioned this pull request Jun 24, 2018
- for the above reason, do conversion on minreal'd xferfcn in statesp.py
- add a test for not canceling pole/zero pairs when calculating pole()
- add import of matlab in discrete_test.py
@murrayrm murrayrm added this to the 0.8.0 milestone Jun 30, 2018
Copy link
Member

@murrayrm murrayrm left a comment

Choose a reason for hiding this comment

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

I've looked through these changes and they look good to merge.

@murrayrm
Copy link
Member

murrayrm commented Jul 1, 2018

I fixed up the Travis CI issues in PR #210 and tested this code (locally) to make sure that it passes unit tests. On MacOS 10.13 I get the following error:

ERROR: testModred (control.tests.matlab_test.TestMatlab)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/murray/Dropbox/macosx/src/python-control/murrayrm/control/tests/matlab_test.py", line 400, in testModred
    modred(self.siso_ss3, [1], 'matchdc')
  File "/Users/murray/Dropbox/macosx/src/python-control/murrayrm/control/modelsimp.py", line 181, in modred
    raise ValueError("Matrix A22 is singular to working precision.")
ValueError: Matrix A22 is singular to working precision.

I haven't figured out what specifically in this PR is causing the problem, but need to chase this down before we can merge.

@repagh Can you run this against the latest version of slycot and see if you get the same error?

@repagh
Copy link
Member Author

repagh commented Jul 1, 2018

I get the same error.

However, I do not think this should be an issue. The modred is performed on a state-space system created with tf2ss, through slycot. One of the states is removed in modred, and since the tf2ss has been changed, a different set (of equally valid) states has come out of that step. Without control over what states are chosen for a state-space system, one should not try to eliminate a specific single state.

Using siso_ss1 instead of self.siso_ss3 for the test works.

  of which the selection of states was automatic
@repagh
Copy link
Member Author

repagh commented Jul 1, 2018

I also see a bunch of other tests failing (e.g. test_robust). I don't get that same behaviour locally.

Closer inspection of the log shows that the failing slycot builds are missing openblas; I think we need to update .travis.yml here too.

@murrayrm
Copy link
Member

murrayrm commented Jul 2, 2018

The other tests are failing due to changes that are addressed in PR #210. I'll test locally and if everything is working then I'll merge PR #210 and then this PR, which should get us back to a working master branch.

@murrayrm
Copy link
Member

murrayrm commented Jul 2, 2018

Confirmed that latest change (to modred unit tests) fixes the issue on my local machine. PR #210 is now merged, so this PR is ready to go.

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.

None yet

4 participants