Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Docstring fix in create_statefbk_iosystem#923

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

KybernetikJo
Copy link
Contributor

This PR only changes the docstring of create_statefbk_iosystem, makes help more readable.

  • Changes math formulas to sphinx math
  • Changes most signal-names to inline math in order to be consistent with formulas
  • Fixes some typos
  • Adds a full example

@coveralls
Copy link

coveralls commentedJul 13, 2023
edited
Loading

Coverage Status

coverage: 94.968%. remained the same when pullinge65750a on KybernetikJo:doc-fix-create_statefbk_iosystem into42c6fb1 on python-control:main.

Copy link
Member

@murrayrmmurrayrm left a comment

Choose a reason for hiding this comment

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

The numpydoc style guide says:

Equations : as discussed in theNotes section above, LaTeX formatting should be kept to a minimum. Often it’s possible to show equations as Python code or pseudo-code instead, which is much more readable in a terminal.

Based on this, I have made several suggestions below regarding reverting to plain text in the docstrings, for better display on terminals.

@sawyerbfuller@bnavigator Any thoughts on this general style issue? If we think that Sphinx/readthedocs is the main way people will digest documentation, I am OK with using the :math: directive more liberally.

u =ud - K_p (x -xd) - K_iintegral(C x - C x_d)
.. math ::u =u_d - K_p (x -x_d) - K_i\int(C x - C x_d)
Copy link
Member

Choose a reason for hiding this comment

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

This is probably OK, but see the general comment regarding keeping equations to a minimum.

Comment on lines 606 to 608
u =ud - K_p(mu) (x -xd) - K_i(mu)integral(C x - C x_d)
.. math ::u =u_d - K_p(\mu) (x -x_d) - K_i(\mu)\int(C x - C x_d)

wheremu represents the scheduling variable.
where:math:`\mu` represents the scheduling variable.
Copy link
Member

Choose a reason for hiding this comment

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

As above, it might make more sense here to just use text rather than LaTeX.

@@ -614,7 +614,7 @@ def create_statefbk_iosystem(
is given, the output of this system should represent the full state.

gain : ndarray or tuple
If an array is given, it represents the state feedback gain (K).
If an array is given, it represents the state feedback gain (`K`).
Copy link
Member

Choose a reason for hiding this comment

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

I would leave this as K to make it easier to read on a terminal.

@@ -623,18 +623,18 @@ def create_statefbk_iosystem(

If a tuple is given, then it specifies a gain schedule. The tuple
should be of the form `(gains, points)` where gains is a list of
gains :math:`K_j` and points is a list of values :math:`\\mu_j` at
gains :math:`K_j` and points is a list of values :math:`\mu_j` at
Copy link
Member

Choose a reason for hiding this comment

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

I would change this tomu_j (get rid of the :math: altogether).

which the gains are computed. The `gainsched_indices` parameter
should be used to specify the scheduling variables.

xd_labels, ud_labels : str or list of str, optional
Set the name of the signals to use for the desired state and
inputs. If a single string is specified, it should be a
format string using the variable `i` as an index. Otherwise,
a list of strings matching the size ofxd andud,
a list of strings matching the size of:math:`x_d` and:math:`u_d`,
Copy link
Member

Choose a reason for hiding this comment

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

Suggest leaving as is.

Comment on lines 653 to 659
the controller is the desired statexd, the desired inputud, and
the system statex (or state estimatexhat, if an estimator is
the controller is the desired state:math:`x_d`, the desired input:math:`u_d`, and
the system state:math:`x` (or state estimate:math:`\hat{x}`, if an estimator is
given). If value is an integer `q`, the first `q` values of the
[xd, ud, x] vector are used. Otherwise, the value should be a
:math:`[x_d, u_d, x]` vector are used. Otherwise, the value should be a
slice or a list of indices. The list of indices can be specified
as either integer offsets or as signal names.The default is to
use the desired statexd.
as either integer offsets or as signal names. The default is to
use the desired state:math:`x_d`.
Copy link
Member

Choose a reason for hiding this comment

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

I would leave all of this unchanged.

Comment on lines 680 to 683
takes as inputs the desired state`xd`, the desired input
`ud`, and either the system state `x` or the estimated state
`xhat`. It outputs the controller action `u` according to the
takes as inputs the desired state:math:`x_d`, the desired input
:math:`u_d`, and either the system state:math:`x` or the estimated state
:math:`\hat{x}`. It outputs the controller action:math:`u` according to the
formula :math:`u = u_d - K(x - x_d)`. If the keyword
Copy link
Member

Choose a reason for hiding this comment

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

I would leave this unchanged and convert the formula on line 683 to remove the :math: directive (sou = ud - K(x - xd)).

Comment on lines 693 to 694
systems takes as inputs the desired trajectory`(xd, ud)` and
outputs the system state `x` and the applied input `u`
system takes as inputs the desired trajectory:math:`(x_d, u_d)` and
outputs the system state:math:`x` and the applied input:math:`u`
Copy link
Member

Choose a reason for hiding this comment

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

I would remove the :math: directives.

@bnavigator
Copy link
Contributor

Any thoughts on this general style issue? If we think that Sphinx/readthedocs is the main way people will digest documentation, I am OK with using the :math: directive more liberally.

I agree with all your comments there.

More complex equations should be set in math and most users will

OTOH we should not go overboard for single symbols.

>>> Q = np.eye(2)
>>> R = np.eye(1)
>>>
>>> K, _, _ = ct.lqr(sys,Q,R)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
>>>K,_,_=ct.lqr(sys,Q,R)
>>>K,_,_=ct.lqr(sys,Q,R)

Comment on lines +726 to +728
>>> import control as ct
>>> import numpy as np
>>>
Copy link
Contributor

Choose a reason for hiding this comment

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

np andct are globally implicit

doctest_global_setup="""
import numpy as np
import control as ct

@KybernetikJo
Copy link
ContributorAuthor

KybernetikJo commentedAug 22, 2023
edited
Loading

The numpydoc style guide says:

Equations : as discussed in theNotes section above, LaTeX formatting should be kept to a minimum. Often it’s possible to show equations as Python code or pseudo-code instead, which is much more readable in a terminal.

Based on this, I have made several suggestions below regarding reverting to plain text in the docstrings, for better display on terminals.

@sawyerbfuller@bnavigator Any thoughts on this general style issue? If we think that Sphinx/readthedocs is the main way people will digest documentation, I am OK with using the :math: directive more liberally.

I was completely unaware of that part of numpydoc, and I'm ok with us not merging it.
(It was a good remark, because I would like to change Slycot/slycot/analysis.py to numpydoc. I can take that into account over there.)

What should we do with this PR?

  • Close this PR with comment.
  • Keep it open, not do anything, just keep it as reference. Maybe latex rendering in terminals will change at some point in the future.
  • Incorporate comments from@murrayrm,@bnavigator and merge. I'm not sure it's worth it, though.

I am fine with all three variants.

@bnavigator
Copy link
Contributor

Although there is little left after incorporating our comments, I think even minor typo fixes and formatting are worth merging. Keep on working and thanks for your contributions!

@murrayrmmurrayrm merged commit0a6146b intopython-control:mainSep 16, 2023
@murrayrmmurrayrm added this to the0.10.0 milestoneMar 31, 2024
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@murrayrmmurrayrmmurrayrm left review comments

@bnavigatorbnavigatorbnavigator left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.10.0
Development

Successfully merging this pull request may close these issues.

4 participants
@KybernetikJo@coveralls@bnavigator@murrayrm

[8]ページ先頭

©2009-2025 Movatter.jp