Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

By review I mean please provide feedback so that I can improve my proposal
before submitting final proposal. I think I should share it in fresh thread
so that more people can give feedback along with your feedback.

Sudeep Sidhu

On Thu, Apr 1, 2021 at 12:45 PM Jason Moore  wrote:

> Sudeep,
>
> I do not plan to review any GSoC proposals until we are in the actual
> review process. If you have specific questions you can ask on the mailing
> list and we all well answer as we have time.
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAJUjCNmMM39wh43_uKdcvs73-c6VUcys%2BgG5iB5OjxR%3DfSQ7Qw%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

I do not plan to review any GSoC proposals until we are in the actual
review process. If you have specific questions you can ask on the mailing
list and we all well answer as we have time.

Jason
moorepants.info
+01 530-601-9791


On Thu, Apr 1, 2021 at 8:56 AM Sudeep Sidhu 
wrote:

> Jason,
>
> I had submitted my GSoC draft proposal a few days back on official GSoC
> page, since I'm left with just 12 days to submit the final proposal's pdf I
> was really hoping you could review my proposal so that I can submit the
> final proposal comfortably before the deadline.
> Sudeep Sidhu GSoC Proposal
> 
>
> Sudeep Sidhu
>
> --
> 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/CAJUjCN%3D2tJ35-q8TDtP9ynuOL12veroncDqXgX4rrq1d_nP4dw%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/CAP7f1Ai3fZp6V%2BrZHqG%2B9kGHAJ_sTy9f1QmZDF8Vik5bBbXv_g%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I had submitted my GSoC draft proposal a few days back on official GSoC
page, since I'm left with just 12 days to submit the final proposal's pdf I
was really hoping you could review my proposal so that I can submit the
final proposal comfortably before the deadline.
Sudeep Sidhu GSoC Proposal


Sudeep Sidhu

-- 
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/CAJUjCN%3D2tJ35-q8TDtP9ynuOL12veroncDqXgX4rrq1d_nP4dw%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

> The exact details of what you would do if your proposal was accepted
> are less important than showing that you can make substantial
> improvements in general. It's very likely that if any proposal based
> on DomainMatrix is accepted then the details of what would get
> implemented would end up different from any proposal made now because
> part of the work is in identifying what should be done.

Thanks for clarifying this. I am reasonably familiar with Jordan Canonical 
Form and 
Matrix exponential and I think I can implement them. I'll add these to my 
proposal instead
of QR and Cholesky Decompositions.

Thanks

Kartik
On Sunday, 21 March 2021 at 4:45:10 pm UTC+5:30 Oscar wrote:

> On Sun, 21 Mar 2021 at 10:51, Kartik Sethi  wrote:
> >
> > There is already a PR #21120 which is trying to implement DomainScalar 
> class
> > which is why I deleted that message.
>
> Personally I read these messages as an email mailing list so deleting
> a message is unnoticeable to me (you can't delete an email from my
> inbox).
>
> > Should I add Jordan Normal Form to my
> > Proposal instead assuming that DomainScalar would be implemented by then 
> or should
> > I add improvements to DomainScalar as one of the objectives in my 
> proposal.
>
> I think that improving Jordan form and matrix exponential is
> definitely something to do since currently the main usage of
> DomainMatrix outside of linsolve is eigenvects and it clearly shows a
> big improvement there. The Jordan form calculation is very similar and
> is actually used more widely e.g. for computing the matrix exponential
> and for solving systems of ODEs so applying the same improvement there
> should be a high priority for DomainMatrix.
>
> > I am a little confused about this.
>
> The most important thing for a GSOC proposal is to demonstrate that:
>
> 1) You understand the parts of the codebase you are proposing to work
> on and have ideas to improve things.
> 2) There are substantial improvements to be made that are of value to 
> sympy.
> 3) You individually are capable of implementing *some* of those
> substantial improvements.
>
> The exact details of what you would do if your proposal was accepted
> are less important than showing that you can make substantial
> improvements in general. It's very likely that if any proposal based
> on DomainMatrix is accepted then the details of what would get
> implemented would end up different from any proposal made now because
> part of the work is in identifying what should be done.
>
> 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/e5a998cc-c272-4b70-93dd-109806c9cadcn%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Sun, 21 Mar 2021 at 10:51, Kartik Sethi  wrote:
>
> There is already a PR #21120 which is trying to implement DomainScalar class
> which is why I deleted that message.

Personally I read these messages as an email mailing list so deleting
a message is unnoticeable to me (you can't delete an email from my
inbox).

> Should I add Jordan Normal Form to my
> Proposal instead assuming that DomainScalar would be implemented by then or 
> should
> I add improvements to DomainScalar as one of the objectives in my proposal.

I think that improving Jordan form and matrix exponential is
definitely something to do since currently the main usage of
DomainMatrix outside of linsolve is eigenvects and it clearly shows a
big improvement there. The Jordan form calculation is very similar and
is actually used more widely e.g. for computing the matrix exponential
and for solving systems of ODEs so applying the same improvement there
should be a high priority for DomainMatrix.

> I am a little confused about this.

The most important thing for a GSOC proposal is to demonstrate that:

1) You understand the parts of the codebase you are proposing to work
on and have ideas to improve things.
2) There are substantial improvements to be made that are of value to sympy.
3) You individually are capable of implementing *some* of those
substantial improvements.

The exact details of what you would do if your proposal was accepted
are less important than showing that you can make substantial
improvements in general. It's very likely that if any proposal based
on DomainMatrix is accepted then the details of what would get
implemented would end up different from any proposal made now because
part of the work is in identifying what should be done.

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/CAHVvXxSKppvNz24hmc0J7V5PoU0Y2w264_bSEDkZc_LvJss2TQ%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

There is already a PR #21120  which 
is trying to implement DomainScalar class 
which is why I deleted that message. Should I add Jordan Normal Form to my 
Proposal instead assuming that DomainScalar would be implemented by then or 
should 
I add improvements to DomainScalar as one of the objectives in my proposal.

I am a little confused about this.

Kartik 
On Sunday, 21 March 2021 at 3:23:48 pm UTC+5:30 Oscar wrote:

> On Sun, 21 Mar 2021 at 07:48, Kartik Sethi  wrote:
> >
> > S.Y. Lee, in #20987 It is outlined that there is a need to implement a 
> DomainScalar class, which would help speed up eigenvector computation.
> > I think that would be a more fruitful endeavour instead of working on 
> these decompositions.
>
> The eigenvector calculation is already speeded up on master although
> it's possible that further improvements can be made. What DomainScalar
> would potentially do is make it easier to write the code for something
> like that which would be useful for extending the same approach
> elsewhere e.g. to use DomainMatrix for the Jordan normal form which is
> a very similar calculation to the eigenvector calculation.
>
>
> 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/04afb95b-d42e-410e-99ee-351ba309e206n%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Sun, 21 Mar 2021 at 07:48, Kartik Sethi  wrote:
>
> S.Y. Lee,  in #20987 It is outlined that there is a need to implement a 
> DomainScalar class, which would help speed up eigenvector computation.
> I think that would be a more fruitful endeavour instead of working on  these 
> decompositions.

The eigenvector calculation is already speeded up on master although
it's possible that further improvements can be made. What DomainScalar
would potentially do is make it easier to write the code for something
like that which would be useful for extending the same approach
elsewhere e.g. to use DomainMatrix for the Jordan normal form which is
a very similar calculation to the eigenvector calculation.


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/CAHVvXxSf3LsxMM9nWM-YzZAzVau%3Dke0-3Fc14N%2Bm88gme%3DiTeA%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

S.Y. Lee,  in #20987  It is 
outlined that there is a need to implement a DomainScalar class, which 
would help speed up eigenvector computation. 
I think that would be a more fruitful endeavour instead of working on  
these decompositions. 

What do you think?

On Saturday, 20 March 2021 at 6:26:07 pm UTC+5:30 Kartik Sethi wrote:

