I had a quick look and it seems reasonable.

On Wed, 25 Mar 2020 at 14:48, Milan Jolly <milan.joll...@gmail.com> wrote:
>
> If there are no issues with the proposal or the timeline mentioned(which I 
> will update soon due to the GSoC program timeline changes), then I am 
> planning on submitting the proposal in 2 days. Feedback would be appreciated 
> if possible.
>
> On Monday, March 23, 2020 at 10:00:22 PM UTC+5:30, Milan Jolly wrote:
>>
>> Thank you for your feedback. I have added another paragraph in the 
>> Motivation section where the I have added how these new solvers are 
>> advantageous to the end users.
>>
>> On Monday, March 23, 2020 at 1:25:31 AM UTC+5:30, Oscar wrote:
>>>
>>> I took a quick look. It's long so I didn't read it fully but it looks
>>> good. There is a lot of detail about what you would do but perhaps the
>>> motivation section can be strengthened. What does all of this mean for
>>> end users etc? If you completed the work described then sympy's
>>> capabilities for systems of ODEs would be expanded enormously.
>>>
>>> On Sun, 22 Mar 2020 at 19:26, Milan Jolly <milan....@gmail.com> wrote:
>>> >
>>> > Here is the link to my proposal: 
>>> > https://docs.google.com/document/d/12QN19LSjwEvYoSukyq-BWd76ZrI24FQuU0CGIOIx6Ww/edit?usp=sharing
>>> >
>>> > On Saturday, March 21, 2020 at 3:22:00 AM UTC+5:30, Oscar wrote:
>>> >>
>>> >> Stating clearly what the different parts do in high-level terms should
>>> >> be sufficient.
>>> >>
>>> >> On Fri, 20 Mar 2020 at 16:57, Milan Jolly <milan....@gmail.com> wrote:
>>> >> >
>>> >> > Thanks for clearing my doubt.
>>> >> >
>>> >> > Now, I have started preparing my GSOC proposal and it will be ready 
>>> >> > soon. But, I wanted to know that will it be ok that I don't give 
>>> >> > details about the implementations of the helper functions and solvers 
>>> >> > and simply state what they do, which parameters they take,  what they 
>>> >> > return and how they fit in the solving process while I give more 
>>> >> > details about how they fit together more generally. I would like to 
>>> >> > elucidate more on how the main function ode_sol handles the system of 
>>> >> > equations using the helper functions and various solvers as it is the 
>>> >> > only thing that is not clearly mentioned in the roadmap.
>>> >> >
>>> >> > On Friday, March 20, 2020 at 7:33:17 PM UTC+5:30, Oscar wrote:
>>> >> >>
>>> >> >> 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 <milan....@gmail.com> 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 <milan....@gmail.com> 
>>> >> >> >> 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 <milan....@gmail.com> 
>>> >> >> >> >> 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 
>>> >> >> >> >> >> <milan....@gmail.com> 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 
>>> >> >> >> >> >> >> <milan....@gmail.com> 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 
>>> >> >> >> >> >> >> > <milan....@gmail.com> 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 
>>> >> >> >> >> >> >> >> <oscar.j...@gmail.com> 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 
>>> >> >> >> >> >> >> >>> <milan....@gmail.com> 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 
>>> >> >> >> >> >> >> >>> > <oscar.j...@gmail.com> 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 
>>> >> >> >> >> >> >> >>> >> <milan....@gmail.com> 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 
>>> >> >> >> >> >> >> >>> >> > sy...@googlegroups.com.
>>> >> >> >> >> >> >> >>> >> > 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 
>>> >> >> >> >> >> >> >>> >> sy...@googlegroups.com.
>>> >> >> >> >> >> >> >>> >> 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 
>>> >> >> >> >> >> >> >>> > sy...@googlegroups.com.
>>> >> >> >> >> >> >> >>> > 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 
>>> >> >> >> >> >> >> >>> sy...@googlegroups.com.
>>> >> >> >> >> >> >> >>> 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 sy...@googlegroups.com.
>>> >> >> >> >> >> >> > 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 sy...@googlegr
>
> --
> 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/40081db9-7195-4dd8-9925-102280f78ed2%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAHVvXxT5EGs0wtY-St4j0XpAd29Oz86ujsJMpyPwhm_NAY_4aQ%40mail.gmail.com.

Reply via email to