Hi Naveen, Great, very detailed. But maybe first do the testing of the solver with the ODE database before merging with dsolve, unless your idea is to use the database for all ODE solvers. That would also considerably shift the focus towards testing of all subsolvers and if this is your plan (you mention something along those lines) then you should place more focus on this part, maybe even change the title of the proposal as this will then be most of your work.
You could also sketch how the Riccati ODE solver would be extended to e.g. second order linear ODEs. Actually, if you simply add a function SecondOrder2Riccati to transform second order linear ODEs and test if it has a rational solution, then you basically have the first class (of 3) of Liouvillian solutions for the second order linear ODE. The second class is also not difficult (as you can see in Bronsteins implementation in axiom, or in my implementation of Smith's maple code in maxima), you just have to construct different Riccati ODEs from the original one. After implementing Kovacic' method, Riccati ODEs that do not have rational solutions can be transformed into a second order linear ODE and with Kovacic' solver we check if it has a Liouvillian solution. By the way, the Kovacic method will solve more than 50% of all Kamke ODEs that are second order linear, so pretty good. Best regards, Nijso On Saturday, 3 April 2021 at 07:19:06 UTC+2 naveensai...@gmail.com wrote: > Hi Nijso and Oscar, > > I just finished making my proposal > <https://drive.google.com/file/d/14GyTe_bJJQMxlOqr_3ITSspGDxZNm8ip/view>. > Please go through it and let me know what you feel. > > Regards > Naveen > On Friday, April 2, 2021 at 9:28:41 AM UTC+5:30 Naveen Saisreenivas Thota > wrote: > >> Hi Nijso and Oscar, >> >> I just created a GitHub repo for the solver - RationalRiccatiSolver >> <https://github.com/naveensaigit/RationalRiccatiSolver>. >> >> Naveen >> On Wednesday, March 31, 2021 at 3:18:43 PM UTC+5:30 Naveen Saisreenivas >> Thota wrote: >> >>> Hi Nijso, >>> >>> > Great to see that you are making so much progress in such a short time! >>> Thank you! I have to say that you are really helping a lot creating a >>> roadmap that can help the ODE module a lot. Infact, the Riccati solver >>> wasn't even being considered until you talked about it! >>> >>> > You must have an upper bound for m, or else you have to check all >>> polynomials of degree 1..infinity. The upper bound is computed in step 8, >>> so that means that all d_i and c_i must be >known values. There might be >>> special solutions that can be found by searching for a low order polynomial >>> solution (P=1,2,3,4), and from that you could then compute the general >>> solution. > But it is not guaranteed that this will give you a solution. >>> So there is no way to generate a general solution if there are symbolic >>> constants in the equation? For example, if we consider Example 1.24, can we >>> not get the solution as given in the table, i.e. in terms of "a" and "b" >>> without substituting numbers for them like I'm presently doing? >>> >>> > Can you make a repository for your implementation? Then it will also >>> be easier to collaborate. You can then also put all ODEs in a separate >>> regression test. Since it is at this moment an >independent software >>> package, it needs a license, it would be good to choose the same as sympy >>> (new bsd). >>> Sure, I will do it by today or tomorrow. >>> >>> > The solution should be in Q, so rational, and some solutions are now >>> in C, so complex. This should be looked into. >>> To prevent this, should I discard imaginary poles? >>> >>> > You previously mentioned that you would also like to work on either >>> Kovacic or the generalization of the rational Riccati ODE to rational first >>> order ODEs if time permits. This Riccati solver > is a base solver for >>> these methods and should therefore be thoroughly tested. That is why I >>> think that before adding more functionality, the focus should be on a good >>> regression test. You > could make a time planning, with time reserved for >>> making the regression test, and finding and fixing problems for the Riccati >>> solver. In my experience, successfully going through the >entire ODE >>> database takes some time, especially if you care about time efficiency and >>> returning 'nice' answers. >>> Yes, in fact testing is taking more time than writing the code for the >>> solver, so I understand what you mean! So, I would definitely focus on >>> testing the Riccati solver on as many examples as possible from Kamke, >>> Murphy, etc. If time still remains, I will go ahead and implement either >>> Kovacic's algorithm or the algorithm to get all rational solutions of a >>> general first order ODE depending on what feels more necessary for SymPy. >>> >>> > Then, looking at Kovacic' method, you will see that it also depends on >>> the characterization of the poles of f(x) in the ODE y"=f(x)*y, so making a >>> function for pole computation in such a >way that it can be used by >>> Kovacic' method will allow code sharing. Kovacic' method can easily give >>> you very large expressions that can take a very long time to compute, so it >>> takes much > more time to debug and test this algorithm. That is something >>> that you should take into account. >>> I've seen some papers which use Differential Galois theory and come up >>> with an algorithm that essentially solves the same problem, but the solvers >>> are much faster. We can look into all of the available options and then >>> decide. >>> >>> Naveen >>> On Wednesday, March 31, 2021 at 2:29:17 PM UTC+5:30 >>> nijso.be...@gmail.com wrote: >>> >>>> Hi Naveen, >>>> >>>> Great to see that you are making so much progress in such a short time! >>>> Regarding your question: >>>> >I'm unable to understand how to compute solutions symbolically when >>>> the value of "m" is unknown. Is it possible? I can use sympy's assumptions >>>> to make sure that m.is_integer gives True, but how do I find polynomial >>>> solutions of degree "m" >for the auxiliary equation when "m" is unknown? >>>> You must have an upper bound for m, or else you have to check all >>>> polynomials of degree 1..infinity. The upper bound is computed in step 8, >>>> so that means that all d_i and c_i must be known values. There might be >>>> special solutions that can be found by searching for a low order >>>> polynomial >>>> solution (P=1,2,3,4), and from that you could then compute the general >>>> solution. But it is not guaranteed that this will give you a solution. >>>> >>>> Can you make a repository for your implementation? Then it will also be >>>> easier to collaborate. You can then also put all ODEs in a separate >>>> regression test. Since it is at this moment an independent software >>>> package, it needs a license, it would be good to choose the same as sympy >>>> (new bsd). >>>> The solution should be in Q, so rational, and some solutions are now in >>>> C, so complex. This should be looked into. >>>> You previously mentioned that you would also like to work on either >>>> Kovacic or the generalization of the rational Riccati ODE to rational >>>> first >>>> order ODEs if time permits. This Riccati solver is a base solver for these >>>> methods and should therefore be thoroughly tested. That is why I think >>>> that >>>> before adding more functionality, the focus should be on a good regression >>>> test. You could make a time planning, with time reserved for making the >>>> regression test, and finding and fixing problems for the Riccati solver. >>>> In >>>> my experience, successfully going through the entire ODE database takes >>>> some time, especially if you care about time efficiency and returning >>>> 'nice' answers. >>>> >>>> Then, looking at Kovacic' method, you will see that it also depends on >>>> the characterization of the poles of f(x) in the ODE y"=f(x)*y, so making >>>> a >>>> function for pole computation in such a way that it can be used by >>>> Kovacic' >>>> method will allow code sharing. Kovacic' method can easily give you very >>>> large expressions that can take a very long time to compute, so it takes >>>> much more time to debug and test this algorithm. That is something that >>>> you >>>> should take into account. >>>> >>>> >>>> Best regards, >>>> Nijso >>>> >>>> On Tuesday, 30 March 2021 at 20:25:11 UTC+2 naveensai...@gmail.com >>>> wrote: >>>> >>>>> Hi Nijso, >>>>> >>>>> I've made some changes to the code - split it up into functions and >>>>> added all the Riccati ODEs with Rational Solution from the report >>>>> <https://www3.risc.jku.at/publications/download/risc_5197/RISCReport15-19.pdf>. >>>>> >>>>> The present code can solve all the ODEs, but not completely in the sense >>>>> that I've substituted for constants like a, b, c with values in the >>>>> equation. >>>>> I have a doubt in Step 11 of Algorithm 11 >>>>> <https://www3.risc.jku.at/publications/download/risc_5387/PhDThesisThieu.pdf> >>>>> . >>>>> I'm unable to understand how to compute solutions symbolically when >>>>> the value of "m" is unknown. Is it possible? I can use sympy's >>>>> assumptions >>>>> to make sure that m.is_integer gives True, but how do I find polynomial >>>>> solutions of degree "m" for the auxiliary equation when "m" is unknown? >>>>> >>>>> Naveen >>>>> On Tuesday, March 30, 2021 at 2:16:14 PM UTC+5:30 >>>>> nijso.be...@gmail.com wrote: >>>>> >>>>>> Hi Naveen, >>>>>> >>>>>> This ODE comes from Banks, Gundersen, Laine: Meromorphic Solutions of >>>>>> the Riccati Differential Equation (example 4.2 >>>>>> http://www.acadsci.fi/mathematica/Vol06/vol06pp369-398.pdf) >>>>>> >>>>>> ode = y(x).diff(x) - y(x)**2 - 21/2 + 9/4*x**2 >>>>>> >>>>>> Your current implementation fails to find the solution (-1/(x-1) >>>>>> -1/x - 1/(x+1) + 3x/2) >>>>>> >>>>>> >>>>>> This ODE is example 4.6 from the thesis of Thieu: >>>>>> >>>>>> ode = y(x).diff(x) - ( (-3*x**2+2*x-2)/(x*(x-1)**2) - >>>>>> (6*x**2-x+3)/(x*(x-1))*y(x) - (3*x**2+1)/(x)*y(x)*y(x)) >>>>>> >>>>>> Your implementation finds 3 complex solutions while it should return >>>>>> 1 rational solution. >>>>>> >>>>>> Best regards, >>>>>> Nijso >>>>>> >>>>>> On Tuesday, 30 March 2021 at 09:53:35 UTC+2 nijso.be...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> By the way, Naveen, could you create a repository for your work? It >>>>>>> will be easier to work with. >>>>>>> >>>>>>> Best regards, >>>>>>> Nijso >>>>>>> >>>>>>> On Tuesday, 30 March 2021 at 09:48:48 UTC+2 nijso.be...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Naveen, Oscar, >>>>>>>> I agree with Oscar that there is still much work to be done, even >>>>>>>> having 'only' the rational Riccati solver implemented and tested is >>>>>>>> still a >>>>>>>> lot of work, after all you have to implement and test all subcases >>>>>>>> (movable >>>>>>>> poles, fixed poles, poles at infinity). And the solver should not only >>>>>>>> work >>>>>>>> on the solvable ODEs, but should also not get stuck on ODEs that are >>>>>>>> not >>>>>>>> solvable using this method. Also sometimes we will find only special >>>>>>>> solutions and we would need to construct the general solution from >>>>>>>> them. >>>>>>>> Since this is a core solver for possibly many other solvers, it is >>>>>>>> important that it functions very well. >>>>>>>> >>>>>>>> I have put the first 367 kamke odes (the ODEs of first order and >>>>>>>> first degree) in sympy format in a list, it is here: >>>>>>>> https://github.com/bigfooted/sympy_ode >>>>>>>> >>>>>>>> I think a modular approach is best and the solver should consist of >>>>>>>> a number of independent functions that can be re-used elsewhere. For >>>>>>>> instance: >>>>>>>> isRiccati(ode) : return True if the input ODE is Riccati, False >>>>>>>> otherwise, >>>>>>>> Riccati2Normal(ode) : returns the Riccati ode in normal form, >>>>>>>> Poles(ode) : returns the poles, and their order and multiplicities, >>>>>>>> etc.. >>>>>>>> But I think you have made a good start. >>>>>>>> >>>>>>>> Regarding the GSoC application: I would focus a bit more on that >>>>>>>> now, it's always good to be able to get some feedback before >>>>>>>> submitting >>>>>>>> (not sure how that works regarding independent reviewing, though). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Nijso >>>>>>>> >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, 30 March 2021 at 08:34:12 UTC+2 naveensai...@gmail.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Oscar, >>>>>>>>> >>>>>>>>> Should we add all the ODEs of Kamke and Murphy or only Riccati >>>>>>>>> ODEs? In either case, how do we plan on parsing the solution from >>>>>>>>> Maple/Mathematica? I could see that there is a Mathematica Parser, >>>>>>>>> but even >>>>>>>>> that seems to be very basic and is not parsing some complex >>>>>>>>> expressions. >>>>>>>>> >>>>>>>>> Naveen >>>>>>>>> On Monday, March 29, 2021 at 7:17:25 PM UTC+5:30 Naveen >>>>>>>>> Saisreenivas Thota wrote: >>>>>>>>> >>>>>>>>>> > When reviewing GSOC applications (just speaking for myself - I >>>>>>>>>> am not >>>>>>>>>> > the only reviewer) I am most interested in ensuring that we can >>>>>>>>>> get >>>>>>>>>> > the best contributors who are capable of making the most >>>>>>>>>> valuable >>>>>>>>>> > contributions to important parts of SymPy. What you are >>>>>>>>>> proposing here >>>>>>>>>> > is a significant improvement to an important part of SymPy so >>>>>>>>>> the main >>>>>>>>>> > points to focus on in your application are: >>>>>>>>>> > 1) making it clear why this is important and how significant >>>>>>>>>> the improvement is >>>>>>>>>> > 2) demonstrating that you personally understand what needs >>>>>>>>>> doing and >>>>>>>>>> > are capable of doing the necessary work >>>>>>>>>> >>>>>>>>>> Okay, thank you for the advice, Oscar! I'll make the proposal and >>>>>>>>>> post it here so that you and others can review it. >>>>>>>>>> >>>>>>>>>> Naveen >>>>>>>>>> On Monday, March 29, 2021 at 5:03:53 PM UTC+5:30 Oscar wrote: >>>>>>>>>> >>>>>>>>>>> On Mon, 29 Mar 2021 at 10:42, Naveen Saisreenivas Thota >>>>>>>>>>> <naveensai...@gmail.com> wrote: >>>>>>>>>>> > >>>>>>>>>>> > > I think you underestimate how much work is involved in >>>>>>>>>>> really making >>>>>>>>>>> > > the implementation robust and complete. Note that it's much >>>>>>>>>>> better to >>>>>>>>>>> > > have a well-tested, complete, efficient implementation of a >>>>>>>>>>> single >>>>>>>>>>> > > algorithm with nicely organised and documented code than it >>>>>>>>>>> is to have >>>>>>>>>>> > > multiple half-implemented algorithms. As Nijso emphasised >>>>>>>>>>> earlier the >>>>>>>>>>> > > most important thing first is to establish a systematic test >>>>>>>>>>> base. We >>>>>>>>>>> > > should get the Kamke examples in and you should verify that >>>>>>>>>>> this does >>>>>>>>>>> > > find all the rational function solutions for all of the >>>>>>>>>>> Ricatti ODEs. >>>>>>>>>>> > >>>>>>>>>>> > I was thinking as much, but I wanted to ask just to know your >>>>>>>>>>> opinion as well. I did test the current code with some examples, >>>>>>>>>>> but I am >>>>>>>>>>> yet to test it with all of them. So, from what you say, I am >>>>>>>>>>> planning to >>>>>>>>>>> include Rational Riccati Solver and ODE test bank (Kamke and >>>>>>>>>>> Murphy) as the >>>>>>>>>>> primary items to be done and leave computation of rational >>>>>>>>>>> solutions for a >>>>>>>>>>> general 1st order equation as a bonus? Will this be okay? >>>>>>>>>>> >>>>>>>>>>> Yes, I think that sounds good. >>>>>>>>>>> >>>>>>>>>>> Note, as I said in reply to some other queries about GSOC >>>>>>>>>>> exactly what >>>>>>>>>>> you would or wouldn't achieve within the duration of the project >>>>>>>>>>> is >>>>>>>>>>> less important than demonstrating that you are capable of making >>>>>>>>>>> significant contributions to SymPy. All tasks can turn out to be >>>>>>>>>>> harder or easier than expected so it's hard to estimate in >>>>>>>>>>> advance >>>>>>>>>>> what is possible given a fixed timeframe. >>>>>>>>>>> >>>>>>>>>>> When reviewing GSOC applications (just speaking for myself - I >>>>>>>>>>> am not >>>>>>>>>>> the only reviewer) I am most interested in ensuring that we can >>>>>>>>>>> get >>>>>>>>>>> the best contributors who are capable of making the most >>>>>>>>>>> valuable >>>>>>>>>>> contributions to important parts of SymPy. What you are >>>>>>>>>>> proposing here >>>>>>>>>>> is a significant improvement to an important part of SymPy so >>>>>>>>>>> the main >>>>>>>>>>> points to focus on in your application are: >>>>>>>>>>> 1) making it clear why this is important and how significant the >>>>>>>>>>> improvement is >>>>>>>>>>> 2) demonstrating that you personally understand what needs doing >>>>>>>>>>> and >>>>>>>>>>> are capable of doing the necessary work >>>>>>>>>>> >>>>>>>>>>> Then if your application is successful and it turns out that >>>>>>>>>>> (based on >>>>>>>>>>> the work you have already done) it is not hard to complete some >>>>>>>>>>> of the >>>>>>>>>>> tasks listed then there is no shortage of other things to be >>>>>>>>>>> done for >>>>>>>>>>> ODEs in SymPy. On the other hand if one of the tasks turns out >>>>>>>>>>> to be >>>>>>>>>>> more involved than expected then it is better to limit the scope >>>>>>>>>>> of >>>>>>>>>>> the project later and make sure that the parts that are >>>>>>>>>>> implemented >>>>>>>>>>> are done well. >>>>>>>>>>> >>>>>>>>>>> A general point that I often make to students is that (usually) >>>>>>>>>>> it is >>>>>>>>>>> better to do half a job well than to do the whole job badly. If >>>>>>>>>>> half a >>>>>>>>>>> job is done well then it makes a good starting point for someone >>>>>>>>>>> in >>>>>>>>>>> future to finish that work. If the whole job is done badly it >>>>>>>>>>> potentially makes it more difficult for someone else to improve >>>>>>>>>>> that >>>>>>>>>>> work than it would be for them if starting from scratch. >>>>>>>>>>> >>>>>>>>>>> Oscar >>>>>>>>>>> >>>>>>>>>> -- 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/26e2e552-1fc5-49ce-8d3a-449c21517a8en%40googlegroups.com.