> >  Mind me jumping in the discussion for this, but I have some comments
> Not at all.
> S.Y. Lee what do you suggest I work on instead of these decompositions. I 
> have added some fraction-free algorithms which were listed on #20987 
> . I could not find any 
> paper/website for 
> Paterson-Stockmayer inverse so I went with decompositions instead. 
>
> I am open to any suggestions 
> On Saturday, 20 March 2021 at 5:53:46 pm UTC+5:30 syle...@gmail.com wrote:
>
>> Mind me jumping in the discussion for this, but I have some comments
>>
>> The important aspect of DomainMatrix is that the computations should be 
>> 'rational' (which can be generalized up to 'multivariate rational function 
>> field')
>> So I don't think that you can implement cholesky or hessenberg or 
>> householder easily.
>> I have also though about adjoining the new square roots as algebraic 
>> extensions,
>> But I'm afraid that you can't anticipate the speed just like numeric 
>> cases even if this approach is taken.
>> On Sunday, March 14, 2021 at 10:16:15 PM UTC+9 kartik...@gmail.com wrote:
>>
>>> Oscar Benjamin, Have you had a chance to review my GSoC application 
>>> draft? 
>>> I've posted it here 
>>> https://github.com/sympy/sympy/wiki/GSoC-2021-Current-Applications
>>>
>>> On Friday, 12 March 2021 at 11:44:49 am UTC+5:30 Kartik Sethi wrote:
>>>
 Oscar Benjamin, could you review this first draft of my proposal. 
 Please let me know if you feel that I should focus 
 on some other topics/ algorithms in DomainMatrix instead of the ones 
 chosen by me. 

 GSoC 2021 Proposal 
 
 On Tuesday, 9 March 2021 at 6:49:29 am UTC+5:30 Oscar wrote:

> On Mon, 8 Mar 2021 at 16:00, Kartik Sethi  
> wrote: 
> > 
> > Oscar Benjamin, what if someone else also puts up this same proposal 
> to improve the DomainMatrix module for Gsoc. How does sympy decide which 
> person will work on it. 
>
> There is plenty more work to do on DomainMatrix than one person could 
> do in a single GSOC project so there could be two people doing related 
> projects on this although we do have limits on how many projects a 
> single mentor could supervise. I am not the only person who could 
> mentor a project on DomainMatrix though and it's also possible that I 
> would mentor a project on something else instead such as ODEs. 
>
> We will look at all applications and decide which to accept based on a 
> number of factors. The two major factors are the priority of the 
> project and the quality of the application. I think that DomainMatrix 
> is high priority but if there are stronger proposals for other 
> projects then it is possible that no proposal for DomainMatrix would 
> be accepted. 
>
> I suggest not to overthink this. The main thing is just to have a good 
> application that is well motivated and shows clear understanding of 
> the work to be done. 
>
> -- 
> 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/b966cd23-2e9f-4e98-a1be-65e640ad05dcn%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

>  Mind me jumping in the discussion for this, but I have some comments
Not at all.
S.Y. Lee what do you suggest I work on instead of these decompositions. I 
have added some fraction-free algorithms which were listed on #20987 
. I could not find any 
paper/website for 
Paterson-Stockmayer inverse so I went with decompositions instead. 

I am open to any suggestions 
On Saturday, 20 March 2021 at 5:53:46 pm UTC+5:30 syle...@gmail.com wrote:

> Mind me jumping in the discussion for this, but I have some comments
>
> The important aspect of DomainMatrix is that the computations should be 
> 'rational' (which can be generalized up to 'multivariate rational function 
> field')
> So I don't think that you can implement cholesky or hessenberg or 
> householder easily.
> I have also though about adjoining the new square roots as algebraic 
> extensions,
> But I'm afraid that you can't anticipate the speed just like numeric cases 
> even if this approach is taken.
> On Sunday, March 14, 2021 at 10:16:15 PM UTC+9 kartik...@gmail.com wrote:
>
>> Oscar Benjamin, Have you had a chance to review my GSoC application 
>> draft? 
>> I've posted it here 
>> https://github.com/sympy/sympy/wiki/GSoC-2021-Current-Applications
>>
>> On Friday, 12 March 2021 at 11:44:49 am UTC+5:30 Kartik Sethi wrote:
>>
>>> Oscar Benjamin, could you review this first draft of my proposal. Please 
>>> let me know if you feel that I should focus 
>>> on some other topics/ algorithms in DomainMatrix instead of the ones 
>>> chosen by me. 
>>>
>>> GSoC 2021 Proposal 
>>> 
>>> On Tuesday, 9 March 2021 at 6:49:29 am UTC+5:30 Oscar wrote:
>>>
 On Mon, 8 Mar 2021 at 16:00, Kartik Sethi  wrote: 
 > 
 > Oscar Benjamin, what if someone else also puts up this same proposal 
 to improve the DomainMatrix module for Gsoc. How does sympy decide which 
 person will work on it. 

 There is plenty more work to do on DomainMatrix than one person could 
 do in a single GSOC project so there could be two people doing related 
 projects on this although we do have limits on how many projects a 
 single mentor could supervise. I am not the only person who could 
 mentor a project on DomainMatrix though and it's also possible that I 
 would mentor a project on something else instead such as ODEs. 

 We will look at all applications and decide which to accept based on a 
 number of factors. The two major factors are the priority of the 
 project and the quality of the application. I think that DomainMatrix 
 is high priority but if there are stronger proposals for other 
 projects then it is possible that no proposal for DomainMatrix would 
 be accepted. 

 I suggest not to overthink this. The main thing is just to have a good 
 application that is well motivated and shows clear understanding of 
 the work to be done. 

 -- 
 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/8ea4784a-64fd-4e79-9f78-824ed3f13b44n%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[S.Y. Lee]

Mind me jumping in the discussion for this, but I have some comments

The important aspect of DomainMatrix is that the computations should be 
'rational' (which can be generalized up to 'multivariate rational function 
field')
So I don't think that you can implement cholesky or hessenberg or 
householder easily.
I have also though about adjoining the new square roots as algebraic 
extensions,
But I'm afraid that you can't anticipate the speed just like numeric cases 
even if this approach is taken.
On Sunday, March 14, 2021 at 10:16:15 PM UTC+9 kartik...@gmail.com wrote:

> Oscar Benjamin, Have you had a chance to review my GSoC application draft? 
> I've posted it here 
> https://github.com/sympy/sympy/wiki/GSoC-2021-Current-Applications
>
> On Friday, 12 March 2021 at 11:44:49 am UTC+5:30 Kartik Sethi wrote:
>
>> Oscar Benjamin, could you review this first draft of my proposal. Please 
>> let me know if you feel that I should focus 
>> on some other topics/ algorithms in DomainMatrix instead of the ones 
>> chosen by me. 
>>
>> GSoC 2021 Proposal 
>> 
>> On Tuesday, 9 March 2021 at 6:49:29 am UTC+5:30 Oscar wrote:
>>
>>> On Mon, 8 Mar 2021 at 16:00, Kartik Sethi  wrote: 
>>> > 
>>> > Oscar Benjamin, what if someone else also puts up this same proposal 
>>> to improve the DomainMatrix module for Gsoc. How does sympy decide which 
>>> person will work on it. 
>>>
>>> There is plenty more work to do on DomainMatrix than one person could 
>>> do in a single GSOC project so there could be two people doing related 
>>> projects on this although we do have limits on how many projects a 
>>> single mentor could supervise. I am not the only person who could 
>>> mentor a project on DomainMatrix though and it's also possible that I 
>>> would mentor a project on something else instead such as ODEs. 
>>>
>>> We will look at all applications and decide which to accept based on a 
>>> number of factors. The two major factors are the priority of the 
>>> project and the quality of the application. I think that DomainMatrix 
>>> is high priority but if there are stronger proposals for other 
>>> projects then it is possible that no proposal for DomainMatrix would 
>>> be accepted. 
>>>
>>> I suggest not to overthink this. The main thing is just to have a good 
>>> application that is well motivated and shows clear understanding of 
>>> the work to be done. 
>>>
>>> -- 
>>> 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/fc5a11e2-e35e-4531-8d7d-6eec25865fc6n%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Oscar Benjamin, Have you had a chance to review my GSoC application draft? 
I've posted it here 
https://github.com/sympy/sympy/wiki/GSoC-2021-Current-Applications

On Friday, 12 March 2021 at 11:44:49 am UTC+5:30 Kartik Sethi wrote:

> Oscar Benjamin, could you review this first draft of my proposal. Please 
> let me know if you feel that I should focus 
> on some other topics/ algorithms in DomainMatrix instead of the ones 
> chosen by me. 
>
> GSoC 2021 Proposal 
> 
> On Tuesday, 9 March 2021 at 6:49:29 am UTC+5:30 Oscar wrote:
>
>> On Mon, 8 Mar 2021 at 16:00, Kartik Sethi  wrote:
>> >
>> > Oscar Benjamin, what if someone else also puts up this same proposal to 
>> improve the DomainMatrix module for Gsoc. How does sympy decide which 
>> person will work on it.
>>
>> There is plenty more work to do on DomainMatrix than one person could
>> do in a single GSOC project so there could be two people doing related
>> projects on this although we do have limits on how many projects a
>> single mentor could supervise. I am not the only person who could
>> mentor a project on DomainMatrix though and it's also possible that I
>> would mentor a project on something else instead such as ODEs.
>>
>> We will look at all applications and decide which to accept based on a
>> number of factors. The two major factors are the priority of the
>> project and the quality of the application. I think that DomainMatrix
>> is high priority but if there are stronger proposals for other
>> projects then it is possible that no proposal for DomainMatrix would
>> be accepted.
>>
>> I suggest not to overthink this. The main thing is just to have a good
>> application that is well motivated and shows clear understanding of
>> the work to be done.
>>
>> --
>> 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/fa9f7dae-6131-4fc5-8723-668a8ed9f2a8n%40googlegroups.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

I have shared my draft proposal at the specified wiki page. Please review
so that I can improve it as much as I can.

Sudeep Sidhu

-- 
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/CAJUjCNksZNa3m8zCMM0U5H0ZYno4NUSyY%2BMrXpPXE-ye50t94w%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Thanks Naman

Sudeep Sidhu

On Sat, 13 Mar 2021, 21:42 Naman Nimmo,  wrote:

>
> *So shall I create a new wiki page for 2021 proposals on sympy repository
>> and share my google docs link there as done in previous years?*
>>
>
> GSoC 2021 current applications can be added here:
> https://github.com/sympy/sympy/wiki/GSoC-2021-Current-Applications
>
> Regards,
>
> --
>
> On Sat, 13 Mar 2021, 16:58 Jason Moore,  wrote:
>>
>>> Sudeep,
>>>
>>> Please see the GSoC instructions:
>>> https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions. We
>>> recommend the wiki.
>>>
>>> Jason
>>> moorepants.info
>>> +01 530-601-9791
>>>
>>>
>>> On Fri, Mar 12, 2021 at 1:39 PM Sudeep Sidhu 
>>> wrote:
>>>
 Jason,

 I have prepared my draft proposal for GSoC'21. Where shall I share it
 so that you and others can review it.

 Sudeep Sidhu

 --
 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/CAJUjCN%3DNo%2BonpynE4PqsL%3Dk_%2BZF1e9-_kWr%3Do9ivgf%2B8xr17qg%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/CAP7f1AirRMUN%3DYbdbjtTiuvwg3isUSSP28ziywQ6toLc_YZt-Q%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/CAJUjCNkDNmjhA%3DD85C9NBfWiS02S4Tkf-8vkf6hh3tDws_vqyA%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/CALkUZDmtmaDrQd2JpLSEyG7uSWXpqdTYhhvkXUrHLXDEZmakQQ%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/CAJUjCNm_zNdxZy8NGXhKK9Qxjy5K-9BSkbi99NGwVuGgnod5FQ%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Naman Nimmo]

> *So shall I create a new wiki page for 2021 proposals on sympy repository
> and share my google docs link there as done in previous years?*
>

GSoC 2021 current applications can be added here:
https://github.com/sympy/sympy/wiki/GSoC-2021-Current-Applications

Regards,

--

On Sat, 13 Mar 2021, 16:58 Jason Moore,  wrote:
>
>> Sudeep,
>>
>> Please see the GSoC instructions:
>> https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions. We
>> recommend the wiki.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Fri, Mar 12, 2021 at 1:39 PM Sudeep Sidhu 
>> wrote:
>>
>>> Jason,
>>>
>>> I have prepared my draft proposal for GSoC'21. Where shall I share it so
>>> that you and others can review it.
>>>
>>> Sudeep Sidhu
>>>
>>> --
>>> 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/CAJUjCN%3DNo%2BonpynE4PqsL%3Dk_%2BZF1e9-_kWr%3Do9ivgf%2B8xr17qg%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/CAP7f1AirRMUN%3DYbdbjtTiuvwg3isUSSP28ziywQ6toLc_YZt-Q%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/CAJUjCNkDNmjhA%3DD85C9NBfWiS02S4Tkf-8vkf6hh3tDws_vqyA%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/CALkUZDmtmaDrQd2JpLSEyG7uSWXpqdTYhhvkXUrHLXDEZmakQQ%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

So shall I create a new wiki page for 2021 proposals on sympy repositoryand
share my google docs link there as done in previous years?

Sudeep Sidhu

On Sat, 13 Mar 2021, 16:58 Jason Moore,  wrote:

> Sudeep,
>
> Please see the GSoC instructions:
> https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions. We
> recommend the wiki.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Fri, Mar 12, 2021 at 1:39 PM Sudeep Sidhu 
> wrote:
>
>> Jason,
>>
>> I have prepared my draft proposal for GSoC'21. Where shall I share it so
>> that you and others can review it.
>>
>> Sudeep Sidhu
>>
>> --
>> 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/CAJUjCN%3DNo%2BonpynE4PqsL%3Dk_%2BZF1e9-_kWr%3Do9ivgf%2B8xr17qg%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/CAP7f1AirRMUN%3DYbdbjtTiuvwg3isUSSP28ziywQ6toLc_YZt-Q%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/CAJUjCNkDNmjhA%3DD85C9NBfWiS02S4Tkf-8vkf6hh3tDws_vqyA%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

Please see the GSoC instructions:
https://github.com/sympy/sympy/wiki/GSoC-Student-Instructions. We recommend
the wiki.

Jason
moorepants.info
+01 530-601-9791


On Fri, Mar 12, 2021 at 1:39 PM Sudeep Sidhu 
wrote:

> Jason,
>
> I have prepared my draft proposal for GSoC'21. Where shall I share it so
> that you and others can review it.
>
> Sudeep Sidhu
>
> --
> 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/CAJUjCN%3DNo%2BonpynE4PqsL%3Dk_%2BZF1e9-_kWr%3Do9ivgf%2B8xr17qg%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/CAP7f1AirRMUN%3DYbdbjtTiuvwg3isUSSP28ziywQ6toLc_YZt-Q%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I have prepared my draft proposal for GSoC'21. Where shall I share it so
that you and others can review it.

Sudeep Sidhu

-- 
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/CAJUjCN%3DNo%2BonpynE4PqsL%3Dk_%2BZF1e9-_kWr%3Do9ivgf%2B8xr17qg%40mail.gmail.com.

Re: [sympy] GSoC Idea Discussion

[Rohan Gupta]

If not, I know there happen to be a number of problems with respect to the 
2/3 arg mul. I would also like to try and attempt to fix that from all the 
possible angles - fixing all the dependent code after considering the 
effects on downstream projects.

On Friday, March 12, 2021 at 2:27:45 PM UTC+5:30 Rohan Gupta wrote:

> No, this isn't listed on the ideas page. 
> I just thought it would be an interesting idea that could be implemented 
> on a larger range of functions.
>
> If this isn't a good enough idea, I'd love to work on calculus-related 
> projects such as Risch algorithm or other ODE related projects. Could you 
> guide me with this?
>
> On Friday, March 12, 2021 at 12:33:56 AM UTC+5:30 Oscar wrote:
>
>> On Thu, 11 Mar 2021 at 18:54, Rohan Gupta  wrote: 
>> > 
>> > I'm interested in working on numerical integration techniques for 
>> functions. 
>>
>> Is this listed on the ideas page somewhere? 
>>
>> In general numerical techniques are out of scope for sympy and should 
>> be implemented in mpmath or numpy/scipy etc. The idea is that sympy 
>> should use the routines from e.g. mpmath rather than implement its own 
>> numerical algorithms. 
>>
>> There are some algorithms already implemented in mpmath though that 
>> are not used in sympy. For example in sympy you can do: 
>>
>> In [164]: Integral(x, (x, 0, 1)).evalf() 
>> Out[164]: 0.500 
>>
>> Under the hood this calls mpmath's quad function (I think). This 
>> doesn't work for multiple integrals though: 
>>
>> In [165]: Integral(x*y, (x, 0, 1), (y, 0, 1)).evalf() 
>> Out[165]: 
>> 1 1 
>> ⌠ ⌠ 
>> ⎮ ⎮ x⋅y dx dy 
>> ⌡ ⌡ 
>> 0 0 
>>
>> It should be relatively straight-forward to make that work because 
>> mpmath's quad function can handle multiple integrals: 
>>
>>
>> https://mpmath.org/doc/current/calculus/integration.html#standard-quadrature-quad
>>  
>>
>> -- 
>> 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/f80eb252-434c-47e8-8405-a0ef97d9958dn%40googlegroups.com.

Re: [sympy] GSoC Idea Discussion

[Rohan Gupta]

No, this isn't listed on the ideas page. 
I just thought it would be an interesting idea that could be implemented on 
a larger range of functions.

If this isn't a good enough idea, I'd love to work on calculus-related 
projects such as Risch algorithm or other ODE related projects. Could you 
guide me with this?

On Friday, March 12, 2021 at 12:33:56 AM UTC+5:30 Oscar wrote:

> On Thu, 11 Mar 2021 at 18:54, Rohan Gupta  wrote:
> >
> > I'm interested in working on numerical integration techniques for 
> functions.
>
> Is this listed on the ideas page somewhere?
>
> In general numerical techniques are out of scope for sympy and should
> be implemented in mpmath or numpy/scipy etc. The idea is that sympy
> should use the routines from e.g. mpmath rather than implement its own
> numerical algorithms.
>
> There are some algorithms already implemented in mpmath though that
> are not used in sympy. For example in sympy you can do:
>
> In [164]: Integral(x, (x, 0, 1)).evalf()
> Out[164]: 0.500
>
> Under the hood this calls mpmath's quad function (I think). This
> doesn't work for multiple integrals though:
>
> In [165]: Integral(x*y, (x, 0, 1), (y, 0, 1)).evalf()
> Out[165]:
> 1 1
> ⌠ ⌠
> ⎮ ⎮ x⋅y dx dy
> ⌡ ⌡
> 0 0
>
> It should be relatively straight-forward to make that work because
> mpmath's quad function can handle multiple integrals:
>
>
> https://mpmath.org/doc/current/calculus/integration.html#standard-quadrature-quad
>
> --
> 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/83c0b7e8-6dea-411f-a3ac-9ac544a1166an%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Oscar Benjamin, could you review this first draft of my proposal. Please 
let me know if you feel that I should focus 
on some other topics/ algorithms in DomainMatrix instead of the ones chosen 
by me. 

GSoC 2021 Proposal 

On Tuesday, 9 March 2021 at 6:49:29 am UTC+5:30 Oscar wrote:

> On Mon, 8 Mar 2021 at 16:00, Kartik Sethi  wrote:
> >
> > Oscar Benjamin, what if someone else also puts up this same proposal to 
> improve the DomainMatrix module for Gsoc. How does sympy decide which 
> person will work on it.
>
> There is plenty more work to do on DomainMatrix than one person could
> do in a single GSOC project so there could be two people doing related
> projects on this although we do have limits on how many projects a
> single mentor could supervise. I am not the only person who could
> mentor a project on DomainMatrix though and it's also possible that I
> would mentor a project on something else instead such as ODEs.
>
> We will look at all applications and decide which to accept based on a
> number of factors. The two major factors are the priority of the
> project and the quality of the application. I think that DomainMatrix
> is high priority but if there are stronger proposals for other
> projects then it is possible that no proposal for DomainMatrix would
> be accepted.
>
> I suggest not to overthink this. The main thing is just to have a good
> application that is well motivated and shows clear understanding of
> the work to be done.
>
> --
> 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/f850ba4b-8750-47f0-b286-17961148fdf7n%40googlegroups.com.

Re: [sympy] GSoC Idea Discussion

[Oscar Benjamin]

On Thu, 11 Mar 2021 at 18:54, Rohan Gupta  wrote:
>
> I'm interested in working on numerical integration techniques for functions.

Is this listed on the ideas page somewhere?

In general numerical techniques are out of scope for sympy and should
be implemented in mpmath or numpy/scipy etc. The idea is that sympy
should use the routines from e.g. mpmath rather than implement its own
numerical algorithms.

There are some algorithms already implemented in mpmath though that
are not used in sympy. For example in sympy you can do:

In [164]: Integral(x, (x, 0, 1)).evalf()
Out[164]: 0.500

Under the hood this calls mpmath's quad function (I think). This
doesn't work for multiple integrals though:

In [165]: Integral(x*y, (x, 0, 1), (y, 0, 1)).evalf()
Out[165]:
1 1
⌠ ⌠
⎮ ⎮ x⋅y dx dy
⌡ ⌡
0 0

It should be relatively straight-forward to make that work because
mpmath's quad function can handle multiple integrals:

https://mpmath.org/doc/current/calculus/integration.html#standard-quadrature-quad

--
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/CAHVvXxQKPoO7LH1Mg%3DzWKWN_jbG2GjQm0y%3DV3%2B1b1WCX2i9GYg%40mail.gmail.com.

Re: [sympy] GSoC Idea Discussion

[Alan Bromborsky]

On 3/11/21 8:45 AM, Aryan Goyal wrote:

Hey there,
I'd like to contribute to the Project name- *Improve the plotting 
module.* As I have a good piece of knowledge in matplotlib, Python, 
HTML, CSS Javascript.


Thank You
Aryan Goyal
--
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/5bb06850-d838-4558-b73e-32fa479b0022n%40googlegroups.com 
.


There is a very good advanced free plotting program, Asymptote (look at 
the gallery in the link) which is LaTeX aware -


https://asymptote.sourceforge.io/

The problem is it has it's own programming language with no good Python 
wrapper (on github there is a primative one).  Take a look at the link 
and see what you think.


Here is an example -

https://asymptote.sourceforge.io/gallery/3Dwebgl/Klein.html

Here is the example code (you can rotate it and zoom with the mouse) -

import graph3;

size(469pt);

currentprojection=
  perspective(camera=(25.0851928432063,-30.3337528952473,19.3728775115443),
  up=Z,
  target=(-0.590622314050054,0.692357205025578,-0.627122488455679),
  zoom=1,autoadjust=false);

triple f(pair t) {
  real u=t.x;
  real v=t.y;
  real r=2-cos(u);
  real x=3*cos(u)*(1+sin(u))+r*cos(v)*(u < pi ? cos(u) : -1);
  real y=8*sin(u)+(u < pi ? r*sin(u)*cos(v) : 0);
  real z=r*sin(v);
  return (x,y,z);
}

surface s=surface(f,(0,0),(2pi,2pi),8,8,Spline);
draw(s,lightolive+white,"bottle",render(merge=true));

string lo="$\displaystyle u\in[0,\pi]: \cases{x=3\cos u(1+\sin u)+(2-\cos 
u)\cos u\cos v,\cr
y=8\sin u+(2-\cos u)\sin u\cos v,\cr
z=(2-\cos u)\sin v.\cr}$";

