Useful GSoC Idea

[Ondřej Čertík]

Hi,

Here is a great idea for a GSoC project:

https://github.com/sympy/sympy/issues/2803#issuecomment-604697523

Would any student be interested? I know at least one user who couldn't use SymPy because of that. So fixing it would be very useful to a lot of people. The scope of the GSoC project could be to get SymPy working with Fourier transforms of many such functions including Piecewise and adding a nice page to SymPy's documentation with examples.

I'll be happy to mentor such a project.

Ondrej

[Aaron Meurer]

Yes, presently the integral transforms code don't do any kind of table
lookups. They just try to compute the integral, and if the integral
can't be computed it can't give a result. In this case, the integral
itself is wrong and it should be fixed. This has been mentioned in
some other issues as well https://github.com/sympy/sympy/issues/13491,
https://github.com/sympy/sympy/issues/13606 (and probably others if
you search the tracker).

Such a project should also improve the other transforms as well, not
just Fourier. It would also be beneficial if integrate() itself were
improved, so that integrals that look like transforms always work
whenever a *_transform() call works.

Aaron Meurer

> --
> 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/60677008-15a5-4c6c-8f04-fa5c0dfe1a14%40www.fastmail.com.

[Oscar Benjamin]

Hi Ondrej,

What exactly what the project do? Is there a wider approach that can
be taken that handles this sort of thing?

Oscar

[Jackson Morris]

Hello there, 

I just commented on the issue, but I figure that this is a better way to communicate. Here is my comment from the issue: I would certainly be interested in working on this for GSoC. I am still getting familiar with the internals of sympy, but I think that this would be right up my alley. Would getting this fixed be the main component of the project?

Best,

Jackson

[Ondřej Čertík]

Hi Jackson and Oscar,

Indeed, fixing this would be the main goal of the project. Let's brainstorm the possible approaches.

1) One is to work on the integrate() function, and make it return distributions (delta functions) where appropriate. One way to do that is using pattern matching, similar to Rubi. One would match the typical integrals that occur, and return the correct answer. One would probably write a dedicated function for that, say, integrate_distributions, and then somehow hook it up into integrate.

2) The other approach is to tie it specifically into the fourier_transform() function.

I was hoping we could write general enough integrate_distributions function, so that when it is called from inside Fourier, Laplace and other transforms, it would return the correct answer.

Finally, cos(x) is just one simple example. It needs to be extended to work correctly with piecewise functions and other. I can provide such examples from a person who reported this issue to me yesterday.

For example, if it could do majority of these transforms correctly, that would be ideal:

https://en.wikipedia.org/wiki/Fourier_transform#Tables_of_important_Fourier_transforms

There will be always corner cases, but getting 90% of them correctly would go a long way.

Ondrej

> --
> 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/a51452c8-bb74-4fa2-b2ac-04c66e7e9199%40googlegroups.com <https://groups.google.com/d/msgid/sympy/a51452c8-bb74-4fa2-b2ac-04c66e7e9199%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Aaron Meurer]

On Fri, Mar 27, 2020 at 10:51 AM Ondřej Čertík <ond...@certik.us> wrote:
>
> Hi Jackson and Oscar,
>
> Indeed, fixing this would be the main goal of the project. Let's brainstorm the possible approaches.
>
> 1) One is to work on the integrate() function, and make it return distributions (delta functions) where appropriate. One way to do that is using pattern matching, similar to Rubi. One would match the typical integrals that occur, and return the correct answer. One would probably write a dedicated function for that, say, integrate_distributions, and then somehow hook it up into integrate.

I think this is the right approach. We already have a pattern matching
integrator called manualintegrate that this can be added to. We can
also investigate if the meijerg algorithm can be improved to work in
these cases. If it can, then that will enable a lot more than we could
get by naive pattern matching. In each case, I would investigate
meijerg first. If it can be improved (and is fast), then that is
enough. It is only if it can't that we should add a table lookup. In
some cases, meijerg can work but it needs some better pre-processing
(like calling apart() first so it can operate on a partial fraction
decomposition).

The benefit of improving integrate is that things will work regardless
of whether they call fourier_transform or just create the integral of
a Fourier transform. As you probably know, integrals that look like
common transforms appear all the time even when you aren't necessarily
thinking in terms of that transform.

By the way, since you mentioned RUBI, I don't think even it would help
here, since, unless I am mistaken, it doesn't deal with definite
integrals.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ec797a11-e354-48a5-9ce9-f0b5617d7099%40www.fastmail.com.

