the current state of play using git or
from the zip here:
https://github.com/sympy/sympy/archive/master.zip
Oscar
On Mon, 11 Nov 2019 at 23:15, David Bailey wrote:
>
> On 11/11/2019 19:26, Aaron Meurer wrote:
>
> Hi all.
>
> I'm happy to announce that Oscar Benjamin will be the release m
wrote:
>
> Hi all.
>
> I'm happy to announce that Oscar Benjamin will be the release manager
> for SymPy 1.5. This will be the first release managed by someone other
> than me since 0.6.7, which was in 2010.
>
> Aaron Meurer
>
> --
> You received this message because
On Tue, 12 Nov 2019 at 23:46, Jason Moore wrote:
>
> There are two things that I think are important:
>
> - don't include backwards incompatible changes in releases without a
> deprecation cycle (cycle should be measured in real time, not # cycles)
It isn't always possible to have a deprecation
*
- Sachin Agarwal
- Harsh Agarwal*
- Supreet Agrawal
- Abhinav Anand*
- Oscar Gerardo Lazo Arjona*
- arooshiverma*
- Juan Barbosa*
- Oscar Benjamin
- Gabriel Bernardino*
- Parker Berry
- Johan Blåbäck
- Francesco Bonazzi
- Ondřej Čertík
- Arighna Chakrabarty
- Pengning Chao*
- Sean P. Cornelius*
- Björn
On Fri, 13 Dec 2019 at 21:41, Oscar Benjamin wrote:
>
> Hi all,
>
> It is my pleasure to announce the release of SymPy 1.5 today. I have
> uploaded the release files to for this release to PyPI so you should
> be able to install or upgrade with
>
> $ pip install -U
c 13, 2019 at 2:40 PM Oscar Benjamin
> wrote:
> >
> > Hi all,
> >
> > It is my pleasure to announce the release of SymPy 1.5 today. I have
> > uploaded the release files to for this release to PyPI so you should
> > be able to install or upgrade with
> >
&
> mathics, you may need to use separate virtual environments until it is
> updated to work with SymPy 1.5.
>
> Aaron Meurer
>
> On Fri, Dec 13, 2019 at 3:11 PM David Bailey wrote:
> >
> > On 13/12/2019 21:41, Oscar Benjamin wrote:
> >
> > Hi all,
> >
&
On Sat, Dec 14, 2019 at 4:47 PM Isuru Fernando wrote:
>> >
>> > FYI, NumPy has already dropped python 2.7 support in 1.17.0 in July. They
>> > are supporting 1.16.x until January, 1 2020 and 1.16.x will no longer be
>> > supported.
>> >
>> > Isur
appens when NumPy drops
> it. I personally feel like shit might hit the fan.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
>
> On Sat, Dec 14, 2019 at 3:05 PM Aaron Meurer wrote:
>>
>>
>>
>> On Sat, Dec 14, 2019 at 2:31 PM Oscar Benjamin
>
.
On Sun, 15 Dec 2019 at 11:50, Oscar Benjamin wrote:
>
> In practical terms, maintaining an LTS just means that if a
> substantial problem arises with using SymPy 1.5 on Python 2.7 we could
> add a fix for it on the 1.5 branch and release 1.5.x with that fix. I
> can't see what tha
I would like to make it so that functions like `sin` are first-class
symbolic objects, subclassing from Basic. There has been an abandoned
attempt to do that in the past. If we had that then we could have a
symbolic differentiation operator.
I don't think I'd want normal SymPy functions to
What do you mean that SymPy uses a different coordinate system to OpenGL?
If you are referring to the fact that OpenGL uses a left-handed
coordinate system then that shouldn't matter. SymPy doesn't have any
handedness in its coordinate system because that doesn't come into any
of the equations
This is the right place to ask this question. You can also ask on
StackOverflow.
On Sat, 7 Dec 2019 at 21:20, Jaime Resano Aisa
wrote:
> Well I'm having issues coding a geometry program and I thought it could be
> a problem with the axis correspondency, but if that is not the case it is
> my
These calculations can be made much faster in SymPy. These are only
2x2 matrices so I would just take the basic formula for the inverse of
a 2x2 matrix and sub into that:
In [20]: Matrix([[x, y], [z, t]]).inv()
Out[20]:
⎡t -y⎤
⎢─ ─⎥
⎢t⋅x - y⋅z t⋅x - y⋅z⎥
⎢
There might be others but I was thinking of this PR:
https://github.com/sympy/sympy/pull/13872
The idea there is that functions like sin should become first-class
symbolic objects. Then sin(x) would create an object that represents
calling the function sin with the argument x like Call(sin, x).
type annotations with enforcement in testing.
> integration of MatchPy into SymPy (unfortunately this step requires to drop
> Python 3.5 support as well, as MatchPy is Python 3.6+ only).
>
>
> On Saturday, 14 December 2019 02:38:23 UTC+1, Oscar wrote:
>>
>> On Fri,
tell the other issues are just issues like all the
rest of the 3000 open issues that SymPy has.
On Mon, 7 Oct 2019 at 21:15, Oscar Benjamin wrote:
>
> I have been working on finishing some of these but I feel the need
> (hint, hint :) ) to point out that this particular one is waiting
Hi Orestis,
It's great that you would like to contribute to SymPy. There is plenty
of work to be done on ODEs. For your suggestions I think that possibly
the simplest would be implementing a solver for the Legendre equation.
I would recommend to start with fixing the simplest thing possible
By the way all of the methods you are both discussing for dsolve are
for solving single ODEs. Actually the part that really *needs* work is
systems of ODEs. It wouldn't be hard to make big improvements there.
On Wed, 16 Oct 2019 at 15:09, open jungle wrote:
>
> Thank you, I'll get to it as soon
HI Lauren,
Thanks for all of the great work you did!
Oscar
On Tue, 26 Nov 2019 at 23:14, Lauren Glattly wrote:
>
> Hello,
>
> I just wanted to share the results of the 2019 Google Season of Docs project
> with SymPy:
>
On Tue, 26 Nov 2019 at 21:21, Jaime Resano Aisa
wrote:
>
> How can I modify code from the polygon file and execute it locally for making
> the test process without creating pull requests? I only need to execute the
> tests of that class
You can run the tests locally by running e.g
$ bin/test
Kindly provide a link.
> Happy Holidays to the Sympy Team
>
> Terry Lee Deglow-Smith
>
> On Fri, Nov 29, 2019 at 1:34 AM Oscar Benjamin
> wrote:
>>
>> Hi SymPy users and contributors,
>>
>> It is my pleasure to announce the *release candidate*
Bailey wrote:
>
> On 29/11/2019 09:34, Oscar Benjamin wrote:
>
> Hi SymPy users and contributors,
>
> It is my pleasure to announce the *release candidate* of SymPy 1.5. This is
> is intended for advance testing but if there are no regressions
> reported then there will be n
On Mon, 2 Dec 2019 at 01:59, JS S wrote:
>
> But what confuses me is this:
>
> - ImmutableDenseMatrix is subclass of Expr
> - ImmutableSparseMatrix is subclass of Basic, but not Expr.
> - ImmutableDenseNDimArray is, unlike its Matrix counterpart, subclass of
> Basic but not Expr.
I don't think
Hi SymPy users and contributors,
It is my pleasure to announce the *release candidate* of SymPy 1.5. This is
is intended for advance testing but if there are no regressions
reported then there will be no changes to this before the 1.5 final
release.
The final release will be in around a week
I have been working on finishing some of these but I feel the need
(hint, hint :) ) to point out that this particular one is waiting
review:
https://github.com/sympy/sympy/pull/17593
I think it should go together with the other changes to ProductSet and
Lambda which are already merged for 1.5.
There is no function to find all 3 solutions. It would be good to have
one. In general it can be hard even to know how many solutions there
are from a pure numerical algorithm but I think that something based
on interval-Newton would be useful:
I think it would be good to use mypy but it will be a lot of work just
to get working on a small part of the codebase because so much of
SymPy is inconsistent about types right now. Ultimately it's not just
a case of "using mypy" but actually fixing the inconsistencies which
is a big task. Perhaps
possibilities to use Piecewise for systems of n equations.
> Giving a solution that is correct in the limit is sufficient.
>
> Aaron Meurer
>
> On Mon, Feb 24, 2020 at 3:31 PM Oscar Benjamin
> wrote:
> >
> > Hi all,
> >
> > I've written a roadmap for rewriting th
On Thu, 5 Mar 2020 at 11:30, Lorenzo Monacelli
wrote:
>
> Dear all,
> I would like to implement some basic manipulation with matrices that I need.
> The problem I'm facing is that I cannot figure out how to recognize correctly
> a MatrixSymbol:
> from sympy.abc import i,j
> A =
Hi all,
I've written a roadmap for rewriting the ODE systems code:
https://github.com/sympy/sympy/wiki/ODE-Systems-roadmap
The roadmap represents a bonfire of the existing code and proposes to
delete all 33 of the current systems solvers. Around 7 of those are
untested and entirely broken and
?
>
> On Mon, Feb 24, 2020, 2:52 AM Oscar Benjamin
> 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 w
There has been some work in simplifying unions of imagesets:
https://github.com/sympy/sympy/pull/18489
I think that work could be continued by someone else (better to ask
first on that pull request before working on it though).
On Mon, 2 Mar 2020 at 19:05, Aaron Meurer wrote:
>
> Can you
Do you have a link to the relevant page? How can you tell that the
format is changed?
On Mon, 2 Mar 2020 at 19:54, Chris Smith wrote:
>
> The wiki was changed from rest to wikimedia format but this broke some things
> and put an illegible table of contents on the page. This should be fixed by
There have been proposals to add a control theory module. See here for
a recent revival of that:
https://github.com/sympy/sympy/issues/18460
Would that be a good place to put some of the ideas you are suggesting?
On Fri, 24 Jan 2020 at 13:17, Chanakya Ajit Ekbote wrote:
>
> There are certain
Hi Naman,
Sorry I wasn't objecting to the proposal. If this is something that
you are interested in then I think it is a good addition.
Oscar
On Tue, 4 Feb 2020 at 19:35, Aaron Meurer wrote:
>
> I agree with Jason. The idea is on the ideas page so it is valid for GSoC.
>
> If the proposal gets
I don't see any connection between the original post and your reply but...
My understanding is that the Coppersmith Winograd algorithm is not
really used anywhere:
https://en.wikipedia.org/wiki/Galactic_algorithm
I'm not sure if that is the same algorithm. The paper you cite looks
like an
on
> the project which has value in itself. Its also easier for newcomers to wrap
> their head around.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Mon, Feb 3, 2020 at 6:16 AM Oscar Benjamin
> wrote:
>>
>> In general I question whethe
In general I question whether things like this need to be part of the
main sympy project rather than as another project on pypi that can be
installed separately. If we are going to include domain-specific
modules that are really just built on top of sympy then I think that
it is important that
On Mon, 3 Feb 2020 at 20:40, Aaron Meurer wrote:
>
> This isn't against the rules of GSoC. However, I would caution against
> doing such a thing. Unless there are other people other than the GSoC
> student who are willing to help develop and maintain the package after
> the end of GSoC, the
On Tue, 4 Feb 2020 at 10:08, Sachin Agarwal wrote:
>
> After that I would request some member of SymPy to allot a specific number of
> issues to me so that we can ensure nobody else tries to work on them.
> Moreover which will be enough to constitute a summer project.
We don't generally
Hi Sachin,
I think that a project along these lines needs to have some scope.
There are a lot of open issues so which ones roughly would you fix?
It needs to be possible for someone to act as a mentor so it should be
well-defined which parts of the codebase you will work on. Issues on
github are
You can see some of the discussion here:
https://github.com/sympy/sympy_doc/pull/33#issuecomment-580970009
I think the original discussion was on the mailing list...
On Sat, 1 Feb 2020 at 01:33, Jason Moore wrote:
>
> Is there an issue or email thread regarding the decision to do this? I'd like
The sympy plotting module is mostly a wrapper around matplotlib. You
can use matplotlib directly for a lot of the things you suggest.
I think it would be better if sympy's plotting module didn't try to
wrap up other libraries as "backends" but instead focussed on
documenting how it should be used
Those might be able to speed things up but not until the ODE module is
refactored. The reason the module needs to be refactored is that right
now it runs the whole of classify_ode including the matching code for
every single solver.
If it just returned the first match straight away and computed
The release notes for 1.6 are here:
https://github.com/sympy/sympy/wiki/Release-Notes-for-1.6
On Thu, 20 Feb 2020 at 17:56, Chris Smith wrote:
>
> That's what I figured, but I can't find a path to their location. I see
> "Release Notes" but that only has 1.5 as the most recent. And the change
It doesn't always make sense to delegate these properties to the
subexpressions of a Piecewise. For example knowing that the
subexpressions are hypergeometric functions does not mean that the
piecewise itself is a hypergeometric function.
On Fri, 21 Feb 2020 at 13:28, Chris Smith wrote:
>
> In
I have started writing a roadmap and intro to the maths for dsolve for
systems here:
https://github.com/sympy/sympy/wiki/ODE-Systems-roadmap
On Sun, 23 Feb 2020 at 05:22, Aaron Meurer wrote:
>
> Are you familiar with Oscar's efforts to refactor the ODE module?
>
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://gith
The docs are updated when a new version of SymPy is released. I'm not
sure when that will be but not for a while given that the last version
was only just released.
On Sat, 11 Jan 2020 at 22:21, Jaime Resano Aisa
wrote:
>
> Hi, I did a pull request which got merged a few weeks ago but the docs
I've added some stuff about ODEs:
https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#systems-of-ordinary-differential-equations
https://github.com/sympy/sympy/wiki/GSoC-2020-Ideas#refactor-the-ode-module-and-make-it-fast
I'll try to add more later
On Wed, 15 Jan 2020 at 18:42, mohit balwani
I've just merged a PR that fixes the 1000 or so mypy errors on sympy's
master branch:
https://github.com/sympy/sympy/pull/18244
This means it is now possible to try out using mypy without seeing
lots of unrelated errors. The next step is to add type hints in key
places. They don't need to be
What do you mean by complex coefficients?
I can think of several meanings:
1. You want to know if any of the coefficients has non-zero imaginary part.
2. You want to know that all of the coefficients represent complex
numbers and not something else like matrices.
3. You want to know that the
If you install google cloud SDK and clone the sympy live repo you can
run it locally with:
../../google-cloud-sdk/bin/dev_appserver.py .
(i.e. run this command in the root of the sympy-live repo and give the
path to the dev_appserver.py script)
Then go to a browser and open localhost:8080
That
The integrate function when used without limits finds an
antiderivative. In general antiderivatives are not unique and can
differ by a constant which I think is the case here. The
simplifications below won't work though unless the symbols are
declared positive:
In [44]: a, b, x = symbols('a b x',
On Mon, 13 Jan 2020 at 20:52, Josefsson-Ljungdahl wrote:
>
> Yes, a primitive function is unique only up to a constant but it is not
> strictly correct to pick out a particular one since the constant is
> arbitrary. This may be an academic point but I would have thought that it
> would be
I'm not sure what you're asking. These all calculate instantly:
In [11]: x, y, a = symbols('x, y, a')
In [12]: eqn=y*(x*a)*0.3014
In [13]: eqn
Out[13]: 0.3014⋅a⋅x⋅y
In [14]: solve(eqn, x)
Out[14]: [0.0]
In [15]: eqn=y*(x*a)**0.3014
In [16]: eqn
Out[16]:
0.3014
y⋅(a⋅x)
In [17]:
e your app.yaml file, I will take it as a reference
> to work mine and I will reinstall everything and try to work it this time..
>
> On Mon, Jan 20, 2020, 19:57 Oscar Benjamin wrote:
>>
>> I'm afraid I can't tell you exactly what to do here. It depends where
>> the f
hell . You'll also
>> probably
>> # want to add login: admin to restrict to admins only.
>> - url: /.*
>> script: shell.application
>> secure: always
>> "
>>
>> On Sun, Jan 19, 2020 at 6:38 PM Oscar Benjamin
>> wrote:
>>>
>>>
Thanks for reporting this. I've just tried myself and I get the same.
Maybe there is a problem with updating it to 1.5. I tried a few things
to get it to update but they haven't worked.
On Tue, 24 Dec 2019 at 17:44, Hunter McClelland
wrote:
>
> I'm a first-time Sympy user, and was excited to
so suspect there would be
>>> issues getting mypy to work with the SymPy type system. I'm not sure
>>> how well they support custom types. It would be a good GSoC project or
>>> if an existing dev wants to work on it, a good proposal for a NumFOCUS
>>> small developm
Can you simplify this a bit? That's a lot of code but presumably there
is a smaller part that shows the problem. Is this it?
In [4]: simplify(Derivative(sin(x), x))
Out[4]: cos(x)
On Thu, 26 Dec 2019 at 20:05, wrote:
>
> It looks to me like “simplify” has lost all derivatives. As you might
))
> eqTest2 = eqTest1.simplify()
> print('eqTest2 = simplification of eqTest1:')
> print(eqTest2)
> print(latex(eqTest2))
>
> Tom
> (Dr. Thomas S. Ligon)
> thomassli...@gmail.com
> Frohnloher Str. 6a
> 81475 Muenchen
> Germany
> Tel. +49(89)74575075
>
> -Or
!
- Oscar Benjamin
- S.Y. Lee
- Aaron Meurer
--
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 sympy+unsubscr...@googlegroups.com.
To view this
-docs-html-1.5.1.zip
760b1d02e32ef3e152dfa61b88bb732bf900ca0709b10d79e729164a2fb5236b
sympy-docs-pdf-1.5.1.pdf
On Sun, 5 Jan 2020 at 15:31, Oscar Benjamin wrote:
>
> Hi all,
>
> It is my pleasure to announce the release of SymPy 1.5.1 today. I have
> uploaded the release files to f
You need to give much more detail if you want a reasonable response.
What does it even mean to "implement statistical mechanics"?
On Mon, 9 Mar 2020 at 19:30, Riyan wrote:
>
>
> Can someone please tell me your views on the above idea.
>
> On Sunday, March 8, 2020 at 4:18:25 PM UTC+5:30, Riyan
Hi Neeraj,
That all sounds excellent. I don't know the algorithms you are
referring to or the summation code that well myself but I know that it
needs some love!
A GSOC proposal is always more enticing if it demonstrates
understanding of the existing codebase and known problems. It is
probably
e blocks which are not tested.
>
> So will this be enough for GSoC'20?
>
> On Fri, Jan 24, 2020, 12:14 AM Oscar Benjamin
> wrote:
>>
>> Those might be able to speed things up but not until the ODE module is
>> refactored. The reason the module needs to be refac
ern matching to write general solution we should use the
>> extracted elements given by wilds function.
>>
>> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin
>> wrote:
>>>
>>> I think the series solvers should probably have their own superclass.
>>&g
p. 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 secti
On Wed, 11 Mar 2020 at 16:58, Aaron Meurer wrote:
>
> The convention used is actually related to the Karr algorithm, in that
> it is based on the conventions defined in his paper
> https://docs.sympy.org/latest/modules/concrete.html#sympy.concrete.summations.Sum.
> It relates to the way so-called
endent derivatives
> and in pattern matching to write general solution we should use the extracted
> elements given by wilds function.
>
> On Tue, Mar 10, 2020 at 4:18 PM Oscar Benjamin
> wrote:
>>
>> I think the series solvers should probably have their own superclass.
>
It's not clear to me what problem your proposal is intending to solve.
In what way is it different from the current evalf algorithm/results?
--
Oscar
On Wed, 11 Mar 2020 at 22:48, Shubham thorat wrote:
>
> This is how I have divided the tasks:
> The algorithm is defined in this paper:
>
UvutTmkDX6BmsFfmIs/edit?usp=drivesdk
>
> Any suggestions would really be appreciated.
>
> On Tue, Mar 10, 2020, 9:15 PM Oscar Benjamin
> wrote:
>>
>> Hi Mohit,
>>
>> You don't need to resend the previous emails. This discussion is
>> becoming too det
Yes, that sounds like a reasonable change.
On Fri, 10 Apr 2020 at 14:17, jlh wrote:
>
> Hello everyone!
>
> I noticed that powers of non-square matrices (with MatPow) do not raise an
> error, e.g. if A = MatrixSymbol('A', 2, 3) then MatPow(A, 10) does not raise.
> I would assume that this is
I just tried this and it worked fine:
$ python
Python 3.8.1 (v3.8.1:1b293b6006, Dec 18 2019, 14:08:53)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from sympy.testing import *
>>>
On Tue, 7 Apr 2020 at 23:13, Chris Smith
Thanks I think that this is a bug on roots_quintic. Can you open an
issue on github:
https://github.com/sympy/sympy/
On Mon, 20 Apr 2020 at 20:02, Tiam Koukpari wrote:
>
> I found a bug in Sympy's solve function.
>
> from sympy import solve
> from sympy.abc import x
> solve(x**5 - 6*x**3 -
lo,
>> I have made some changes in project motivation. Does this look good or
>> Should I detail that more?
>>
>> On Thu, Mar 12, 2020 at 5:15 AM Oscar Benjamin
>> wrote:
>>>
>>> I think it would be good to spend more time explaining what change
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:
uld 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 wrote:
>> >>
>> >> I will go through the roadmap
Hi Ondrej,
What exactly what the project do? Is there a wider approach that can
be taken that handles this sort of thing?
Oscar
On Thu, 26 Mar 2020 at 21:38, Ondřej Čertík wrote:
>
> Hi,
>
> Here is a great idea for a GSoC project:
>
>
Hi all,
Over the past couple of months I have lost count of the number of
times that I have been emailed off-list by people interested in
applying for GSOC with sympy this year.
It's excellent that so many people are interested but I have not
replied to *any* off-list emails and I don't intend
Anyone is welcome to contribute to work on systems of ODEs.
There is a lot written about this here:
https://github.com/sympy/sympy/wiki/ODE-Systems-roadmap
Some work is already going on here:
https://github.com/sympy/sympy/pull/18720
You can also see the open issues here:
>> think about how that code would fit in from the beginning
>>> >> >> >> >> >> and to
>>> >> >> >> >> >> clearly document it both in issues and in the code.
>>> >> >> >> >
wrote:
>>
>> +oscar.j.benja...@gmail.com I have made changes you suggested about
>> refactoring test_ode.py in phase-I. could you please review it again?
>>
>> On Sun, Mar 15, 2020 at 7:40 PM Oscar Benjamin
>> wrote:
>>>
>>> I think it would be
ki, but we can add something.
>>
>> Aaron Meurer
>>
>> On Thu, Mar 26, 2020 at 4:07 PM Oscar Benjamin
>> wrote:
>> >
>> > Hi all,
>> >
>> > Over the past couple of months I have lost count of the number of
>> > times tha
Perhaps there could also be a mentor mailing list for helping any new
contributors (GSOC or otherwise) looking to open a first pull request.
On Fri, 27 Mar 2020 at 20:41, Oscar Benjamin wrote:
>
> On Fri, 27 Mar 2020 at 18:31, Aaron Meurer wrote:
> >
> > Maybe the bes
On Fri, 27 Mar 2020 at 18:31, Aaron Meurer wrote:
>
> Maybe the best way for students to simply introduce themselves would
> be to mention that they are apply to GSoC when they open their first
> pull request. Since they have to open a pull request anyway, this
> should reduce the noise.
I think
Numerical solutions of ODEs are mostly out of scope for sympy. There
is some capability for numerically solving ODEs in mpmath and I think
that sympy should make use of that but we don't need to implement
these numerical algorithms in sympy except to use the methods provided
by mpmath.
On Sun, 29
Hi Bhaskar,
It is fine for multiple applicants to suggest similar projects. There
are plenty of other things to do in terms of refactoring and
optimising that will become possible as the initial refactoring
becomes complete. For example we should add benchmarks to the
benchmarks repo and profile
You can use dsolve for boundary value problems you just have to give the
boundary conditions as the ICs argument e.g.:
In [*27*]: f = Function('f')
In [*28*]: t = Symbol('t')
In [*29*]: dsolve(f(t).diff(t, 2)-f(t))
Out[*29*]:
-t t
f(t) = C₁⋅ℯ + C₂⋅ℯ
In [*30*]:
>>
> >> Oscar
> >>
> >> On Sun, 26 Apr 2020 at 09:18, Aaron Meurer wrote:
> >> >
> >> > Thanks for doing this!
> >> >
> >> > It might be worth running the benchmarks to see if there any
> >> > regressions we
It doesn't look like dsolve can do that. I think it's worth opening an
issue on github for that.
To solve your problem right now you can set up the IC equations using
the general solution and solve for the constants with solve.
--
Oscar
On Mon, 27 Apr 2020 at 22:21, Isaque Soares wrote:
>
>
Hi all,
I think it's time to start thinking about the sympy 1.6 release. At
this stage all that needs doing is flagging issues or pull requests
that are potential release blockers.
I've opened an issue to keep track of the release itself here:
https://github.com/sympy/sympy/issues/19193
If you
erformance related.
>
> Aaron Meurer
>
> On Sat, Apr 25, 2020 at 2:07 PM Oscar Benjamin
> wrote:
> >
> > Hi all,
> >
> > I think it's time to start thinking about the sympy 1.6 release. At
> > this stage all that needs doing is flagging issues or pull
Hi Arpan,
There is no particular timeline at this stage but I guess in a week or
so I'll make a 1.6 branch and start clearing release blockers.
Oscar
On Sun, 26 Apr 2020 at 12:25, Arpan Chattopadhyay
wrote:
>
> In how many days are we planning to take SymPy 1.6 live?
>
> --
> You received this
What version of sympy are you using? I get an exception from eq3 = eq1 + eq2.
We need a new Equation class that works properly with arithmetic
operations etc. I have made written one but haven't added it to sympy
yet. I got sidetracked at the time because deeper structural changes
were needed
Oh sorry, I got confused. In 1.6 (the next release) adding two
Equalitys will give a TypeError.
In [1]: Eq(x, y) + Eq(z, t)
---
TypeError Traceback (most recent call last)
in
> 1 Eq(x, y)
Seeing that use of factor_terms makes me think again that expand
should definitely pull out that constant.
On Thu, 30 Apr 2020 at 22:27, Chris Smith wrote:
>
> The following light-weight version of what Oscar has suggested might be
> sufficient:
>
> >>> def add(s,o):
> ... assert s.func ==
= I*sin(x)
In [37]: (eq1 + eq2)/2
Out[37]: exp(I*x)/2 + exp(-I*x)/2 = cos(x)
--
Oscar
On Thu, 30 Apr 2020 at 23:29, David Bailey wrote:
>
> On 30/04/2020 19:18, Oscar Benjamin wrote:
>
> In 1.5 it just gives a nonsense object:
>
> In [1]: Eq(x, y) + Eq(z, t)
> Out[1]: (x = y)
101 - 200 of 710 matches
Mail list logo
