ENH: signal: SOS LTI systems

[e-q]

We want second order sections to be first class scipy.signal citizens, so I started working on giving them their own lti subclass. This is very much a work in progress, but I wanted to start a place to have relevant discussions.

Specifically, the usual argument-counting scheme really falls down for sos. (Reminder: we often identify what form the LTI system tuple takes with len(system), 2=TF, 3=ZPK, 4=SS) However, since the cascading sections are specified as an ndarray with shape [n, 6], when we call len(system), we can get literally any integer. This doesn't just affect instantiation of lti objects, but also the input arguments of freqresp, step, lsim, etc. What should we do?

Here is an incomplete list of other TODOs:

• Docstrings
• Simulation functions
• do we need to support multiple inputs/outputs? (Q: What is current suport in other LTI classes?)
• Add sos support to cont2discrete
• Add some kind of _sos_normalize function
• Tests

An alternative, which I believe @endolith has mentioned, is to instead create general cascaded LTI systems. Then, SOS systems are just cascaded second order TF systems. I don't think I've come across other kinds of cascaded systems though.

(As a side note, I moved the lti conversion functions that lived in filter_design to lti_conversion for my own sanity. Even after the moves, filter_design is over 3kloc.)

[endolith]

What should we do?

Can't you just check if the input has shape [n, 6]?

[larsoner]

Or maybe even if isinstance(x, np.ndarray) and x.shape[1] == 6?

[larsoner]

(... and x.ndim == 2 and x.shape[1] == 6 I mean)

[e-q]

I guess the only problem with this approach is that in only works with ndarrays, but not a 2D list. This is unfortunate, but not a tragedy.

I also note that this feature will have to include a fix for gh-5668.

[larsoner]

That seems like an acceptable tradeoff so long as it's documented behavior. Our generation functions create them that way anyway.