string hi="$\displaystyle u\in[\pi,2\pi]:\\\cases{x=3\cos u(1+\sin u)-(2-\cos 
u)\cos v,\cr
y=8\sin u,\cr
z=(2-\cos u)\sin v.\cr}$";

real h=0.0125;

begingroup3("parametrization");
draw(surface(xscale(-0.38)*yscale(-0.18)*lo,s,0,1.7,h,bottom=false),
 "[0,pi]");
draw(surface(xscale(0.26)*yscale(0.1)*rotate(90)*hi,s,4.9,1.4,h,bottom=false),
 "[pi,2pi]");
endgroup3();

begingroup3("boundary");
draw(s.uequals(0),blue+dashed);
draw(s.uequals(pi),blue+dashed);
endgroup3();

add(new void(frame f, transform3 t, picture pic, projection P) {
draw(f,invert(box(min(f,P),max(f,P)),P),"frame");
  });

--
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/7b3b5ae3-a137-3554-d1dc-f2cdb81f3f89%40gmail.com.

Re: [sympy] GSoC Idea Discussion

[Oscar Benjamin]

On Thu, 11 Mar 2021 at 11:33, Shreyas Sai  wrote:
>
> I'd like to know if Risch algorithm for symbolic integration would be a valid 
> topic for this year in GSoC, if yes, I'd love to help contribution it.

Hi Shreyas,

That would be a valid topic but not an easy one. Given the amount of
time available in a GSOC project (175 hrs?) to make progress on this
you would already need to have some knowledge of the algorithm and of
its implementation in sympy. Completing the algorithm is too much for
one project even if you do have good background knowledge so you would
need to be able to identify some particular part of it to implement.

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

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I have gone through Sahil's work multiple times and I think it has some
really good work and needs polishing, updations and some good test cases.

In Sahil's JointsMethod implementation , the use of root_body is only to
achieve the frame about which equations shall be generated so instead can't
we allow user to directly pass a Newtonian Frame about which equations can
be generated, isn't that the thing the ground body would do like you said
in one of the comments?

Current implementation in Sahil's work is : JointsMethod(joints, root_body)

What I propose is : JointsMethod(newtonian_frame, *joints)

Sudeep Sidhu

-- 
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/CAJUjCNnTXgKubX-dt4Rr_F7KpHL2JVA51EDQfzVgyTEWkX23%3DQ%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Mon, 8 Mar 2021 at 16:00, Kartik Sethi  wrote:
>
> Oscar Benjamin, what if someone else also puts up this same proposal to 
> improve the DomainMatrix module for Gsoc. How does sympy decide which person 
> will work on it.

There is plenty more work to do on DomainMatrix than one person could
do in a single GSOC project so there could be two people doing related
projects on this although we do have limits on how many projects a
single mentor could supervise. I am not the only person who could
mentor a project on DomainMatrix though and it's also possible that I
would mentor a project on something else instead such as ODEs.

We will look at all applications and decide which to accept based on a
number of factors. The two major factors are the priority of the
project and the quality of the application. I think that DomainMatrix
is high priority but if there are stronger proposals for other
projects then it is possible that no proposal for DomainMatrix would
be accepted.

I suggest not to overthink this. The main thing is just to have a good
application that is well motivated and shows clear understanding of
the work to be done.

--
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/CAHVvXxRMOLyRpFi6XmWvftYWmhaiqo%3DerRcLeTvVDJnjkPZp5g%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Oscar Benjamin, what if someone else also puts up this same proposal to 
improve the DomainMatrix module for Gsoc. How does sympy decide which 
person will work on it.


On Monday, 1 March 2021 at 12:16:35 pm UTC+5:30 Kartik Sethi wrote:

> Thanks for the suggestion. I'll start looking into methods that can be 
> made faster and also look into making DomainMatrix more complete.
>
> On Sunday, 28 February 2021 at 8:08:15 pm UTC+5:30 Oscar wrote:
>
>> On Sun, 28 Feb 2021 at 14:26, Oscar Benjamin  
>> wrote:
>> >
>> > The most useful thing that a GSOC project could do is really just to
>> > make the whole DomainMatrix class a bit more complete, usable and
>> > documented so that it's easier for users and future contributors to
>> > make use of it and also make improvements to it. There are always
>> > contributors wanting to add basic matrix algorithms like SVD etc
>> > regardless of GSOC. I would personally rank a GSOC project more highly
>> > if it looks like a more involved piece of work that needs someone to
>> > spend a bit of time getting to know a particular part of the codebase.
>>
>> I should add here that GSOC projects often do not end up doing
>> precisely what is specified in the proposal. Think of the proposal as
>> more like demonstrating that there are things that can be done and you
>> understand how to do them and have a rough idea of what you can
>> achieve in the time. The actual list of "I will do this, then that,
>> ..." is less important than just demonstrating that you know what
>> should be done and how to do it.
>>
>> --
>> 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/040a844b-a1c5-43de-ab6e-354402bf96dcn%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Thanks for the suggestion. I'll start looking into methods that can be made 
faster and also look into making DomainMatrix more complete.

On Sunday, 28 February 2021 at 8:08:15 pm UTC+5:30 Oscar wrote:

> On Sun, 28 Feb 2021 at 14:26, Oscar Benjamin  
> wrote:
> >
> > The most useful thing that a GSOC project could do is really just to
> > make the whole DomainMatrix class a bit more complete, usable and
> > documented so that it's easier for users and future contributors to
> > make use of it and also make improvements to it. There are always
> > contributors wanting to add basic matrix algorithms like SVD etc
> > regardless of GSOC. I would personally rank a GSOC project more highly
> > if it looks like a more involved piece of work that needs someone to
> > spend a bit of time getting to know a particular part of the codebase.
>
> I should add here that GSOC projects often do not end up doing
> precisely what is specified in the proposal. Think of the proposal as
> more like demonstrating that there are things that can be done and you
> understand how to do them and have a rough idea of what you can
> achieve in the time. The actual list of "I will do this, then that,
> ..." is less important than just demonstrating that you know what
> should be done and how to do it.
>
> --
> 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/52e0dfd0-afad-4f9c-9e0d-3526c6710115n%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Sun, 28 Feb 2021 at 14:26, Oscar Benjamin  wrote:
>
> The most useful thing that a GSOC project could do is really just to
> make the whole DomainMatrix class a bit more complete, usable and
> documented so that it's easier for users and future contributors to
> make use of it and also make improvements to it. There are always
> contributors wanting to add basic matrix algorithms like SVD etc
> regardless of GSOC. I would personally rank a GSOC project more highly
> if it looks like a more involved piece of work that needs someone to
> spend a bit of time getting to know a particular part of the codebase.

I should add here that GSOC projects often do not end up doing
precisely what is specified in the proposal. Think of the proposal as
more like demonstrating that there are things that can be done and you
understand how to do them and have a rough idea of what you can
achieve in the time. The actual list of "I will do this, then that,
..." is less important than just demonstrating that you know what
should be done and how to do it.

--
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/CAHVvXxQsfFOqSVJdWzdam1g8vOu7ko%2BwB7RYNKzCcY%2B5wVa7kA%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Sun, 28 Feb 2021 at 10:38, Kartik Sethi  wrote:
>
> I was wondering if completing the tasks listed on 
> https://github.com/sympy/sympy/issues/20987 could be a Gsoc proposal.

Some of the things in that list are fairly trivial like "make Matrix
use DomainMatrix for charpoly". The DomainMatrix charpoly method is
there already and is efficient so it's just a case of changing the
charpoly method of matrix to call that.

Other things on the list are a bit more complex like "implement the
Bareiss algorithm": that's not a complicated algorithm but
implementing it efficiently with pivoting for sparse matrices takes a
bit of work.

Then other things are much more difficult like "Make risch use
DomainMatrix" and are clearly beyond the scope of a GSOC proposal
right now (unless you already have significant knowledge of the
algorithm and its implementation in sympy).

So a GSOC proposal could focus on only some of the things from that
list. The list itself is very incomplete so there are plenty of other
things that would make both DomainMatrix faster and other ways to make
Matrix faster by using DomainMatrix. If you can think of anything then
please suggest on the issue so that we can add it to the list.

The most useful thing that a GSOC project could do is really just to
make the whole DomainMatrix class a bit more complete, usable and
documented so that it's easier for users and future contributors to
make use of it and also make improvements to it. There are always
contributors wanting to add basic matrix algorithms like SVD etc
regardless of GSOC. I would personally rank a GSOC project more highly
if it looks like a more involved piece of work that needs someone to
spend a bit of time getting to know a particular part of the codebase.

> There's a lot to do in that list and I can even add some other functions like 
> QR decomposition, Hessenberg Decomposition, SVD, Polar Decomposition etc. to 
> that list.

Since DomainMatrix works over a domain or a field some algorithms make
less sense for it. For example an algorithm that involves computing
lots of square roots means taking repeated field extensions which
would probably not be efficient with DomainMatrix.

I'm not sure how easy it is to implement any of those with
DomainMatrix but certainly if the algorithm boils down to operations
like charpoly, and nullspace (like computing the eigenvectors or
Jordan form does) then we can just make those core operations more
efficient using DomainMatrix.

I would begin with the trivial things like for example charpoly takes
11 seconds to compute the characteristic polynomial of this small 5x5
matrix of complex numbers:

In [1]: M = randMatrix(5) + randMatrix(5)*I

In [2]: %time p1 = M.charpoly()
CPU times: use 11.4 s, sys: 67.4 ms, total: 11.5 s
Wall time: 11.6 s

It only takes a few milliseconds to do the same with DomainMatrix:

In [4]: from sympy.polys.matrices import DomainMatrix

In [5]: %time dM = DomainMatrix.from_Matrix(M)
CPU times: user 552 µs, sys: 1e+03 ns, total: 553 µs
Wall time: 558 µs

In [6]: %time p2 = dM.charpoly()
CPU times: user 2.77 ms, sys: 26 µs, total: 2.79 ms
Wall time: 2.83 ms

In [7]: Poly(p2, p1.gens, domain=dM.domain) == p1
Out[7]: True

Making Matrix.charpoly faster then is a pretty trivial pull request at
this stage. That would then speed up all the other operations that use
charpoly (eigenvals, Jordan form etc).

If you time various operations like this with Matrix then you can see
what is slow and whether or not DomainMatrix can be used to speed
things up. Ideally though we just use it for a small number of
operations that are the core to other algorithms. The thing to pay
attention to is what kinds of entries you have in the matrix and what
domain the resulting DomainMatrix uses. DomainMatrix is faster for a
matrix of integers but where it really makes a difference is something
like the above which is a matrix of Gaussian integers or matrices that
involve algebraic quantities like sqrt(2) or matrices with symbols in
so that the entries are e.g. polynomials in x and y.

--
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/CAHVvXxREHu-mW1LXDRyhAs0nK5N84-9-exxiaH%2B_z9YO4Leryw%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Oscar Benjamin, I was wondering if completing the tasks listed on 
https://github.com/sympy/sympy/issues/20987 could be a Gsoc proposal.
There's a lot to do in that list and I can even add some other functions 
like QR decomposition, Hessenberg Decomposition, SVD, Polar Decomposition 
etc. to that list.
Since DomainMatrix class seems a lot faster, users would actually be able 
to use these functions for matrices.
What do you think?
On Sunday, 21 February 2021 at 12:51:46 pm UTC+5:30 Kartik Sethi wrote:

> Thanks for listing out the issues. I'll start looking into them
>
> On Sunday, 21 February 2021 at 4:00:01 am UTC+5:30 Oscar wrote:
>
>> On Sat, 20 Feb 2021 at 11:33, Oscar Benjamin  
>> wrote:
>> > This is not listed anywhere on the ideas page or really documented
>> > anywhere yet but there is a new mostly internal implementation of
>> > matrices in the sympy.polys.matrices module. This new implementation
>> > is called DomainMatrix and is based on the polys domains. The domains
>> > themselves are explained in these recently added docs:
>> > https://docs.sympy.org/dev/modules/polys/domainsintro.html
>> > There are aren't any docs for DomainMatrix yet and it is not that easy
>> > to use but you can find more information in this most recent PR which
>> > links to other PRs:
>> > https://github.com/sympy/sympy/pull/20780
>>
>> I've opened an issue to list things that need doing with DomainMatrix:
>> https://github.com/sympy/sympy/issues/20987
>>
>

-- 
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/ee4b4125-25f6-4572-bc48-28bc33da0aa8n%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Thanks for listing out the issues. I'll start looking into them

On Sunday, 21 February 2021 at 4:00:01 am UTC+5:30 Oscar wrote:

> On Sat, 20 Feb 2021 at 11:33, Oscar Benjamin  
> wrote:
> > This is not listed anywhere on the ideas page or really documented
> > anywhere yet but there is a new mostly internal implementation of
> > matrices in the sympy.polys.matrices module. This new implementation
> > is called DomainMatrix and is based on the polys domains. The domains
> > themselves are explained in these recently added docs:
> > https://docs.sympy.org/dev/modules/polys/domainsintro.html
> > There are aren't any docs for DomainMatrix yet and it is not that easy
> > to use but you can find more information in this most recent PR which
> > links to other PRs:
> > https://github.com/sympy/sympy/pull/20780
>
> I've opened an issue to list things that need doing with DomainMatrix:
> https://github.com/sympy/sympy/issues/20987
>

-- 
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/5668efbc-770f-4573-a86f-be598e135b43n%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Thanks for listing out some of the issues. I'll start looking into them.

On Sunday, 21 February 2021 at 4:00:01 am UTC+5:30 Oscar wrote:

> On Sat, 20 Feb 2021 at 11:33, Oscar Benjamin  
> wrote:
> > This is not listed anywhere on the ideas page or really documented
> > anywhere yet but there is a new mostly internal implementation of
> > matrices in the sympy.polys.matrices module. This new implementation
> > is called DomainMatrix and is based on the polys domains. The domains
> > themselves are explained in these recently added docs:
> > https://docs.sympy.org/dev/modules/polys/domainsintro.html
> > There are aren't any docs for DomainMatrix yet and it is not that easy
> > to use but you can find more information in this most recent PR which
> > links to other PRs:
> > https://github.com/sympy/sympy/pull/20780
>
> I've opened an issue to list things that need doing with DomainMatrix:
> https://github.com/sympy/sympy/issues/20987
>

-- 
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/ec80c9ac-2924-4217-9f8b-fb575e19c579n%40googlegroups.com.

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Sat, 20 Feb 2021 at 11:33, Oscar Benjamin  wrote:
> This is not listed anywhere on the ideas page or really documented
> anywhere yet but there is a new mostly internal implementation of
> matrices in the sympy.polys.matrices module. This new implementation
> is called DomainMatrix and is based on the polys domains. The domains
> themselves are explained in these recently added docs:
> https://docs.sympy.org/dev/modules/polys/domainsintro.html
> There are aren't any docs for DomainMatrix yet and it is not that easy
> to use but you can find more information in this most recent PR which
> links to other PRs:
> https://github.com/sympy/sympy/pull/20780

I've opened an issue to list things that need doing with DomainMatrix:
https://github.com/sympy/sympy/issues/20987

-- 
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/CAHVvXxSKii_Qga9iXsWOXNRyh_oVm%3D6kWU4un8Hz7Za19BcHhw%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Sat, 20 Feb 2021 at 14:28, Kartik Sethi  wrote:
>
> Thanks Oscar Benjamin for the wonderful suggestions. I will start looking 
> into algorithms and methods that have not been implemented for the domain 
> Matrix class yet.
> I would be happy to help in building Domain Matrix class.
>
> Do you think improving and implementing algorithms in Domain Matrix class 
> would be a suitable Gsoc Proposal?

Yes, absolutely. If anyone is interested in improving sympy's matrix
calculations I think that this is the most important thing to do right
now. Many algorithms are already implemented for Matrix but are
basically unusable because they are too slow except in the simplest
cases. If we can make core matrix operations faster then that will
benefit all of them.

In the cases where DomainMatrix is slow the main thing that is slow is
gcd computations. That can be improved by making more use of fraction
free algorithms as in this PR that anyone is welcome to finish:
https://github.com/sympy/sympy/pull/20483

The other side of it is improving the gcd algorithms themselves but I
think that should be a whole separate project.


--
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/CAHVvXxTLXFUrcnrTY4cDMytEPSbM9fR0G-gZtap9vRPi0Ogegw%40mail.gmail.com.

Re: [sympy] Gsoc Idea Discussion

[Kartik Sethi]

Thanks Oscar Benjamin for the wonderful suggestions. I will start looking 
into algorithms and methods that have not been implemented for the domain 
Matrix class yet.
I would be happy to help in building Domain Matrix class.

Do you think improving and implementing algorithms in Domain Matrix class 
would be a suitable Gsoc Proposal?

On Saturday, 20 February 2021 at 5:04:13 pm UTC+5:30 Oscar wrote:

> On Sat, 20 Feb 2021 at 07:40, Kartik Sethi  wrote:
> >
> > Hey, my name is Kartik Sethi. I am interested in taking part in Gsoc 
> this year. I have been contributing to sympy for the past couple of months.
>
> Hi Kartik,
>
> > I have come up with a few ideas for Gsoc. I am focusing primarily on the 
> sympy matrices module.
> >
> > Implementing complete Singular Value decomposition. Sympy currently has 
> a function for condensed SVD ( I am a contributor on this #20761).
> > Using the complete SVD, I can implement Polar decomposition
> > Hermite Normal Form. There is an old un-merged PR (#18534), I could work 
> on this and complete it.
> > Sparse-Fraction Free Algorithm another old unfinished PR (#9133)
>
> The Matrix class does not necessarily get much benefit from
> fraction-free algorithms because of the internal representation.
> DomainMatrix does though (see below).
>
> > Jordan Canonical Form
>
> This is already implemented as the Matrix.jordan_form method so I'm
> not sure what you are proposing. The main way it could be improved is
> by having the method use DomainMatrix internally just like eigenvects
> does (see below).
>
> > Improve time complexity for QR decomposition of upper Hessenberg. There 
> is an algorithm using Householder reflectors that can cut down 
> time-complexity to O(n^2) instead of current O(n^3)
>
> When I've timed calculations with Matrix they almost never match up to
> the big-O behaviour that is typically expected for any given
> algorithm. I think there are too many other symbolic computations
> going on that it slows down more than it should as n grows. Operations
> with DomainMatrix though do tend to have the big-O that you would
> expect if you take into account bit complexity.
>
> This is not listed anywhere on the ideas page or really documented
> anywhere yet but there is a new mostly internal implementation of
> matrices in the sympy.polys.matrices module. This new implementation
> is called DomainMatrix and is based on the polys domains. The domains
> themselves are explained in these recently added docs:
> https://docs.sympy.org/dev/modules/polys/domainsintro.html
> There are aren't any docs for DomainMatrix yet and it is not that easy
> to use but you can find more information in this most recent PR which
> links to other PRs:
> https://github.com/sympy/sympy/pull/20780
>
> The easiest way to test out DomainMatrix is by converting from a
> normal Matrix like this:
>
> In [75]: from sympy.polys.matrices import DomainMatrix
>
> In [76]: M = Matrix(range(25)).reshape(5, 5)
>
> In [77]: M
> Out[77]:
> ⎡0 1 2 3 4 ⎤
> ⎢ ⎥
> ⎢5 6 7 8 9 ⎥
> ⎢ ⎥
> ⎢10 11 12 13 14⎥
> ⎢ ⎥
> ⎢15 16 17 18 19⎥
> ⎢ ⎥
> ⎣20 21 22 23 24⎦
>
> In [78]: dM = DomainMatrix.from_Matrix(M)
>
> In [80]: dM
> Out[80]: DomainMatrix([[0, 1, 2, 3, 4], [5, 6, 7, 8, 9], [10, 11, 12,
> 13, 14], [15, 16, 17, 18, 19], [20, 21, 22, 23, 24]], (5, 5), ZZ)
>
> DomainMatrix is much faster than Matrix for many calculations. The
> difference is observable for a simple matrix of integers like this:
>
> In [81]: %time M.det()
> CPU times: user 2.4 ms, sys: 281 µs, total: 2.68 ms
> Wall time: 2.73 ms
> Out[81]: 0
>
> In [82]: %time dM.det()
> CPU times: user 143 µs, sys: 161 µs, total: 304 µs
> Wall time: 310 µs
> Out[82]: mpz(0)
>
> The difference becomes really noticeable if the matrix has algebraic
> elements like I or sqrt(2) or has symbols like x or y in it:
>
> In [88]: M = randMatrix(5, 5) + randMatrix(5, 5) * I
>
> In [89]: M
> Out[89]:
> ⎡26 + 27⋅ⅈ 41 + 76⋅ⅈ 98 + 76⋅ⅈ 64 + 52⋅ⅈ 48 + 2⋅ⅈ ⎤
> ⎢ ⎥
> ⎢65 + 81⋅ⅈ 49 + 25⋅ⅈ 39 + 82⋅ⅈ 74⋅ⅈ 77 + 3⋅ⅈ ⎥
> ⎢ ⎥
> ⎢11 + 59⋅ⅈ 49 + 67⋅ⅈ 50 + 25⋅ⅈ 69 + 24⋅ⅈ 79 + 31⋅ⅈ⎥
> ⎢ ⎥
> ⎢42 + 29⋅ⅈ 33 + 72⋅ⅈ 37 + 59⋅ⅈ 10 + 12⋅ⅈ 27 + 62⋅ⅈ⎥
> ⎢ ⎥
> ⎣97 + 7⋅ⅈ 4 + 26⋅ⅈ 8 + 30⋅ⅈ 47 + 84⋅ⅈ 81 + 6⋅ⅈ ⎦
>
> In [90]: dM = DomainMatrix.from_Matrix(M)
>
> In [91]: %time ok = M.det()
> CPU times: user 486 ms, sys: 4.15 ms, total: 490 ms
> Wall time: 492 ms
>
> In [92]: %time ok = dM.det()
> CPU times: user 12 ms, sys: 422 µs, total: 12.4 ms
> Wall time: 12.7 ms
>
> In [93]: %time ok = M.charpoly()
> CPU times: user 18.9 s, sys: 186 ms, total: 19.1 s
> Wall time: 19.2 s
>
> In [94]: %time ok = dM.charpoly()
> CPU times: user 10 ms, sys: 170 µs, total: 10.2 ms
> Wall time: 10.5 ms
>
> That's a 50x speed difference for computing the determinant and a
> 2000x difference for the characteristic polynomial. This is just for a
> 5x5 matrix: the speed difference will be more significant for larger
> matrices. Further optimisations are still possible for both det and
> charpoly: sparse fraction free elimination 

Re: [sympy] Gsoc Idea Discussion

[Oscar Benjamin]

On Sat, 20 Feb 2021 at 07:40, Kartik Sethi  wrote:
>
> Hey, my name is Kartik Sethi. I am interested in taking part in Gsoc this 
> year. I have been contributing to sympy for the past couple of months.

Hi Kartik,

> I have come up with a few ideas for Gsoc. I am focusing primarily on the 
> sympy matrices module.
>
> Implementing complete Singular Value decomposition. Sympy currently has a 
> function for condensed SVD ( I am a contributor on this #20761).
> Using the complete SVD, I can implement Polar decomposition
> Hermite Normal Form. There is an old un-merged PR (#18534), I could work on 
> this and complete it.
> Sparse-Fraction Free Algorithm another old unfinished PR (#9133)

The Matrix class does not necessarily get much benefit from
fraction-free algorithms because of the internal representation.
DomainMatrix does though (see below).

> Jordan Canonical Form

This is already implemented as the Matrix.jordan_form method so I'm
not sure what you are proposing. The main way it could be improved is
by having the method use DomainMatrix internally just like eigenvects
does (see below).

> Improve time complexity for QR decomposition of upper Hessenberg. There is an 
> algorithm using Householder reflectors that can cut down time-complexity to 
> O(n^2) instead of current O(n^3)

When I've timed calculations with Matrix they almost never match up to
the big-O behaviour that is typically expected for any given
algorithm. I think there are too many other symbolic computations
going on that it slows down more than it should as n grows. Operations
with DomainMatrix though do tend to have the big-O that you would
expect if you take into account bit complexity.

This is not listed anywhere on the ideas page or really documented
anywhere yet but there is a new mostly internal implementation of
matrices in the sympy.polys.matrices module. This new implementation
is called DomainMatrix and is based on the polys domains. The domains
themselves are explained in these recently added docs:
https://docs.sympy.org/dev/modules/polys/domainsintro.html
There are aren't any docs for DomainMatrix yet and it is not that easy
to use but you can find more information in this most recent PR which
links to other PRs:
https://github.com/sympy/sympy/pull/20780

The easiest way to test out DomainMatrix is by converting from a
normal Matrix like this:

In [75]: from sympy.polys.matrices import DomainMatrix

In [76]: M = Matrix(range(25)).reshape(5, 5)

In [77]: M
Out[77]:
⎡0   1   2   3   4 ⎤
⎢  ⎥
⎢5   6   7   8   9 ⎥
⎢  ⎥
⎢10  11  12  13  14⎥
⎢  ⎥
⎢15  16  17  18  19⎥
⎢  ⎥
⎣20  21  22  23  24⎦

In [78]: dM = DomainMatrix.from_Matrix(M)

In [80]: dM
Out[80]: DomainMatrix([[0, 1, 2, 3, 4], [5, 6, 7, 8, 9], [10, 11, 12,
13, 14], [15, 16, 17, 18, 19], [20, 21, 22, 23, 24]], (5, 5), ZZ)

DomainMatrix is much faster than Matrix for many calculations. The
difference is observable for a simple matrix of integers like this:

In [81]: %time M.det()
CPU times: user 2.4 ms, sys: 281 µs, total: 2.68 ms
Wall time: 2.73 ms
Out[81]: 0

In [82]: %time dM.det()
CPU times: user 143 µs, sys: 161 µs, total: 304 µs
Wall time: 310 µs
Out[82]: mpz(0)

The difference becomes really noticeable if the matrix has algebraic
elements like I or sqrt(2) or has symbols like x or y in it:

In [88]: M = randMatrix(5, 5) + randMatrix(5, 5) * I

In [89]: M
Out[89]:
⎡26 + 27⋅ⅈ  41 + 76⋅ⅈ  98 + 76⋅ⅈ  64 + 52⋅ⅈ  48 + 2⋅ⅈ ⎤
⎢ ⎥
⎢65 + 81⋅ⅈ  49 + 25⋅ⅈ  39 + 82⋅ⅈ74⋅ⅈ 77 + 3⋅ⅈ ⎥
⎢ ⎥
⎢11 + 59⋅ⅈ  49 + 67⋅ⅈ  50 + 25⋅ⅈ  69 + 24⋅ⅈ  79 + 31⋅ⅈ⎥
⎢ ⎥
⎢42 + 29⋅ⅈ  33 + 72⋅ⅈ  37 + 59⋅ⅈ  10 + 12⋅ⅈ  27 + 62⋅ⅈ⎥
⎢ ⎥
⎣97 + 7⋅ⅈ   4 + 26⋅ⅈ   8 + 30⋅ⅈ   47 + 84⋅ⅈ  81 + 6⋅ⅈ ⎦

In [90]: dM = DomainMatrix.from_Matrix(M)

In [91]: %time ok = M.det()
CPU times: user 486 ms, sys: 4.15 ms, total: 490 ms
Wall time: 492 ms

In [92]: %time ok = dM.det()
CPU times: user 12 ms, sys: 422 µs, total: 12.4 ms
Wall time: 12.7 ms

In [93]: %time ok = M.charpoly()
CPU times: user 18.9 s, sys: 186 ms, total: 19.1 s
Wall time: 19.2 s

In [94]: %time ok = dM.charpoly()
CPU times: user 10 ms, sys: 170 µs, total: 10.2 ms
Wall time: 10.5 ms

That's a 50x speed difference for computing the determinant and a
2000x difference for the characteristic polynomial. This is just for a
5x5 matrix: the speed difference will be more significant for larger
matrices. Further optimisations are still possible for both det and
charpoly: sparse fraction free elimination could be used for det for
example.

It is not currently clear how to make use of DomainMatrix for users.
Currently it is only used as part of linsolve and internally by the
Matrix.eigenvects routine. Right now the thing that would make the
biggest difference to matrices in sympy would be 

Re: [sympy] GSoC Idea Discussion

[Aaron Meurer]

On Fri, Feb 12, 2021 at 10:24 PM Sidharth  wrote:
>
> Hello SymPy Community!
>
> I was interested in a few ideas in the GSoC Ideas page, and wanted to know a 
> bit more about their usefulness to the community and expected time required 
> to finish -
>
> sympy.logic - It seems like sympy.logic has a lot of scope for improvement 
> and development. There has been work by sd-biswas and ShubhamKJha in previous 
> GSoC projects but some of it is unfinished. I found this issue #7175 which 
> lists some fixes to be made in the logic module and two open PRs #7608 and 
> #17609 which aim to implement First Order Logic. There are a few more open 
> PRs (#7555 #2964 #2852). From the comments on these, they appear to be very 
> useful to the sympy community, but the comments were a few years ago. Are 
> they still useful/needed? Also, would working on fixing these and maybe 
> introducing Second Order Logic or Linear Temporal Logic be appropriate for 
> the new reduced GSoC period, or is it too much/too less? As Jason said in the 
> other discussion, I think it is better to finish/improve the current 
> implementations before moving on to implement new things. As I have done a 
> formal course on Logic for Computer Science at my college in my previous 
> semester, my knowledge on this is still fresh and it should provide some help 
> in researching about this further and in the project.

Yes, I think this project is still useful. Some of the pull requests
from older projects were not merged because they were not able to be
finished. It would be good to finish them up so they can be merged.

Personally, I would focus just on second order logic for a project.
Other logics like modal logic are less important for SymPy, and they
would require a good standard second order logic foundation to
implement well anyway. Note that project sizes are reduced this year
compared to previous GSoC years, so focusing just on second order
logic, including finishing up previous work as appropriate, is a good
project size.

Others will have to provide updates on the state of the series module
as I haven't followed the recent developments there too closely.

Aaron Meurer

>
>
> sympy.series - There were a few pointers here that had me interested. First 
> was the rs_series expansion. I could only find this implemented in 
> polys/ring_series.py currently, so I believe the project to extend it to all 
> functions is still relevant? At a glance, this method seems mathematically 
> involved, and I have only done an undergraduate level course on calculus. 
> Could anyone suggest relevant reading material for this? Also, I don't think 
> it is possible to extend it to all sympy functions in the reduced GSoC 
> period, but since I do not know much about it, could someone confirm whether 
> this would be feasible in the new GSoC timeline, and how important it is 
> currently?
>
> Another prompt was 'asymptotic series' but I could not understand much from 
> this. Is it the extension of aseries to all functions which need a separate 
> asymptotic expansion method? Similarly for 'improve limits - make sure all 
> basic limits work', does this involved going through the related 
> NotImplemented errors and implementing them? Also, I see this mentioned in 
> the ideas page and Sachin did it in his GSoC project last year, but is a 
> possible project idea simply fixing a bunch of open series/limits issues?
>
> Regarding these various ideas I have mentioned in sympy.series, is there any 
> idea that the community prefers, or any idea that would be more suited to the 
> shorter GSoC period (perhaps just fixing issues)? Is there any other idea 
> that I have not mentioned which is more "important"? I have been working on 
> some series related issues recently and although they are taking a long time 
> to debug (probably due to my inexperience), I am learning a lot on the way 
> thanks to the reviewers and have a decent understanding of how limits and 
> series expansions are implemented in sympy.
>
> Any input from the community would be appreciated!
>
> Regards,
> Sidharth (0sidharth)
>
> --
> 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/b55c595e-d9be-4f35-af9f-9a41946a4cb2n%40googlegroups.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%3D6LPH8tEkhg%2Bm2VL8zhjm2ApHv%3D4Re%3DDsQLNh32tCvwj%2Bw%40mail.gmail.com.

Re: [sympy] GSoC Idea Discussion

[cheshta babbar]

Thank you Oscar, I'll keep in mind to put the reference next time.
Also, I went through the issue you just shared, it looks like a good idea
for gsoc, could someone guide me on it? I have fairly good understanding of
the algorithm and would start working on it right away, though some
supervision would be of great help.

On Fri, 12 Feb, 2021, 19:46 Oscar Benjamin, 
wrote:

> On Fri, 12 Feb 2021 at 13:13, cheshta babbar 
> wrote:
> >
> > While going through ideas , I found this idea , Multivariate polynomials
> and factorization, using Gao's partial differential equations approach,
> very appealing . I wanted to know if this idea is outdated or is being
> considered for this year's GSoC . Also, it'd be great to have someone
> guiding from the start if the idea has any potential.
>
> It's helpful if you can provide a link so that people can see what
> you're referring to. I guess you're referring to this:
>
> https://github.com/sympy/sympy/wiki/GSoC-Ideas#multivariate-polynomials-and-factorization
>
> The information on the ideas page is out of date so you would need to
> look into the code to see what is implemented and what is not. I have
> recently done some work on this that could be a good starting point
> for a project along these lines:
> https://github.com/sympy/sympy/issues/20874
>
> More work is needed in this area and it is very important and would
> make a good GSOC project. That being said I'm not sure who would
> supervise it. My own knowledge for polys is limited but I could
> partially supervise something like this.
>
>
> 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/CAHVvXxRMsaMO26V-syT%3DKDrx3vQ9-T2iknvi4U0t7eW2smn6Ww%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/CAL63R54gr1X7MUy76Zs-bVOZs8YfLA-St2zG44DfbhLY1npGqA%40mail.gmail.com.

Re: [sympy] GSoC Idea Discussion

[Oscar Benjamin]

On Fri, 12 Feb 2021 at 13:13, cheshta babbar  wrote:
>
> While going through ideas , I found this idea , Multivariate polynomials and 
> factorization, using Gao's partial differential equations approach, very 
> appealing . I wanted to know if this idea is outdated or is being considered 
> for this year's GSoC . Also, it'd be great to have someone guiding from the 
> start if the idea has any potential.

It's helpful if you can provide a link so that people can see what
you're referring to. I guess you're referring to this:
https://github.com/sympy/sympy/wiki/GSoC-Ideas#multivariate-polynomials-and-factorization

The information on the ideas page is out of date so you would need to
look into the code to see what is implemented and what is not. I have
recently done some work on this that could be a good starting point
for a project along these lines:
https://github.com/sympy/sympy/issues/20874

More work is needed in this area and it is very important and would
make a good GSOC project. That being said I'm not sure who would
supervise it. My own knowledge for polys is limited but I could
partially supervise something like this.


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/CAHVvXxRMsaMO26V-syT%3DKDrx3vQ9-T2iknvi4U0t7eW2smn6Ww%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

Thanks for clarifying things for me , I actually got confused because your
name wasn't in potential mentors list so I thought about that "good to go".

Other than looking in other dynamics packages I wanted to learn a bit
theory about Joints and JointsMethod , searching google is showing Truss,
so please recommend me a book or website to gain that knowledge.

Sudeep Sidhu



On Wed, 10 Feb 2021, 20:42 Jason Moore,  wrote:

> Sudeep,
>
> We don't tell you what is "good to go". Every applicant can propose
> whatever they want. The applications are judged on the scope, the
> likelihood of success, the writer's communication, alignment with sympy's
> roadmap, and their applicant's interaction with the community.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Wed, Feb 10, 2021 at 4:07 PM Sudeep Sidhu 
> wrote:
>
>> Jason,
>>
>> I'll surely look into it.
>>
>> So is JointsMethod good to go as GSoC project?
>>
>> On Wed, 10 Feb 2021, 19:15 Jason Moore,  wrote:
>>
>>> Sudeep,
>>>
>>> The only thing I can think of to look it is how people do this in other
>>> dynamics software. Many of them let the user define a system based on
>>> descriptions of rigid bodies and different joint types. That description is
>>> the used to define the mathematics of the kinematics. The software Simbody
>>> does it, for example: https://github.com/simbody/simbody You can see
>>> that the concept of a "mobilizer" is used.
>>>
>>> Jason
>>> moorepants.info
>>> +01 530-601-979
>>>
>> --
>> 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/CAJUjCNmYppkxNO91SpEuMBXhbbHx26bnWF8-ioxA5NiECuWtFg%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/CAP7f1AhSTDWC2n-z5h-jCLugdrvqPNMMWa96ck27E2Y-ttbJjQ%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/CAJUjCN%3D0uFuMMabBiHPGRbq6dt9xNDtTFfsnxQryqroxF%3DQcTg%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

We don't tell you what is "good to go". Every applicant can propose
whatever they want. The applications are judged on the scope, the
likelihood of success, the writer's communication, alignment with sympy's
roadmap, and their applicant's interaction with the community.

Jason
moorepants.info
+01 530-601-9791


On Wed, Feb 10, 2021 at 4:07 PM Sudeep Sidhu 
wrote:

> Jason,
>
> I'll surely look into it.
>
> So is JointsMethod good to go as GSoC project?
>
> On Wed, 10 Feb 2021, 19:15 Jason Moore,  wrote:
>
>> Sudeep,
>>
>> The only thing I can think of to look it is how people do this in other
>> dynamics software. Many of them let the user define a system based on
>> descriptions of rigid bodies and different joint types. That description is
>> the used to define the mathematics of the kinematics. The software Simbody
>> does it, for example: https://github.com/simbody/simbody You can see
>> that the concept of a "mobilizer" is used.
>>
>> Jason
>> moorepants.info
>> +01 530-601-979
>>
> --
> 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/CAJUjCNmYppkxNO91SpEuMBXhbbHx26bnWF8-ioxA5NiECuWtFg%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/CAP7f1AhSTDWC2n-z5h-jCLugdrvqPNMMWa96ck27E2Y-ttbJjQ%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I'll surely look into it.

So is JointsMethod good to go as GSoC project?

On Wed, 10 Feb 2021, 19:15 Jason Moore,  wrote:

> Sudeep,
>
> The only thing I can think of to look it is how people do this in other
> dynamics software. Many of them let the user define a system based on
> descriptions of rigid bodies and different joint types. That description is
> the used to define the mathematics of the kinematics. The software Simbody
> does it, for example: https://github.com/simbody/simbody You can see that
> the concept of a "mobilizer" is used.
>
> Jason
> moorepants.info
> +01 530-601-979
>

-- 
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/CAJUjCNmYppkxNO91SpEuMBXhbbHx26bnWF8-ioxA5NiECuWtFg%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

The only thing I can think of to look it is how people do this in other
dynamics software. Many of them let the user define a system based on
descriptions of rigid bodies and different joint types. That description is
the used to define the mathematics of the kinematics. The software Simbody
does it, for example: https://github.com/simbody/simbody You can see that
the concept of a "mobilizer" is used.

Jason
moorepants.info
+01 530-601-9791


On Wed, Feb 10, 2021 at 1:51 PM Sudeep Sidhu 
wrote:

> Jason,
>
> I went through the previous JointsMethod work, I think it would be wise to
> complete the previous 2 PRs of Joint Methods because it contains some good
> work and completing them would take less time rather than starting from
> scratch.
> Please refer a source to read more about Joints and JointsMethod.
>
> Sudeep Sidhu
>
>
>
>
> On Tue, 9 Feb 2021, 18:19 Sudeep Sidhu, 
> wrote:
>
>> Jason,
>>
>> I'm comfortable in implementing JointsMethod and it has some previous
>> work done too (unmerged GSoC work). All I would need is some guidance with
>> concepts if I get stuck somewhere and a good source to read about
>> JointsMethod. I have some knowledge of dynamics too so I think I can
>> implement it.
>>
>> Sudeep Sidhu
>>
>> On Tue, 9 Feb 2021, 15:28 Jason Moore,  wrote:
>>
>>> I personally think completing the JointsMethod is of higher priority
>>> than the FeatherStone method. The JointsMethod would open up the use of the
>>> library to a much wider set of users because they will be able to construct
>>> models with less knowledge of the underlying mathematics. For example, a
>>> double compound pendulum could be created like this:
>>>
>>> ground = RigidBody(...)
>>> upper_link = RigidBody(...)
>>> lower_link = RigidBody(...)
>>>
>>> base_joint = PinJoin(ground, lower_link, ...)
>>> intermediate_joint = PinJoint(lower_link, upper_link, ...)
>>>
>>> joint_method = JointMethod((base_joint, intermediate_joint), ...)
>>>
>>> equations_of_motion = joint_method.generate_eoms(...)
>>>
>>> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAJUjCNnYjAqYz6z_sSum_-WLAGwP0FNotfSQvwxotNKcqqqs_A%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/CAP7f1Aj2h_Q0%2BbP2HvpON3VaqctVjiuAXdO2YZJs_bWd%3D6iHDw%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I went through the previous JointsMethod work, I think it would be wise to
complete the previous 2 PRs of Joint Methods because it contains some good
work and completing them would take less time rather than starting from
scratch.
Please refer a source to read more about Joints and JointsMethod.

Sudeep Sidhu




On Tue, 9 Feb 2021, 18:19 Sudeep Sidhu,  wrote:

> Jason,
>
> I'm comfortable in implementing JointsMethod and it has some previous work
> done too (unmerged GSoC work). All I would need is some guidance with
> concepts if I get stuck somewhere and a good source to read about
> JointsMethod. I have some knowledge of dynamics too so I think I can
> implement it.
>
> Sudeep Sidhu
>
> On Tue, 9 Feb 2021, 15:28 Jason Moore,  wrote:
>
>> I personally think completing the JointsMethod is of higher priority than
>> the FeatherStone method. The JointsMethod would open up the use of the
>> library to a much wider set of users because they will be able to construct
>> models with less knowledge of the underlying mathematics. For example, a
>> double compound pendulum could be created like this:
>>
>> ground = RigidBody(...)
>> upper_link = RigidBody(...)
>> lower_link = RigidBody(...)
>>
>> base_joint = PinJoin(ground, lower_link, ...)
>> intermediate_joint = PinJoint(lower_link, upper_link, ...)
>>
>> joint_method = JointMethod((base_joint, intermediate_joint), ...)
>>
>> equations_of_motion = joint_method.generate_eoms(...)
>>
>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAJUjCNnYjAqYz6z_sSum_-WLAGwP0FNotfSQvwxotNKcqqqs_A%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I'm comfortable in implementing JointsMethod and it has some previous work
done too (unmerged GSoC work). All I would need is some guidance with
concepts if I get stuck somewhere and a good source to read about
JointsMethod. I have some knowledge of dynamics too so I think I can
implement it.

Sudeep Sidhu

On Tue, 9 Feb 2021, 15:28 Jason Moore,  wrote:

> I personally think completing the JointsMethod is of higher priority than
> the FeatherStone method. The JointsMethod would open up the use of the
> library to a much wider set of users because they will be able to construct
> models with less knowledge of the underlying mathematics. For example, a
> double compound pendulum could be created like this:
>
> ground = RigidBody(...)
> upper_link = RigidBody(...)
> lower_link = RigidBody(...)
>
> base_joint = PinJoin(ground, lower_link, ...)
> intermediate_joint = PinJoint(lower_link, upper_link, ...)
>
> joint_method = JointMethod((base_joint, intermediate_joint), ...)
>
> equations_of_motion = joint_method.generate_eoms(...)
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAJUjCN%3DQ-g3xHGG3JJJybmTtzVViWSmRRwAiAOjwakXGUZtXzQ%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

I personally think completing the JointsMethod is of higher priority than
the FeatherStone method. The JointsMethod would open up the use of the
library to a much wider set of users because they will be able to construct
models with less knowledge of the underlying mathematics. For example, a
double compound pendulum could be created like this:

ground = RigidBody(...)
upper_link = RigidBody(...)
lower_link = RigidBody(...)

base_joint = PinJoin(ground, lower_link, ...)
intermediate_joint = PinJoint(lower_link, upper_link, ...)

joint_method = JointMethod((base_joint, intermediate_joint), ...)

equations_of_motion = joint_method.generate_eoms(...)

Jason
moorepants.info
+01 530-601-9791


On Mon, Feb 8, 2021 at 2:37 PM Sudeep Sidhu 
wrote:

>
>
> On Mon, 8 Feb 2021, 19:00 Jason Moore,  wrote:
>
>> James worked with Featherstone's book "Rigid Body Dynamics Algorithms".
>> But I think that the spatial vector implementation used in simbody may be a
>> good thing to copy.
>>
>> I also think that focusing on improving end-user use of the software is
>> more bang for the buck and adding the Featherstone algorithm doesn't add
>> much for general users.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>
> So is Spatial Vector good to go as a GSoC project or shall I look for
> something else from mechanics/vectors ideas because may have a couple of
> more ideas in which I may be interested in other than Spatial Vectors.
>
> Sudeep Sidhu
>
> --
> 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/CAJUjCNnZaG17SAshVAVANcMbUMiGMKD4-Y0sr02TVfjZGhgsDQ%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/CAP7f1AgssaWT0O21qEO0crG_9yzzQ7nKmxDEgURGBjD_V55XvQ%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

On Mon, 8 Feb 2021, 19:00 Jason Moore,  wrote:

> James worked with Featherstone's book "Rigid Body Dynamics Algorithms".
> But I think that the spatial vector implementation used in simbody may be a
> good thing to copy.
>
> I also think that focusing on improving end-user use of the software is
> more bang for the buck and adding the Featherstone algorithm doesn't add
> much for general users.
>
> Jason
> moorepants.info
> +01 530-601-9791
>

So is Spatial Vector good to go as a GSoC project or shall I look for
something else from mechanics/vectors ideas because may have a couple of
more ideas in which I may be interested in other than Spatial Vectors.

Sudeep Sidhu

-- 
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/CAJUjCNnZaG17SAshVAVANcMbUMiGMKD4-Y0sr02TVfjZGhgsDQ%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

James worked with Featherstone's book "Rigid Body Dynamics Algorithms". But
I think that the spatial vector implementation used in simbody may be a
good thing to copy.

I also think that focusing on improving end-user use of the software is
more bang for the buck and adding the Featherstone algorithm doesn't add
much for general users.

Jason
moorepants.info
+01 530-601-9791


On Mon, Feb 8, 2021 at 1:58 PM Sudeep Sidhu 
wrote:

>
>
> On Mon, 8 Feb 2021, 18:24 Sudeep Sidhu, 
> wrote:
>
>> Jason,
>>
>> I would definitely like to work on physics mechanics/vectors project in
>> this summer as physics has been my favourite subject and I'm really eager
>> to learn more physics to code it and I think I can learn it myself while
>> coding plus you could help me if I get stuck somewhere.
>>
>> So which would be better to implement first, spatial vector or
>> Featherstone method? If possible can you please share notes or pdf link of
>> related topic as it would be nice to have a headstart.
>>
>
>>
>>
> I would really like to implement Spatial Vector in this year's GSoC . If
> possible please share a link of a good source to read and learn more about
> spatial vectors.
>
>>
>>
>>
>>
>>>
>>> On Mon, Feb 8, 2021, 12:50 Jason Moore  wrote:
>>>
 Sudeep,

 FeatherstoneMethod should not require any implementation of joints, I
 think it should work with knowledge of the rigid bodies and particles in a
 system and their relative kinematics. That would keep things general. I do
 think that a nice implementation of a spatial vector would provide the best
 foundation for building the Featherstone algorithm and allow it to work
 with the classes we have already established for describing the kinematics
 of a system.

 Jason
 moorepants.info
 +01 530-601-9791


 On Mon, Feb 8, 2021 at 9:08 AM Sudeep Sidhu 
 wrote:

> Jason,
>
> I would like to work in this realm in this year's GSoC.
>
> I went through Sahil Shekhewat's and James Milam's (jbm950) previous
> unmerged GSoC work and found out that(I may be wrong)  *FeatherStoneMethod
> *can't be added until we add fully working *JointsMethod* class and
> implement  *spatial vectors*.
>
> I would like to implement *Spatial Vectors* in this year's GSoC and
> would like to discuss it further.
>
> Sudeep Sidhu
>
>
>
>
>> On Sun, Feb 7, 2021 at 2:24 PM Jason Moore 
>> wrote:
>>
>>> Sudeep,
>>>
>>> The topics related to sympy.physics.vector/mechanics are still
>>> possibilities. I will have time to mentor this summer if someone wants 
>>> to
>>> do projects in this realm.
>>>
>>> We have not updated the ideas page yet for this year so those could
>>> be adjusted. Off the top of my head here are some things that I think 
>>> are
>>> priorities:
>>>
>>> - Finish and enhance the work of Sahil Shekhewat so that models can
>>> be built with body and joint specifications (unmerged GSOC work).
>>> - Finish and enhance the work of James Milam (jbm950) that adds a
>>> FeatherstoneMethod. This is one way to increase the computational
>>> efficiency. One thing that is missing are nice implementations of 
>>> spatial
>>> vectors and their operators.
>>> - Finish and enhance the work of Nikhil Pappu. The Autolev parser
>>> needs to be battle tested on some examples and bugs worked out. We need 
>>> the
>>> tests in the private gitlab repo to actually be run by SymPy. (merged, 
>>> but
>>> not polished GSOC work).
>>> - The Linearizer class was updated by James Crist, but I think it is
>>> effectively broken for more complex problems. This needs to be fixed 
>>> and we
>>> need examples of it working for systems with holonomic and nonholonomic
>>> constraints.
>>> - Improve symbolic computational speed. Hard examples need to be
>>> profiled and the Python implementations improved, work on the core
>>> differentiation algorithms to maximize speed, and ensure that optional
>>> dependencies on symengine function and help for hard problems.
>>> - Develop a more comprehensive set of examples. I've started
>>> creating more and migrating threse to the PyDy documentation:
>>> https://pydy.readthedocs.io/en/latest/#examples. One barrier to
>>> user adoption is the lack of examples that are clearly written that 
>>> cover
>>> all types of dynamic systems.
>>> - I've recently discovered that for some problems the resulting
>>> symbolic equations are in a form that results in numerical error
>>> accumulation in the arithmetic. This is problematic and figuring out 
>>> what
>>> this issue is and remedying it would be a nice improvement.
>>> - All of these PRs are hanging:
>>> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
>>> and it would 

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

On Mon, 8 Feb 2021, 18:24 Sudeep Sidhu,  wrote:

> Jason,
>
> I would definitely like to work on physics mechanics/vectors project in
> this summer as physics has been my favourite subject and I'm really eager
> to learn more physics to code it and I think I can learn it myself while
> coding plus you could help me if I get stuck somewhere.
>
> So which would be better to implement first, spatial vector or
> Featherstone method? If possible can you please share notes or pdf link of
> related topic as it would be nice to have a headstart.
>

>
>
I would really like to implement Spatial Vector in this year's GSoC . If
possible please share a link of a good source to read and learn more about
spatial vectors.

>
>
>
>
>>
>> On Mon, Feb 8, 2021, 12:50 Jason Moore  wrote:
>>
>>> Sudeep,
>>>
>>> FeatherstoneMethod should not require any implementation of joints, I
>>> think it should work with knowledge of the rigid bodies and particles in a
>>> system and their relative kinematics. That would keep things general. I do
>>> think that a nice implementation of a spatial vector would provide the best
>>> foundation for building the Featherstone algorithm and allow it to work
>>> with the classes we have already established for describing the kinematics
>>> of a system.
>>>
>>> Jason
>>> moorepants.info
>>> +01 530-601-9791
>>>
>>>
>>> On Mon, Feb 8, 2021 at 9:08 AM Sudeep Sidhu 
>>> wrote:
>>>
 Jason,

 I would like to work in this realm in this year's GSoC.

 I went through Sahil Shekhewat's and James Milam's (jbm950) previous
 unmerged GSoC work and found out that(I may be wrong)  *FeatherStoneMethod
 *can't be added until we add fully working *JointsMethod* class and
 implement  *spatial vectors*.

 I would like to implement *Spatial Vectors* in this year's GSoC and
 would like to discuss it further.

 Sudeep Sidhu




> On Sun, Feb 7, 2021 at 2:24 PM Jason Moore  wrote:
>
>> Sudeep,
>>
>> The topics related to sympy.physics.vector/mechanics are still
>> possibilities. I will have time to mentor this summer if someone wants to
>> do projects in this realm.
>>
>> We have not updated the ideas page yet for this year so those could
>> be adjusted. Off the top of my head here are some things that I think are
>> priorities:
>>
>> - Finish and enhance the work of Sahil Shekhewat so that models can
>> be built with body and joint specifications (unmerged GSOC work).
>> - Finish and enhance the work of James Milam (jbm950) that adds a
>> FeatherstoneMethod. This is one way to increase the computational
>> efficiency. One thing that is missing are nice implementations of spatial
>> vectors and their operators.
>> - Finish and enhance the work of Nikhil Pappu. The Autolev parser
>> needs to be battle tested on some examples and bugs worked out. We need 
>> the
>> tests in the private gitlab repo to actually be run by SymPy. (merged, 
>> but
>> not polished GSOC work).
>> - The Linearizer class was updated by James Crist, but I think it is
>> effectively broken for more complex problems. This needs to be fixed and 
>> we
>> need examples of it working for systems with holonomic and nonholonomic
>> constraints.
>> - Improve symbolic computational speed. Hard examples need to be
>> profiled and the Python implementations improved, work on the core
>> differentiation algorithms to maximize speed, and ensure that optional
>> dependencies on symengine function and help for hard problems.
>> - Develop a more comprehensive set of examples. I've started creating
>> more and migrating threse to the PyDy documentation:
>> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
>> adoption is the lack of examples that are clearly written that cover all
>> types of dynamic systems.
>> - I've recently discovered that for some problems the resulting
>> symbolic equations are in a form that results in numerical error
>> accumulation in the arithmetic. This is problematic and figuring out what
>> this issue is and remedying it would be a nice improvement.
>> - All of these PRs are hanging:
>> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
>> and it would be nice to resolve them and get them merged.
>> - If work can be done on PyDy, as has in the past, there are several
>> things there too 1) support DAEs, 2) improve the visualizer in a number 
>> of
>> ways, 3) migrate examples to jupyter-sphinx, etc.
>>
>> At this point, I'm generally in disfavor of proposing any new
>> features or extensions to the library over fixing and improving what we
>> already have. As you can see, we have several GSoC projects that were not
>> fully polished off or were not merged at all.
>>
>> Jason
>> moorepants.info

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I would definitely like to work on physics mechanics/vectors project in
this summer as physics has been my favourite subject and I'm really eager
to learn more physics to code it and I think I can learn it myself while
coding plus you could help me if I get stuck somewhere.

So which would be better to implement first, spatial vector or Featherstone
method? If possible can you please share notes or pdf link of related topic
as it would be nice to have a headstart.






>
> On Mon, Feb 8, 2021, 12:50 Jason Moore  wrote:
>
>> Sudeep,
>>
>> FeatherstoneMethod should not require any implementation of joints, I
>> think it should work with knowledge of the rigid bodies and particles in a
>> system and their relative kinematics. That would keep things general. I do
>> think that a nice implementation of a spatial vector would provide the best
>> foundation for building the Featherstone algorithm and allow it to work
>> with the classes we have already established for describing the kinematics
>> of a system.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Mon, Feb 8, 2021 at 9:08 AM Sudeep Sidhu 
>> wrote:
>>
>>> Jason,
>>>
>>> I would like to work in this realm in this year's GSoC.
>>>
>>> I went through Sahil Shekhewat's and James Milam's (jbm950) previous
>>> unmerged GSoC work and found out that(I may be wrong)  *FeatherStoneMethod
>>> *can't be added until we add fully working *JointsMethod* class and
>>> implement  *spatial vectors*.
>>>
>>> I would like to implement *Spatial Vectors* in this year's GSoC and
>>> would like to discuss it further.
>>>
>>> Sudeep Sidhu
>>>
>>>
>>>
>>>
 On Sun, Feb 7, 2021 at 2:24 PM Jason Moore  wrote:

> Sudeep,
>
> The topics related to sympy.physics.vector/mechanics are still
> possibilities. I will have time to mentor this summer if someone wants to
> do projects in this realm.
>
> We have not updated the ideas page yet for this year so those could be
> adjusted. Off the top of my head here are some things that I think are
> priorities:
>
> - Finish and enhance the work of Sahil Shekhewat so that models can be
> built with body and joint specifications (unmerged GSOC work).
> - Finish and enhance the work of James Milam (jbm950) that adds a
> FeatherstoneMethod. This is one way to increase the computational
> efficiency. One thing that is missing are nice implementations of spatial
> vectors and their operators.
> - Finish and enhance the work of Nikhil Pappu. The Autolev parser
> needs to be battle tested on some examples and bugs worked out. We need 
> the
> tests in the private gitlab repo to actually be run by SymPy. (merged, but
> not polished GSOC work).
> - The Linearizer class was updated by James Crist, but I think it is
> effectively broken for more complex problems. This needs to be fixed and 
> we
> need examples of it working for systems with holonomic and nonholonomic
> constraints.
> - Improve symbolic computational speed. Hard examples need to be
> profiled and the Python implementations improved, work on the core
> differentiation algorithms to maximize speed, and ensure that optional
> dependencies on symengine function and help for hard problems.
> - Develop a more comprehensive set of examples. I've started creating
> more and migrating threse to the PyDy documentation:
> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
> adoption is the lack of examples that are clearly written that cover all
> types of dynamic systems.
> - I've recently discovered that for some problems the resulting
> symbolic equations are in a form that results in numerical error
> accumulation in the arithmetic. This is problematic and figuring out what
> this issue is and remedying it would be a nice improvement.
> - All of these PRs are hanging:
> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
> and it would be nice to resolve them and get them merged.
> - If work can be done on PyDy, as has in the past, there are several
> things there too 1) support DAEs, 2) improve the visualizer in a number of
> ways, 3) migrate examples to jupyter-sphinx, etc.
>
> At this point, I'm generally in disfavor of proposing any new features
> or extensions to the library over fixing and improving what we already
> have. As you can see, we have several GSoC projects that were not fully
> polished off or were not merged at all.
>
> Jason
> moorepants.info
> +01 530-601-9791 <(530)%20601-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
> 

Re: [sympy] GSoC Idea discussion

[Mhd Ali]

Please someone should help me, doesn't some need to really know physics to
take on those projects relating to physics stuff

On Mon, Feb 8, 2021, 12:50 Jason Moore  wrote:

> Sudeep,
>
> FeatherstoneMethod should not require any implementation of joints, I
> think it should work with knowledge of the rigid bodies and particles in a
> system and their relative kinematics. That would keep things general. I do
> think that a nice implementation of a spatial vector would provide the best
> foundation for building the Featherstone algorithm and allow it to work
> with the classes we have already established for describing the kinematics
> of a system.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Mon, Feb 8, 2021 at 9:08 AM Sudeep Sidhu 
> wrote:
>
>> Jason,
>>
>> I would like to work in this realm in this year's GSoC.
>>
>> I went through Sahil Shekhewat's and James Milam's (jbm950) previous
>> unmerged GSoC work and found out that(I may be wrong)  *FeatherStoneMethod
>> *can't be added until we add fully working *JointsMethod* class and
>> implement  *spatial vectors*.
>>
>> I would like to implement *Spatial Vectors* in this year's GSoC and
>> would like to discuss it further.
>>
>> Sudeep Sidhu
>>
>>
>>
>>
>>> On Sun, Feb 7, 2021 at 2:24 PM Jason Moore  wrote:
>>>
 Sudeep,

 The topics related to sympy.physics.vector/mechanics are still
 possibilities. I will have time to mentor this summer if someone wants to
 do projects in this realm.

 We have not updated the ideas page yet for this year so those could be
 adjusted. Off the top of my head here are some things that I think are
 priorities:

 - Finish and enhance the work of Sahil Shekhewat so that models can be
 built with body and joint specifications (unmerged GSOC work).
 - Finish and enhance the work of James Milam (jbm950) that adds a
 FeatherstoneMethod. This is one way to increase the computational
 efficiency. One thing that is missing are nice implementations of spatial
 vectors and their operators.
 - Finish and enhance the work of Nikhil Pappu. The Autolev parser needs
 to be battle tested on some examples and bugs worked out. We need the tests
 in the private gitlab repo to actually be run by SymPy. (merged, but not
 polished GSOC work).
 - The Linearizer class was updated by James Crist, but I think it is
 effectively broken for more complex problems. This needs to be fixed and we
 need examples of it working for systems with holonomic and nonholonomic
 constraints.
 - Improve symbolic computational speed. Hard examples need to be
 profiled and the Python implementations improved, work on the core
 differentiation algorithms to maximize speed, and ensure that optional
 dependencies on symengine function and help for hard problems.
 - Develop a more comprehensive set of examples. I've started creating
 more and migrating threse to the PyDy documentation:
 https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
 adoption is the lack of examples that are clearly written that cover all
 types of dynamic systems.
 - I've recently discovered that for some problems the resulting
 symbolic equations are in a form that results in numerical error
 accumulation in the arithmetic. This is problematic and figuring out what
 this issue is and remedying it would be a nice improvement.
 - All of these PRs are hanging:
 https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
 and it would be nice to resolve them and get them merged.
 - If work can be done on PyDy, as has in the past, there are several
 things there too 1) support DAEs, 2) improve the visualizer in a number of
 ways, 3) migrate examples to jupyter-sphinx, etc.

 At this point, I'm generally in disfavor of proposing any new features
 or extensions to the library over fixing and improving what we already
 have. As you can see, we have several GSoC projects that were not fully
 polished off or were not merged at all.

 Jason
 moorepants.info
 +01 530-601-9791 <(530)%20601-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/CAP7f1AgguJTXrTiNpZVS-oe9-jT8BjeSqRiJRPCmbhj4mC4b5A%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 

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

