[email protected] 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 <[email protected]> > 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 >> <[email protected]> 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 < >> [email protected]> 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 >> >> <[email protected]> wrote: >> >> > >> >> > hello, >> >> > >> >> > so should I resend the previous mail to the mailing list? >> >> > >> >> > On Tue, Mar 10, 2020 at 6:59 PM mohit balwani < >> [email protected]> 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 < >> [email protected]> 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 >> >> >>> <[email protected]> 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 >> >> >>> > >> >> >>> > [email protected] does this classification look good? >> >> >>> > Any suggestions would be really helpful. >> >> >>> > >> >> >>> > Regards, >> >> >>> > Mohit >> >> >>> > >> >> >>> > On Sun, Mar 8, 2020 at 1:53 PM mohit balwani < >> [email protected]> 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 < >> [email protected]> 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 < >> [email protected]> 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 < >> [email protected]> 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 >> >> >>> >>> >> <[email protected]> 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 [email protected]. >> >> >>> >>> >> > 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 [email protected]. >> >> >>> >>> >> 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 [email protected]. >> >> >>> >>> > 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 [email protected]. >> >> >>> >>> 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 [email protected]. >> >> 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 [email protected]. >> > 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/6befc892-802b-4190-9779-c27f3e27adde%40googlegroups.com.
