Re: [Discussion] GSoC 2020 -- Adding control package to sympy.physics

[Naman Nimmo]

Hi Everyone,

I'm Naman Gera, from the Electronics and Communication Engineering department at the Indian Institute of Information Technology, Guwahati. 

I started contributing to Sympy in December 2019 and ever since then, I've learned so many things. I have immense respect for this brilliantly talented open source community. They are some of the best coders I have seen, developing open-source (even on weekends!) because they believe in it. I have raised several PRs so as to solve some issues, and after each new PR, I learned something new and also understood that particular part of code. 

This summer, I would like to work on adding a control package to sympy.physics.  

> Initially, I would try to complete the work started in #17866

   I'll get the already implemented methods polished for merging. 

> After setting up the base classes (which are `StateSpaceModel` and `TransferFunctionModel`), I'll add some other methods like   `observability_matrix`, `observability_subspace`, `is_observable`, `series`, `parallel` (interconnection) and many more which can be useful for any Engineer attempting to solve a `control` problem.  

> The main aim would be to make the whole model symbolic. The package will use some of sympy's core classes like `Basic` so as to avoid rewriting code.  

> In the later part of the program, I'll also introduce some graphical analyses such as the Bode diagram, the Nyquist diagrams etc.. 

In the meantime, I'll take some inspiration from other CAS as much as possible. 

I'm also ready to implement some other ideas which the community or my potential mentor will suggest. 

Regards,

Naman

[Oscar Benjamin]

In general I question whether things like this need to be part of the
main sympy project rather than as another project on pypi that can be
installed separately. If we are going to include domain-specific
modules that are really just built on top of sympy then I think that
it is important that they are in some way contributing to the rest of
sympy.

For example the work that goes into creating this package could also
involve making improvements to things like dsolve and lambdify for
solving ODEs and analytically and numerically. The PR right now has
its own implementation for those things which I don't think is right.
If we need improvements to lambdify and dsolve so that they are more
useful for control theory then we should make those improvements which
will be of more general use than the control theory package itself.

Oscar

> --
> 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/CALkUZDniQkQkpnhDMivsRBwPSyFkCLgp4EYqZpuqhE%2BLAHwrew%40mail.gmail.com.

[Jason Moore]

Historically we've been very supportive of adding well designed domain specific packages. SymPy, in fact, was built originally with at least a partial desire for solving symbolic physics.

There are of course advantages and disadvantages in doing this.

My personal opinion is that we limit GSoC projects to projects that improve existing SymPy packages, instead of adding new packages (core or not). I'd love to see a GSoC proposal that just listed 50 issues in the tracker that would be fixed. But these new package ideas do get people excited to work on the project which has value in itself. Its also easier for newcomers to wrap their head around.

Jason

moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRnbKS%3DNpwmKA7JRtDO%3Du7d-kV50pzU5VXH34roA8m7Ww%40mail.gmail.com.

[Oscar Benjamin]

I don't know if this fits with GSOC rules but I wonder if a better
model might be for a GSOC project to do something like:

1. Create a new symcontrol project to go on PyPI.
2. Make improvements to the sympy codebase as needed in order to
implement the control theory calculations.
3. Add an examples notebook to sympy that shows simple control theory
calculations and links out to the third party package for a more
comprehensive approach.
4. Make the third party package tested on Travis.

(Perhaps we should test other downstream packages on Travis as well).

Otherwise there are a number of growing problems:

1. There are already 750k lines of code in sympy and much of it needs
improvement. Sympy desperately needs improvements in quality much more
than quantity.
2. New features and API are added all the time with very little
practical rationale.
3. Often features and the code that implements them are duplicated
because there is so much code that no one knows what already exists in
the codebase.
4. Major new features like new packages are implemented by relative
novices leaving more experienced contributors to pick through the
pieces later.
5. Many sympy packages are already broken, unused and unmaintained.

I am personally much more interested in GSOC proposals that improve
existing features. Modest improvements to e.g. concrete or dsolve for
systems would be more useful to users than new domain specific
packages.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1Ah%2BdPnhAZm8U-%2B5v8j8PjFVna9Z6vT6PAbmaFVpHwG6oA%40mail.gmail.com.

[Gagandeep Singh (B17CS021)]

IMO, adding new APIs to sympy which are present in other CAS is fine. In fact, sometimes various bugs are discovered while adding new APIs and their testing. For example `Range` now supports symbolic inputs to some extent which was needed while making extensions to stats module. 

Wolfram Alpha supports control systems as available at https://www.wolframalpha.com/examples/science-and-technology/engineering/control-systems/. However,  we should not hurry in adding a new package. A proper discussion should happen for designing the APIs, the framework of the package before proceeding towards the implementation.

It is true that there are a lot of bugs across various modules of SymPy which should be fixed. IMO, a GSoC project shouldn't be based on fixing a subset of issues, as it would be very difficult to allocate mentors to such a student. In addition, bugs can never disappear, they will always exist and in a difficult task like computer algebra they will be there with us. However, to tackle the problem of stalled issues, I would suggest that we can participate in programs like KWoC, RGSoC to name a few. They don't require any specific proposals to be submitted or mentors to be allocated and students participating in these programs usually fix issues which is kind of an open source sprint. I am getting familiar with such programs so that we can participate in them in future, if community agrees.

For the control package, I would say, the contributor should think how to use existing framework of SymPy(probably control package is very much related to ODEs, though I am not familiar with the literature) and use minimum lines of code to add this new functionality that again requires a lot of exploration and thinking. So, may be we can discuss and improve if anyone has thought of something. I would be happy to see a post describing the rough idea of APIs which would be better as we will be having a direction in which we can think.

[Aaron Meurer]

This isn't against the rules of GSoC. However, I would caution against
doing such a thing. Unless there are other people other than the GSoC
student who are willing to help develop and maintain the package after
the end of GSoC, the package has a very high risk of falling on the
wayside.

An advantage of something being in SymPy itself is that it
automatically gets full development support from the rest of the
package, for instance, the tests for it are always run on Travis, it
is included in any package-wide refactorings, and so on. I would say
at the very least if there were to be a GSoC project that creates a
new package, then that package should go on under sympy org on GitHub
(github.com/sympy/new-package), so that the whole SymPy development
team has access to it.

I can't speak to the control idea specifically because I'm not too
familiar with it. I would only say that it belongs in SymPy only if it
is symbolic in nature. I would also ask if it doesn't belong in SymPy
should it go in another pre-existing package, such as PyDy?

I agree that I would prefer to see GSoC projects that improve some of
the things that are already there. We already list "high priority"
ideas on the ideas page
https://github.com/sympy/sympy/wiki/gsoc-2020-ideas#high-priority.
Unfortunately, some of the projects that would have the most impact
would also be the most difficult. For instance, certain improvements
to the polys could have enormous impacts, but these require much
deeper mathematics than most other projects, as well as familiarity
with a large preexisting chunk of the codebase.

I think it is possible to make a project out of fixing issues. I've
seen similar projects from other organizations. The important thing is
that for such a project, it needs to be clearly stated what the goal
of the project is, so that it can be very clear if it should pass or
fail the evaluations. If any students are interested in this I think
we can work out what such a project should look like.

Aaron Meurer

On Mon, Feb 3, 2020 at 10:09 AM Oscar Benjamin

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

[Oscar Benjamin]

On Mon, 3 Feb 2020 at 20:40, Aaron Meurer <asme...@gmail.com> wrote:
>
> This isn't against the rules of GSoC. However, I would caution against
> doing such a thing. Unless there are other people other than the GSoC
> student who are willing to help develop and maintain the package after
> the end of GSoC, the package has a very high risk of falling on the
> wayside.

If no one is interested in maintaining the package then it will fall
by the wayside inside or outside of the main sympy repo. I think it's
better that happens outside so we don't end up with dead modules like
categories in the main repo.

> An advantage of something being in SymPy itself is that it
> automatically gets full development support from the rest of the
> package, for instance, the tests for it are always run on Travis,
> it is included in any package-wide refactorings, and so on.

Having carried out a few package-wide pieces of work I consider this a
disadvantage. Unmaintained code imposes a disproportionate burden when
trying to improve the rest of the codebase.

I did suggest that we could test 3rd party packages in Travis. I think
that's a good idea anyway so we have a better idea of the impact of
changes on downstream users. We should try to avoid breaking
downstream projects but I don't think we should spend time improving
unmaintained code.

> Unfortunately, some of the projects that would have the most impact
> would also be the most difficult. For instance, certain improvements
> to the polys could have enormous impacts, but these require much
> deeper mathematics than most other projects, as well as familiarity
> with a large preexisting chunk of the codebase.

Maybe we can break these down into more manageable pieces of work.

--
Oscar

[Aaron Meurer]

On Mon, Feb 3, 2020 at 2:02 PM Oscar Benjamin
<oscar.j....@gmail.com> wrote:
>
> On Mon, 3 Feb 2020 at 20:40, Aaron Meurer <asme...@gmail.com> wrote:
> >
> > This isn't against the rules of GSoC. However, I would caution against
> > doing such a thing. Unless there are other people other than the GSoC
> > student who are willing to help develop and maintain the package after
> > the end of GSoC, the package has a very high risk of falling on the
> > wayside.
>
> If no one is interested in maintaining the package then it will fall
> by the wayside inside or outside of the main sympy repo. I think it's
> better that happens outside so we don't end up with dead modules like
> categories in the main repo.

These are valid points. There are certain types of submodules in SymPy
which are leaves in the dependency graph. They are not used by other
submodules, and would not conceivably be used by other submodules in
the future. And they also aren't fundamental features of the package.
The arguments for including these submodules in SymPy are much weaker
than for other more "standard" submodules.

Also I should point out that "control theory" is currently an idea on
the GSoC ideas page. So that does imply that it's in scope for a
project.

>
> > An advantage of something being in SymPy itself is that it
> > automatically gets full development support from the rest of the
> > package, for instance, the tests for it are always run on Travis,
> > it is included in any package-wide refactorings, and so on.
>
> Having carried out a few package-wide pieces of work I consider this a
> disadvantage. Unmaintained code imposes a disproportionate burden when
> trying to improve the rest of the codebase.
>
> I did suggest that we could test 3rd party packages in Travis. I think
> that's a good idea anyway so we have a better idea of the impact of
> changes on downstream users. We should try to avoid breaking
> downstream projects but I don't think we should spend time improving
> unmaintained code.

Running integration tests on downstream dependencies is a good idea.
Some people from other projects started working on some tooling for
this, but I don't think it is completed yet.
https://github.com/numba/texasbbq

>
> > Unfortunately, some of the projects that would have the most impact
> > would also be the most difficult. For instance, certain improvements
> > to the polys could have enormous impacts, but these require much
> > deeper mathematics than most other projects, as well as familiarity
> > with a large preexisting chunk of the codebase.
>
> Maybe we can break these down into more manageable pieces of work.

We could definitely make some the ideas on the ideas page more
approachable. A GSoC project for many of the ideas would necessarily
only be some subset of the idea, with the full idea needing to be
split across multiple summers' projects or work outside of GSoC.
Another issue with some of these projects is that there aren't many
people who can mentor them.

Aaron Meurer

>
> --
> Oscar

>
> --
> 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/CAHVvXxTL9NAOp0MqhLTLVcuU%3DRQdTGgAz-fQ7Q5dFVX_tbQdFQ%40mail.gmail.com.

[Naman Nimmo]

Thanks for confirming the current scope of adding such type of package. I only started working on this because of the current stalling PRs: #12189 and #17866

"Control theory" is currently listed on the GSoC ideas page. So, I thought it's in scope for a project spread over the summer. 

And also because of these pieces of evidence: [1], [2]

Hopefully, now I'll pick up any idea which aims to improve the already existing sympy packages. 

[Jason Moore]

Naman,

