Discussion[GSoC 2020]: Project out of fixing issues

100 views
Skip to first unread message

Sachin Agarwal

unread,
Feb 4, 2020, 2:21:28 AM2/4/20
to sy...@googlegroups.com
Hello Everyone,

I am Sachin Agarwal, a second year Undergraduate student pursuing Computer Science Engineering at Indian Institute of Information Technology, Guwahati. 

I regularly contribute to SymPy and have been contributing since October 2019. I have a profound interest in Mathematics, and am well familiar with programming languages like C, C++ and Python. 

As mentioned by Aaron, we can have a project this summer trying to fix as many existing issues as possible. I am interested in taking up this project. 

Please reply to this thread if you have any opinions about this project.

Oscar Benjamin

unread,
Feb 4, 2020, 4:45:47 AM2/4/20
to sympy
Hi Sachin,

I think that a project along these lines needs to have some scope.
There are a lot of open issues so which ones roughly would you fix?

It needs to be possible for someone to act as a mentor so it should be
well-defined which parts of the codebase you will work on. Issues on
github are labelled so e.g. one possibility would be to say that you
will focus on the concrete module and the issues that are labelled as
concrete:
https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Aconcrete

If you look through the concrete issues you will find that many of
them are perhaps due to problems elsewhere in the codebase so I guess
the target could be to investigate each issue and then either:
1. Fix the issue by making changes in concrete and/or small changes elsewhere.
2. Ensure that the underlying issue is identified and a label for e.g.
series or whichever part of the codebase is added.

If you investigate hard enough you will see that there are basic
problems that need changes in the module so actually the best approach
to fixing many of the issues might not be fixing small issues one at a
time. Probably we should fix the definition of Sum so that we don't
have nonsensical results like:
```
In [3]: Sum(1, (n, 1, S.Half)).doit()
Out[3]: 1/2
```
Once the definition is clear then at least we know what the right
answer should be for each of the issues.

Another example of a scope for issues would be piecewise:
https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Afunctions.elementary.piecewise
For piecewise the piecewise function itself is a tighter scope than
the concrete module but the issues all involve other parts of the
codebase.

There are many different labels that you could focus on. I suggest to
find one where you understand the maths, skim through the issues, and
then try fixing a few. For a GSOC proposal you could read through the
list of issues and write a plan that says what changes could be made
and which issues that would fix.
> --
> 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/CAM8%3DFcBZ-OWWk4uNspLgOBo%3DVV_p-%3D3QOPXAUKap%3D8czu-6Jig%40mail.gmail.com.

Sachin Agarwal

unread,
Feb 4, 2020, 5:08:49 AM2/4/20
to sy...@googlegroups.com
I totally agree with you, I am of a similar opinion. I need some time to decide the module corresponding to which I am a bit familiar with the math part.

After that I would request some member of SymPy to allot a specific number of issues to me so that we can ensure nobody else tries to work on them. Moreover which will be enough to constitute a summer project. 

Thus corresponding to those issues I will prepare a proposal, as you have mentioned, properly suggesting the changes which will fix those issues. And any new functions, if possible, which could be added to that module to support some new features. 

Oscar Benjamin

unread,
Feb 4, 2020, 5:15:19 AM2/4/20
to sympy
On Tue, 4 Feb 2020 at 10:08, Sachin Agarwal <sachinag...@gmail.com> wrote:
>
> After that I would request some member of SymPy to allot a specific number of issues to me so that we can ensure nobody else tries to work on them. Moreover which will be enough to constitute a summer project.

We don't generally allocate issues to contributors. Anyone is free to
work on any issue. Part of working on the issues would include
reviewing contributions from others and reviving old pull requests.

--
Oscar

Gagandeep Singh (B17CS021)

unread,
Feb 4, 2020, 5:17:17 AM2/4/20
to sy...@googlegroups.com
Hi Sachin,

I think has Oscar has highlighted some very good points about your idea. I would like to add a few points to it.

Fixing issues in GSoC project is nice though quite unpredictable, for example an issue in stats module can be linked to probably integrals or solvers module. However, there is still some scope for making an organised and well designed proposal.
You can start with first making draft list of issues on which you want to work during the summers. You can include those issues which you think you can fix, that is you should be confident enough after looking at the example code and doing some background research on it. Then you can divide the list into various modules. Though note that you should put an issue under the module where the root cause of it lies and not where it was reported. For example, most of the performance related problems in computing CDF of a random variable are connected to the integrals module though they are reported under the stats module. You can discuss on github about where the root cause lies. Dividing the list into modules can be helpful in allocating mentors. You can include some git diffs in your proposal which will show your attempts at making those fixes, though it is not expected from you to show fully working code.

One more idea that you can include in the community bonding period, which is to increase the code coverage by adding/improving tests. This will also help you to identify new bugs which you can fix during the coding period or may be it can also be helpful for some future student. The current coverage is usually around 75% which should be increased.
 
