Coverage decreased (-10.2%) to 74.014% when pulling d1da3e1 on sawyerbfuller:better-tfinal into 7af3fbf on python-control:master.

Coverage increased (+2.09%) to 86.303% when pulling c588cdc on sawyerbfuller:better-tfinal into 5c79fc8 on python-control:master.

Thank you very much for this. It's all good. Feel free to butcher as you see fit and excuses in advance if I made mistakes here and there.

Sorry, the merge of #441 created a merge conflict mainly due to whitespace changes. I rebased to current master for you.

To continue working, if you don't have local changes and your personal fork is the remote origin:

git reset --hard origin/better-tfinal

If you don't like my interference, to revert my rebase, just git push -f your local branch again.

@bnavigator all looks good. I double checked and new code works fine with z-plane poles at zero or 1, so #441 is no longer needed, except for if it adds a unit test

sys = tf(1, [1, -1], True)
plt.plot(*control.step_response(sys))
sys = tf(1, [1,], True)
plt.plot(*control.step_response(sys))

• avoid log(0) in automatic timevector calculation #441 is already merged. Excluding many automatic PEP8 whitespace fixes from my IDE, it contained only the one line deselecting the pole. Your PR will replace that small fix with new code. Only the exact content of the lines you are replacing changed. Hence the merge conflict and required rebase.
• The inline code comments contain a few more unicode symbols. We will need to abandon Python 2 eventually 🙄 Maybe adding an encoding header to the top is easier here.

• The inline code comments contain a few more unicode symbols. We will need to abandon Python 2 eventually 🙄 Maybe adding an encoding header to the top is easier here.

I'll give up and do that if this last commit fails too.

I double checked and new code works fine with z-plane poles at zero or 1,

phew... 😅

@ilayn Related: your code uses is_step only for computing cont-time responses, but not discrete-time. Is that intentional? S

Yes, because in discrete time, we don't really need to have to get the fast dynamics contributions since they are bounded by the sampling period. I might be wrong though, didn't give too much of a careful thought. Probably can be tested with very fast poles and very slow poles.

@ilayn thanks, makes sense.

Update on the above code: whoops, I didn't actually put a pole at the origin. updated code still works:

sys = tf(1, [1, -1], True)
plt.stem(*control.step_response(sys))
sys = tf(1, [1, 0], 1)
plt.stem(*control.step_response(sys), markerfmt='C1o', linefmt='C1')