I had a quick look and it seems reasonable.

On Wed, 25 Mar 2020 at 16:11, mohit balwani
<mohitbalwani.ic...@gmail.com> 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
>>> <mohitbalwani.ic...@gmail.com> 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
>>> >>> <mohitbalwani.ic...@gmail.com> 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
>>> >>> >> <mohitbalwani.ic...@gmail.com> 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
>>> >>> >> >>> <mohitbalwani.ic...@gmail.com> 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 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 
>>> >>> >> >>> >>> <mohitbalwani.ic...@gmail.com> 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
>>> >>> >> >>> >>> >> <mohitbalwani.ic...@gmail.com> 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 to sympy+unsubscr...@googlegroups.com.
>>> >>> >> >>> >>> To view this discussion on the web visit 
>>> >>> >> >>> >>> https://groups.google.com/d/msgid/sympy/CAHVvXxSf5xAg2V0M1vF2xo%2B1_0C_s4P1pf8%3DPJwVKUYfNNRxyA%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/CAHVvXxS_jx5EeJ2jSefgTGEXDY_D86C4i85178H26nCYEcrkPA%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%2Buv0SrJtnusseGyGDwUqOBM-vGmTv5Z%2B4CwONdomBt%3D_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/CAHVvXxQvJeYsxKjg8au9JtG%2BP9n%2BNzx0S9xBMuynQeUqRUJS8w%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/6befc892-802b-4190-9779-c27f3e27adde%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/CAHVvXxQNG0rnRMdvrf%2BGB-9k%3D_odncVq%3DL%3D_QD-sdyXL3t95qQ%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%2BvEdS%2Bbye3qCz3NSYAFvNGNMuDmNykP%2Bq4R0TskfLO6KQ%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/CAHVvXxQmbcjjfAMjqjATdA%3Da6qNU8fBk%3D_F%3Duiq9CpPjfgvR-Q%40mail.gmail.com.

Reply via email to