Another question for this community: should this package eventually become more tightly integrated with SciPy? And if so, what is the best way to do this?
To be more specific, there are a few ways this might happen. It may be that it ultimately makes sense for python-control to be integrated directly into the main SciPy distribution, perhaps as part of scipy.signal, or perhaps as a separate sub-package (though if I understand, this is very rarely done). Another possibility is for python-control to become a SciKit. I discovered SciKits only recently (I think they are a new thing), but as far as I can tell, they are toolkits that interact closely with SciPy. According to the SciPy website, it's appropriate for a package to be a SciKit when:
The package is deemed too specialized to live in SciPy itself or
The package has a GPL license, which is incompatible with SciPy’s BSD license or
The package is meant to be included in SciPy, but development is still in progress.
The second doesn't apply to python-control, but I think either the first or the third would apply.
My own opinion is that having a closer tie with SciPy might help to make python-control more "mainstream," and might attract more users or developers. So I would be in favor of making python-control a SciKit, for instance renaming it as scikit-control. This would involve some minor reorganization, and posting on PyPI (as James Goppert has already done with his fork), but shouldn't be too much of a hassle. I am happy to help out, or even take the lead on this, if others think it is a good idea.
Does anybody else have thoughts or opinions on this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I like the idea of a scikit, which I hadn't heard of until now. Would like to hear from others if there are any reasons not to do this. Particularly James Goppert (since his fork is up on PyPI) and Ryan Krauss, who has tried using python-control for his class, if memory serves.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think an active control system toolkit would be immensely valuable for the scientific and engineering popularity of Python. I also agree that "control" is too large/specialized to be incorporated into scipy.signal. As I see it, the current definitions (e.g. of "transfer functions - tf") of scipy.signal and of the "control" package are incompatible, and an incorporation of "control" into a scipy.signal compatable format ("scikits-control") would be much appreciated.
If Richard Murray agrees (and supports it), I might be able to come up with some manpower for such a project. Please let me know what you think about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another question for this community: should this package eventually become more tightly integrated with SciPy? And if so, what is the best way to do this?
To be more specific, there are a few ways this might happen. It may be that it ultimately makes sense for python-control to be integrated directly into the main SciPy distribution, perhaps as part of scipy.signal, or perhaps as a separate sub-package (though if I understand, this is very rarely done). Another possibility is for python-control to become a SciKit. I discovered SciKits only recently (I think they are a new thing), but as far as I can tell, they are toolkits that interact closely with SciPy. According to the SciPy website, it's appropriate for a package to be a SciKit when:
The second doesn't apply to python-control, but I think either the first or the third would apply.
My own opinion is that having a closer tie with SciPy might help to make python-control more "mainstream," and might attract more users or developers. So I would be in favor of making python-control a SciKit, for instance renaming it as scikit-control. This would involve some minor reorganization, and posting on PyPI (as James Goppert has already done with his fork), but shouldn't be too much of a hassle. I am happy to help out, or even take the lead on this, if others think it is a good idea.
Does anybody else have thoughts or opinions on this?
I like the idea of a scikit, which I hadn't heard of until now. Would like to hear from others if there are any reasons not to do this. Particularly James Goppert (since his fork is up on PyPI) and Ryan Krauss, who has tried using python-control for his class, if memory serves.
I think an active control system toolkit would be immensely valuable for the scientific and engineering popularity of Python. I also agree that "control" is too large/specialized to be incorporated into scipy.signal. As I see it, the current definitions (e.g. of "transfer functions - tf") of scipy.signal and of the "control" package are incompatible, and an incorporation of "control" into a scipy.signal compatable format ("scikits-control") would be much appreciated.
If Richard Murray agrees (and supports it), I might be able to come up with some manpower for such a project. Please let me know what you think about it.