Adding a new package for signal processing.

[Chanakya Ajit Ekbote]

I feel that a new package that focuses on signal processing is required in SymPy as there are a lot of functionalities that SymPy provides that are not present in other conventional signal processing libraries. Please refer to the discussion: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/sympy/bRmTmiPYe5I/Wu7FABFtAwAJ as well as the PR #18419: https://github.com/sympy/sympy/pull/18419.

---

Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

[Chanakya Ajit Ekbote]

There are certain functionalities of SymPy such as solving differential equations, transform calculus, integral calculus etc. that a user may use in order to use SymPy for Signal Processing (SP) as well as Control System (CS) applications, however he/she has to entirely code a new method or function that is specific to his/her domain. Moreover, it would require a person with a decent amount of coding knowledge in order to implement the application they want. In addition to that a researcher or a student would just want to enter an expression and get the output he/she wants. Hence I propose the following:

Phase 1: The goal of Phase 1 would be to use SymPy's own existing methods for simple SP and CS applications.

We update the existing packages such as plotter, transform calculus, solvers etc . in order to cater to SP and CS needs. For example, we'd have to add pole zero plots, magnitude response plots, phase response plots to the plotter package. The alternative would be to create a new package that caters specifically to the needs of SP and CSA. This package would have methods that compute the magnitude response, phase responses, bode plots, phase plots, magnitude plots etc.

The developments in this phase would target an intermediate student or a novice researcher for basic functionalities.

Phase 2: We develop new functionalities for SP and CS applications. 

We would be implementing DFT, Z Transform, Wavelet Transform, Fourier Bessel Transform etc which can be calculated using the calculus as well as transform libraries.

In addition to that solving differential equations could be done in the Laplace, Fourier or Z Domain (depending on the application), and  the steps could also be displayed (which would help a student a lot).

The developments in this phase would target an intermediate researcher for advanced functionalities.

Phase 3: Add GUI functionalities as well as simulators

We could add a GUI Bond Graph Tool that would help researchers define a system easily and obtain the response.

Moreover we could also add a simulator that correctly simulates the output, given certain boundary value conditions.

This is just a rough outline of what I believe would be the ideal approach. All suggestions are welcome, and these phases would be tweaked after the discussion.

I had already started working on Phase 1: The link to the PR is click here.

[Oscar Benjamin]

There have been proposals to add a control theory module. See here for
a recent revival of that:
https://github.com/sympy/sympy/issues/18460

Would that be a good place to put some of the ideas you are suggesting?

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e07bb5d9-2e46-4281-9312-74506dd182c0%40googlegroups.com.

[Chanakya Ajit Ekbote]

Since signal processing and control systems go hand in hand (to a certain extent) I think it'll be a good starting point. I think we could port this discussion to the issue #18460. Thank you.

> To unsubscribe from this group and stop receiving emails from it, send an email to sy...@googlegroups.com.

[S.Y. Lee]

I'm not sure that pole_zero_plots, z-transforms are the stuff that are purely signal processing project.

Can they be done under the umbrella of the control systems framework?

But of course they can be similar in the nature.

[Chanakya Ajit Ekbote]

Usually, control systems and signal processing go hand in hand. The same methods are used in both disciplines. The former uses these methods for designing systems, and the latter uses these methods for analysing systems. Hence they can be done under the umbrella of the control system framework as well.

The main distinction that can come is in the signal processing part. Algorithms such as DFT, FFT are usually only used for signal processing. Hence we may need a separate package for signal processing and control systems if there is some interest to move in that direction.

--

You received this message because you are subscribed to the Google Groups "sympy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d156cf91-7e4e-45e2-ba35-f652455557a0%40googlegroups.com.

[S.Y. Lee]

In my opinion, most of the stuff like `DFT`, `FFT` doesn't need a standalone package, but can be implemented as some improvements over the current `discrete` module, or `matrices`, `array` module.
I'd contribute most of the stuff down in the core mathematics than some engineering package if they are not coming up with some specific 'model' like how the mechanics or control system does.

Because we would ultimately have to resolve things in more generalized form if it is more about math than engineering, like solving DFT as a summation problem.

On Thursday, January 23, 2020 at 2:16:08 PM UTC+9, Chanakya Ajit Ekbote wrote: