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 [email protected] > 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 [email protected] 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 [email protected] >>> 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 [email protected] >>>> 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 [email protected] >>>>> 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 [email protected] >>>>>> 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 >>>>>>>>> <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/a40cdadd-736e-4235-9d7e-f724f3c09df7n%40googlegroups.com.