If you are excited about the control package, I think you should work on it. It is a very nice addition that an electrical engineering student is ideal to work on.

Don't let this broader conversation happening here discourage you. We shouldn't have hijacked your thread.

I'm very supportive of a control package being added to SymPy. Many people over the years have asked for it and no one has made an external one of any popularity.

Jason

moorepants.info
+01 530-601-9791

--

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/CALkUZDmkP7uzNRTn%3DLDw3BB8fNTKPN8u_ydG7xexwNbJ-wavFw%40mail.gmail.com.

[Naman Nimmo]

Thanks, Jason. 

I'm excited about this topic. I don't usually get to implement the things I learn in college, so it's just pure theory.. and it gets kind of boring. This topic is related to my major so that would be like a cherry on the top. I hope my coding skills will take a giant leap and I'll try my best to write maintainable code. 

I'll also try to implement some of the ideas discussed in this thread before and work on adding such a package swiftly.  

I hope the further discussion can be done on the issue that I had opened before. 

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AgBoO2w4Bn%2BB2nreoOewD53Eu%2B%2BhVH2XVum1Ea9ovAG%2Bw%40mail.gmail.com.

[Aaron Meurer]

I agree with Jason. The idea is on the ideas page so it is valid for GSoC.

If the proposal gets accepted and we decide that the package is better
suited as a separate library, we can do that. But this shouldn't
impact the proposal or the likelihood of the project being accepted.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AgBoO2w4Bn%2BB2nreoOewD53Eu%2B%2BhVH2XVum1Ea9ovAG%2Bw%40mail.gmail.com.

[Oscar Benjamin]

Hi Naman,

Sorry I wasn't objecting to the proposal. If this is something that
you are interested in then I think it is a good addition.

Oscar

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6LBEXNhk%3DaB%2B%2B9bPOW4_01z7dh3WDUYyPZwB6Ceu6Neew%40mail.gmail.com.

[David Bailey]

Hi everyone,

The plotting.plot and plotting.plot3d  functions are very nice, and produce good looking output, but I can't see any way to create arbitrary plots that would not have axes, but would be composed of lines, points, filled regions, and text positioned as desired, for example:

A circuit diagram

Other engineering diagrams

Fractals

Organic chemical structures

I am sure there are packages out there to do any one of those tasks, but what do those packages use to generate their plotting output?

Since plot() returns a plot object that can be subsequently rendered, I have wondered if the answer is to actually construct a plot object 'by hand'.

Any hints would be welcome,

David

[Oscar Benjamin]

The sympy plotting module is mostly a wrapper around matplotlib. You
can use matplotlib directly for a lot of the things you suggest.

I think it would be better if sympy's plotting module didn't try to
wrap up other libraries as "backends" but instead focussed on
documenting how it should be used in combination with the underlying
plotting libraries.

> --
> 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/5bf2e639-f9e7-caff-2802-917979d1ff10%40dbailey.co.uk.

[Gagandeep Singh (B17CS021)]

IMO, Oscar is suggesting a nice idea. Using wrappers for the APIs already existing for plotting just slows down the computation of overall results. If the SymPy wrappers for plotting module aren't making any difference in the algorithms for plotting then may be we can remove them though it would be a drastic change. Other approach can be to stop extending it further and just focussing on fixing the current bugs. 

My views are based on a high level idea of plotting module, someone with more experience should take the decision regarding this.

Thanks.

With Regards,
Gagandeep Singh
Github - https://www.github.com/czgdp1807
LinkedIn - https://www.linkedin.com/in/czgdp1807

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxT_8H-0yESmso8eZ%2BOqtQBHOG-_Q6DK4fUrDirre6pS1g%40mail.gmail.com.

[David Bailey]

On 08/02/2020 12:35, Gagandeep Singh (B17CS021) wrote:

IMO, Oscar is suggesting a nice idea. Using wrappers for the APIs already existing for plotting just slows down the computation of overall results. If the SymPy wrappers for plotting module aren't making any difference in the algorithms for plotting then may be we can remove them though it would be a drastic change. Other approach can be to stop extending it further and just focussing on fixing the current bugs. 

My views are based on a high level idea of plotting module, someone with more experience should take the decision regarding this.

Thanks Oscar and Gagandeep,

Looking at the MatplotLib site, I see most of the examples have axes, but gratifyingly there are a few that don't. There is even a Mandelbrot example (without axes) so if you can plot that, I imagine you can do just about anything!

I don't think it would be a good idea to make drastic changes to SymPy - because that just creates confusion, and stability counts for a lot - but it might be nice to change the documentation to point directly at Matplotlib, because otherwise users get the impression that the plotting features in SymPy are much less complete than they really are.

David

[Aaron Meurer]

You can plot pretty much anything with matplotlib if you know what you
are doing. It is an extremely versatile library. The gallery shows the
sorts of things that are possible https://matplotlib.org/gallery.html.
Removing the axes from a plot should be a trivial thing to do.

The SymPy plotting functions are mainly designed as a convenience.
Generally you can also manually wrap the expression with `lambdify`
and pass it a `linspace`. They do do some nice things like adaptive
sampling which aren't trivial to do manually. Also some functions such
as the implicit plotting functions implement nontrivial algorithms.

The matplotlib developers have also expressed to me that they would
like to add function plotting directly into matplotlib. That would
make plotting a SymPy expression directly with matplotlib much simpler
without using the SymPy wrappers (it would just be a question of
calling `lambdify` first). I would be in favor of moving logic that
isn't specific to symbolics away from SymPy and into matplotlib.

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/37e594cf-2439-0e55-a7f9-8aeedaa2f6a7%40dbailey.co.uk.

[Jonty K.]

That's true....i know little bit about matplolib, but its much powerful than its it appears.

[David Bailey]

On 08/02/2020 12:21, Oscar Benjamin wrote:

The sympy plotting module is mostly a wrapper around matplotlib. You
can use matplotlib directly for a lot of the things you suggest.

I think it would be better if sympy's plotting module didn't try to
wrap up other libraries as "backends" but instead focussed on
documenting how it should be used in combination with the underlying
plotting libraries.

Hi everyone,

I have followed the advice to use matplotlib from several members of the group. It certainly looks like the right way to proceed, but I can't get even the simplest Matplotlib program to actually produce a plot.

import matplotlib
import matplotlib.pyplot as plt
import numpy as np

# Data for plotting
t = np.arange(0.0, 2.0, 0.01)
s = 1 + np.sin(2 * np.pi * t)

fig, ax = plt.subplots()
ax.plot(t, s)

ax.set(xlabel='time (s)', ylabel='voltage (mV)',
       title='About as simple as it gets, folks')
ax.grid()

fig.savefig("test.png")
plt.show()

It reports: ModuleNotFoundError: No module named 'tkinter'

However when I try to install that module, I get:

 ERROR: Could not find a version that satisfies the requirement tkinter (from versions: none)
ERROR: No matching distribution found for tkinter

This is the same python instalation that is running Sympy plots successfully, though only after I followed the advice of someone here to use

matplotlib.use("Qt5Agg")

I am running SymPy 1.5 and Python 3.7 under 64-bit Windows 10.

Thanks,

David

[Aaron Meurer]

Matplotlib has several backends, some of which work better than
others. The use() function changes the backend.

I would also recommend installing matplotlib via Anaconda. That will
come with all the things you need to show plots.

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/8f2d8d4f-ddb5-500b-7df4-1cdfaf42e3d0%40dbailey.co.uk.

[David Bailey]

On 10/02/2020 18:21, Aaron Meurer wrote:

Matplotlib has several backends, some of which work better than
others. The use() function changes the backend.

I would also recommend installing matplotlib via Anaconda. That will
come with all the things you need to show plots.

Thanks Aaron, but since Matplotlib is presumably operating correctly with SymPy, I am concerned that if re-installing it changes something, it won't then work with SymPy!

Incidentally, I think the pitfalls in actually getting plotting running under Windows, would make an excellent subject for the new documentation you are planning.

David

[Aaron Meurer]

SymPy also comes with Anaconda. Anaconda basically installs a
completely separate Python installation, but as long as the same
installation includes SymPy and matplotlib they will be able to work
with each other.

The issue is that things like tkinter or qt that are needed for
matplotlib plotting are not Python packages but rather C libraries, so
pip cannot install them. The conda package manager that comes with
Anaconda is much better at installing those things, especially on
Windows. I would also suggest using conda-forge, which includes even
more packages.

I would also mention that if you don't care about interaction, the
easiest way to use matplotlib is in the Jupyter notebook with
'%matplotlib inline'.

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/54097b1a-ab98-1aa9-fac5-8582c4315d3c%40dbailey.co.uk.

[David Bailey]

Thanks Aaron, but I took a look at Anaconda, hoping that it was a better version of pip, but it is a huge sprawling package weighing in at almost 1 Gigabyte of storage - even in its compressed form. It seems to want to take over my entire python experience. I'd really like to know how SymPy manages to use Matplotlib to create plots, which it does correctly using  my current python setup, and which would presumably solve the problem.

I have already tried executing matplotlib.use("Qt5Agg"), which Oscar recommended some time back and which got SymPy plots working nicely under 64-bit Windows 10.

I chose to test a very simple test program from the Matplotlib examples:

import matplotlib
import matplotlib.pyplot as plt
import numpy as np

# Data for plotting
t = np.arange(0.0, 2.0, 0.01)
s = 1 + np.sin(2 * np.pi * t)

fig, ax = plt.subplots()
ax.plot(t, s)

ax.set(xlabel='time (s)', ylabel='voltage (mV)',
       title='About as simple as it gets, folks')
ax.grid()

fig.savefig("test.png")
plt.show()

Best wishes,

David

[Aaron Meurer]

You can also install miniconda and use conda to install only the
packages you need. Anaconda is just a pre-packaging of the most useful
packages so you don't have to install most things.

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/92ad4b45-be3d-2a35-8ba1-846f6aa072d7%40dbailey.co.uk.

[David Bailey]

A short while ago, I wrote about the creation of arbitrary diagrams, as opposed to plots. Matplotlib was recommended, but I was having difficulty making it work.

I resolved this problem, and I think it might be of some interest.

Some time ago, Oscar recommended that I use "matplotlib.use("Qt5Agg") in order to make SymPy plots work - which they now do. However, this trick still did not permit a Matplotlib program to execute. However, it turns out that if I do any plot using SymPy, e.g. sympy.plot(x**2,show=False)

it connects something that then lets matplotlib execute matplotlib code.

David

[Naman Nimmo]

Hi, 

I have completed the first draft of my GSoC Application. I know it's too early right now but I had discussed the implementation plan in Feb first week and now it took me a week to finally write it down. 

Some small tweaks might be needed, but I think this is ready from my side. Please review this and drop comments if you feel any changes are required. Thanks! 

Link to my Application:    https://docs.google.com/document/d/1Sifc2injFLrdsSfG7FCN0PN3ZRrwRXCaKVFUcjME2Kg/edit?usp=sharing

Naman Gera

On Tue, Feb 4, 2020 at 7:17 PM Jason Moore <moore...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AgBoO2w4Bn%2BB2nreoOewD53Eu%2B%2BhVH2XVum1Ea9ovAG%2Bw%40mail.gmail.com.

[Naman Nimmo]

The application period has started for GSoC. Is it okay to submit this application or should I change something in it? I haven't received any feedback on this. 

[Naman Nimmo]

Jason,

I have uploaded my final proposal on the GSoC website. But Google allows us to edit our proposals before the deadline, so if you have any suggestions or improvements, please let me know. 

https://docs.google.com/document/d/1Sifc2injFLrdsSfG7FCN0PN3ZRrwRXCaKVFUcjME2Kg/edit?usp=sharing

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AgBoO2w4Bn%2BB2nreoOewD53Eu%2B%2BhVH2XVum1Ea9ovAG%2Bw%40mail.gmail.com.