FeatherstoneMethod should not require any implementation of joints, I think
it should work with knowledge of the rigid bodies and particles in a system
and their relative kinematics. That would keep things general. I do think
that a nice implementation of a spatial vector would provide the best
foundation for building the Featherstone algorithm and allow it to work
with the classes we have already established for describing the kinematics
of a system.

Jason
moorepants.info
+01 530-601-9791


On Mon, Feb 8, 2021 at 9:08 AM Sudeep Sidhu 
wrote:

> Jason,
>
> I would like to work in this realm in this year's GSoC.
>
> I went through Sahil Shekhewat's and James Milam's (jbm950) previous
> unmerged GSoC work and found out that(I may be wrong)  *FeatherStoneMethod
> *can't be added until we add fully working *JointsMethod* class and
> implement  *spatial vectors*.
>
> I would like to implement *Spatial Vectors* in this year's GSoC and would
> like to discuss it further.
>
> Sudeep Sidhu
>
>
>
>
>> On Sun, Feb 7, 2021 at 2:24 PM Jason Moore  wrote:
>>
>>> Sudeep,
>>>
>>> The topics related to sympy.physics.vector/mechanics are still
>>> possibilities. I will have time to mentor this summer if someone wants to
>>> do projects in this realm.
>>>
>>> We have not updated the ideas page yet for this year so those could be
>>> adjusted. Off the top of my head here are some things that I think are
>>> priorities:
>>>
>>> - Finish and enhance the work of Sahil Shekhewat so that models can be
>>> built with body and joint specifications (unmerged GSOC work).
>>> - Finish and enhance the work of James Milam (jbm950) that adds a
>>> FeatherstoneMethod. This is one way to increase the computational
>>> efficiency. One thing that is missing are nice implementations of spatial
>>> vectors and their operators.
>>> - Finish and enhance the work of Nikhil Pappu. The Autolev parser needs
>>> to be battle tested on some examples and bugs worked out. We need the tests
>>> in the private gitlab repo to actually be run by SymPy. (merged, but not
>>> polished GSOC work).
>>> - The Linearizer class was updated by James Crist, but I think it is
>>> effectively broken for more complex problems. This needs to be fixed and we
>>> need examples of it working for systems with holonomic and nonholonomic
>>> constraints.
>>> - Improve symbolic computational speed. Hard examples need to be
>>> profiled and the Python implementations improved, work on the core
>>> differentiation algorithms to maximize speed, and ensure that optional
>>> dependencies on symengine function and help for hard problems.
>>> - Develop a more comprehensive set of examples. I've started creating
>>> more and migrating threse to the PyDy documentation:
>>> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
>>> adoption is the lack of examples that are clearly written that cover all
>>> types of dynamic systems.
>>> - I've recently discovered that for some problems the resulting symbolic
>>> equations are in a form that results in numerical error accumulation in the
>>> arithmetic. This is problematic and figuring out what this issue is and
>>> remedying it would be a nice improvement.
>>> - All of these PRs are hanging:
>>> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
>>> and it would be nice to resolve them and get them merged.
>>> - If work can be done on PyDy, as has in the past, there are several
>>> things there too 1) support DAEs, 2) improve the visualizer in a number of
>>> ways, 3) migrate examples to jupyter-sphinx, etc.
>>>
>>> At this point, I'm generally in disfavor of proposing any new features
>>> or extensions to the library over fixing and improving what we already
>>> have. As you can see, we have several GSoC projects that were not fully
>>> polished off or were not merged at all.
>>>
>>> Jason
>>> moorepants.info
>>> +01 530-601-9791 <(530)%20601-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/CAP7f1AgguJTXrTiNpZVS-oe9-jT8BjeSqRiJRPCmbhj4mC4b5A%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/46e97251-1908-4bc4-af73-20faba189babn%40googlegroups.com
> 
> .
>