IMO, picking those issues which already have `Please take over` labelled PRs will be a great step in continuing stalled work, and it will also provide you a head start.





--
With regards,
Gagandeep Singh

Sachin Agarwal

unread,
Feb 4, 2020, 5:24:39 AM2/4/20
to sy...@googlegroups.com
Thanks Gagandeep for your valuable suggestion. I will start working on those issues marked as "Please Take Over" to get a head start.

But I have one concern, suppose I am working on some issue on my local machine and thinking of including a fix for it in my proposal. But after the application period has ended, suppose someone solves that issue during April, then including that issue in my proposal would be a waste.



Gagandeep Singh (B17CS021)

unread,
Feb 4, 2020, 5:30:02 AM2/4/20
to sy...@googlegroups.com
Yes, that's probably a concern. For that I would suggest you to first test whether an issue persists in the latest version of the master branch. Usually many old issues are fixed but are still open. One more thing you can do is to create WIP PRs instead of showing diffs. Though do make sure any active PR isn't working on an issue in which you are interested. In this way, you can start initialising your work a bit before the formal start of your project and your efforts will not go in vain. 
In fact cherry picking commits from some stalled PRs would be great to give credits to the original authors.


Sachin Agarwal

unread,
Feb 4, 2020, 5:46:18 AM2/4/20
to sy...@googlegroups.com
Yeah I was also thinking of a similar solution to cope this concern.

Moreover, I was thinking if it is possible to develop some tool such that when some PR is merged fixing some specific issue, then we also try to run all the existing issues and see if some additional issues are also getting resolved. 
And if any additional issue gets resolved then we close that issue automatically referencing that PR.

This way the number of pending issues will decrease and will increase efficiency. 


Aaron Meurer

unread,
Feb 4, 2020, 2:46:20 PM2/4/20
to sympy
Gagandeep brings up a good point which is that some issues can take
much longer to fix than you might initially expect. You would need to
address this possibility your proposal.

Aaron Meurer
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAM8%3DFcAaXn8uSfG_JHYTgV6_x%3DvJDKJ_p6dX-CNMPUA984odRw%40mail.gmail.com.

Jonty K.

unread,
Feb 4, 2020, 11:40:16 PM2/4/20
to sympy
I was also thinking of a similar proposal substance. Thanks for throwing some light into this topic.

Sachin Agarwal

unread,
Mar 7, 2020, 10:00:57 AM3/7/20
to sy...@googlegroups.com
Hi

I have decided to focus on the "series" module, since I am a bit familiar with its maths. 
When I was going through the issues labelled "series", I observed many issues where limit values are evaluated incorrectly by sympy. 
Hence, I have planned to improve the limit evaluation capabilities of sympy and resolve some other issues as well related to series module. 

Phase-1 plan:


These 4 issues are related to wrong evaluations of limit expressions done by sympy. As far as I have investigated, all these issues have their root cause in the series module itself. So I will try to fix these first.

Afterwards:


This is a WIP PR by me on the implementation of Raabe's Test (which was previously not there in the codebase). This is related to "concrete" module, but will definitely improve evaluations related to series module as well. Therefore, I will complete this next.

Finally: 


This is a long pending issue related to "series module". Lot of work needs to be done here, and all that needs to be done has been put in a comment by @jksuom here: https://github.com/sympy/sympy/issues/14068#issue-293993872.
So I will completely follow his suggestions and resolve this issue, which will also resolve some other issues linked to this issue like: https://github.com/sympy/sympy/issues/18008.

With this, I conclude my Phase-1 plan. 

WIll this be enough for Phase-1 or do I have to add some more issues to the list? 
 

With regards,
Sachin Agarwal

On Wed, Feb 5, 2020 at 10:10 AM Jonty K. <jontyk...@gmail.com> wrote:
I was also thinking of a similar proposal substance. Thanks for throwing some light into this topic.

--
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.

Gagandeep Singh (B17CS021)

unread,
Mar 9, 2020, 8:32:25 AM3/9/20
to sy...@googlegroups.com
Hi Sachin,

Though I am not very familiar with the series module. However, I would suggest to describe the mathematics in your proposal behind the fix if there is any. 
And what have you thought about the community bonding period? 
Regarding the sufficiency of the work, it's very difficult to comment right now. From my experience, it's better to plan extra work so that in future you have options if some of your ideas don't work out you can shift to others. 

Best wishes.

Sachin Agarwal

unread,
Mar 9, 2020, 8:53:31 AM3/9/20
to sy...@googlegroups.com
Hi

I will definitely describe the mathematics behind each fix in much detail in my proposal.
Thanks for the suggestion, I will plan extra work for backup. 

Regards
Sachin Agarwal

Reply all
Reply to author
Forward
0 new messages