It's not always the case that symmetric matrices commute so actually checking if it is symmetric is not sufficient e.g.:
In [83]: M = Matrix([[2*x**2, x], [x, x**2]]) In [84]: M.is_symmetric() Out[84]: True In [85]: M*M.diff(x) == M.diff(x)*M Out[85]: False Maybe there is something that can be said more generally about `exp(M(t)).diff(t)` when `M` is symmetric but does not necessarily commute with `M.diff(t)`... On Thu, 19 Mar 2020 at 18:34, Milan Jolly <[email protected]> wrote: > > In ODE systems roadmap, you have mentioned that for system of ODEs where the > coefficient matrix is non-constant, if the coefficient matrix A(t) is > symmetric, then A(t) and its anti derivative B(t) commute and thus we get the > solution based on this fact. But it is also mentioned that if A and B > commuting is more general than when A is symmetric, that is, it is possible > that A is not symmetric but A and B commute. So, for that solver, should we > first compute its anti derivative and test it that commutes with A or just > check if A is symmetric and use the solution? > > On Wednesday, March 18, 2020 at 3:18:31 AM UTC+5:30, Oscar wrote: >> >> That sounds reasonable. >> >> Note that we can't start raising NotImplementedError yet. You will >> need to think about how to introduce the new code gradually while >> still ensuring that dsolve falls back on the old code for cases not >> yet handled by the new code. >> >> On Tue, 17 Mar 2020 at 17:51, Milan Jolly <[email protected]> wrote: >> > >> > So, I have made a rough layout of the main function that will be used to >> > solve ODEs with the methods like >> > neq_nth_order_linear_constant_coeff_homogeneous/nonhomogeneous, >> > neq_nth_linear_symmetric_coeff_homogeneous/nonhomogeneous, special case >> > non-linear solvers, etc. >> > >> > Some notations used: >> > eqs: Equations, funcs: dependent variables, t: independent variable, >> > wcc: weakly connected component, scc: strongly connected component >> > >> > Introduction to helper functions that will be used(these are temporary >> > names, parameters and return elements and may be changed if required): >> > >> > 1. match_ode:- >> > Parameters: eqs, funcs, t >> > Returns: dictionary which has important keys like: order(a dict >> > that has func as a key and maximum order found as value), is_linear, >> > is_constant, is_homogeneous, eqs, funcs. >> > >> > 2. component_division:- >> > Paramters: eqs, funcs >> > Returns: A 3D list where the eqs are first divided into its wccs >> > and then into its sccs. >> > This function is suggested to be implemented later. So, until all >> > the other solvers are not ready(tested and working), this function will >> > just take eqs and return [[eqs]]. >> > >> > 3. get_coeff_matrix:- >> > Parameters: eqs, funcs >> > Returns: coefficient matrix A(t) and f(t) >> > This function takes in a first order linear ODE and returns matrix >> > A(t) and f(t) from X' = A(t) * X + f(t). >> > >> > 4. nth_order_to_first_order:- >> > Parameters: eqs, order >> > Returns: first order ODE with new introduced dependent variables. >> > >> > And all the first order linear solvers mentioned above. >> > >> > Now, besides the main function, there are two separate functions depending >> > on whether the system of ODEs is linear or not, namely _linear_ode_sol and >> > _non_linear_ode_sol. >> > >> > 1. _first_order_linear_ode_sol:- >> > Parameters: match dict(obtained earlier and maybe modified in >> > ode_sol) >> > Returns: Dict with keys as func and value as its solution that >> > solves the ODE. >> > Working: First, extracts A(t) and f(t) using get_coeff_matrix, >> > then using match dict, identify which solver is required and solve the ODE >> > if it is possible to do so. For example: Case where A(t) is not symmetric >> > isn't solved. >> > >> > 2. _non_linear_ode_sol has similar Parameters and Returns but the function >> > operates differently that's why it is essential to use a different >> > function. But I don't have a clear understanding >> > of how to design _non_linear_ode_sol yet but here is what I have came >> > up with: First match the condition where it is possible seperate out the >> > independent variable to get a relationship >> > between the dependent variables and then finally, just use the special >> > solver to solve the ODE. >> > >> > Now, coming to the main function ode_sol(for now, I haven't considered >> > initial values):- >> > Parameters: eqs, funcs, t >> > Returns: Solution in a dict form where func is the key and value is the >> > solution for that corresponding func. >> > >> > Working: >> > The steps of its working- >> > 1. Preprocess the equations. >> > 2. Get the match dict using match_ode function. >> > 3. Convert nth order equations to first order equations using >> > nth_order_to_first_order while storing the funcs seperately so that we can >> > later filter out the dependent variables that were introduced in this step. >> > 4. Get the 3D list of equations using component_division function. >> > 5. Iterate through the wccs and solve and store solutions seperately >> > but for sccs, first solve the first set of equations in a scc, then >> > substitute the solutions found in the first set of the current scc to the >> > second >> > set of current scc. Keep doing this until the all the sets for a >> > particular scc is solved. >> > 6. For solving a component, choose either _linear_ode_sol or >> > _non_linear_ode_sol depending upon the set of equations to be solved. >> > 7. Return a dict by taking out values from the solution obtained >> > using all the dependent variables in funcs as there may be more variables >> > introduced when we made the system into first order. >> > >> > For now, this is what I have came up with. Obviously the order in which we >> > will proceed is, build the basic layout of the main function and >> > component_division will just increase the number of dimensions to 3 >> > rudimentarily as we >> > will have to first ensure that the general solvers work well since working >> > on both of them simultaneously will make it tough to pinpoint the errors. >> > Along with that, non-linear solvers can be implemented later, we can just >> > raise a >> > NotImplementedError for now till we have completed both the general linear >> > solvers and the component_division and then add the special case solvers. >> > >> > On Tuesday, March 17, 2020 at 3:02:29 AM UTC+5:30, Oscar wrote: >> >> >> >> There are possibilities to go from nonlinear to linear e.g.: >> >> >> >> In [6]: x, y = symbols('x, y', cls=Function) >> >> >> >> In [7]: eqs = [x(t).diff(t)**2 - y(t)**2, y(t).diff(t)**2 - x(t)**2] >> >> >> >> In [8]: eqs >> >> Out[8]: >> >> ⎡ 2 2⎤ >> >> ⎢ 2 ⎛d ⎞ 2 ⎛d ⎞ ⎥ >> >> ⎢- y (t) + ⎜──(x(t))⎟ , - x (t) + ⎜──(y(t))⎟ ⎥ >> >> ⎣ ⎝dt ⎠ ⎝dt ⎠ ⎦ >> >> >> >> In [9]: solve(eqs, [x(t).diff(t), y(t).diff(t)], dict=True) >> >> Out[9]: >> >> ⎡⎧d d ⎫ ⎧d d ⎫ >> >> ⎧d d ⎫ ⎧d d ⎫⎤ >> >> ⎢⎨──(x(t)): -y(t), ──(y(t)): -x(t)⎬, ⎨──(x(t)): -y(t), ──(y(t)): >> >> x(t)⎬, ⎨──(x(t)): y(t), ──(y(t)): -x(t)⎬, ⎨──(x(t)): y(t), ──(y(t)): >> >> x(t)⎬⎥ >> >> ⎣⎩dt dt ⎭ ⎩dt dt ⎭ >> >> ⎩dt dt ⎭ ⎩dt dt ⎭⎦ >> >> >> >> On Mon, 16 Mar 2020 at 15:48, Milan Jolly <[email protected]> wrote: >> >> > >> >> > Thanks for the suggestion, I have started with the design for these >> >> > solvers. But I have one doubt, namely since now we are using >> >> > linear_eq_to_matrix function to check if the system of ODEs is linear >> >> > or not, would we require the canonical rearrangements part? Or rather >> >> > are there other cases when we can reduce non-linear ODEs into linear >> >> > ODEs. >> >> > >> >> > On Monday, March 16, 2020 at 2:53:57 AM UTC+5:30, Oscar wrote: >> >> >> >> >> >> That seems reasonable to me. Since the plan is a total rewrite I think >> >> >> that it would be good to put some time in at the beginning for >> >> >> designing how all of these pieces would fit together. For example even >> >> >> if the connected components part comes at the end it would be good to >> >> >> think about how that code would fit in from the beginning and to >> >> >> clearly document it both in issues and in the code. >> >> >> >> >> >> Getting a good design is actually more important than implementing all >> >> >> of the pieces. If the groundwork is done then other contributors in >> >> >> future can easily implement the remaining features one by one. Right >> >> >> now it is not easy to improve the code for systems because of the way >> >> >> that it is structured. >> >> >> >> >> >> On Sun, 15 Mar 2020 at 19:27, Milan Jolly <[email protected]> wrote: >> >> >> > >> >> >> > Thanks for your reply. I have planned a rough layout for the phases. >> >> >> > I took a lot of time this past month to understand all the >> >> >> > mathematics that will be involved and have grasped some part of it. >> >> >> > >> >> >> > If I am lucky and get selected for GSOC'20 for this organisation, >> >> >> > then the below is the rough plan. Please comment on suggestions if >> >> >> > necessary. >> >> >> > >> >> >> > Community Bonding phase: >> >> >> > 1. Using matrix exponential to solve first order linear constant >> >> >> > coefficient homogeneous systems(n equations). >> >> >> > 2. Adding new test cases and/or updating old ones. >> >> >> > 3. Removing and closing related issues if they are solved by the >> >> >> > addition of this general solver. Identifying and removing the >> >> >> > special cases solvers which are covered by this general solver. >> >> >> > >> >> >> > Phase I: >> >> >> > 1. Adding technique to solve first order constant coefficient >> >> >> > non-homogeneous systems(n equations). >> >> >> > 2. Adding the functionality that reduces higher order linear ODEs to >> >> >> > first order linear ODEs(if not done already, and if done, then >> >> >> > incorporating it to solve higher order ODEs). >> >> >> > 3. Adding a special case solver when non-constant linear first order >> >> >> > ODE has symmetric coefficient matrix. >> >> >> > >> >> >> > Phase II: >> >> >> > 1. Adding technique to solve non-constant non-homogeneous linear ODE >> >> >> > based off the solver added by the end of Phase I. >> >> >> > 2. Evaluating and eliminating unnecessary solvers. >> >> >> > 3. Closing related issues solved by the general solvers and >> >> >> > identifying and removing unwanted solvers. >> >> >> > 4. Adding basic rearrangements to simplify the system of ODEs. >> >> >> > >> >> >> > Phase III: >> >> >> > 1. Dividing the ODEs by evaluating which sub-systems are weakly and >> >> >> > strongly connected and handling both of these cases accordingly. >> >> >> > 2. Adding a special case solver where the independent variable can >> >> >> > be eliminated and thus solving the system becomes easier. >> >> >> > 3. Wrapping things up: adding test cases, eliminating unwanted >> >> >> > solvers and updating documentation. >> >> >> > >> >> >> > This is the rough layout and my plan for summer if I get selected. >> >> >> > If this plan seems ok then I would include this plan in my proposal. >> >> >> > >> >> >> > On Saturday, March 14, 2020 at 9:37:31 PM UTC+5:30, Oscar wrote: >> >> >> >> >> >> >> >> It's hard to say how much time each of these would take. The roadmap >> >> >> >> aims to completely replace all of the existing code for systems of >> >> >> >> ODEs. How much of that you think you would be able to do is up to >> >> >> >> you >> >> >> >> if making a proposal. >> >> >> >> >> >> >> >> None of the other things described in the roadmap is implemented >> >> >> >> anywhere as far as I know. Following the roadmap it should be >> >> >> >> possible >> >> >> >> to close all of these issues I think: >> >> >> >> https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+label%3Asolvers.dsolve.system >> >> >> >> >> >> >> >> On Fri, 13 Mar 2020 at 22:30, Milan Jolly <[email protected]> >> >> >> >> wrote: >> >> >> >> > >> >> >> >> > I have mostly read and understood matrix exponentials and Jordan >> >> >> >> > forms along with the ODE systems roadmap. But I am unclear as to >> >> >> >> > what has already been done when it comes to implementing the >> >> >> >> > general solvers. For example: The matrix exponentials part has >> >> >> >> > already been implemented and now I have a PR that has revived the >> >> >> >> > matrix exponential code. >> >> >> >> > >> >> >> >> > I want to make a proposal and contribute to make these general >> >> >> >> > solvers during this summer if my proposal gets accepted. But I am >> >> >> >> > unclear what should be the parts I need to work during community >> >> >> >> > bonding period, phase 1, phase 2 and phase 3 as I am unaware how >> >> >> >> > much time each part of the general solvers would take. >> >> >> >> > >> >> >> >> > If someone can help me in this regard(helping me with these 2 >> >> >> >> > questions) then it would be great. >> >> >> >> > >> >> >> >> > >> >> >> >> > On Tue, Feb 25, 2020, 5:09 AM Milan Jolly <[email protected]> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> I will go through the roadmap. Also, I will work on reviving and >> >> >> >> >> finishing the stalled PRs namely the matrix exponential one for >> >> >> >> >> now as I am interested in working towards this. Thanks. >> >> >> >> >> >> >> >> >> >> On Mon, Feb 24, 2020, 9:56 PM Oscar Benjamin >> >> >> >> >> <[email protected]> wrote: >> >> >> >> >>> >> >> >> >> >>> This section in the roadmap refers to existing stalled PRs >> >> >> >> >>> trying to >> >> >> >> >>> fix the n-equations solver for constant coefficient homogeneous >> >> >> >> >>> ODEs >> >> >> >> >>> which is the first step: >> >> >> >> >>> https://github.com/sympy/sympy/wiki/ODE-Systems-roadmap#constant-coefficients---current-status >> >> >> >> >>> >> >> >> >> >>> A first step would be to attempt to revive one or both of those >> >> >> >> >>> PRs >> >> >> >> >>> and finish them off. >> >> >> >> >>> >> >> >> >> >>> On Mon, 24 Feb 2020 at 05:59, Milan Jolly <[email protected]> >> >> >> >> >>> wrote: >> >> >> >> >>> > >> >> >> >> >>> > So, I am interested in rewriting parts of the current ODE as >> >> >> >> >>> > discussed in the roadmap. Is there any work started in that >> >> >> >> >>> > direction and if not then can I create a PR for the same? >> >> >> >> >>> > >> >> >> >> >>> > On Mon, Feb 24, 2020, 2:52 AM Oscar Benjamin >> >> >> >> >>> > <[email protected]> wrote: >> >> >> >> >>> >> >> >> >> >> >>> >> The current refactoring effort applies only to the case of >> >> >> >> >>> >> solving >> >> >> >> >>> >> *single* ODEs. The ODE systems code also needs to be >> >> >> >> >>> >> refactored but >> >> >> >> >>> >> (in my opinion) needs a complete rewrite. That is what the >> >> >> >> >>> >> roadmap is >> >> >> >> >>> >> about (it describes how to rewrite everything). The code for >> >> >> >> >>> >> systems >> >> >> >> >>> >> of ODEs should also get refactored in the process but there >> >> >> >> >>> >> is no need >> >> >> >> >>> >> to "refactor" it in its current form if it is in fact being >> >> >> >> >>> >> *completely* rewritten: we can just make sure that the new >> >> >> >> >>> >> code is >> >> >> >> >>> >> written the way we want it to be. >> >> >> >> >>> >> >> >> >> >> >>> >> On Sun, 23 Feb 2020 at 19:52, Milan Jolly >> >> >> >> >>> >> <[email protected]> wrote: >> >> >> >> >>> >> > >> >> >> >> >>> >> > Ok so I have gone through the links suggested and I have >> >> >> >> >>> >> > realised that as far as ODE module is concerned, >> >> >> >> >>> >> > refactoring is the most important task. But, as far as >> >> >> >> >>> >> > that is concerned, I think Mohit Balwani is working on >> >> >> >> >>> >> > this for a while and I want to limit any collisions with >> >> >> >> >>> >> > my co-contributors. So, I have couple of ideas to work on: >> >> >> >> >>> >> > 1. Helping to extend the solvers, i.e.implementing a fully >> >> >> >> >>> >> > working n-equations solver for constant coefficient >> >> >> >> >>> >> > homogeneous systems. This is from the ODE systems map. I >> >> >> >> >>> >> > am interested in working on this but I understand that it >> >> >> >> >>> >> > might be hard to work upon it while refactoring takes >> >> >> >> >>> >> > place. Still, if its possible to work on this and if no >> >> >> >> >>> >> > one else has started to work in this direction yet then I >> >> >> >> >>> >> > am willing to work for this. >> >> >> >> >>> >> > 2. Using connected components function implemented by >> >> >> >> >>> >> > Oscar Benjamin in >> >> >> >> >>> >> > https://github.com/sympy/sympy/pull/16225 to enhance ODE >> >> >> >> >>> >> > solvers and computing eigen values faster as mentioned >> >> >> >> >>> >> > here https://github.com/sympy/sympy/issues/16207 . >> >> >> >> >>> >> > 3. This idea is not mentioned in the ideas page and is >> >> >> >> >>> >> > something of my own. If there is anything possible, then I >> >> >> >> >>> >> > can also work on extending functions like maximum, >> >> >> >> >>> >> > minimum, argmax, argmin, etc in calculus module. I have >> >> >> >> >>> >> > been working on the issue >> >> >> >> >>> >> > https://github.com/sympy/sympy/pull/18550 and I think >> >> >> >> >>> >> > there is some scope to extend these functionalities. >> >> >> >> >>> >> > >> >> >> >> >>> >> > On Sunday, February 23, 2020 at 1:32:20 AM UTC+5:30, Milan >> >> >> >> >>> >> > Jolly wrote: >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> Hello everyone, >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> My name is Milan Jolly and I am an undergraduate student >> >> >> >> >>> >> >> at Indian Institute of Technology, Patna. For the past 2 >> >> >> >> >>> >> >> month, I have been learning and exploring sympy through >> >> >> >> >>> >> >> either contributions, reading documentation or trying >> >> >> >> >>> >> >> examples out. This last month I have learned a lot of new >> >> >> >> >>> >> >> things thanks to the well designed code-base, the >> >> >> >> >>> >> >> structured way this community works and most importantly >> >> >> >> >>> >> >> the maintainers who make it work. It has been a pleasure >> >> >> >> >>> >> >> to be a part of the community. >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> I am interested in participating for GSoC this year and I >> >> >> >> >>> >> >> would like to work for this org during the summers if I >> >> >> >> >>> >> >> am lucky. I particularly want to work on improving the >> >> >> >> >>> >> >> current ODE module as it is given in the idea list. There >> >> >> >> >>> >> >> is a lot of work that needs to be taken care of like: >> >> >> >> >>> >> >> 1. Implementing solvers for solving constant coefficient >> >> >> >> >>> >> >> non-homogeneous systems >> >> >> >> >>> >> >> 2. Solving mixed order ODEs >> >> >> >> >>> >> >> 3. Adding rearrangements to solve the system >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> These are not my ideas but I have taken inspiration from >> >> >> >> >>> >> >> the ideas page but I am up for working on these. If >> >> >> >> >>> >> >> someone can guide me regarding this then it would be >> >> >> >> >>> >> >> really helpful. >> >> >> >> >>> >> > >> >> >> >> >>> >> > -- >> >> >> >> >>> >> > 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/1033f581-abbb-4be5-a5b2-1988f4261535%40googlegroups.com. >> >> >> >> >>> >> >> >> >> >> >>> >> -- >> >> >> >> >>> >> 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/CAHVvXxTeWturK6WmtHKxakLqbV1yhp5_KoTPs8vPtmbu8%3D2VxQ%40mail.gmail.com. >> >> >> >> >>> > >> >> >> >> >>> > -- >> >> >> >> >>> > 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/CAMrWc1BZKcwjFvVQwZZ80P6s-CP62Tn_VN30zBEdjmqhrN44DA%40mail.gmail.com. >> >> >> >> >>> >> >> >> >> >>> -- >> >> >> >> >>> 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/CAHVvXxRGFJC%2BGeowaNJcVFQsQsGq%2Bh0SW-jmYezsSzU5%3DvipcA%40mail.gmail.com. >> >> >> >> > >> >> >> >> > -- >> >> >> >> > 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/CAMrWc1CYmTAwU4mFX%3DkOdZnmkzosN14VUAQBdteUETXas58n1w%40mail.gmail.com. >> >> >> > >> >> >> > -- >> >> >> > 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/b2d61327-da27-4baf-a753-cf4069abfc78%40googlegroups.com. >> >> > >> >> > -- >> >> > 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/38ad9558-b8e0-465a-aeb4-5ea782144b55%40googlegroups.com. >> >> >> > -- >> > 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/debf5cf4-2817-43ab-b4ad-64c60bf94c1e%40googlegroups.com. > > -- > 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/07fab7ec-3854-4a29-8e33-6e0804177d49%40googlegroups.com. -- 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/CAHVvXxQubdB3%3DOKjz%2BHhn6BNf1eMXtuY%2BwaKiDNgT%3D5SaTQZLA%40mail.gmail.com.
