I am almost done with my proposal but I wanted to ask something regarding
the same. Now, I have made a theory section and an implementation section
separately. In the theory section, I have given sufficient examples but the
implementation section became very big and I haven't added examples of
their working as I have just given the rough plan for all the functions
that will be implemented. Is it mandatory to give some demonstrations for
each of the functions(solvers, helpers, and the main ones)?
On Sat, Mar 21, 2020, 3:21 AM Oscar Benjamin <oscar.j.benja...@gmail.com>
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.joll...@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...@googlegroups.com.
> >> >> >> >> > 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 sy...@googlegroups.com.
> >> >> >> > 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 sy...@googlegroups.com.
> >> >> > 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 sy...@googlegroups.com.
> >> > 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 sympy+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/c69dc11d-d2bc-4e57-83e2-e06c483886aa%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/CAHVvXxSxwZevbwy%3DiOMe_awP%3Djoj6wuLQRoFuhmjjLfeeFv%3DWw%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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAMrWc1DQmWvGWhwVDidi39YqHAZ%3D96QWbfJCeLtAL5neqV97%3DQ%40mail.gmail.com.
