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

use dt=0 instead of dt=None (unspecified timebase) as default option for lti systems? #422

Closed
sawyerbfuller opened this issue Jun 22, 2020 · 5 comments · Fixed by #490
Closed
Milestone

Comments

@sawyerbfuller
Copy link
Contributor

sawyerbfuller commented Jun 22, 2020

I was wondering if somebody could tell me the motivation behind the current convention for default initialization of LTI systems to have dt=None? Using dt=None means an unspecified time base, allowing the system to be interpreted either as cont or discrete time. (I couldn't find any discussion of this but please let me know if I missed it).

A system with an unspecified dt seems to be an unusual object:

  • printing out its transfer function shows 's' as the complex variable, suggesting it is a cont-time system
  • but isdtime(sys) evaluates to true (but not if strict=True is specified) -- I thought this was a bug at first
  • cont and discrete time systems have substantially different behavior, which seems to be at odds with the notion that an object should know how to handle itself

Have you thought about using a default of dt=0 (continuous time), and leave the dt=None case be a special case, to be instantiated only when needed? (Issue #419 made me think of this and is related)

@ilayn
Copy link

ilayn commented Jun 22, 2020

It's a relic from Matlab with some very old historic reasons but survived under backwards-compatibility flow. Then apparently adopted also here. Internally matlab secretly inserts some default value (that I forgot) whenever dt is needed anyways. My take on this is that user should insert some random value if they don't care because they don't care or defaulys should map to dt=0.01 to be slightly realistic.

@murrayrm
Copy link
Member

I think I was the person who used dt=None. The motivation was a bit different: if someone didn't specify whether the system was continuous or discrete, we wanted to allow as much flexibility as possible. So, for example, if you combine a system without a timebase (dt=None) with one that has a time base (dt=0, dt=True, dt=0.1, etc) then the first system will assume the time base of the other.

This probably doesn't matter that much, though it is handy for systems that are constants (no states).

The current approach is documented here.

I would like to see a bit more discussion of this before we make a change, since it may break people's code.

@sawyerbfuller
Copy link
Contributor Author

Hi Richard, makes sense that dt=None that could be very useful for systems that are a static gain.

Could dt=None be a special case that is used by default when constructing such systems?

Looks like in matlab that the default is dt=0 (continuous time). with an option to set it to -1 to be unspecified if desired: https://www.mathworks.com/help/control/ref/tf.html#f4-209775_sep_mw_ec86807c-5450-4be4-ae9a-e85042c27676

I couldn’t find any examples of systems using an unspecified time base online after a quick search.

@sawyerbfuller
Copy link
Contributor Author

Does anybody here have code that would break if dt=0 were the default instead of dt=None?

@murrayrm
Copy link
Member

One other possibility is to set up a package wide configuration variable that sets the default system type. I've been thinking that as we make various changes to defaults and other parameters, we might create a function use_legacy_defaults(version) that sets the defaults to whatever they were in a given release. That way if something breaks, you use call use_legacy_defults('0.8.3') and everything works as in the current release.

@bnavigator bnavigator linked a pull request Aug 16, 2020 that will close this issue
@murrayrm murrayrm added this to the 0.9.0 milestone Dec 26, 2020
@bnavigator bnavigator linked a pull request Dec 31, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants