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 [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/8c20f080-af4c-4660-8ada-c84a0f5cd4d3n%40googlegroups.com.
