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 <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/CAGoPB%2BvqSNJOkQQYFb0%2BQpT4kmyVaXBycvntaqUQvQtJskbXLw%40mail.gmail.com.