[Bhaskar Gupta]

Hi everyone, 

I found this idea to be really interesting and would like to work on this. 

In my opinion, the second approach is much better than the first and also this will make it easier to maintain in the future. 

Can you please explain to me how to move forward on this.

Thanks,

Bhaskar

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ec797a11-e354-48a5-9ce9-f0b5617d7099%40www.fastmail.com.

[Jackson Morris]

So, a potential plan of action could be something like determining which integration method could most easily be extended to return distributions (whether that is meijerg, or manual integrate)

 and then implementing such an extension to either of these methods. If it proves intractable to improve either of these methods we would then look into a look-up table? Would it be unrealistic to try to implement other sorts of generalized functions into Sympy for a GSoC project?

Thanks! Jackson

> > an email to sy...@googlegroups.com.

> >  To view this discussion on the web visit
> > https://groups.google.com/d/msgid/sympy/a51452c8-bb74-4fa2-b2ac-04c66e7e9199%40googlegroups.com <https://groups.google.com/d/msgid/sympy/a51452c8-bb74-4fa2-b2ac-04c66e7e9199%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
> --
> 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 sy...@googlegroups.com.

[Aaron Meurer]

manualintegrate basically is a lookup table. So if you want to
implement a lookup table, it should go there, rather than trying to
reinvent it.

What other sorts of generalized functions would you want to implement?

Aaron Meurer

> 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/17f88db9-1638-4601-967e-2d1341b17019%40googlegroups.com.

[Jackson Morris]

My initial thought was that we could have some kind of a "distribution object" in order for us to more easily identify when the result of an integral could be written in clean terms (we could also use these when we need a distribution to describe the derivative of some function), but now I am realizing that almost all (interesting) instances of distributions occurring in these types of integrals are variations of the delta function (eg derivatives), which is already covered in the functions module. Also, is investigating whether the meijerg methods can be modified to return distributions something I should look into now when formulating my timeline/plan, or can there be some built in time for determining which will be more feasible (between meijerg or manualintegrate).

Thanks,

Jackson

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/17f88db9-1638-4601-967e-2d1341b17019%40googlegroups.com.

[Aaron Meurer]

Modifying the meijerg algorithm will require some time for you to
understand the algorithm and the code behind it, so you should
allocate some time for it.Adding support to manualintegrate should be
much easier. We should probably try to do both.

Aaron Meurer

> 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/6586eb95-2e36-4ff2-80d3-f90fba57dd9e%40googlegroups.com.

[Jackson Morris]

