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/8966d0a7-1c5e-4572-b22f-afd1557f99b0n%40googlegroups.com.
