Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Thank you for response. So should i submit this proposal?
On Thu, Mar 26, 2020, 3:20 AM Oscar Benjamin
wrote:
> I had a quick look and it seems reasonable.
>
> On Wed, 25 Mar 2020 at 16:11, mohit balwani
> wrote:
> >
> > Hello everyone,
> >
> > I have made a final draft proposal on "Refactoring the ODE module and
> make it fast". If someone can please review this and suggest changes so
> that I can incorporate them accordingly before the GSoC timeline.
> >
> > link:
> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=sharing
> > waiting for the feedback.
> > Thanks.
> >
> >
> > On Fri, Mar 20, 2020 at 1:55 PM mohit balwani <
> mohitbalwani.ic...@gmail.com> wrote:
> >>
> >> +oscar.j.benja...@gmail.com I have made changes you suggested about
> refactoring test_ode.py in phase-I. could you please review it again?
> >>
> >> On Sun, Mar 15, 2020 at 7:40 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>>
> >>> I think it would be better to refactor the tests at the start as in
> >>> https://github.com/sympy/sympy/issues/18377
> >>> That can significantly increase test coverage which gives more
> >>> confidence when refactoring everything else. It would also make it
> >>> possible to compare timings before and after the refactor.
> >>>
> >>> On Sun, 15 Mar 2020 at 11:51, mohit balwani
> >>> wrote:
> >>> >
> >>> > +oscar.j.benja...@gmail.com can you please review the changes in
> proposal so that i know what i need to make changes in it?
> >>> > On Friday, March 13, 2020 at 10:27:39 PM UTC+5:30, mohit balwani
> wrote:
> >>> >>
> >>> >> hello,
> >>> >> I have made some changes in project motivation. Does this look
> good or Should I detail that more?
> >>> >>
> >>> >> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>> >>>
> >>> >>> I think it would be good to spend more time explaining what changes
> >>> >>> you will make and why.
> >>> >>>
> >>> >>> Don't assume that someone reviewing this proposal will understand
> the
> >>> >>> current problems of the ODE module or why your proposal is
> beneficial.
> >>> >>> You should make it clear to them what the problems are and how your
> >>> >>> proposed changes will lead to tangible improvements. (This advice
> >>> >>> applies to all GSOC applicants)
> >>> >>>
> >>> >>> --
> >>> >>> Oscar
> >>> >>>
> >>> >>> On Wed, 11 Mar 2020 at 19:19, mohit balwani
> >>> >>> wrote:
> >>> >>> >
> >>> >>> > Hi,
> >>> >>> >
> >>> >>> > Here is rough draft of my GSoC proposal
> >>> >>> >
> >>> >>> >
> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
> >>> >>> >
> >>> >>> > Any suggestions would really be appreciated.
> >>> >>> >
> >>> >>> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>> >>> >>
> >>> >>> >> Hi Mohit,
> >>> >>> >>
> >>> >>> >> You don't need to resend the previous emails. This discussion is
> >>> >>> >> becoming too detailed though and belongs on the Github issue for
> >>> >>> >> refactoring the ODE module:
> >>> >>> >> https://github.com/sympy/sympy/issues/18348
> >>> >>> >>
> >>> >>> >> Oscar
> >>> >>> >>
> >>> >>> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
> >>> >>> >> wrote:
> >>> >>> >> >
> >>> >>> >> > hello,
> >>> >>> >> >
> >>> >>> >> > so should I resend the previous mail to the mailing list?
> >>> >>> >> >
> >>> >>> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani <
> mohitbalwani.ic...@gmail.com> wrote:
> >>> >>> >> >>
> >>> >>> >> >> For pattern matching, I kept in mind that we can extract the
> elements of our general solution from the equation with direct matching
> just like First_linear. And for `SingleODESolver` there will be proper
> logic checking whether the given equation matches or not.
> >>> >>> >> >>
> >>> >>> >> >> I am a bit confused about how all linear solvers can be
> based on pattern because
> >>> >>> >> >> let's say we want to implement
> `nth_linear_constant_coeff_undetermined_coefficients`.
> >>> >>> >> >> its general equation is
> >>> >>> >> >>
> >>> >>> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x)
> + a_0 f(x) = P(x)
> >>> >>> >> >>
> >>> >>> >> >> Now p(x) needs to have a finite number of linearly
> independent derivatives and in pattern matching to write general solution
> we should use the extracted elements given by wilds function.
> >>> >>> >> >>
> >>> >>> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>> >>> >> >>>
> >>> >>> >> >>> I think the series solvers should probably have their own
> superclass.
> >>> >>> >> >>> I'd like to move them out of normal dsolve anyway.
> >>> >>> >> >>>
> >>> >>> >> >>> Of the others I think that probably all the linear ones can
> be based
> >>> >>> >> >>> on the Pattern solver. You should give a rationale for why
> you have
> >>> >>> >> >>> divided them up like this.
> >>> >>> >> >>>
> >>> >>> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit b
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
I had a quick look and it seems reasonable.
On Wed, 25 Mar 2020 at 16:11, mohit balwani
wrote:
>
> Hello everyone,
>
> I have made a final draft proposal on "Refactoring the ODE module and make it
> fast". If someone can please review this and suggest changes so that I can
> incorporate them accordingly before the GSoC timeline.
>
> link:
> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=sharing
> waiting for the feedback.
> Thanks.
>
>
> On Fri, Mar 20, 2020 at 1:55 PM mohit balwani
> wrote:
>>
>> +oscar.j.benja...@gmail.com I have made changes you suggested about
>> refactoring test_ode.py in phase-I. could you please review it again?
>>
>> On Sun, Mar 15, 2020 at 7:40 PM Oscar Benjamin
>> wrote:
>>>
>>> I think it would be better to refactor the tests at the start as in
>>> https://github.com/sympy/sympy/issues/18377
>>> That can significantly increase test coverage which gives more
>>> confidence when refactoring everything else. It would also make it
>>> possible to compare timings before and after the refactor.
>>>
>>> On Sun, 15 Mar 2020 at 11:51, mohit balwani
>>> wrote:
>>> >
>>> > +oscar.j.benja...@gmail.com can you please review the changes in proposal
>>> > so that i know what i need to make changes in it?
>>> > On Friday, March 13, 2020 at 10:27:39 PM UTC+5:30, mohit balwani wrote:
>>> >>
>>> >> hello,
>>> >> I have made some changes in project motivation. Does this look good or
>>> >> Should I detail that more?
>>> >>
>>> >> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin
>>> >> wrote:
>>> >>>
>>> >>> I think it would be good to spend more time explaining what changes
>>> >>> you will make and why.
>>> >>>
>>> >>> Don't assume that someone reviewing this proposal will understand the
>>> >>> current problems of the ODE module or why your proposal is beneficial.
>>> >>> You should make it clear to them what the problems are and how your
>>> >>> proposed changes will lead to tangible improvements. (This advice
>>> >>> applies to all GSOC applicants)
>>> >>>
>>> >>> --
>>> >>> Oscar
>>> >>>
>>> >>> On Wed, 11 Mar 2020 at 19:19, mohit balwani
>>> >>> wrote:
>>> >>> >
>>> >>> > Hi,
>>> >>> >
>>> >>> > Here is rough draft of my GSoC proposal
>>> >>> >
>>> >>> > https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
>>> >>> >
>>> >>> > Any suggestions would really be appreciated.
>>> >>> >
>>> >>> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Hi Mohit,
>>> >>> >>
>>> >>> >> You don't need to resend the previous emails. This discussion is
>>> >>> >> becoming too detailed though and belongs on the Github issue for
>>> >>> >> refactoring the ODE module:
>>> >>> >> https://github.com/sympy/sympy/issues/18348
>>> >>> >>
>>> >>> >> Oscar
>>> >>> >>
>>> >>> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
>>> >>> >> wrote:
>>> >>> >> >
>>> >>> >> > hello,
>>> >>> >> >
>>> >>> >> > so should I resend the previous mail to the mailing list?
>>> >>> >> >
>>> >>> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani
>>> >>> >> > wrote:
>>> >>> >> >>
>>> >>> >> >> For pattern matching, I kept in mind that we can extract the
>>> >>> >> >> elements of our general solution from the equation with direct
>>> >>> >> >> matching just like First_linear. And for `SingleODESolver` there
>>> >>> >> >> will be proper logic checking whether the given equation matches
>>> >>> >> >> or not.
>>> >>> >> >>
>>> >>> >> >> I am a bit confused about how all linear solvers can be based on
>>> >>> >> >> pattern because
>>> >>> >> >> let's say we want to implement
>>> >>> >> >> `nth_linear_constant_coeff_undetermined_coefficients`.
>>> >>> >> >> its general equation is
>>> >>> >> >>
>>> >>> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0
>>> >>> >> >> f(x) = P(x)
>>> >>> >> >>
>>> >>> >> >> Now p(x) needs to have a finite number of linearly independent
>>> >>> >> >> derivatives and in pattern matching to write general solution we
>>> >>> >> >> should use the extracted elements given by wilds function.
>>> >>> >> >>
>>> >>> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin
>>> >>> >> >> wrote:
>>> >>> >> >>>
>>> >>> >> >>> I think the series solvers should probably have their own
>>> >>> >> >>> superclass.
>>> >>> >> >>> I'd like to move them out of normal dsolve anyway.
>>> >>> >> >>>
>>> >>> >> >>> Of the others I think that probably all the linear ones can be
>>> >>> >> >>> based
>>> >>> >> >>> on the Pattern solver. You should give a rationale for why you
>>> >>> >> >>> have
>>> >>> >> >>> divided them up like this.
>>> >>> >> >>>
>>> >>> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>>> >>> >> >>> wrote:
>>> >>> >> >>> >
>>> >>> >> >>> > Hi,
>>> >>> >> >>> > currently, there are 28 solvers in the ODE module out of which
>>> >>> >> >>> > 6 solvers have been refactored already.
>>> >>> >> >>> >
>>> >>> >> >>> > I have classified the remaining 22 so
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Hello everyone,
I have made a final draft proposal on "Refactoring the ODE module and make
it fast". If someone can please review this and suggest changes so that I
can incorporate them accordingly before the GSoC timeline.
link:
https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=sharing
waiting for the feedback.
Thanks.
On Fri, Mar 20, 2020 at 1:55 PM mohit balwani
wrote:
> +oscar.j.benja...@gmail.com I have made changes you suggested about
> refactoring test_ode.py in phase-I. could you please review it again?
>
> On Sun, Mar 15, 2020 at 7:40 PM Oscar Benjamin
> wrote:
>
>> I think it would be better to refactor the tests at the start as in
>> https://github.com/sympy/sympy/issues/18377
>> That can significantly increase test coverage which gives more
>> confidence when refactoring everything else. It would also make it
>> possible to compare timings before and after the refactor.
>>
>> On Sun, 15 Mar 2020 at 11:51, mohit balwani
>> wrote:
>> >
>> > +oscar.j.benja...@gmail.com can you please review the changes in
>> proposal so that i know what i need to make changes in it?
>> > On Friday, March 13, 2020 at 10:27:39 PM UTC+5:30, mohit balwani wrote:
>> >>
>> >> hello,
>> >> I have made some changes in project motivation. Does this look good
>> or Should I detail that more?
>> >>
>> >> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>>
>> >>> I think it would be good to spend more time explaining what changes
>> >>> you will make and why.
>> >>>
>> >>> Don't assume that someone reviewing this proposal will understand the
>> >>> current problems of the ODE module or why your proposal is beneficial.
>> >>> You should make it clear to them what the problems are and how your
>> >>> proposed changes will lead to tangible improvements. (This advice
>> >>> applies to all GSOC applicants)
>> >>>
>> >>> --
>> >>> Oscar
>> >>>
>> >>> On Wed, 11 Mar 2020 at 19:19, mohit balwani
>> >>> wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> > Here is rough draft of my GSoC proposal
>> >>> >
>> >>> >
>> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
>> >>> >
>> >>> > Any suggestions would really be appreciated.
>> >>> >
>> >>> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>> >>
>> >>> >> Hi Mohit,
>> >>> >>
>> >>> >> You don't need to resend the previous emails. This discussion is
>> >>> >> becoming too detailed though and belongs on the Github issue for
>> >>> >> refactoring the ODE module:
>> >>> >> https://github.com/sympy/sympy/issues/18348
>> >>> >>
>> >>> >> Oscar
>> >>> >>
>> >>> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
>> >>> >> wrote:
>> >>> >> >
>> >>> >> > hello,
>> >>> >> >
>> >>> >> > so should I resend the previous mail to the mailing list?
>> >>> >> >
>> >>> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani <
>> mohitbalwani.ic...@gmail.com> wrote:
>> >>> >> >>
>> >>> >> >> For pattern matching, I kept in mind that we can extract the
>> elements of our general solution from the equation with direct matching
>> just like First_linear. And for `SingleODESolver` there will be proper
>> logic checking whether the given equation matches or not.
>> >>> >> >>
>> >>> >> >> I am a bit confused about how all linear solvers can be based
>> on pattern because
>> >>> >> >> let's say we want to implement
>> `nth_linear_constant_coeff_undetermined_coefficients`.
>> >>> >> >> its general equation is
>> >>> >> >>
>> >>> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) +
>> a_0 f(x) = P(x)
>> >>> >> >>
>> >>> >> >> Now p(x) needs to have a finite number of linearly independent
>> derivatives and in pattern matching to write general solution we should use
>> the extracted elements given by wilds function.
>> >>> >> >>
>> >>> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>> >> >>>
>> >>> >> >>> I think the series solvers should probably have their own
>> superclass.
>> >>> >> >>> I'd like to move them out of normal dsolve anyway.
>> >>> >> >>>
>> >>> >> >>> Of the others I think that probably all the linear ones can be
>> based
>> >>> >> >>> on the Pattern solver. You should give a rationale for why you
>> have
>> >>> >> >>> divided them up like this.
>> >>> >> >>>
>> >>> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>> >>> >> >>> wrote:
>> >>> >> >>> >
>> >>> >> >>> > Hi,
>> >>> >> >>> > currently, there are 28 solvers in the ODE module out of
>> which 6 solvers have been refactored already.
>> >>> >> >>> >
>> >>> >> >>> > I have classified the remaining 22 solvers on the basis of
>> their parent class whether they should inherit SinglePatternODESolver or
>> SingleODESolver
>> >>> >> >>> >
>> >>> >> >>> > SinglePatternODESolver
>> >>> >> >>> >
>> >>> >> >>> > separable
>> >>> >> >>> > separable_reduced
>> >>> >> >>> > linear_coefficients
>> >>> >> >>> > Liouville
>>
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=sharing
can someone provide feedback on this?
On Fri, Mar 20, 2020 at 1:55 PM mohit balwani
wrote:
> +oscar.j.benja...@gmail.com I have made changes you suggested about
> refactoring test_ode.py in phase-I. could you please review it again?
>
> On Sun, Mar 15, 2020 at 7:40 PM Oscar Benjamin
> wrote:
>
>> I think it would be better to refactor the tests at the start as in
>> https://github.com/sympy/sympy/issues/18377
>> That can significantly increase test coverage which gives more
>> confidence when refactoring everything else. It would also make it
>> possible to compare timings before and after the refactor.
>>
>> On Sun, 15 Mar 2020 at 11:51, mohit balwani
>> wrote:
>> >
>> > +oscar.j.benja...@gmail.com can you please review the changes in
>> proposal so that i know what i need to make changes in it?
>> > On Friday, March 13, 2020 at 10:27:39 PM UTC+5:30, mohit balwani wrote:
>> >>
>> >> hello,
>> >> I have made some changes in project motivation. Does this look good
>> or Should I detail that more?
>> >>
>> >> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>>
>> >>> I think it would be good to spend more time explaining what changes
>> >>> you will make and why.
>> >>>
>> >>> Don't assume that someone reviewing this proposal will understand the
>> >>> current problems of the ODE module or why your proposal is beneficial.
>> >>> You should make it clear to them what the problems are and how your
>> >>> proposed changes will lead to tangible improvements. (This advice
>> >>> applies to all GSOC applicants)
>> >>>
>> >>> --
>> >>> Oscar
>> >>>
>> >>> On Wed, 11 Mar 2020 at 19:19, mohit balwani
>> >>> wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> > Here is rough draft of my GSoC proposal
>> >>> >
>> >>> >
>> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
>> >>> >
>> >>> > Any suggestions would really be appreciated.
>> >>> >
>> >>> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>> >>
>> >>> >> Hi Mohit,
>> >>> >>
>> >>> >> You don't need to resend the previous emails. This discussion is
>> >>> >> becoming too detailed though and belongs on the Github issue for
>> >>> >> refactoring the ODE module:
>> >>> >> https://github.com/sympy/sympy/issues/18348
>> >>> >>
>> >>> >> Oscar
>> >>> >>
>> >>> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
>> >>> >> wrote:
>> >>> >> >
>> >>> >> > hello,
>> >>> >> >
>> >>> >> > so should I resend the previous mail to the mailing list?
>> >>> >> >
>> >>> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani <
>> mohitbalwani.ic...@gmail.com> wrote:
>> >>> >> >>
>> >>> >> >> For pattern matching, I kept in mind that we can extract the
>> elements of our general solution from the equation with direct matching
>> just like First_linear. And for `SingleODESolver` there will be proper
>> logic checking whether the given equation matches or not.
>> >>> >> >>
>> >>> >> >> I am a bit confused about how all linear solvers can be based
>> on pattern because
>> >>> >> >> let's say we want to implement
>> `nth_linear_constant_coeff_undetermined_coefficients`.
>> >>> >> >> its general equation is
>> >>> >> >>
>> >>> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) +
>> a_0 f(x) = P(x)
>> >>> >> >>
>> >>> >> >> Now p(x) needs to have a finite number of linearly independent
>> derivatives and in pattern matching to write general solution we should use
>> the extracted elements given by wilds function.
>> >>> >> >>
>> >>> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>> >> >>>
>> >>> >> >>> I think the series solvers should probably have their own
>> superclass.
>> >>> >> >>> I'd like to move them out of normal dsolve anyway.
>> >>> >> >>>
>> >>> >> >>> Of the others I think that probably all the linear ones can be
>> based
>> >>> >> >>> on the Pattern solver. You should give a rationale for why you
>> have
>> >>> >> >>> divided them up like this.
>> >>> >> >>>
>> >>> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>> >>> >> >>> wrote:
>> >>> >> >>> >
>> >>> >> >>> > Hi,
>> >>> >> >>> > currently, there are 28 solvers in the ODE module out of
>> which 6 solvers have been refactored already.
>> >>> >> >>> >
>> >>> >> >>> > I have classified the remaining 22 solvers on the basis of
>> their parent class whether they should inherit SinglePatternODESolver or
>> SingleODESolver
>> >>> >> >>> >
>> >>> >> >>> > SinglePatternODESolver
>> >>> >> >>> >
>> >>> >> >>> > separable
>> >>> >> >>> > separable_reduced
>> >>> >> >>> > linear_coefficients
>> >>> >> >>> > Liouville
>> >>> >> >>> > 2nd_linear_airy
>> >>> >> >>> > 2nd_linear_bessel
>> >>> >> >>> > 2nd_hypergeometrics
>> >>> >> >>> >
>> >>> >> >>> > SingleODESolver
>> >>> >> >>> >
>> >>> >> >>> > 1st_exact
>> >>> >> >>> > 1st_homogeneous_coeff_s
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
+oscar.j.benja...@gmail.com I have made changes you suggested about
refactoring test_ode.py in phase-I. could you please review it again?
On Sun, Mar 15, 2020 at 7:40 PM Oscar Benjamin
wrote:
> I think it would be better to refactor the tests at the start as in
> https://github.com/sympy/sympy/issues/18377
> That can significantly increase test coverage which gives more
> confidence when refactoring everything else. It would also make it
> possible to compare timings before and after the refactor.
>
> On Sun, 15 Mar 2020 at 11:51, mohit balwani
> wrote:
> >
> > +oscar.j.benja...@gmail.com can you please review the changes in
> proposal so that i know what i need to make changes in it?
> > On Friday, March 13, 2020 at 10:27:39 PM UTC+5:30, mohit balwani wrote:
> >>
> >> hello,
> >> I have made some changes in project motivation. Does this look good or
> Should I detail that more?
> >>
> >> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>>
> >>> I think it would be good to spend more time explaining what changes
> >>> you will make and why.
> >>>
> >>> Don't assume that someone reviewing this proposal will understand the
> >>> current problems of the ODE module or why your proposal is beneficial.
> >>> You should make it clear to them what the problems are and how your
> >>> proposed changes will lead to tangible improvements. (This advice
> >>> applies to all GSOC applicants)
> >>>
> >>> --
> >>> Oscar
> >>>
> >>> On Wed, 11 Mar 2020 at 19:19, mohit balwani
> >>> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Here is rough draft of my GSoC proposal
> >>> >
> >>> >
> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
> >>> >
> >>> > Any suggestions would really be appreciated.
> >>> >
> >>> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>> >>
> >>> >> Hi Mohit,
> >>> >>
> >>> >> You don't need to resend the previous emails. This discussion is
> >>> >> becoming too detailed though and belongs on the Github issue for
> >>> >> refactoring the ODE module:
> >>> >> https://github.com/sympy/sympy/issues/18348
> >>> >>
> >>> >> Oscar
> >>> >>
> >>> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
> >>> >> wrote:
> >>> >> >
> >>> >> > hello,
> >>> >> >
> >>> >> > so should I resend the previous mail to the mailing list?
> >>> >> >
> >>> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani <
> mohitbalwani.ic...@gmail.com> wrote:
> >>> >> >>
> >>> >> >> For pattern matching, I kept in mind that we can extract the
> elements of our general solution from the equation with direct matching
> just like First_linear. And for `SingleODESolver` there will be proper
> logic checking whether the given equation matches or not.
> >>> >> >>
> >>> >> >> I am a bit confused about how all linear solvers can be based on
> pattern because
> >>> >> >> let's say we want to implement
> `nth_linear_constant_coeff_undetermined_coefficients`.
> >>> >> >> its general equation is
> >>> >> >>
> >>> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) +
> a_0 f(x) = P(x)
> >>> >> >>
> >>> >> >> Now p(x) needs to have a finite number of linearly independent
> derivatives and in pattern matching to write general solution we should use
> the extracted elements given by wilds function.
> >>> >> >>
> >>> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>> >> >>>
> >>> >> >>> I think the series solvers should probably have their own
> superclass.
> >>> >> >>> I'd like to move them out of normal dsolve anyway.
> >>> >> >>>
> >>> >> >>> Of the others I think that probably all the linear ones can be
> based
> >>> >> >>> on the Pattern solver. You should give a rationale for why you
> have
> >>> >> >>> divided them up like this.
> >>> >> >>>
> >>> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
> >>> >> >>> wrote:
> >>> >> >>> >
> >>> >> >>> > Hi,
> >>> >> >>> > currently, there are 28 solvers in the ODE module out of
> which 6 solvers have been refactored already.
> >>> >> >>> >
> >>> >> >>> > I have classified the remaining 22 solvers on the basis of
> their parent class whether they should inherit SinglePatternODESolver or
> SingleODESolver
> >>> >> >>> >
> >>> >> >>> > SinglePatternODESolver
> >>> >> >>> >
> >>> >> >>> > separable
> >>> >> >>> > separable_reduced
> >>> >> >>> > linear_coefficients
> >>> >> >>> > Liouville
> >>> >> >>> > 2nd_linear_airy
> >>> >> >>> > 2nd_linear_bessel
> >>> >> >>> > 2nd_hypergeometrics
> >>> >> >>> >
> >>> >> >>> > SingleODESolver
> >>> >> >>> >
> >>> >> >>> > 1st_exact
> >>> >> >>> > 1st_homogeneous_coeff_subs_indep_div_dep
> >>> >> >>> > 1st_homogeneous_coeff_subs_dep_div_indep
> >>> >> >>> > 1st_power_series
> >>> >> >>> > 2nd_power_series_ordinary
> >>> >> >>> > 2nd_power_series_regular
> >>> >> >>> > nth_linear_constant_coeff_homogeneous
> >>> >> >>> > nth_linear_euler_eq_homogeneous
> >>> >> >>> > nth_linear_constant_c
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
I think it would be better to refactor the tests at the start as in
https://github.com/sympy/sympy/issues/18377
That can significantly increase test coverage which gives more
confidence when refactoring everything else. It would also make it
possible to compare timings before and after the refactor.
On Sun, 15 Mar 2020 at 11:51, mohit balwani
wrote:
>
> +oscar.j.benja...@gmail.com can you please review the changes in proposal so
> that i know what i need to make changes in it?
> On Friday, March 13, 2020 at 10:27:39 PM UTC+5:30, mohit balwani wrote:
>>
>> hello,
>> I have made some changes in project motivation. Does this look good or
>> Should I detail that more?
>>
>> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin
>> wrote:
>>>
>>> I think it would be good to spend more time explaining what changes
>>> you will make and why.
>>>
>>> Don't assume that someone reviewing this proposal will understand the
>>> current problems of the ODE module or why your proposal is beneficial.
>>> You should make it clear to them what the problems are and how your
>>> proposed changes will lead to tangible improvements. (This advice
>>> applies to all GSOC applicants)
>>>
>>> --
>>> Oscar
>>>
>>> On Wed, 11 Mar 2020 at 19:19, mohit balwani
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > Here is rough draft of my GSoC proposal
>>> >
>>> > https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
>>> >
>>> > Any suggestions would really be appreciated.
>>> >
>>> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin
>>> > wrote:
>>> >>
>>> >> Hi Mohit,
>>> >>
>>> >> You don't need to resend the previous emails. This discussion is
>>> >> becoming too detailed though and belongs on the Github issue for
>>> >> refactoring the ODE module:
>>> >> https://github.com/sympy/sympy/issues/18348
>>> >>
>>> >> Oscar
>>> >>
>>> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
>>> >> wrote:
>>> >> >
>>> >> > hello,
>>> >> >
>>> >> > so should I resend the previous mail to the mailing list?
>>> >> >
>>> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani
>>> >> > wrote:
>>> >> >>
>>> >> >> For pattern matching, I kept in mind that we can extract the elements
>>> >> >> of our general solution from the equation with direct matching just
>>> >> >> like First_linear. And for `SingleODESolver` there will be proper
>>> >> >> logic checking whether the given equation matches or not.
>>> >> >>
>>> >> >> I am a bit confused about how all linear solvers can be based on
>>> >> >> pattern because
>>> >> >> let's say we want to implement
>>> >> >> `nth_linear_constant_coeff_undetermined_coefficients`.
>>> >> >> its general equation is
>>> >> >>
>>> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0
>>> >> >> f(x) = P(x)
>>> >> >>
>>> >> >> Now p(x) needs to have a finite number of linearly independent
>>> >> >> derivatives and in pattern matching to write general solution we
>>> >> >> should use the extracted elements given by wilds function.
>>> >> >>
>>> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> I think the series solvers should probably have their own superclass.
>>> >> >>> I'd like to move them out of normal dsolve anyway.
>>> >> >>>
>>> >> >>> Of the others I think that probably all the linear ones can be based
>>> >> >>> on the Pattern solver. You should give a rationale for why you have
>>> >> >>> divided them up like this.
>>> >> >>>
>>> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>>> >> >>> wrote:
>>> >> >>> >
>>> >> >>> > Hi,
>>> >> >>> > currently, there are 28 solvers in the ODE module out of which 6
>>> >> >>> > solvers have been refactored already.
>>> >> >>> >
>>> >> >>> > I have classified the remaining 22 solvers on the basis of their
>>> >> >>> > parent class whether they should inherit SinglePatternODESolver or
>>> >> >>> > SingleODESolver
>>> >> >>> >
>>> >> >>> > SinglePatternODESolver
>>> >> >>> >
>>> >> >>> > separable
>>> >> >>> > separable_reduced
>>> >> >>> > linear_coefficients
>>> >> >>> > Liouville
>>> >> >>> > 2nd_linear_airy
>>> >> >>> > 2nd_linear_bessel
>>> >> >>> > 2nd_hypergeometrics
>>> >> >>> >
>>> >> >>> > SingleODESolver
>>> >> >>> >
>>> >> >>> > 1st_exact
>>> >> >>> > 1st_homogeneous_coeff_subs_indep_div_dep
>>> >> >>> > 1st_homogeneous_coeff_subs_dep_div_indep
>>> >> >>> > 1st_power_series
>>> >> >>> > 2nd_power_series_ordinary
>>> >> >>> > 2nd_power_series_regular
>>> >> >>> > nth_linear_constant_coeff_homogeneous
>>> >> >>> > nth_linear_euler_eq_homogeneous
>>> >> >>> > nth_linear_constant_coeff_undetermined_coefficients
>>> >> >>> > nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
>>> >> >>> > nth_linear_constant_coeff_variation_of_parameters
>>> >> >>> > nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
>>> >> >>> > nth_order_reducible
>>> >> >>> > 1st_homogeneous_coeff_best ( it just gives the best result from
>>> >> >>> > "1st_homogeneous_coeff_subs_indep_div_d
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
+oscar.j.benja...@gmail.com can you please review the changes in proposal
so that i know what i need to make changes in it?
On Friday, March 13, 2020 at 10:27:39 PM UTC+5:30, mohit balwani wrote:
>
> hello,
> I have made some changes in project motivation. Does this look good or
> Should I detail that more?
>
> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin
> wrote:
>
>> I think it would be good to spend more time explaining what changes
>> you will make and why.
>>
>> Don't assume that someone reviewing this proposal will understand the
>> current problems of the ODE module or why your proposal is beneficial.
>> You should make it clear to them what the problems are and how your
>> proposed changes will lead to tangible improvements. (This advice
>> applies to all GSOC applicants)
>>
>> --
>> Oscar
>>
>> On Wed, 11 Mar 2020 at 19:19, mohit balwani
>> wrote:
>> >
>> > Hi,
>> >
>> > Here is rough draft of my GSoC proposal
>> >
>> >
>> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
>> >
>> > Any suggestions would really be appreciated.
>> >
>> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >>
>> >> Hi Mohit,
>> >>
>> >> You don't need to resend the previous emails. This discussion is
>> >> becoming too detailed though and belongs on the Github issue for
>> >> refactoring the ODE module:
>> >> https://github.com/sympy/sympy/issues/18348
>> >>
>> >> Oscar
>> >>
>> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
>> >> wrote:
>> >> >
>> >> > hello,
>> >> >
>> >> > so should I resend the previous mail to the mailing list?
>> >> >
>> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani <
>> mohitbalwani.ic...@gmail.com> wrote:
>> >> >>
>> >> >> For pattern matching, I kept in mind that we can extract the
>> elements of our general solution from the equation with direct matching
>> just like First_linear. And for `SingleODESolver` there will be proper
>> logic checking whether the given equation matches or not.
>> >> >>
>> >> >> I am a bit confused about how all linear solvers can be based on
>> pattern because
>> >> >> let's say we want to implement
>> `nth_linear_constant_coeff_undetermined_coefficients`.
>> >> >> its general equation is
>> >> >>
>> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0
>> f(x) = P(x)
>> >> >>
>> >> >> Now p(x) needs to have a finite number of linearly independent
>> derivatives and in pattern matching to write general solution we should use
>> the extracted elements given by wilds function.
>> >> >>
>> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin <
>> oscar.j.benja...@gmail.com> wrote:
>> >> >>>
>> >> >>> I think the series solvers should probably have their own
>> superclass.
>> >> >>> I'd like to move them out of normal dsolve anyway.
>> >> >>>
>> >> >>> Of the others I think that probably all the linear ones can be
>> based
>> >> >>> on the Pattern solver. You should give a rationale for why you have
>> >> >>> divided them up like this.
>> >> >>>
>> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>> >> >>> wrote:
>> >> >>> >
>> >> >>> > Hi,
>> >> >>> > currently, there are 28 solvers in the ODE module out of which 6
>> solvers have been refactored already.
>> >> >>> >
>> >> >>> > I have classified the remaining 22 solvers on the basis of their
>> parent class whether they should inherit SinglePatternODESolver or
>> SingleODESolver
>> >> >>> >
>> >> >>> > SinglePatternODESolver
>> >> >>> >
>> >> >>> > separable
>> >> >>> > separable_reduced
>> >> >>> > linear_coefficients
>> >> >>> > Liouville
>> >> >>> > 2nd_linear_airy
>> >> >>> > 2nd_linear_bessel
>> >> >>> > 2nd_hypergeometrics
>> >> >>> >
>> >> >>> > SingleODESolver
>> >> >>> >
>> >> >>> > 1st_exact
>> >> >>> > 1st_homogeneous_coeff_subs_indep_div_dep
>> >> >>> > 1st_homogeneous_coeff_subs_dep_div_indep
>> >> >>> > 1st_power_series
>> >> >>> > 2nd_power_series_ordinary
>> >> >>> > 2nd_power_series_regular
>> >> >>> > nth_linear_constant_coeff_homogeneous
>> >> >>> > nth_linear_euler_eq_homogeneous
>> >> >>> > nth_linear_constant_coeff_undetermined_coefficients
>> >> >>> > nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
>> >> >>> > nth_linear_constant_coeff_variation_of_parameters
>> >> >>> > nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
>> >> >>> > nth_order_reducible
>> >> >>> > 1st_homogeneous_coeff_best ( it just gives the best result from
>> "1st_homogeneous_coeff_subs_indep_div_dep" and
>> "1st_homogeneous_coeff_subs_dep_div_indep")
>> >> >>> > Lie_group
>> >> >>> >
>> >> >>> > +oscar.j.benja...@gmail.com does this classification look good?
>> >> >>> > Any suggestions would be really helpful.
>> >> >>> >
>> >> >>> > Regards,
>> >> >>> > Mohit
>> >> >>> >
>> >> >>> > On Sun, Mar 8, 2020 at 1:53 PM mohit balwani <
>> mohitbalwani.ic...@gmail.com> wrote:
>> >> >>> >>
>> >> >>> >> Hi, oscar
>> >> >>> >>
>> >> >>> >> I started looking at the (Single) ODE
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
hello,
I have made some changes in project motivation. Does this look good or
Should I detail that more?
On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin
wrote:
> I think it would be good to spend more time explaining what changes
> you will make and why.
>
> Don't assume that someone reviewing this proposal will understand the
> current problems of the ODE module or why your proposal is beneficial.
> You should make it clear to them what the problems are and how your
> proposed changes will lead to tangible improvements. (This advice
> applies to all GSOC applicants)
>
> --
> Oscar
>
> On Wed, 11 Mar 2020 at 19:19, mohit balwani
> wrote:
> >
> > Hi,
> >
> > Here is rough draft of my GSoC proposal
> >
> >
> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
> >
> > Any suggestions would really be appreciated.
> >
> > On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin
> wrote:
> >>
> >> Hi Mohit,
> >>
> >> You don't need to resend the previous emails. This discussion is
> >> becoming too detailed though and belongs on the Github issue for
> >> refactoring the ODE module:
> >> https://github.com/sympy/sympy/issues/18348
> >>
> >> Oscar
> >>
> >> On Tue, 10 Mar 2020 at 15:26, mohit balwani
> >> wrote:
> >> >
> >> > hello,
> >> >
> >> > so should I resend the previous mail to the mailing list?
> >> >
> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani <
> mohitbalwani.ic...@gmail.com> wrote:
> >> >>
> >> >> For pattern matching, I kept in mind that we can extract the
> elements of our general solution from the equation with direct matching
> just like First_linear. And for `SingleODESolver` there will be proper
> logic checking whether the given equation matches or not.
> >> >>
> >> >> I am a bit confused about how all linear solvers can be based on
> pattern because
> >> >> let's say we want to implement
> `nth_linear_constant_coeff_undetermined_coefficients`.
> >> >> its general equation is
> >> >>
> >> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0
> f(x) = P(x)
> >> >>
> >> >> Now p(x) needs to have a finite number of linearly independent
> derivatives and in pattern matching to write general solution we should use
> the extracted elements given by wilds function.
> >> >>
> >> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >> >>>
> >> >>> I think the series solvers should probably have their own
> superclass.
> >> >>> I'd like to move them out of normal dsolve anyway.
> >> >>>
> >> >>> Of the others I think that probably all the linear ones can be based
> >> >>> on the Pattern solver. You should give a rationale for why you have
> >> >>> divided them up like this.
> >> >>>
> >> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
> >> >>> wrote:
> >> >>> >
> >> >>> > Hi,
> >> >>> > currently, there are 28 solvers in the ODE module out of which 6
> solvers have been refactored already.
> >> >>> >
> >> >>> > I have classified the remaining 22 solvers on the basis of their
> parent class whether they should inherit SinglePatternODESolver or
> SingleODESolver
> >> >>> >
> >> >>> > SinglePatternODESolver
> >> >>> >
> >> >>> > separable
> >> >>> > separable_reduced
> >> >>> > linear_coefficients
> >> >>> > Liouville
> >> >>> > 2nd_linear_airy
> >> >>> > 2nd_linear_bessel
> >> >>> > 2nd_hypergeometrics
> >> >>> >
> >> >>> > SingleODESolver
> >> >>> >
> >> >>> > 1st_exact
> >> >>> > 1st_homogeneous_coeff_subs_indep_div_dep
> >> >>> > 1st_homogeneous_coeff_subs_dep_div_indep
> >> >>> > 1st_power_series
> >> >>> > 2nd_power_series_ordinary
> >> >>> > 2nd_power_series_regular
> >> >>> > nth_linear_constant_coeff_homogeneous
> >> >>> > nth_linear_euler_eq_homogeneous
> >> >>> > nth_linear_constant_coeff_undetermined_coefficients
> >> >>> > nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
> >> >>> > nth_linear_constant_coeff_variation_of_parameters
> >> >>> > nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
> >> >>> > nth_order_reducible
> >> >>> > 1st_homogeneous_coeff_best ( it just gives the best result from
> "1st_homogeneous_coeff_subs_indep_div_dep" and
> "1st_homogeneous_coeff_subs_dep_div_indep")
> >> >>> > Lie_group
> >> >>> >
> >> >>> > +oscar.j.benja...@gmail.com does this classification look good?
> >> >>> > Any suggestions would be really helpful.
> >> >>> >
> >> >>> > Regards,
> >> >>> > Mohit
> >> >>> >
> >> >>> > On Sun, Mar 8, 2020 at 1:53 PM mohit balwani <
> mohitbalwani.ic...@gmail.com> wrote:
> >> >>> >>
> >> >>> >> Hi, oscar
> >> >>> >>
> >> >>> >> I started looking at the (Single) ODE solver closely and as
> suggested by you, they are to be refactored in the form of classes. After
> performing all this work it will be easier to maintain the code and
> whenever a new solver is to be added it will be very easy to add it. In my
> GSoC proposal what exactly I should elaborate on because refactoring
> different solvers will be based on either SinglePatternODESolver
> >> >
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
I think it would be good to spend more time explaining what changes
you will make and why.
Don't assume that someone reviewing this proposal will understand the
current problems of the ODE module or why your proposal is beneficial.
You should make it clear to them what the problems are and how your
proposed changes will lead to tangible improvements. (This advice
applies to all GSOC applicants)
--
Oscar
On Wed, 11 Mar 2020 at 19:19, mohit balwani
wrote:
>
> Hi,
>
> Here is rough draft of my GSoC proposal
>
> https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
>
> Any suggestions would really be appreciated.
>
> On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin
> wrote:
>>
>> Hi Mohit,
>>
>> You don't need to resend the previous emails. This discussion is
>> becoming too detailed though and belongs on the Github issue for
>> refactoring the ODE module:
>> https://github.com/sympy/sympy/issues/18348
>>
>> Oscar
>>
>> On Tue, 10 Mar 2020 at 15:26, mohit balwani
>> wrote:
>> >
>> > hello,
>> >
>> > so should I resend the previous mail to the mailing list?
>> >
>> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani
>> > wrote:
>> >>
>> >> For pattern matching, I kept in mind that we can extract the elements of
>> >> our general solution from the equation with direct matching just like
>> >> First_linear. And for `SingleODESolver` there will be proper logic
>> >> checking whether the given equation matches or not.
>> >>
>> >> I am a bit confused about how all linear solvers can be based on pattern
>> >> because
>> >> let's say we want to implement
>> >> `nth_linear_constant_coeff_undetermined_coefficients`.
>> >> its general equation is
>> >>
>> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0 f(x) =
>> >> P(x)
>> >>
>> >> Now p(x) needs to have a finite number of linearly independent
>> >> derivatives and in pattern matching to write general solution we should
>> >> use the extracted elements given by wilds function.
>> >>
>> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin
>> >> wrote:
>> >>>
>> >>> I think the series solvers should probably have their own superclass.
>> >>> I'd like to move them out of normal dsolve anyway.
>> >>>
>> >>> Of the others I think that probably all the linear ones can be based
>> >>> on the Pattern solver. You should give a rationale for why you have
>> >>> divided them up like this.
>> >>>
>> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>> >>> wrote:
>> >>> >
>> >>> > Hi,
>> >>> > currently, there are 28 solvers in the ODE module out of which 6
>> >>> > solvers have been refactored already.
>> >>> >
>> >>> > I have classified the remaining 22 solvers on the basis of their
>> >>> > parent class whether they should inherit SinglePatternODESolver or
>> >>> > SingleODESolver
>> >>> >
>> >>> > SinglePatternODESolver
>> >>> >
>> >>> > separable
>> >>> > separable_reduced
>> >>> > linear_coefficients
>> >>> > Liouville
>> >>> > 2nd_linear_airy
>> >>> > 2nd_linear_bessel
>> >>> > 2nd_hypergeometrics
>> >>> >
>> >>> > SingleODESolver
>> >>> >
>> >>> > 1st_exact
>> >>> > 1st_homogeneous_coeff_subs_indep_div_dep
>> >>> > 1st_homogeneous_coeff_subs_dep_div_indep
>> >>> > 1st_power_series
>> >>> > 2nd_power_series_ordinary
>> >>> > 2nd_power_series_regular
>> >>> > nth_linear_constant_coeff_homogeneous
>> >>> > nth_linear_euler_eq_homogeneous
>> >>> > nth_linear_constant_coeff_undetermined_coefficients
>> >>> > nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
>> >>> > nth_linear_constant_coeff_variation_of_parameters
>> >>> > nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
>> >>> > nth_order_reducible
>> >>> > 1st_homogeneous_coeff_best ( it just gives the best result from
>> >>> > "1st_homogeneous_coeff_subs_indep_div_dep" and
>> >>> > "1st_homogeneous_coeff_subs_dep_div_indep")
>> >>> > Lie_group
>> >>> >
>> >>> > +oscar.j.benja...@gmail.com does this classification look good?
>> >>> > Any suggestions would be really helpful.
>> >>> >
>> >>> > Regards,
>> >>> > Mohit
>> >>> >
>> >>> > On Sun, Mar 8, 2020 at 1:53 PM mohit balwani
>> >>> > wrote:
>> >>> >>
>> >>> >> Hi, oscar
>> >>> >>
>> >>> >> I started looking at the (Single) ODE solver closely and as suggested
>> >>> >> by you, they are to be refactored in the form of classes. After
>> >>> >> performing all this work it will be easier to maintain the code and
>> >>> >> whenever a new solver is to be added it will be very easy to add it.
>> >>> >> In my GSoC proposal what exactly I should elaborate on because
>> >>> >> refactoring different solvers will be based on either
>> >>> >> SinglePatternODESolver
>> >>> >> or SingleODESolver only and both of the base classes are already
>> >>> >> implemented so we just have to inherit them. one thing I noted that
>> >>> >> there are helper functions in ode.py so I guess they should be moved
>> >>> >> to other file deutils.py may be.
>> >>> >> so in my proposal should I show the c
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Hi,
Here is rough draft of my GSoC proposal
https://docs.google.com/document/d/1slfj2CJRgKpmf0zOW93YkxYUDUvutTmkDX6BmsFfmIs/edit?usp=drivesdk
Any suggestions would really be appreciated.
On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin
wrote:
> Hi Mohit,
>
> You don't need to resend the previous emails. This discussion is
> becoming too detailed though and belongs on the Github issue for
> refactoring the ODE module:
> https://github.com/sympy/sympy/issues/18348
>
> Oscar
>
> On Tue, 10 Mar 2020 at 15:26, mohit balwani
> wrote:
> >
> > hello,
> >
> > so should I resend the previous mail to the mailing list?
> >
> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani <
> mohitbalwani.ic...@gmail.com> wrote:
> >>
> >> For pattern matching, I kept in mind that we can extract the elements
> of our general solution from the equation with direct matching just like
> First_linear. And for `SingleODESolver` there will be proper logic checking
> whether the given equation matches or not.
> >>
> >> I am a bit confused about how all linear solvers can be based on
> pattern because
> >> let's say we want to implement
> `nth_linear_constant_coeff_undetermined_coefficients`.
> >> its general equation is
> >>
> >> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0 f(x)
> = P(x)
> >>
> >> Now p(x) needs to have a finite number of linearly independent
> derivatives and in pattern matching to write general solution we should use
> the extracted elements given by wilds function.
> >>
> >> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>>
> >>> I think the series solvers should probably have their own superclass.
> >>> I'd like to move them out of normal dsolve anyway.
> >>>
> >>> Of the others I think that probably all the linear ones can be based
> >>> on the Pattern solver. You should give a rationale for why you have
> >>> divided them up like this.
> >>>
> >>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
> >>> wrote:
> >>> >
> >>> > Hi,
> >>> > currently, there are 28 solvers in the ODE module out of which 6
> solvers have been refactored already.
> >>> >
> >>> > I have classified the remaining 22 solvers on the basis of their
> parent class whether they should inherit SinglePatternODESolver or
> SingleODESolver
> >>> >
> >>> > SinglePatternODESolver
> >>> >
> >>> > separable
> >>> > separable_reduced
> >>> > linear_coefficients
> >>> > Liouville
> >>> > 2nd_linear_airy
> >>> > 2nd_linear_bessel
> >>> > 2nd_hypergeometrics
> >>> >
> >>> > SingleODESolver
> >>> >
> >>> > 1st_exact
> >>> > 1st_homogeneous_coeff_subs_indep_div_dep
> >>> > 1st_homogeneous_coeff_subs_dep_div_indep
> >>> > 1st_power_series
> >>> > 2nd_power_series_ordinary
> >>> > 2nd_power_series_regular
> >>> > nth_linear_constant_coeff_homogeneous
> >>> > nth_linear_euler_eq_homogeneous
> >>> > nth_linear_constant_coeff_undetermined_coefficients
> >>> > nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
> >>> > nth_linear_constant_coeff_variation_of_parameters
> >>> > nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
> >>> > nth_order_reducible
> >>> > 1st_homogeneous_coeff_best ( it just gives the best result from
> "1st_homogeneous_coeff_subs_indep_div_dep" and
> "1st_homogeneous_coeff_subs_dep_div_indep")
> >>> > Lie_group
> >>> >
> >>> > +oscar.j.benja...@gmail.com does this classification look good?
> >>> > Any suggestions would be really helpful.
> >>> >
> >>> > Regards,
> >>> > Mohit
> >>> >
> >>> > On Sun, Mar 8, 2020 at 1:53 PM mohit balwani <
> mohitbalwani.ic...@gmail.com> wrote:
> >>> >>
> >>> >> Hi, oscar
> >>> >>
> >>> >> I started looking at the (Single) ODE solver closely and as
> suggested by you, they are to be refactored in the form of classes. After
> performing all this work it will be easier to maintain the code and
> whenever a new solver is to be added it will be very easy to add it. In my
> GSoC proposal what exactly I should elaborate on because refactoring
> different solvers will be based on either SinglePatternODESolver
> >>> >> or SingleODESolver only and both of the base classes are already
> implemented so we just have to inherit them. one thing I noted that there
> are helper functions in ode.py so I guess they should be moved to other
> file deutils.py may be.
> >>> >> so in my proposal should I show the code for one of the
> non-refactored solvers?
> >>> >>
> >>> >> Thanks,
> >>> >> Mohit
> >>> >>
> >>> >> On Sat, Mar 7, 2020 at 2:22 AM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>> >>>
> >>> >>> Hi Mohit,
> >>> >>>
> >>> >>> That's plenty enough for a GSOC project. You should try to go into
> >>> >>> more detail in your proposal about exactly what you think should
> >>> >>> happen though. Perhaps review all of the (single) ODE solvers that
> are
> >>> >>> there now and how they can be refactored and simplified or
> improved in
> >>> >>> the process.
> >>> >>>
> >>> >>> Refactoring the tests so that they can be reused will make it
> poss
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Hi Mohit,
You don't need to resend the previous emails. This discussion is
becoming too detailed though and belongs on the Github issue for
refactoring the ODE module:
https://github.com/sympy/sympy/issues/18348
Oscar
On Tue, 10 Mar 2020 at 15:26, mohit balwani
wrote:
>
> hello,
>
> so should I resend the previous mail to the mailing list?
>
> On Tue, Mar 10, 2020 at 6:59 PM mohit balwani
> wrote:
>>
>> For pattern matching, I kept in mind that we can extract the elements of our
>> general solution from the equation with direct matching just like
>> First_linear. And for `SingleODESolver` there will be proper logic checking
>> whether the given equation matches or not.
>>
>> I am a bit confused about how all linear solvers can be based on pattern
>> because
>> let's say we want to implement
>> `nth_linear_constant_coeff_undetermined_coefficients`.
>> its general equation is
>>
>> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0 f(x) = P(x)
>>
>> Now p(x) needs to have a finite number of linearly independent derivatives
>> and in pattern matching to write general solution we should use the
>> extracted elements given by wilds function.
>>
>> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin
>> wrote:
>>>
>>> I think the series solvers should probably have their own superclass.
>>> I'd like to move them out of normal dsolve anyway.
>>>
>>> Of the others I think that probably all the linear ones can be based
>>> on the Pattern solver. You should give a rationale for why you have
>>> divided them up like this.
>>>
>>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>>> wrote:
>>> >
>>> > Hi,
>>> > currently, there are 28 solvers in the ODE module out of which 6 solvers
>>> > have been refactored already.
>>> >
>>> > I have classified the remaining 22 solvers on the basis of their parent
>>> > class whether they should inherit SinglePatternODESolver or
>>> > SingleODESolver
>>> >
>>> > SinglePatternODESolver
>>> >
>>> > separable
>>> > separable_reduced
>>> > linear_coefficients
>>> > Liouville
>>> > 2nd_linear_airy
>>> > 2nd_linear_bessel
>>> > 2nd_hypergeometrics
>>> >
>>> > SingleODESolver
>>> >
>>> > 1st_exact
>>> > 1st_homogeneous_coeff_subs_indep_div_dep
>>> > 1st_homogeneous_coeff_subs_dep_div_indep
>>> > 1st_power_series
>>> > 2nd_power_series_ordinary
>>> > 2nd_power_series_regular
>>> > nth_linear_constant_coeff_homogeneous
>>> > nth_linear_euler_eq_homogeneous
>>> > nth_linear_constant_coeff_undetermined_coefficients
>>> > nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
>>> > nth_linear_constant_coeff_variation_of_parameters
>>> > nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
>>> > nth_order_reducible
>>> > 1st_homogeneous_coeff_best ( it just gives the best result from
>>> > "1st_homogeneous_coeff_subs_indep_div_dep" and
>>> > "1st_homogeneous_coeff_subs_dep_div_indep")
>>> > Lie_group
>>> >
>>> > +oscar.j.benja...@gmail.com does this classification look good?
>>> > Any suggestions would be really helpful.
>>> >
>>> > Regards,
>>> > Mohit
>>> >
>>> > On Sun, Mar 8, 2020 at 1:53 PM mohit balwani
>>> > wrote:
>>> >>
>>> >> Hi, oscar
>>> >>
>>> >> I started looking at the (Single) ODE solver closely and as suggested by
>>> >> you, they are to be refactored in the form of classes. After performing
>>> >> all this work it will be easier to maintain the code and whenever a new
>>> >> solver is to be added it will be very easy to add it. In my GSoC
>>> >> proposal what exactly I should elaborate on because refactoring
>>> >> different solvers will be based on either SinglePatternODESolver
>>> >> or SingleODESolver only and both of the base classes are already
>>> >> implemented so we just have to inherit them. one thing I noted that
>>> >> there are helper functions in ode.py so I guess they should be moved to
>>> >> other file deutils.py may be.
>>> >> so in my proposal should I show the code for one of the non-refactored
>>> >> solvers?
>>> >>
>>> >> Thanks,
>>> >> Mohit
>>> >>
>>> >> On Sat, Mar 7, 2020 at 2:22 AM Oscar Benjamin
>>> >> wrote:
>>> >>>
>>> >>> Hi Mohit,
>>> >>>
>>> >>> That's plenty enough for a GSOC project. You should try to go into
>>> >>> more detail in your proposal about exactly what you think should
>>> >>> happen though. Perhaps review all of the (single) ODE solvers that are
>>> >>> there now and how they can be refactored and simplified or improved in
>>> >>> the process.
>>> >>>
>>> >>> Refactoring the tests so that they can be reused will make it possible
>>> >>> to run all solvers on all of the tested ODEs which will expose many
>>> >>> bugs in the individual solvers. You don't need to worry about having
>>> >>> enough to do if you start thinking about fixing those bugs! If I was
>>> >>> doing this work myself I would begin with refactoring the tests so
>>> >>> that I can use them to compare before/after performance while
>>> >>> refactoring the solving code.
>>> >>>
>>> >>> I think this would be too much
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Hi Mohit,
I'm replying on the mailing list. I didn't realise we had gone
off-list in the last couple of emails.
This conversation belongs in the issue on github.
Oscar
On Tue, 10 Mar 2020 at 13:29, mohit balwani
wrote:
>
> For pattern matching, I kept in mind that we can extract the elements of our
> general solution from the equation with direct matching just like
> First_linear. And for `SingleODESolver` there will be proper logic checking
> whether the given equation matches or not.
>
> I am a bit confused about how all linear solvers can be based on pattern
> because
> let's say we want to implement
> `nth_linear_constant_coeff_undetermined_coefficients`.
> its general equation is
>
> a_n f^{(n)}(x) + a_{n-1} f^{(n-1)}(x) + .. + a_1 f'(x) + a_0 f(x) = P(x)
>
> Now p(x) needs to have a finite number of linearly independent derivatives
> and in pattern matching to write general solution we should use the extracted
> elements given by wilds function.
>
> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin
> wrote:
>>
>> I think the series solvers should probably have their own superclass.
>> I'd like to move them out of normal dsolve anyway.
>>
>> Of the others I think that probably all the linear ones can be based
>> on the Pattern solver. You should give a rationale for why you have
>> divided them up like this.
>>
>> On Tue, 10 Mar 2020 at 10:29, mohit balwani
>> wrote:
>> >
>> > Hi,
>> > currently, there are 28 solvers in the ODE module out of which 6 solvers
>> > have been refactored already.
>> >
>> > I have classified the remaining 22 solvers on the basis of their parent
>> > class whether they should inherit SinglePatternODESolver or SingleODESolver
>> >
>> > SinglePatternODESolver
>> >
>> > separable
>> > separable_reduced
>> > linear_coefficients
>> > Liouville
>> > 2nd_linear_airy
>> > 2nd_linear_bessel
>> > 2nd_hypergeometrics
>> >
>> > SingleODESolver
>> >
>> > 1st_exact
>> > 1st_homogeneous_coeff_subs_indep_div_dep
>> > 1st_homogeneous_coeff_subs_dep_div_indep
>> > 1st_power_series
>> > 2nd_power_series_ordinary
>> > 2nd_power_series_regular
>> > nth_linear_constant_coeff_homogeneous
>> > nth_linear_euler_eq_homogeneous
>> > nth_linear_constant_coeff_undetermined_coefficients
>> > nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
>> > nth_linear_constant_coeff_variation_of_parameters
>> > nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
>> > nth_order_reducible
>> > 1st_homogeneous_coeff_best ( it just gives the best result from
>> > "1st_homogeneous_coeff_subs_indep_div_dep" and
>> > "1st_homogeneous_coeff_subs_dep_div_indep")
>> > Lie_group
>> >
>> > +oscar.j.benja...@gmail.com does this classification look good?
>> > Any suggestions would be really helpful.
>> >
>> > Regards,
>> > Mohit
>> >
>> > On Sun, Mar 8, 2020 at 1:53 PM mohit balwani
>> > wrote:
>> >>
>> >> Hi, oscar
>> >>
>> >> I started looking at the (Single) ODE solver closely and as suggested by
>> >> you, they are to be refactored in the form of classes. After performing
>> >> all this work it will be easier to maintain the code and whenever a new
>> >> solver is to be added it will be very easy to add it. In my GSoC proposal
>> >> what exactly I should elaborate on because refactoring different solvers
>> >> will be based on either SinglePatternODESolver
>> >> or SingleODESolver only and both of the base classes are already
>> >> implemented so we just have to inherit them. one thing I noted that there
>> >> are helper functions in ode.py so I guess they should be moved to other
>> >> file deutils.py may be.
>> >> so in my proposal should I show the code for one of the non-refactored
>> >> solvers?
>> >>
>> >> Thanks,
>> >> Mohit
>> >>
>> >> On Sat, Mar 7, 2020 at 2:22 AM Oscar Benjamin
>> >> wrote:
>> >>>
>> >>> Hi Mohit,
>> >>>
>> >>> That's plenty enough for a GSOC project. You should try to go into
>> >>> more detail in your proposal about exactly what you think should
>> >>> happen though. Perhaps review all of the (single) ODE solvers that are
>> >>> there now and how they can be refactored and simplified or improved in
>> >>> the process.
>> >>>
>> >>> Refactoring the tests so that they can be reused will make it possible
>> >>> to run all solvers on all of the tested ODEs which will expose many
>> >>> bugs in the individual solvers. You don't need to worry about having
>> >>> enough to do if you start thinking about fixing those bugs! If I was
>> >>> doing this work myself I would begin with refactoring the tests so
>> >>> that I can use them to compare before/after performance while
>> >>> refactoring the solving code.
>> >>>
>> >>> I think this would be too much for one GSOC project but the ultimate
>> >>> goal I would like is to see the ODE code organised more like
>> >>> integral_steps with rules leading to other rules and so on so that we
>> >>> can have step-by-step solutions and better debugging output. Many of
>> >>> the solvers are actually using substitu
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Hi, currently, there are 28 solvers in the ODE module out of which 6 solvers have been refactored already. I have classified the remaining 22 solvers on the basis of their parent class whether they should inherit SinglePatternODESolver or SingleODESolver SinglePatternODESolver 1. separable 2. separable_reduced 3. linear_coefficients 4. Liouville 5. 2nd_linear_airy 6. 2nd_linear_bessel 7. 2nd_hypergeometrics SingleODESolver 1. *1st_exact * 2. *1st_homogeneous_coeff_subs_indep_div_dep * 3. *1st_homogeneous_coeff_subs_dep_div_indep * 4. *1st_power_series * 5. *2nd_power_series_ordinary * 6. *2nd_power_series_regular * 7. *nth_linear_constant_coeff_homogeneous * 8. *nth_linear_euler_eq_homogeneous * 9. *nth_linear_constant_coeff_undetermined_coefficients * 10. *nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients* 11. *nth_linear_constant_coeff_variation_of_parameters * 12. *nth_linear_euler_eq_nonhomogeneous_variation_of_parameters * 13. *nth_order_reducible * 14. *1st_homogeneous_coeff_best ( it just gives the best result from "1st_homogeneous_coeff_subs_indep_div_dep" and "1st_homogeneous_coeff_subs_dep_div_indep") * 15. *Lie_group* +oscar.j.benja...@gmail.com does this classification look good? Any suggestions would be really helpful. Regards, Mohit On Sun, Mar 8, 2020 at 1:53 PM mohit balwani wrote: > Hi, oscar > > I started looking at the (Single) ODE solver closely and as suggested by > you, they are to be refactored in the form of classes. After performing all > this work it will be easier to maintain the code and whenever a new solver > is to be added it will be very easy to add it. In my GSoC proposal what > exactly I should elaborate on because refactoring different solvers will be > based on either SinglePatternODESolver > or SingleODESolver only and both of the base classes are already > implemented so we just have to inherit them. one thing I noted that there > are helper functions in ode.py so I guess they should be moved to > other file deutils.py may be. > so in my proposal should I show the code for one of the non-refactored > solvers? > > Thanks, > Mohit > > On Sat, Mar 7, 2020 at 2:22 AM Oscar Benjamin > wrote: > >> Hi Mohit, >> >> That's plenty enough for a GSOC project. You should try to go into >> more detail in your proposal about exactly what you think should >> happen though. Perhaps review all of the (single) ODE solvers that are >> there now and how they can be refactored and simplified or improved in >> the process. >> >> Refactoring the tests so that they can be reused will make it possible >> to run all solvers on all of the tested ODEs which will expose many >> bugs in the individual solvers. You don't need to worry about having >> enough to do if you start thinking about fixing those bugs! If I was >> doing this work myself I would begin with refactoring the tests so >> that I can use them to compare before/after performance while >> refactoring the solving code. >> >> I think this would be too much for one GSOC project but the ultimate >> goal I would like is to see the ODE code organised more like >> integral_steps with rules leading to other rules and so on so that we >> can have step-by-step solutions and better debugging output. Many of >> the solvers are actually using substitutions so we should make it >> possible for a solver to simply match the ODE and say "use this >> substitution". We can't even begin to implement a rule-based system >> until dsolve is refactored though. >> >> Oscar >> >> On Fri, 6 Mar 2020 at 19:34, mohit balwani >> wrote: >> > >> > I am planning to take Refactoring ODE module as a GSoC project. >> > >> > For every solver we need to make it as a separate class so that >> classify_ode() can easily match the ode and return the solution right away. >> After that the test_ode.py also needs to be refactored as there are lot of >> redundant test and we can use data structures for maintaining and testing >> each and every part of test_ode.py.This will provide uniformity as there >> are some blocks which are not tested. >> > >> > So will this be enough for GSoC'20? >> > >> > On Fri, Jan 24, 2020, 12:14 AM Oscar Benjamin < >> oscar.j.benja...@gmail.com> wrote: >> >> >> >> Those might be able to speed things up but not until the ODE module is >> >> refactored. The reason the module needs to be refactored is that right >> >> now it runs the whole of classify_ode including the matching code for >> >> every single solver. >> >> >> >> If it just returned the first match straight away and computed the >> >> result it would be much faster. Then adding new fast methods that are >> >> tried first can speed things up. As it stands though each method that >> >> you add will probably just slow it down more. There needs to be a >> >> refactor first so that classify_ode still works as expected even if >> >> dsolve does something different. >> >> >> >> >> >> On Thu, 23 Jan 2020 a
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Hi, oscar I started looking at the (Single) ODE solver closely and as suggested by you, they are to be refactored in the form of classes. After performing all this work it will be easier to maintain the code and whenever a new solver is to be added it will be very easy to add it. In my GSoC proposal what exactly I should elaborate on because refactoring different solvers will be based on either SinglePatternODESolver or SingleODESolver only and both of the base classes are already implemented so we just have to inherit them. one thing I noted that there are helper functions in ode.py so I guess they should be moved to other file deutils.py may be. so in my proposal should I show the code for one of the non-refactored solvers? Thanks, Mohit On Sat, Mar 7, 2020 at 2:22 AM Oscar Benjamin wrote: > Hi Mohit, > > That's plenty enough for a GSOC project. You should try to go into > more detail in your proposal about exactly what you think should > happen though. Perhaps review all of the (single) ODE solvers that are > there now and how they can be refactored and simplified or improved in > the process. > > Refactoring the tests so that they can be reused will make it possible > to run all solvers on all of the tested ODEs which will expose many > bugs in the individual solvers. You don't need to worry about having > enough to do if you start thinking about fixing those bugs! If I was > doing this work myself I would begin with refactoring the tests so > that I can use them to compare before/after performance while > refactoring the solving code. > > I think this would be too much for one GSOC project but the ultimate > goal I would like is to see the ODE code organised more like > integral_steps with rules leading to other rules and so on so that we > can have step-by-step solutions and better debugging output. Many of > the solvers are actually using substitutions so we should make it > possible for a solver to simply match the ODE and say "use this > substitution". We can't even begin to implement a rule-based system > until dsolve is refactored though. > > Oscar > > On Fri, 6 Mar 2020 at 19:34, mohit balwani > wrote: > > > > I am planning to take Refactoring ODE module as a GSoC project. > > > > For every solver we need to make it as a separate class so that > classify_ode() can easily match the ode and return the solution right away. > After that the test_ode.py also needs to be refactored as there are lot of > redundant test and we can use data structures for maintaining and testing > each and every part of test_ode.py.This will provide uniformity as there > are some blocks which are not tested. > > > > So will this be enough for GSoC'20? > > > > On Fri, Jan 24, 2020, 12:14 AM Oscar Benjamin < > oscar.j.benja...@gmail.com> wrote: > >> > >> Those might be able to speed things up but not until the ODE module is > >> refactored. The reason the module needs to be refactored is that right > >> now it runs the whole of classify_ode including the matching code for > >> every single solver. > >> > >> If it just returned the first match straight away and computed the > >> result it would be much faster. Then adding new fast methods that are > >> tried first can speed things up. As it stands though each method that > >> you add will probably just slow it down more. There needs to be a > >> refactor first so that classify_ode still works as expected even if > >> dsolve does something different. > >> > >> > >> On Thu, 23 Jan 2020 at 16:04, mohit balwani > >> wrote: > >> > > >> > > >> > > >> > On Thursday, January 9, 2020 at 10:00:33 PM UTC+5:30, mohit balwani > wrote: > >> >> > >> >> I have ideas of implementing functionalities in ODE mentioned in > wiki page. with whom should I discuss it? > >> > > >> > > >> > > >> > I have attached a pdf file in which there are shortcut tricks to > solve linear ode, i don't know whether these methods are already > implemented indirectly or will enhance the speed.But In my opinion if they > are implemented then lot of work could be saved. For example if we look at > method of undetermined coefficients, to find a particular integral of ode > it solves for coefficient by comparing them and call solve which has matrix > as argument. Now with the help of these tricks we do not need to call solve > as it will directly find out the coefficients of particular integral. This > pdf is handwritten notes and i have tried to write them as neat and > understandable as possible and with each case i have also written 1 example > so that it becomes easy to go through. > >> > > >> > -- > >> > 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/2df1d019-75a6-48eb-a6ce-676337cda1a5%40googlegroups.com > . > >> > >> -- > >> You received this m
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Hi Mohit, That's plenty enough for a GSOC project. You should try to go into more detail in your proposal about exactly what you think should happen though. Perhaps review all of the (single) ODE solvers that are there now and how they can be refactored and simplified or improved in the process. Refactoring the tests so that they can be reused will make it possible to run all solvers on all of the tested ODEs which will expose many bugs in the individual solvers. You don't need to worry about having enough to do if you start thinking about fixing those bugs! If I was doing this work myself I would begin with refactoring the tests so that I can use them to compare before/after performance while refactoring the solving code. I think this would be too much for one GSOC project but the ultimate goal I would like is to see the ODE code organised more like integral_steps with rules leading to other rules and so on so that we can have step-by-step solutions and better debugging output. Many of the solvers are actually using substitutions so we should make it possible for a solver to simply match the ODE and say "use this substitution". We can't even begin to implement a rule-based system until dsolve is refactored though. Oscar On Fri, 6 Mar 2020 at 19:34, mohit balwani wrote: > > I am planning to take Refactoring ODE module as a GSoC project. > > For every solver we need to make it as a separate class so that > classify_ode() can easily match the ode and return the solution right away. > After that the test_ode.py also needs to be refactored as there are lot of > redundant test and we can use data structures for maintaining and testing > each and every part of test_ode.py.This will provide uniformity as there are > some blocks which are not tested. > > So will this be enough for GSoC'20? > > On Fri, Jan 24, 2020, 12:14 AM Oscar Benjamin > wrote: >> >> Those might be able to speed things up but not until the ODE module is >> refactored. The reason the module needs to be refactored is that right >> now it runs the whole of classify_ode including the matching code for >> every single solver. >> >> If it just returned the first match straight away and computed the >> result it would be much faster. Then adding new fast methods that are >> tried first can speed things up. As it stands though each method that >> you add will probably just slow it down more. There needs to be a >> refactor first so that classify_ode still works as expected even if >> dsolve does something different. >> >> >> On Thu, 23 Jan 2020 at 16:04, mohit balwani >> wrote: >> > >> > >> > >> > On Thursday, January 9, 2020 at 10:00:33 PM UTC+5:30, mohit balwani wrote: >> >> >> >> I have ideas of implementing functionalities in ODE mentioned in wiki >> >> page. with whom should I discuss it? >> > >> > >> > >> > I have attached a pdf file in which there are shortcut tricks to solve >> > linear ode, i don't know whether these methods are already implemented >> > indirectly or will enhance the speed.But In my opinion if they are >> > implemented then lot of work could be saved. For example if we look at >> > method of undetermined coefficients, to find a particular integral of ode >> > it solves for coefficient by comparing them and call solve which has >> > matrix as argument. Now with the help of these tricks we do not need to >> > call solve as it will directly find out the coefficients of particular >> > integral. This pdf is handwritten notes and i have tried to write them as >> > neat and understandable as possible and with each case i have also written >> > 1 example so that it becomes easy to go through. >> > >> > -- >> > 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/2df1d019-75a6-48eb-a6ce-676337cda1a5%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/CAHVvXxR-9tiiEN8Fak_0czd19gtBTiL_Lna09CLWcck72e5j-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/CAGoPB%2BuBTuy4jfMssJJqd59oZO-zf3uA29sMFPxkmjnbwmMexA%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
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Thanks for the response. I just wanted apporoval that,are they worth enough to implement? Now i will try to help in refactoring as soon as possible. On Fri, Jan 24, 2020, 12:14 AM Oscar Benjamin wrote: > Those might be able to speed things up but not until the ODE module is > refactored. The reason the module needs to be refactored is that right > now it runs the whole of classify_ode including the matching code for > every single solver. > > If it just returned the first match straight away and computed the > result it would be much faster. Then adding new fast methods that are > tried first can speed things up. As it stands though each method that > you add will probably just slow it down more. There needs to be a > refactor first so that classify_ode still works as expected even if > dsolve does something different. > > > On Thu, 23 Jan 2020 at 16:04, mohit balwani > wrote: > > > > > > > > On Thursday, January 9, 2020 at 10:00:33 PM UTC+5:30, mohit balwani > wrote: > >> > >> I have ideas of implementing functionalities in ODE mentioned in wiki > page. with whom should I discuss it? > > > > > > > > I have attached a pdf file in which there are shortcut tricks to solve > linear ode, i don't know whether these methods are already implemented > indirectly or will enhance the speed.But In my opinion if they are > implemented then lot of work could be saved. For example if we look at > method of undetermined coefficients, to find a particular integral of ode > it solves for coefficient by comparing them and call solve which has matrix > as argument. Now with the help of these tricks we do not need to call solve > as it will directly find out the coefficients of particular integral. This > pdf is handwritten notes and i have tried to write them as neat and > understandable as possible and with each case i have also written 1 example > so that it becomes easy to go through. > > > > -- > > 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/2df1d019-75a6-48eb-a6ce-676337cda1a5%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/CAHVvXxR-9tiiEN8Fak_0czd19gtBTiL_Lna09CLWcck72e5j-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/CAGoPB%2BvdFVkkouP0mARHBJDahVShnNi_wCU%3D%2BZBhFXMUXHHh4A%40mail.gmail.com.
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
Those might be able to speed things up but not until the ODE module is refactored. The reason the module needs to be refactored is that right now it runs the whole of classify_ode including the matching code for every single solver. If it just returned the first match straight away and computed the result it would be much faster. Then adding new fast methods that are tried first can speed things up. As it stands though each method that you add will probably just slow it down more. There needs to be a refactor first so that classify_ode still works as expected even if dsolve does something different. On Thu, 23 Jan 2020 at 16:04, mohit balwani wrote: > > > > On Thursday, January 9, 2020 at 10:00:33 PM UTC+5:30, mohit balwani wrote: >> >> I have ideas of implementing functionalities in ODE mentioned in wiki page. >> with whom should I discuss it? > > > > I have attached a pdf file in which there are shortcut tricks to solve > linear ode, i don't know whether these methods are already implemented > indirectly or will enhance the speed.But In my opinion if they are > implemented then lot of work could be saved. For example if we look at method > of undetermined coefficients, to find a particular integral of ode it solves > for coefficient by comparing them and call solve which has matrix as > argument. Now with the help of these tricks we do not need to call solve as > it will directly find out the coefficients of particular integral. This pdf > is handwritten notes and i have tried to write them as neat and > understandable as possible and with each case i have also written 1 example > so that it becomes easy to go through. > > -- > 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/2df1d019-75a6-48eb-a6ce-676337cda1a5%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/CAHVvXxR-9tiiEN8Fak_0czd19gtBTiL_Lna09CLWcck72e5j-A%40mail.gmail.com.
Re: [sympy] Re: [DISCUSSION] GSOC idea about ODE
I've added some stuff about ODEs: https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#systems-of-ordinary-differential-equations https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#refactor-the-ode-module-and-make-it-fast I'll try to add more later On Wed, 15 Jan 2020 at 18:42, mohit balwani wrote: > > Is GSOC 2020 ideas page updated now? > > -- > 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/7eb55697-b634-4b22-98c3-0d64053f83f6%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/CAHVvXxSA8JcSTHPJ4EtUbnphsCM_QmBDBm4toM9H8prBc%2BtNBA%40mail.gmail.com.