Ah alright, I am relived to hear that - I started taking a look at some of the docs (https://docs.sympy.org/latest/modules/integrals/g-functions.html#g-functions) and was a bit intimidated. This sounds good and I will have my proposal posted in the very near future. 

Jackson Morris

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/6586eb95-2e36-4ff2-80d3-f90fba57dd9e%40googlegroups.com.

[Ondřej Čertík]

Note that the deadline for an application is tomorrow. If you want us to provide feedback so that you can improve it, please post a draft as soon as you can.

Ondrej

> an email to sympy+un...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sympy/e37e2c7c-ca70-4eb0-838e-c9eee3b84d1b%40googlegroups.com <https://groups.google.com/d/msgid/sympy/e37e2c7c-ca70-4eb0-838e-c9eee3b84d1b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jackson Morris]

Ah, I posted the link in the Gitter chat last night, but should have also poster here: https://docs.google.com/document/d/1cYyk2beU8d4XLtBV_Z-j7XLUpF4JOgROv1mHEcB1_rc/edit?usp=sharing any feedback would be greatly appreciated!

> https://groups.google.com/d/msgid/sympy/e37e2c7c-ca70-4eb0-838e-c9eee3b84d1b%40googlegroups.com <https://groups.google.com/d/msgid/sympy/e37e2c7c-ca70-4eb0-838e-c9eee3b84d1b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Ondřej Čertík]

On Mon, Mar 30, 2020, at 10:29 AM, Jackson Morris wrote:
> Ah, I posted the link in the Gitter chat last night, but should have
> also poster here:
> https://docs.google.com/document/d/1cYyk2beU8d4XLtBV_Z-j7XLUpF4JOgROv1mHEcB1_rc/edit?usp=sharing any feedback would be greatly appreciated!

No problem. Looks good overall. I left some comments. I would suggest you look into the manualintegrate.py and try to understand how it works and how it could be extended. The extension of meijerint might be challenging, but extending manualintegrate should be doable, and that would allow you to deliver something this summer that can be used. And if there is time, we should tackle meijerint of course. So having more detailed plan for manualintegrate in the proposal would be very helpful.

Also, please try to finish your PR, so that it can be merged.

Ondrej

[Jackson Morris]

Got it, I will add more detail for manualintegrate, rework my timeline, and finish that PR.

Best,

Jackson

--
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/f7f36377-f3ca-4964-a087-5888f35740cb%40www.fastmail.com.

[Jackson Morris]

I have made some changes based on your suggestions, mainly tailoring my plan more toward the manualintegrate approach and more details about how exactly this would go. Any comments are greatly appreciate. Still working on that PR.

Thank you,

Jackson

On Monday, March 30, 2020 at 9:42:47 AM UTC-7, Jackson Morris wrote:

Got it, I will add more detail for manualintegrate, rework my timeline, and finish that PR.

Best,

Jackson

On Mon, Mar 30, 2020 at 9:40 AM Ondřej Čertík <ond...@certik.us> wrote:

On Mon, Mar 30, 2020, at 10:29 AM, Jackson Morris wrote:
> Ah, I posted the link in the Gitter chat last night, but should have
> also poster here:
> https://docs.google.com/document/d/1cYyk2beU8d4XLtBV_Z-j7XLUpF4JOgROv1mHEcB1_rc/edit?usp=sharing any feedback would be greatly appreciated!

No problem. Looks good overall. I left some comments. I would suggest you look into the manualintegrate.py and try to understand how it works and how it could be extended. The extension of meijerint might be challenging, but extending manualintegrate should be doable, and that would allow you to deliver something this summer that can be used. And if there is time, we should tackle meijerint of course. So having more detailed plan for manualintegrate in the proposal would be very helpful.

Also, please try to finish your PR, so that it can be merged.

Ondrej

--
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+unsubscribe@googlegroups.com.

[mikhae...@umontpellier.fr]

For sure really helpful ! (in fact mandatory to switch from Matlab to Python in my teaching department ...)

[cheshta babbar]

Hi,

I really like the idea and am up for taking it as a gsoc project. Could you help me with that? And tell me where to begin with.

--

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/901658c5-1a5a-4c27-a3e7-140e93d383adn%40googlegroups.com.

[Aaron Meurer]

The best place to start is to familiarize yourself with SymPy and the
codebase. The best way to do this is to start to make pull requests
fixing simple things.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAL63R55%2BdO5d3XTxGrvouxTGRFXNOR%3D1w4e3zJVDBJeXnnNbdQ%40mail.gmail.com.

[cheshta babbar]

Yes, I've already started that, I'll keep you posted.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JHsFRFP2JOWJ9jvLYiWga9hAuUJBQoUexRsbdvojJoVA%40mail.gmail.com.

[S.Y. Lee]

I have also seen that meijerg integration can give imprecise result for convergence for some cases

https://github.com/sympy/sympy/issues/16242.
I'm not sure if this problem can be solved algorithmically, but if it can't I think that we have other technical reason to have table lookups for integrations.

[Aaron Meurer]

On Sun, Jan 17, 2021 at 6:50 AM S.Y. Lee <syle...@gmail.com> wrote:
>
> I have also seen that meijerg integration can give imprecise result for convergence for some cases
> https://github.com/sympy/sympy/issues/16242.
> I'm not sure if this problem can be solved algorithmically, but if it can't I think that we have other technical reason to have table lookups for integrations.

The convergence conditions come from the general G-function
convergence conditions. See
https://docs.sympy.org/latest/modules/integrals/g-functions.html#the-g-function-integration-theorems.
I don't know if they can be tightened. It might be possible to do so
for certain special cases, but one would need to do a deep
investigation of the theory. Perhaps it is possible, for instance,
that in some cases a more specific type of special function than the
G-function can be used that has tighter convergence conditions.

Convergence conditions for table lookup integrals should be possible.
The tricky part is finding a sufficiently general form of the integral
to match against, for which you can compute a general tight
convergence condition.

Also, two asides:

- The convergence conditions should also be simplified better. In the
issue you have abs(arg(w) + pi/2) <= pi/2 which is equivalent to im(w)
< 0. SymPy needs to be able to simplify conditions like these.
- I don't know how well the manualintegrate module will scale to lots
of table lookups. We might run into a wall, in which case, we may need
to look into using RUBI again.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/58fc4e52-ce78-446a-827e-0ce113440f15n%40googlegroups.com.