-- 

Re: [sympy] GSoC Idea discussion

[Jason Moore]

We've had students succeed that don't know physics well but are fast
learners. It really depends on your motivation, ability to self learn new
physics topics, and the project you plan to implement.

Jason
moorepants.info
+01 530-601-9791


On Sun, Feb 7, 2021 at 9:47 PM Mhd Ali  wrote:

> Hello,
> Does someone have to be really conversant with physics to handle a project
> like that?
>
>
> On Sun, Feb 7, 2021 at 2:24 PM Jason Moore  wrote:
>
>> Sudeep,
>>
>> The topics related to sympy.physics.vector/mechanics are still
>> possibilities. I will have time to mentor this summer if someone wants to
>> do projects in this realm.
>>
>> We have not updated the ideas page yet for this year so those could be
>> adjusted. Off the top of my head here are some things that I think are
>> priorities:
>>
>> - Finish and enhance the work of Sahil Shekhewat so that models can be
>> built with body and joint specifications (unmerged GSOC work).
>> - Finish and enhance the work of James Milam (jbm950) that adds a
>> FeatherstoneMethod. This is one way to increase the computational
>> efficiency. One thing that is missing are nice implementations of spatial
>> vectors and their operators.
>> - Finish and enhance the work of Nikhil Pappu. The Autolev parser needs
>> to be battle tested on some examples and bugs worked out. We need the tests
>> in the private gitlab repo to actually be run by SymPy. (merged, but not
>> polished GSOC work).
>> - The Linearizer class was updated by James Crist, but I think it is
>> effectively broken for more complex problems. This needs to be fixed and we
>> need examples of it working for systems with holonomic and nonholonomic
>> constraints.
>> - Improve symbolic computational speed. Hard examples need to be profiled
>> and the Python implementations improved, work on the core differentiation
>> algorithms to maximize speed, and ensure that optional dependencies on
>> symengine function and help for hard problems.
>> - Develop a more comprehensive set of examples. I've started creating
>> more and migrating threse to the PyDy documentation:
>> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
>> adoption is the lack of examples that are clearly written that cover all
>> types of dynamic systems.
>> - I've recently discovered that for some problems the resulting symbolic
>> equations are in a form that results in numerical error accumulation in the
>> arithmetic. This is problematic and figuring out what this issue is and
>> remedying it would be a nice improvement.
>> - All of these PRs are hanging:
>> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
>> and it would be nice to resolve them and get them merged.
>> - If work can be done on PyDy, as has in the past, there are several
>> things there too 1) support DAEs, 2) improve the visualizer in a number of
>> ways, 3) migrate examples to jupyter-sphinx, etc.
>>
>> At this point, I'm generally in disfavor of proposing any new features or
>> extensions to the library over fixing and improving what we already have.
>> As you can see, we have several GSoC projects that were not fully polished
>> off or were not merged at all.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>>
>>
>> On Sun, Feb 7, 2021 at 8:25 AM Sudeep Sidhu 
>> wrote:
>>
>>> Hi,
>>>
>>> While going through ideas , I found this idea , *Classical Mechanics:
>>> Efficient Equation of Motion Generation with Python*, very appealing .
>>> I wanted to know if this idea is outdated or is being considered for this
>>> year's GSoC .
>>>
>>> --
>>> 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/7f6f725c-a4a0-4c11-895b-a4eb1e83f837n%40googlegroups.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/CAP7f1AgguJTXrTiNpZVS-oe9-jT8BjeSqRiJRPCmbhj4mC4b5A%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
> 

Re: [sympy] GSoC Idea discussion

[Jason Moore]

For:

I would like to know if the idea, *Continuum Mechanics: Create a Rich 2D
> Beam Solving System*, will be considered this time or not.
> I would also like to know if it is better to
>

   - implement more features in the existing beam module
   - Or expand the continuum mechanics module to implement other structures
   like trusses and frames.

In general, I think fixing and improving what is there is the best
approach, especially for the new shorter GSoC period.

Jason
moorepants.info
+01 530-601-9791


On Sun, Feb 7, 2021 at 7:01 PM Psycho-Pirate 
wrote:

>
> Hi,
> I would like to know if the idea, *Continuum Mechanics: Create a Rich 2D
> Beam Solving System*, will be considered this time or not.
> I would also like to know if it is better to
>
>- implement more features in the existing beam module
>- Or expand the continuum mechanics module to implement other
>structures like trusses and frames.
>
> Due to the short coding period it won't be possible to implement both of
> the above.
>
> On Sunday, February 7, 2021 at 6:54:42 PM UTC+5:30 moore...@gmail.com
> wrote:
>
>> Sudeep,
>>
>> The topics related to sympy.physics.vector/mechanics are still
>> possibilities. I will have time to mentor this summer if someone wants to
>> do projects in this realm.
>>
>> We have not updated the ideas page yet for this year so those could be
>> adjusted. Off the top of my head here are some things that I think are
>> priorities:
>>
>> - Finish and enhance the work of Sahil Shekhewat so that models can be
>> built with body and joint specifications (unmerged GSOC work).
>> - Finish and enhance the work of James Milam (jbm950) that adds a
>> FeatherstoneMethod. This is one way to increase the computational
>> efficiency. One thing that is missing are nice implementations of spatial
>> vectors and their operators.
>> - Finish and enhance the work of Nikhil Pappu. The Autolev parser needs
>> to be battle tested on some examples and bugs worked out. We need the tests
>> in the private gitlab repo to actually be run by SymPy. (merged, but not
>> polished GSOC work).
>> - The Linearizer class was updated by James Crist, but I think it is
>> effectively broken for more complex problems. This needs to be fixed and we
>> need examples of it working for systems with holonomic and nonholonomic
>> constraints.
>> - Improve symbolic computational speed. Hard examples need to be profiled
>> and the Python implementations improved, work on the core differentiation
>> algorithms to maximize speed, and ensure that optional dependencies on
>> symengine function and help for hard problems.
>> - Develop a more comprehensive set of examples. I've started creating
>> more and migrating threse to the PyDy documentation:
>> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
>> adoption is the lack of examples that are clearly written that cover all
>> types of dynamic systems.
>> - I've recently discovered that for some problems the resulting symbolic
>> equations are in a form that results in numerical error accumulation in the
>> arithmetic. This is problematic and figuring out what this issue is and
>> remedying it would be a nice improvement.
>> - All of these PRs are hanging:
>> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
>> and it would be nice to resolve them and get them merged.
>> - If work can be done on PyDy, as has in the past, there are several
>> things there too 1) support DAEs, 2) improve the visualizer in a number of
>> ways, 3) migrate examples to jupyter-sphinx, etc.
>>
>> At this point, I'm generally in disfavor of proposing any new features or
>> extensions to the library over fixing and improving what we already have.
>> As you can see, we have several GSoC projects that were not fully polished
>> off or were not merged at all.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Sun, Feb 7, 2021 at 8:25 AM Sudeep Sidhu 
>> wrote:
>>
>>> Hi,
>>>
>>> While going through ideas , I found this idea , *Classical Mechanics:
>>> Efficient Equation of Motion Generation with Python*, very appealing .
>>> I wanted to know if this idea is outdated or is being considered for this
>>> year's GSoC .
>>>
>>> --
>>> 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/7f6f725c-a4a0-4c11-895b-a4eb1e83f837n%40googlegroups.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 

Re: [sympy] GSoC Idea discussion

[Sudeep Sidhu]

Jason,

I would like to work in this realm in this year's GSoC.

I went through Sahil Shekhewat's and James Milam's (jbm950) previous 
unmerged GSoC work and found out that(I may be wrong)  *FeatherStoneMethod 
*can't 
be added until we add fully working *JointsMethod* class and implement  
*spatial 
vectors*.

I would like to implement *Spatial Vectors* in this year's GSoC and would 
like to discuss it further.

Sudeep Sidhu




> On Sun, Feb 7, 2021 at 2:24 PM Jason Moore  wrote:
>
>> Sudeep,
>>
>> The topics related to sympy.physics.vector/mechanics are still 
>> possibilities. I will have time to mentor this summer if someone wants to 
>> do projects in this realm.
>>
>> We have not updated the ideas page yet for this year so those could be 
>> adjusted. Off the top of my head here are some things that I think are 
>> priorities:
>>
>> - Finish and enhance the work of Sahil Shekhewat so that models can be 
>> built with body and joint specifications (unmerged GSOC work).
>> - Finish and enhance the work of James Milam (jbm950) that adds a 
>> FeatherstoneMethod. This is one way to increase the computational 
>> efficiency. One thing that is missing are nice implementations of spatial 
>> vectors and their operators.
>> - Finish and enhance the work of Nikhil Pappu. The Autolev parser needs 
>> to be battle tested on some examples and bugs worked out. We need the tests 
>> in the private gitlab repo to actually be run by SymPy. (merged, but not 
>> polished GSOC work).
>> - The Linearizer class was updated by James Crist, but I think it is 
>> effectively broken for more complex problems. This needs to be fixed and we 
>> need examples of it working for systems with holonomic and nonholonomic 
>> constraints.
>> - Improve symbolic computational speed. Hard examples need to be profiled 
>> and the Python implementations improved, work on the core differentiation 
>> algorithms to maximize speed, and ensure that optional dependencies on 
>> symengine function and help for hard problems. 
>> - Develop a more comprehensive set of examples. I've started creating 
>> more and migrating threse to the PyDy documentation: 
>> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user 
>> adoption is the lack of examples that are clearly written that cover all 
>> types of dynamic systems.
>> - I've recently discovered that for some problems the resulting symbolic 
>> equations are in a form that results in numerical error accumulation in the 
>> arithmetic. This is problematic and figuring out what this issue is and 
>> remedying it would be a nice improvement.
>> - All of these PRs are hanging: 
>> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
>>  
>> and it would be nice to resolve them and get them merged.
>> - If work can be done on PyDy, as has in the past, there are several 
>> things there too 1) support DAEs, 2) improve the visualizer in a number of 
>> ways, 3) migrate examples to jupyter-sphinx, etc.
>>
>> At this point, I'm generally in disfavor of proposing any new features or 
>> extensions to the library over fixing and improving what we already have. 
>> As you can see, we have several GSoC projects that were not fully polished 
>> off or were not merged at all.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-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/CAP7f1AgguJTXrTiNpZVS-oe9-jT8BjeSqRiJRPCmbhj4mC4b5A%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/46e97251-1908-4bc4-af73-20faba189babn%40googlegroups.com.

Re: [sympy] GSoC Idea discussion

[Mhd Ali]

Hello,
Does someone have to be really conversant with physics to handle a project
like that?


On Sun, Feb 7, 2021 at 2:24 PM Jason Moore  wrote:

> Sudeep,
>
> The topics related to sympy.physics.vector/mechanics are still
> possibilities. I will have time to mentor this summer if someone wants to
> do projects in this realm.
>
> We have not updated the ideas page yet for this year so those could be
> adjusted. Off the top of my head here are some things that I think are
> priorities:
>
> - Finish and enhance the work of Sahil Shekhewat so that models can be
> built with body and joint specifications (unmerged GSOC work).
> - Finish and enhance the work of James Milam (jbm950) that adds a
> FeatherstoneMethod. This is one way to increase the computational
> efficiency. One thing that is missing are nice implementations of spatial
> vectors and their operators.
> - Finish and enhance the work of Nikhil Pappu. The Autolev parser needs to
> be battle tested on some examples and bugs worked out. We need the tests in
> the private gitlab repo to actually be run by SymPy. (merged, but not
> polished GSOC work).
> - The Linearizer class was updated by James Crist, but I think it is
> effectively broken for more complex problems. This needs to be fixed and we
> need examples of it working for systems with holonomic and nonholonomic
> constraints.
> - Improve symbolic computational speed. Hard examples need to be profiled
> and the Python implementations improved, work on the core differentiation
> algorithms to maximize speed, and ensure that optional dependencies on
> symengine function and help for hard problems.
> - Develop a more comprehensive set of examples. I've started creating more
> and migrating threse to the PyDy documentation:
> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
> adoption is the lack of examples that are clearly written that cover all
> types of dynamic systems.
> - I've recently discovered that for some problems the resulting symbolic
> equations are in a form that results in numerical error accumulation in the
> arithmetic. This is problematic and figuring out what this issue is and
> remedying it would be a nice improvement.
> - All of these PRs are hanging:
> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
> and it would be nice to resolve them and get them merged.
> - If work can be done on PyDy, as has in the past, there are several
> things there too 1) support DAEs, 2) improve the visualizer in a number of
> ways, 3) migrate examples to jupyter-sphinx, etc.
>
> At this point, I'm generally in disfavor of proposing any new features or
> extensions to the library over fixing and improving what we already have.
> As you can see, we have several GSoC projects that were not fully polished
> off or were not merged at all.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Sun, Feb 7, 2021 at 8:25 AM Sudeep Sidhu 
> wrote:
>
>> Hi,
>>
>> While going through ideas , I found this idea , *Classical Mechanics:
>> Efficient Equation of Motion Generation with Python*, very appealing . I
>> wanted to know if this idea is outdated or is being considered for this
>> year's GSoC .
>>
>> --
>> 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/7f6f725c-a4a0-4c11-895b-a4eb1e83f837n%40googlegroups.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/CAP7f1AgguJTXrTiNpZVS-oe9-jT8BjeSqRiJRPCmbhj4mC4b5A%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/CANV73fFWXeJqWNe8PWm4y5GC2F0%3DJyiNoN-HCz_uGnGfBx%3DZMw%40mail.gmail.com.

Re: [sympy] GSoC Idea discussion

[Psycho-Pirate]

Hi,
I would like to know if the idea, *Continuum Mechanics: Create a Rich 2D 
Beam Solving System*, will be considered this time or not.
I would also like to know if it is better to 

   - implement more features in the existing beam module 
   - Or expand the continuum mechanics module to implement other structures 
   like trusses and frames. 

Due to the short coding period it won't be possible to implement both of 
the above.

On Sunday, February 7, 2021 at 6:54:42 PM UTC+5:30 moore...@gmail.com wrote:

> Sudeep,
>
> The topics related to sympy.physics.vector/mechanics are still 
> possibilities. I will have time to mentor this summer if someone wants to 
> do projects in this realm.
>
> We have not updated the ideas page yet for this year so those could be 
> adjusted. Off the top of my head here are some things that I think are 
> priorities:
>
> - Finish and enhance the work of Sahil Shekhewat so that models can be 
> built with body and joint specifications (unmerged GSOC work).
> - Finish and enhance the work of James Milam (jbm950) that adds a 
> FeatherstoneMethod. This is one way to increase the computational 
> efficiency. One thing that is missing are nice implementations of spatial 
> vectors and their operators.
> - Finish and enhance the work of Nikhil Pappu. The Autolev parser needs to 
> be battle tested on some examples and bugs worked out. We need the tests in 
> the private gitlab repo to actually be run by SymPy. (merged, but not 
> polished GSOC work).
> - The Linearizer class was updated by James Crist, but I think it is 
> effectively broken for more complex problems. This needs to be fixed and we 
> need examples of it working for systems with holonomic and nonholonomic 
> constraints.
> - Improve symbolic computational speed. Hard examples need to be profiled 
> and the Python implementations improved, work on the core differentiation 
> algorithms to maximize speed, and ensure that optional dependencies on 
> symengine function and help for hard problems. 
> - Develop a more comprehensive set of examples. I've started creating more 
> and migrating threse to the PyDy documentation: 
> https://pydy.readthedocs.io/en/latest/#examples. One barrier to user 
> adoption is the lack of examples that are clearly written that cover all 
> types of dynamic systems.
> - I've recently discovered that for some problems the resulting symbolic 
> equations are in a form that results in numerical error accumulation in the 
> arithmetic. This is problematic and figuring out what this issue is and 
> remedying it would be a nice improvement.
> - All of these PRs are hanging: 
> https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
>  
> and it would be nice to resolve them and get them merged.
> - If work can be done on PyDy, as has in the past, there are several 
> things there too 1) support DAEs, 2) improve the visualizer in a number of 
> ways, 3) migrate examples to jupyter-sphinx, etc.
>
> At this point, I'm generally in disfavor of proposing any new features or 
> extensions to the library over fixing and improving what we already have. 
> As you can see, we have several GSoC projects that were not fully polished 
> off or were not merged at all.
>
> Jason
> moorepants.info
> +01 530-601-9791 <(530)%20601-9791>
>
>
> On Sun, Feb 7, 2021 at 8:25 AM Sudeep Sidhu  wrote:
>
>> Hi, 
>>
>> While going through ideas , I found this idea , *Classical Mechanics: 
>> Efficient Equation of Motion Generation with Python*, very appealing . I 
>> wanted to know if this idea is outdated or is being considered for this 
>> year's GSoC .
>>
>> -- 
>> 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/7f6f725c-a4a0-4c11-895b-a4eb1e83f837n%40googlegroups.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/4dfce88f-13ac-4b8f-a295-e3db775ca74cn%40googlegroups.com.

Re: [sympy] GSoC Idea discussion

[Jason Moore]

Sudeep,

The topics related to sympy.physics.vector/mechanics are still
possibilities. I will have time to mentor this summer if someone wants to
do projects in this realm.

We have not updated the ideas page yet for this year so those could be
adjusted. Off the top of my head here are some things that I think are
priorities:

- Finish and enhance the work of Sahil Shekhewat so that models can be
built with body and joint specifications (unmerged GSOC work).
- Finish and enhance the work of James Milam (jbm950) that adds a
FeatherstoneMethod. This is one way to increase the computational
efficiency. One thing that is missing are nice implementations of spatial
vectors and their operators.
- Finish and enhance the work of Nikhil Pappu. The Autolev parser needs to
be battle tested on some examples and bugs worked out. We need the tests in
the private gitlab repo to actually be run by SymPy. (merged, but not
polished GSOC work).
- The Linearizer class was updated by James Crist, but I think it is
effectively broken for more complex problems. This needs to be fixed and we
need examples of it working for systems with holonomic and nonholonomic
constraints.
- Improve symbolic computational speed. Hard examples need to be profiled
and the Python implementations improved, work on the core differentiation
algorithms to maximize speed, and ensure that optional dependencies on
symengine function and help for hard problems.
- Develop a more comprehensive set of examples. I've started creating more
and migrating threse to the PyDy documentation:
https://pydy.readthedocs.io/en/latest/#examples. One barrier to user
adoption is the lack of examples that are clearly written that cover all
types of dynamic systems.
- I've recently discovered that for some problems the resulting symbolic
equations are in a form that results in numerical error accumulation in the
arithmetic. This is problematic and figuring out what this issue is and
remedying it would be a nice improvement.
- All of these PRs are hanging:
https://github.com/sympy/sympy/pulls?q=is%3Aopen+is%3Apr+label%3Aphysics.mechanics
and it would be nice to resolve them and get them merged.
- If work can be done on PyDy, as has in the past, there are several things
there too 1) support DAEs, 2) improve the visualizer in a number of ways,
3) migrate examples to jupyter-sphinx, etc.

At this point, I'm generally in disfavor of proposing any new features or
extensions to the library over fixing and improving what we already have.
As you can see, we have several GSoC projects that were not fully polished
off or were not merged at all.

Jason
moorepants.info
+01 530-601-9791


On Sun, Feb 7, 2021 at 8:25 AM Sudeep Sidhu 
wrote:

> Hi,
>
> While going through ideas , I found this idea , *Classical Mechanics:
> Efficient Equation of Motion Generation with Python*, very appealing . I
> wanted to know if this idea is outdated or is being considered for this
> year's GSoC .
>
> --
> 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/7f6f725c-a4a0-4c11-895b-a4eb1e83f837n%40googlegroups.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/CAP7f1AgguJTXrTiNpZVS-oe9-jT8BjeSqRiJRPCmbhj4mC4b5A%40mail.gmail.com.