[sympy] Discussion[GSoC 2020]: Project out of fixing issues

[Sachin Agarwal]

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.

-- 
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+unsubscr...@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.

[sympy] Re: Interested GSoC mentors please sign up

[Aaron Meurer]

I have filled out the GSoC org application. If anyone has any comments
on it please let me know before the deadline Wednesday.

https://github.com/sympy/sympy/wiki/GSoC-2020-Organization-Application

Aaron Meurer

On Mon, Feb 3, 2020 at 3:08 PM Aaron Meurer  wrote:
>
> Reminder for interested GSoC mentors to please add your name to
> https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#potential-mentors.
> Google does look at how many mentors are signed up, so doing so this
> week would be helpful (the org application deadline is Wednesday).
>
> Aaron Meurer
>
> On Tue, Jan 14, 2020 at 1:32 PM Aaron Meurer  wrote:
> >
> > It looks like the application questions are the same. I have started
> > the application here based on last year's
> > https://github.com/sympy/sympy/wiki/GSoC-2020-Organization-Application.
> > If anyone thinks we should change what is written there feel free to
> > edit it, or let me know what you think should change.
> >
> > Aaron Meurer
> >
> > On Tue, Jan 14, 2020 at 11:31 AM Aaron Meurer  wrote:
> > >
> > > Google has opened the organization applications for GSoC. If you are
> > > interested in mentoring this year, please add your name to
> > > https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#potential-mentors.
> > > If you were a student in a previous year I encourage you to consider
> > > mentoring this year.
> > >
> > > If you are a student interested in applying, please start here
> > > https://github.com/sympy/sympy/wiki/GSoC-2020-Student-Instructions
> > >
> > > I will also be working on the organization application. The deadline
> > > to submit it is February 5, which is in 3 weeks. I'll post more here
> > > once Google opens up the application and I can see if the questions
> > > are the same as last year.
> > >
> > > 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6JeCRBawvZLRPD4wBTR43EU3%3D_g1qtyD13TqgtMW3Y1Xg%40mail.gmail.com.

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

[Aaron Meurer]

On Mon, Feb 3, 2020 at 2:02 PM Oscar Benjamin
 wrote:
>
> On Mon, 3 Feb 2020 at 20:40, Aaron Meurer  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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/CAHVvXxTL9NAOp0MqhLTLVcuU%3DRQdTGgAz-fQ7Q5dFVX_tbQdFQ%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6K9i7rJs4vca6a7QXF1CAeK6fCo%2BGqfRo6teFtNcbCk%3DQ%40mail.gmail.com.

[sympy] Re: Interested GSoC mentors please sign up

[Aaron Meurer]

Reminder for interested GSoC mentors to please add your name to
https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#potential-mentors.
Google does look at how many mentors are signed up, so doing so this
week would be helpful (the org application deadline is Wednesday).

Aaron Meurer

On Tue, Jan 14, 2020 at 1:32 PM Aaron Meurer  wrote:
>
> It looks like the application questions are the same. I have started
> the application here based on last year's
> https://github.com/sympy/sympy/wiki/GSoC-2020-Organization-Application.
> If anyone thinks we should change what is written there feel free to
> edit it, or let me know what you think should change.
>
> Aaron Meurer
>
> On Tue, Jan 14, 2020 at 11:31 AM Aaron Meurer  wrote:
> >
> > Google has opened the organization applications for GSoC. If you are
> > interested in mentoring this year, please add your name to
> > https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#potential-mentors.
> > If you were a student in a previous year I encourage you to consider
> > mentoring this year.
> >
> > If you are a student interested in applying, please start here
> > https://github.com/sympy/sympy/wiki/GSoC-2020-Student-Instructions
> >
> > I will also be working on the organization application. The deadline
> > to submit it is February 5, which is in 3 weeks. I'll post more here
> > once Google opens up the application and I can see if the questions
> > are the same as last year.
> >
> > 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BWSS_DR6xQRNg8_DB2BwdrMAxNo8bQ%2BnRLYBqP5K8apA%40mail.gmail.com.

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

[Oscar Benjamin]

On Mon, 3 Feb 2020 at 20:40, Aaron Meurer  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxTL9NAOp0MqhLTLVcuU%3DRQdTGgAz-fQ7Q5dFVX_tbQdFQ%40mail.gmail.com.

[sympy] Introduction to Sympy Community

[purva chiniya]

Hello,
I am Purva Chiniya,a third year undergrad at IIT Roorkee.I am proficient in
programming languages and have a profound interest in mathematics and deep
learning.  I'm getting familiar with Sympy and I look forward to
contributing to it.
Thanks:)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAN4J6scNJf2Os0SZWk-Cq7SA69WaSVy8SL9TEhB1AALeXUer%2BA%40mail.gmail.com.

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

[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
 wrote:
>
> 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.
>
> On Mon, 3 Feb 2020 at 16:37, Jason Moore  wrote:
> >
> > 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
> >
> >
> > On Mon, Feb 3, 2020 at 6:16 AM Oscar Benjamin  
> > wrote:
> >>
> >> 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
> >> 

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

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

On Monday, February 3, 2020 at 7:28:14 PM UTC+5:30, Naman Nimmo wrote:
>
> 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
>
>
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/a8ae4fb2-2f72-41f4-befc-ad40e1dfd3f8%40googlegroups.com.

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

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

On Mon, 3 Feb 2020 at 16:37, Jason Moore  wrote:
>
> 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
>
>
> On Mon, Feb 3, 2020 at 6:16 AM Oscar Benjamin  
> wrote:
>>
>> 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
>>
>>
>> On Mon, 3 Feb 2020 at 13:58, Naman Nimmo  wrote:
>> >
>> > 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 

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

[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


On Mon, Feb 3, 2020 at 6:16 AM Oscar Benjamin 
wrote:

> 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
>
>
> On Mon, 3 Feb 2020 at 13:58, Naman Nimmo  wrote:
> >
> > 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
> >
> >
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CALkUZDniQkQkpnhDMivsRBwPSyFkCLgp4EYqZpuqhE%2BLAHwrew%40mail.gmail.com
> .
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxRnbKS%3DNpwmKA7JRtDO%3Du7d-kV50pzU5VXH34roA8m7Ww%40mail.gmail.com
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAP7f1Ah%2BdPnhAZm8U-%2B5v8j8PjFVna9Z6vT6PAbmaFVpHwG6oA%40mail.gmail.com.

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

[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


On Mon, 3 Feb 2020 at 13:58, Naman Nimmo  wrote:
>
> 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
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/CALkUZDniQkQkpnhDMivsRBwPSyFkCLgp4EYqZpuqhE%2BLAHwrew%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxRnbKS%3DNpwmKA7JRtDO%3Du7d-kV50pzU5VXH34roA8m7Ww%40mail.gmail.com.

[sympy] 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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CALkUZDniQkQkpnhDMivsRBwPSyFkCLgp4EYqZpuqhE%2BLAHwrew%40mail.gmail.com.