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

[Ilhan Polat]

I think python-control doesn't need harold at all and in pretty good shape
by itself. So we can start pointing to them anyways,

However, I don't know if it is luck but very recent issues like

https://github.com/scipy/scipy/issues/13496
https://github.com/scipy/scipy/issues/13498

and many more in the backlog are a bit worrisome to me. But then again,
regardless of the issues I don't mind any of these outcomes from this
discussion.



On Sat, Feb 6, 2021 at 6:13 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> 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
>>
> _______________________________________________
> 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/7009beed/attachment-0001.html>