Thanks for your feedback. I will submit the proposal soon.
On Thu, Mar 26, 2020, 3:21 AM Oscar Benjamin
wrote:
> I had a quick look and it seems reasonable.
>
> On Wed, 25 Mar 2020 at 14:48, Milan Jolly wrote:
> >
> > If there are no issues with the proposal or the timeline mentioned(which
> I
I had a quick look and it seems reasonable.
On Wed, 25 Mar 2020 at 14:48, Milan Jolly 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.
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
I took a quick look. I found the logic of ode2sys and ode_rewrite very
resourceful since its required for component division and for reducing
higher order ODEs.
On Wednesday, March 25, 2020 at 2:28:10 AM UTC+5:30, Nicolas Guarin wrote:
>
> You can check what I have done about it in the
Hi Nicolás,
There are some good things in that notebook. Qualitative analysis of
nonlinear ODEs is orthogonal to the work here but absolutely something
that would be great to have in sympy.
Oscar
On Tue, 24 Mar 2020 at 20:58, Nicolas Guarin wrote:
>
> You can check what I have done about it in
You can check what I have done about it in the following notebook:
https://nbviewer.jupyter.org/github/nicoguaro/notebooks_examples/blob/master/ode2sys.ipynb
Let me know how can I help with the development.
Best,
Nicolás
PS: Sorry for taking that much to answer.
On Sunday, March 15, 2020 at
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
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
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
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
Stating clearly what the different parts do in high-level terms should
be sufficient.
On Fri, 20 Mar 2020 at 16:57, Milan Jolly 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
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,
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
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
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
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:
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
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
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
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
On Sun, 15 Mar 2020 at 14:45, Nicolas Guarin wrote:
>
> I have been working in a function that turn a higher-order system of ODEs
> into a system of first order equations. So you think that it might help?
Absolutely. This is mentioned in the roadmap:
I have been working in a function that turn a higher-order system of ODEs into
a system of first order equations. So you think that it might help?
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving
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
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
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
wrote:
> This section in the roadmap refers to existing stalled
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
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
wrote:
> The current refactoring effort applies only to the case of
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
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.
29 matches
Mail list logo
