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/7ac0a0ee-1ebf-470d-9d5d-d59b4fc060d7n%40googlegroups.com.
