[SciPy-Dev] SLICOT, LTI functionality and scipy.signal (WAS: Yes, we don't want any scipy modules BUT)

[Ralf Gommers]

On Wed, Feb 3, 2021 at 12:00 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:

> Hi everyone,
>
> This is an odd ball of an subject so bear with me for a paragraph.
> Currently we have lots of control related functions on scipy.signal with
> varying production grade some are there almost just as a placeholder some
> are pretty good. However, many things don't come with the box such as MIMO
> support, internal delay representations, time and bode plotting (properly
> spaced and considerably dense) and so on. Now of course we have
> python-control and (shameless plug) harold packages that can do some and
> fail to do others. Frankly in my particular case scipy is eating all my OSS
> time. And python-control has their own roadmap. I provide lots of MIMO
> stuff but lacking the academic catalogue functions like root-locus and
> other academic torture tools and python-control is mostly lacking MIMO
> support and a bit short of advanced stuff.
>
> In the mean time, there is a very nice Fortran library SLICOT which also
> powers some matlab functions in production however it is not open source.
> But they moved to GitHub recently and released its earlier version 5.7
> under BSD3. Previously 5.0 was released under GPL and that was the one
> python-control vendored but 5.7 is already pretty capable and actually
> caused me to write this up. This library is quite diverse and written by
> very very high caliber researchers. The reason why I always avoided was
> obviously GPL but apparently they changed their mind which is personally
> fantastic news for me.
>

That's very interesting. python-control itself is BSD-3, but the
recommended optional dependency slycot is indeed GPL v2.

So coming back to the meat of this discussion: I have looked at the LTI
> parts and very very closely and I don't see any way to overhaul them
> without extremely painful deprecation cycles and breakage. But I sincerely
> believe that together with PocketFFT scipy can serve a better quality LTI
> tools. In its current state it's a bit academic-ish and not production
> ready. So this brings us to three concrete options
>

I agree. The scipy.signal module is of varying quality, and the LTI parts
are indeed not great.


> 1- Status quo : I don't like touching that many funcs and waking the
> sleeping dogs
> 2- Whatever we do we do it on the current functions: It doesn't matter if
> it takes 4 years, we don't want any adventures
> 3- Make a new module and lighten up the signal module which was probably
> not exactly the right place.
>
> Please make it as blunt as possible, no hard feelings but I think this
> discussion has to be done at least once and maybe for all. A tiny bit of it
> has already happened last year in https://github.com/scipy/scipy/pull/4515
> but it barely grazed.
>

On reflection, creating a new scipy.control module worries me a little.
What Eric Quintero said on gh-4515 is probably true:

*"I'm a user and a big fan of python-control, but I don't think I'm quite
on board with merging it into scipy. The scope of capabilities that users
may expect from a controls package is a little bigger than what I imagine
for scipy submodules. I think there is an advantage to be had to being a
standalone module that can set its own schedule, deprecation policy, etc."*

Control theory is a little specialized/niche compared to most of the topics
covered by other SciPy submodules, and the combination of that
domain-specific knowledge plus a large amount of Fortran code is not very
appealing.

I think my ideal outcome here would be that python-control and harold
merge, and we recommend that one well-designed/maintained package to users
over and above the LTI and filter design functionality in scipy.signal. We
can't deprecate scipy.signal, because it's too widely used. But it could
have a similar relation to the python-control-harold package as
scipy.cluster has to scikit-learn: we offer the basics, and for
higher-performance or more state-of-the-art stuff, go elsewhere.

Cheers,
Ralf



> Cheers,
> ilhan
>
> Current catalogue
> https://docs.scipy.org/doc/scipy/reference/signal.html
>
> python-control vendored version
> https://github.com/python-control/Slycot
>
> New BSD3 version
> https://github.com/SLICOT/SLICOT-Reference
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210206/33d30d1d/attachment.html>