GSOC proposal feedback (Refactor the ODE module and make it fast)

[mohitbalw...@gmail.com]

Hello everyone, 

I wanted to share my GSoC proposal if someone can provide a feedback, it would be really helpful.

Here is the  Link.

regards,

Mohit

[nijso.be...@gmail.com]

Hi Mohit,

I looked at your proposal. It is not clear to me what the result of the refactoring would be in terms of the algorithmic implementation or the benefits to the ODE solver. Is it the idea to have independent classes and therefore solvers for each of the ODE solvers and classifiers, that can then be called from a master ODE solver class, and that can be called independently? 

In any case I wouldn't use regular pattern matching to check if an ODE belongs to a certain class, as this almost never works consistently and reliably, the preferred approach is to use functional operators like differentiation to determine the class (like for exact ODEs). For instance the well-known example f(x,y) = exp(x*x + y*y) * (cos(x+y) + cos(x-y)) is separable. You can only find this with pattern matching if you follow a correct sequence of rewriting of the function using known rules for trigonometry, logarithms, etc. Your approach does not detail how to do the classifications of all the ODEs besides the mention of 'pattern matching'.

Your proposal for ode.py to loop over the implemented subsolvers, check if it matches the 'pattern' and then solve if it matches makes sense. But how much of the get_solution() part is shared by the different subsolvers? A number of the current subsolvers are actually the same, like the subsolvers based on undetermined coefficients,characteristic or homogeneous equations, there could be some merging here. Also, how is the order of the calls to the different subsolvers determined?  Then finally, there should be some further refinement in the classification, like first classifying as a scalar ODE, then determine the order, then go through the available options for this order (since most methods only work for a specific order of the ODE), this is not clear from the how you tackle this.

Just some ideas, all the best,

Nijso

[mohit balwani]

Hi Nijso,

Thanks for the feedback. 

Basic Idea is to implement an independent class for each solver and then from master ode.py we will just iterate and check if it matches the solver it will return the solution. Here is the issue link where Oscar suggested this approach : Link.

For Now each class will have their own get_general_solution() which returns the solution by that solver. I think after classifying them in these two major categories, then we can move ahead with merging.

I will try to add more details in the proposal for sure.

regards,

Mohit

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/bb2579ce-bdfa-46b4-a48f-f52a822b63d3n%40googlegroups.com.

[nijso.be...@gmail.com]

Hi Mohit, 

Ok great, I suspected this was the idea but it was not so clear from the proposal. I think it is a good move forward in creating a better structured ODE solver. It will make it easier to debug and improve individual solvers and gives a good structure to the overall DE solver. 

Best regards,

Nijso