hat doesn't support Equation, you should pass the lhs and rhs
> separately. I think it would still be possible to have an Equation
> class nested inside of an expression, but such things should be
> avoided (or maybe we should try to disallow it).
>
> Aaron Meurer
>
> On Thu,
Hi David,
Yes, I hope something like it would go into 1.7. I don't have time
myself to make it ready for 1.6.
Oscar
On Fri, 1 May 2020 at 00:15, David Bailey wrote:
>
> On 30/04/2020 23:54, Oscar Benjamin wrote:
>
> Hi David,
>
> I agree entirely. Neither gives a sens
On Fri, 1 May 2020 at 23:59, David Bailey wrote:
>
> On 01/05/2020 23:44, Oscar Benjamin wrote:
>
> On Fri, 1 May 2020 at 12:09, David Bailey wrote:
>
> On 01/05/2020 00:32, Oscar Benjamin wrote:
>
> Hi Aaron,
>
> Yes, if we had Equation we should disallow its use i
On Fri, 1 May 2020 at 12:09, David Bailey wrote:
>
> On 01/05/2020 00:32, Oscar Benjamin wrote:
>
> Hi Aaron,
>
> Yes, if we had Equation we should disallow its use in an expression. I
> don't see any situation where it would make sense. We would need a
> clear dist
On Sat, 2 May 2020 at 12:12, David Bailey wrote:
>
> On 02/05/2020 00:07, Oscar Benjamin wrote:
>
> There is a difference between having an object as part of an
> expression and having an object that supports arithmetic operations.
> Objects of type Expr support ari
Hi Chris,
It's easily fixed.
I have merged the 1.7.dev version update to master now.
I don't see any release notes for 1.7 here yet though:
https://github.com/sympy/sympy/wiki/Release-Notes-for-1.7
You can manually move the release note from here if it went through as 1.6:
Where do they get the full time mentors from?
On Mon, 4 May 2020 at 22:47, Moses Paul wrote:
>
> "The MLH Fellowship is a fully-managed remote internship alternative for
> student developers. They spend 12 weeks contributing to Open Source projects
> like yours under the guidance of a
On Fri, 15 May 2020 at 01:37, Jason Moore wrote:
>
> Thanks Oscar. I'll look at it later tonight to give you a review.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Thu, May 14, 2020 at 3:45 PM Oscar Benjamin
> wrote:
>>
>> On Thu, 14 May 20
Hi Javier,
I'm not sure exactly the problem with the example you showed. I think
it's a bug somewhere.
It is usually better not to use floats in sympy. With exact rational
numbers your example works for me:
In [17]: inverse_laplace_transform(S.Half/(S.Half*s+1)*1/s, s, t)
Out[17]:
-2⋅t
On Wed, 13 May 2020 at 23:39, David Bailey wrote:
>
> Dear Group,
>
> I notice this item in the highlights of 1.6.
>
> DEPRECATION: Passing Poly as the integrand to the integrate function or
> Integral class is now deprecated. Use the integrate method instead e.g.
> Poly(x, x).integrate(x)
>
>
Hi all,
I'm about to put up the release candidate for sympy 1.6. I think that
the release blockers are covered and the performance regressions
identified so far have been addressed. Thanks to all who have helped
with that.
I have been through the release notes and tried to extract what are
the
On Wed, 13 May 2020 at 23:36, Jason Moore wrote:
>
> I had a look at the backwards incompatibilities.
>
> This one stood out:
>
> Submodule names are no longer imported with from sympy import *. They can
> still be imported directly like from sympy import core or accessed like
> sympy.core, or
On Thu, 14 May 2020 at 00:34, David Bailey wrote:
>
> On 13/05/2020 23:36, Jason Moore wrote:
>
> I had a look at the backwards incompatibilities.
>
> This one stood out:
>
> Submodule names are no longer imported with from sympy import *. They can
> still be imported directly like from sympy
-king
- aditisingh2362*
- Sachin Agarwal
- Harsh Agarwal
- Akash Agrawall*
- alejandro*
- Abhinav Anand
- Mohit Balwani
- BasileiosKal*
- Oscar Benjamin
- Francesco Bonazzi
- Ebrahim Byagowi*
- Thomas A Caswell*
- Ondřej Čertík
- Chanakya-Ekbote*
- Arpan Chattopadhyay*
- Riyan Dhiman*
- Bradley
contributed
for the first time for this release.
Thanks to everyone who contributed to this release!
- abhinav28071999*
- Abhishek*
- adhoc-king
- aditisingh2362*
- Sachin Agarwal
- Harsh Agarwal
- Akash Agrawall*
- alejandro*
- Abhinav Anand
- Mohit Balwani
- BasileiosKal*
- Oscar Benjamin
- Francesco
Similar considerations potentially apply to other packages as well.
The __all__ attribute was added to 50 out of 138 __init__.py files
that didn't already have it. Obviously the top-level __init__.py is
the most significant though.
On Thu, 14 May 2020 at 20:23, Oscar Benjamin wrote:
>
>
On Thu, 14 May 2020 at 19:57, Jason Moore wrote:
>
> Is it possible to give a blanket deprecation warning if anyone does an import
> with a `*`? It could warn the user that functionality will change in the next
> version such that modules are not accessible via star imports.
I think that using
On Thu, 14 May 2020 at 18:46, Jason Moore wrote:
>
> These all seem like good reasons to make the change. Did users get a
> deprecation cycle for the change? i.e. if I mport one of the affected imports
> in 1.5 I get a deprecation warning?
No. I'm not sure how you could get a deprecation
On Thu, 14 May 2020 at 08:01, David Bailey wrote:
>
>
> Well I assumed all along that Poly objects were a much more efficient way of
> representing polynomials - presumably an array of tuples of coefficients and
> exponents where the coefficient is non-zero. If these things are all
>
There have been some recent improvements to the code handling this
which you could try out by installing the pre-release of 1.6 with pip:
pip install -U --pre sympy
--
Oscar
On Thu, 14 May 2020 at 09:07, JS wrote:
>
> Hello,
> I have run into a problem with various matrices. I have read
On Thu, 14 May 2020 at 21:12, Aaron Meurer wrote:
>
> > Oscar, your idea looks helpful. It would resolve my concerns, but I'm not
> > sure how to evaluate if that is worth doing. My opinion is that if the
> > effort to deprecate isn't extreme, then we should do it. What "extreme" is
> >
On Thu, 14 May 2020 at 14:05, JS wrote:
>
> Should I report it as a bug on the github? There is currently none for
> is_indefinite.
> Writing something like
> "is_indefinite returns error when it attempts to compute the eigenvalues.
> Try to import the improvments `is_positive_definite`,
>
Looking at it seems that the improvements were for `is_positive_definite`,
`is_positive_semidefinite` etc rather than `is_indefinite`.
These cases compute fine:
In [*11*]: B1.is_positive_semidefinite
Out[*11*]: False
In [*12*]: B1.is_negative_semidefinite
Out[*12*]: False
That's fine don't worry about it. The meaningful part of the codecov
report is the diff coverage so check that.
The coverage of the whole codebase varies from run to run due to
non-determinism in e.g. set ordering and also randomised testing that
takes place in some parts of the test suite.
On
Oh of course in your example you are added tests so your diff is only
in the testing code and coverage is not measured there. In that case
you should only look through codecov to see the coverage reported for
the files you were trying to increase the coverage of.
I have found that it is better to
It's better to use sympy.I rather than 1j as it is exact and does not
use floating point.
You say that the result is bulky but do you have a reason to think
that it can be any simpler?
This kind of explosion is typical if you have matrices where every
element is an arbitrary symbol. That's why
olvers.
>> >> > 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 so
t;> >> >> 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
>> >> >>
ly 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.
>> >> >>
t; >> >> > incorporating it to solve higher order ODEs).
>> >> >> >> > 3. Adding a special case solver when non-constant linear first
>> >> >> >> > order ODE has symmetric coefficient matrix.
>> >> >> >> >
>
Now that your result has a simple form you can also use factor rather
than separatevars.
For simplifying with respect to an equation you can use subs:
In [85]: factor(tr).subs(w1**2 + w2**2 + z1**2 + z2**2, 1)
Out[85]: 2⋅x₁⋅y₁ + 2⋅x₂⋅y₂ + 2⋅x₃⋅y₃
It is generally more reliable to substitute for
> >
>> >> >> >> >> > If I am lucky and get selected for GSOC'20 for this
>> >> >> >> >> > organisation, then the below is the rough plan. Please comment
>> >> >> >> >> > on suggestio
Hi Philippe,
There isn't any way to do this properly right now.
We can't use inequalities like `x < X` but we can say that X = x+delta
where delta is positive:
```
In [3]: x, X = symbols('x X', real=True)
In [4]: e = Min(x, X)
In [5]: e
Out[5]: Min(X, x)
In [6]: delta = Symbol('delta',
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
Probably this is out of scope for sympy but it is hard to say because
you have provided so little information about what you are proposing.
On Wed, 25 Mar 2020 at 01:21, Raj Dave wrote:
>
> A Ai system
>
> On Tue, 24 Mar 2020 at 21:23, Aaron Meurer wrote:
>>
>> What is Jarvis?
>>
>> Aaron
*
- Harsh Agarwal
- Sachin Agarwal
- Akash Agrawall*
- alejandro*
- Abhinav Anand
- Mohit Balwani
- BasileiosKal*
- Oscar Benjamin
- Francesco Bonazzi
- Ebrahim Byagowi*
- Thomas A Caswell*
- Ondřej Čertík
- Chanakya-Ekbote*
- Arpan Chattopadhyay*
- Riyan Dhiman*
- Bradley Dowling*
- erdOne*
- faizan2700
On Mon, 27 Apr 2020 at 19:55, Oscar Benjamin wrote:
>
> Yes, I'm aiming to release as soon as possible. There aren't many
> release blockers and some are already getting fixed.
>
> On Mon, 27 Apr 2020 at 19:52, Aaron Meurer wrote:
> >
> > I think we should try to rel
Hi,
The evalf function is intended to compute the result to any given
specified precision and return a result such that it is correct to
almost every digit. However evalf needs access to the full expression
to be able to do that. If you first substitute a Float in because the
expression will
I agree that a separate repo for SymPEPs is best.
Once 1.7 is released I can try to draft SymPEP 1 soon for discussion
here to bootstrap the process.
Oscar
On Tue, 13 Oct 2020 at 00:22, Jonathan Gutow wrote:
>
> +1 for a separate repo.
>
> I think that initially the default format for SymPEPs
*
then let me know.
Otherwise I'll put out the release candidate for 1.7 ASAP (as soon as
I have a spare few hours - some time this week).
Oscar
On Fri, 9 Oct 2020 at 19:26, Oscar Benjamin wrote:
>
> Hi all,
>
> I'm preparing for the 1.7 release and have created a release branch
> a
do find an issue that is a regression since 1.6 then
please state that clearly when reporting it.
Oscar
On Fri, 2 Oct 2020 at 22:11, Oscar Benjamin wrote:
>
> Hi all,
>
> I think it's time to release SymPy 1.7. There has been a lot of work
> since 1.6 and in particular the GSOC pr
Ideally this would be something that refine could handle and also
ideally there would be an argument to summation to specify the
conditions so that it could internally use refine or something else
internally. That's just not yet implemented in sympy but I think it
will be in future.
There are a
Hi Rohit and Soumi,
Welcome to the project! Looking forward to seeing your work -
documentation is a big focus for sympy now and there's plenty to
improve!
Oscar
On Mon, 17 Aug 2020 at 20:17, Aaron Meurer wrote:
>
> I'm happy to announce that SymPy's Google Season of Docs (GSoD)
> technical
Hi Conrad,
That sounds great. I'm not sure what help you would need in learning
about sympy but there is an introductory tutorial here:
https://docs.sympy.org/latest/tutorial/index.html
This mailing list is a good place to ask specific questions.
There has been some work on vector integrals as
Hi Xavier,
It's great that you're interested in contributing to sympy. You ask if
there are and recommendations to get started so:
Some issues are labelled as "easy to fix" or "good first issue" on
Github. Those are supposed to be things that can be fixed easily but
that you can use as an
Hi Wes,
That sounds like an excellent background for contributing to sympy. Is
there any particular part of sympy that you would like to work on?
Oscar
On Sun, 14 Jun 2020 at 07:24, Wes Galbraith wrote:
>
> Hi Sympy Community,
>
> I am a Python developer working for Pearson Education in
> I think you were uncivil before I was
Please try to avoid being personal. You don't know who contributed
what or when and it's not even useful to think who to "blame" when you
are looking at something created by volunteers in whatever limited
time they have available. I personally started
I wouldn't have suggested that if I realised you were planning to put
it into a book. As Aaron and I said this is something that should be
handled by refine but isn't implemented yet.
All the same it is straight forward to extract the result manually
when you want to from the Piecewise using
Hi all,
I think it's time to release SymPy 1.7. There has been a lot of work
since 1.6 and in particular the GSOC projects finished weeks ago so
it's time to get all the new fixes and features out. The current
release notes for SymPy 1.7 are here:
On Fri, 29 May 2020 at 00:00, Matthias Köppe wrote:
>
> On Thursday, May 28, 2020 at 3:47:27 PM UTC-7, ondrej wrote:
>>
>> > Wondering if a SymPy developer who was involved in the recent
>> > development would be interested in giving a presentation on what is new
>> > in SymPy 1.6. The main
On Fri, 29 May 2020 at 09:53, David Bailey wrote:
>
> On 28/05/2020 22:13, Rainer Dorsch wrote:
>
> Hello,
>
> when solving a cubic equation
>
> fk: 95.9271531456121*x - 1.7e-18/(x - 6.0e-7)**2
>
> I get a strange result:
>
> [6.11e-8 - 0.e-30*I, 3.85627081928849e-7 + 0.e-27*I,
>
On Sun, 31 May 2020 at 03:42, Giuseppe G. A. Celano
wrote:
>
> I am trying to use very small matrices. Is there any way to calculate the
> partial derivatives of "loss2" below?
>
> import numpy as np
> from sympy import *
>
> n, d, n2, d2 = 5, 7, 4, 3
>
> x = np.random.randn(n, d)
> y =
On Sun, 31 May 2020 at 18:44, Giuseppe G. A. Celano
wrote:
>
> PS: I checked my previous post and the code I wrote looks correct:
Your code is correct but it is probably not a good way of solving your
actual problem.
What would make more sense as a use of sympy is to use sympy to derive
a
On Mon, 1 Jun 2020 at 10:36, Garth Snyder wrote:
>
> I believe 1.0 is a floating-point value that's distinct from 1 and presumed
> to be inexact. If you change the 1.0s and 2.0s to 1 and 2, they will be
> dropped or cancelled appropriately.
There is a function nsimplify which can do this for
On Sun, 20 Sep 2020 at 10:42, David Bailey wrote:
>
> On 19/09/2020 23:46, Oscar Benjamin wrote:
>
> On Sat, 19 Sep 2020 at 23:35, David Bailey wrote:
>
> I mean suppose I wanted to replace
>
> f(anything) by g(5*anything**2)
>
> Hi David,
>
> You c
On Sat, 19 Sep 2020 at 23:35, David Bailey wrote:
>
> On 19/09/2020 20:50, Davide Sandona' wrote:
>
> Hello David,
> in Sympy there are three substitution methods:
> 1. subs: it is the most generic.
> 2. xreplace: it only replace the exact expression you provide.
> 3. replace: this is the most
On Sun, 20 Sep 2020 at 12:40, David Bailey wrote:
>
> Hi David (CCing the list),
>
> Yes, I know - I need to remember to press"Reply List" rather than "Reply" in
> Thunderbird!
The reply-to header for the list is set to go back to the list so when
I use reply it always goes to the list.
> I
Hi Roshan,
Thanks for looking at this. Just as a note to anyone interested in
this there has already been some discussion on the issue tracker:
https://github.com/sympy/sympy/issues/20071
Oscar
On Fri, 18 Sep 2020 at 13:00, Roshan VS wrote:
>
> Before I begin I would like to introduce myself,
On Sun, 20 Sep 2020 at 21:13, David Bailey wrote:
>
> On 20/09/2020 17:29, Oscar Benjamin wrote:
>
> The main difference as far as I tell compared to replace is the need
> to create the Wild symbols explicitly. Maybe we could add a bunch of
> those to sympy.abc with name
Hi Jason,
I'm approaching this from the perspective that this is a bug in
cse/lambdify and that you want to identify which part of a large
expression tree triggers the bug. Since evaluating the whole
expression is slow I would start by testing smaller subexpressions and
work up from there. You
it is merged into the 1.7 release branch so you need to
ask me if you want something to go in.
Oscar
On Mon, 19 Oct 2020 at 01:17, Oscar Benjamin wrote:
>
> Hi all,
>
> I'm ready to put out the 1.7 release candidate.
>
> The 1.7 milestone currently lists a few open i
Hi Rohan,
I assume that you are referring to this github issue:
https://github.com/sympy/sympy/issues/16249
It's good to reference the issue because most of the people on this
mailing list won't be familiar with it. Also it probably makes sense
to ask questions about the issue on the issue.
One
Hi all,
I've been thinking for some time that there should be more
coordination amongst sympy contributors and more involvement with the
broader sympy community in the general direction that sympy takes. I
want to propose the idea of SymPy Enhancement Proposals (SEPs)
analogous to numpy's NEPs
On Sat, 1 Aug 2020 at 18:40, Paul Royik wrote:
>
> In sympy.core.parameters it is written that "WARNING! Although the global
> parameters are thread-local, SymPy's cache is not by now. This may lead to
> undesired result in multi-threading operations."
> But in code I see
>
> def
On Mon, 3 Aug 2020 at 21:15, Aaron Meurer wrote:
>
> - We have already done some degree of high-level planning in the past.
> It just hasn't been organized. For example, you can see there are some
> documents on the wiki that go over design ideas for various things.
> Some of them are implemented
I'm not sure why that doesn't work but you can just use evalf directly:
In [7]: expr
Out[7]:
5/2 5/2
10⋅x ⋅ℯ
3
In [8]: expr.n()
Out[8]:
2.5
40.6083132023449⋅x
Oscar
On Thu, 6 Aug 2020 at 23:00, sandona...@gmail.com
wrote:
>
> Hello,
>
> consider this
On Tue, 11 Aug 2020 at 21:38, My Name wrote:
>
> Thanks trying to clear up Sympy's assumptions for me, but I get feeling the
> only people who know how to use it are people familiar with the source code.
> I may resort that, because Maple has brought me to a standstill, but I might
> save time
I'm not sure but I think that could_extract_minus_sign is used for
canonicalisation of the sign in an expression:
In [13]: e1 = -((y - x)*z)
In [14]: e2 = ((x - y)*z)
In [15]: e1
Out[15]: -z⋅(-x + y)
In [16]: e2
Out[16]: z⋅(x - y)
In [17]: e1.could_extract_minus_sign()
Out[17]: True
In [18]:
for this release.
Thanks to everyone who contributed to this release!
- Oscar Benjamin
- Willem Melching*
- Kalevi Suominen
- Eric Wieser
--
Oscar
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving e
Hi all,
I want to release 1.6.2 which fixes a bunch of things:
https://github.com/sympy/sympy/milestone/56?closed=1
Two issues are unfixed though:
https://github.com/sympy/sympy/issues/19839
https://github.com/sympy/sympy/issues/19920
I'm going to go away soon (on holiday) so I want to put the
On Sun, 2 Aug 2020 at 18:49, Gagandeep Singh (B17CS021)
wrote:
>
> I read the original post and I think the idea of introducing SEPs seems to be
> really useful. Since, I am quite involved with `stats` module and was
> thinking to add some new features to it to make it more powerful and useful
On Sun, 2 Aug 2020 at 14:54, Jonathan Gutow wrote:
>
> I think the Plone PLIP implementation is the best of the two. Here's my brief
> understanding (details at:
> https://docs.plone.org/develop/coredev/docs/plips.html):
>
> PLIPs are implemented as issues in the github repository. This
On Sun, 26 Jul 2020 at 21:56, Mikhael Myara
wrote:
>
> And I obtain what follows. I am surprized that inserting values instead of
> some symbols disables sympy simplification. In some more complex cases, the
> computation times required for simplification are huge and lead to non
> simplified
On Sun, 2 Aug 2020 at 04:58, Jason Moore wrote:
>
> I agree with this. SEPs would be a net positive. They seem to work well with
> other projects.
>
> Question: How do we know what changes require SEPs and what don't?
I would say that for now at least it shouldn't be a requirement to
produce a
On Sun, 2 Aug 2020 at 14:48, David Bailey wrote:
>
> I am amazed that you and other SymPy developers find time to develop the
> software after they have finished evaluating and responding to all the offers
> from students. Are you sure the time you all spend on this doesn't cost more
> than
On Sun, 2 Aug 2020 at 01:42, Jonathan Gutow wrote:
>
> Although I am probably one of those "put in episodic work only on
> projects that interest me" people. Other major open-source projects
> (e.g. SageMath and Plone) I have done pieces for have similar structures
> and I thought they were
On Sun, 2 Aug 2020 at 06:32, Paul Royik wrote:
>
> Do you mean that now it is not safe to use evaluate=True in one thread and
> evaluate=False in another?
It is always fine to use evaluate=True/False. The problem is with
using the global evaluate flag:
In [7]: with evaluate(False):
...:
On Fri, 31 Jul 2020 at 17:26, Mikhael Myara
wrote:
>
> Thanks for your answer.
>
> I don’t do it « for sport » ;-) My example is a reduced example coming from a
> practical situation I encountered.
I understand that you have reduced this but it is a lot better if the
reduction is self-contained
On Fri, 31 Jul 2020 at 21:06, Mikhael Myara
wrote:
>
> Le vendredi 31 juillet 2020 20:46:08 UTC+2, Oscar a écrit :
>>
>> On Fri, 31 Jul 2020 at 17:26, Mikhael Myara
>> wrote:
>> >
>> > Thanks for your answer.
>> >
>> > I don’t do it « for sport » ;-) My example is a reduced example coming
>> >
On Thu, 2 Jul 2020 at 19:13, Oscar Benjamin wrote:
>
> The SHA256 hashes for the build artefacts are:
>
> 7f50d922bf055560429777447ac827620fd86d39d1de4ea057422e7552c65f3b
> sympy-1.6.1-py3-none-any.whl
> 7386dba4f7e162e90766b5ea7cab5938c2fe3c620b310518c8ff504b283cb15b
&g
contributed a
patch for the first time for this release; 2 people contributed
for the first time for this release.
Thanks to everyone who contributed to this release!
- Sachin Agarwal
- Oscar Benjamin
- mloubout*
- Tomasz Pytel
- Gilles Schintgen
- Kalevi Suominen
- w495*
The SHA256 hashes
On Tue, 30 Jun 2020 at 16:34, Nicolas Guarin wrote:
>
> I would recommend use the star import for interactive CAS work, otherwise I
> would second Aaron in using
>
> import sympy as sym
Okay maybe we should go with this. It's less ambiguous than the other
variants and is potentially more
Also Faisal just opened a pull request implementing this:
https://github.com/sympy/sympy/pull/19703
Does that look like what you expected? Feel free to comment on the
pull request if you have any suggestions.
Oscar
On Sat, 4 Jul 2020 at 14:24, Kasper Peeters wrote:
>
>
>> Is there a way to
Hi Roberto,
I already answered this on SO:
https://stackoverflow.com/questions/62798213/keep-the-order-of-parameters-fixed-in-sympy-lambdify-from-free-symbols/62800716?noredirect=1#comment111075099_62800716
If you are using symarray to generate the symbols then you can get the
list of symbols
On Sat, 4 Jul 2020 at 16:05, Volker Weißmann
wrote:
>
> using sympy.S.Zero does silence the warning, but isinstance(somevar,
> sympy.S.Zero) does not work, because sympy.S.Zero is not the class but
> an object. How do I get the class Zero?
You can do `type(S.Zero)` to get the class. Normally
Hi Volker,
The problem is that you are using sympy.numbers.Zero. There is no
sympy.numbers module. Rather there is a sympy.core.numbers module
which is where Zero is defined. In SymPy 1.5 the main
sympy/__init__.py used to do
from .core import *
which resulted in the sympy.core.numbers module
gt; On Fri, Jul 10, 2020 at 11:08 AM Oscar Benjamin
> wrote:
>>
>> Hi Roberto,
>>
>> I already answered this on SO:
>> https://stackoverflow.com/questions/62798213/keep-the-order-of-parameters-fixed-in-sympy-lambdify-from-free-symbols/62800716?noredirect=1#commen
Hi Davide,
Interval is a type of Set whereas both AccumulationBounds and SetExpr
are types of Expr. The methods and operations of Set and Expr are very
different and not interchangeable so if we want to be able to
manipulate an AccumBounds like an expression then it can't be a
subclass of
Hi all,
I'm preparing the SymPy 1.6.1 bugfix release and I'm considering
skipping the release candidate and releasing directly and just wanted
to see if anyone has any opinions on that. In the past I haven't seen
much evidence that anyone has actually tested the pre-releases
(release candidate or
On Mon, 29 Jun 2020 at 15:54, Javier Arantegui
wrote:
>
> Hi!
Hi Javier,
> Most probably, this is a silly question...
I don't think it's a silly question
> What is the best way to import Sympy?
>
> I usually use:
>
> from sympy import *
>
> I know that using a wild import should be
Hi Michele,
I don't know the quantum module so well but does qapply work in this case?
Oscar
On Sat, 27 Jun 2020 at 19:52, Michele Cotrufo wrote:
>
> Is there a way to specify that the identity operator must act as identity
> also on the adjoint operators?
>
> from
Hi all,
We're gearing up for a SymPy 1.6.1 bugfix release because a few issues
have come up since releasing 1.6.
The list of issues that will be addressed in 1.6.1 is here:
https://github.com/sympy/sympy/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22SymPy+1.6.1%22
Note that this release will not
Hi Davide,
I'll answer your questions one by one and then summarise the situation below.
1. Are the two modules interacting together now?
The old and new assumptions interact in one direction: the new
assumptions will query the old assumptions if it helps but the old
assumptions are ignorant of
>> >> On Wed, Jun 3, 2020 at 12:53 PM James Bateman wrote:
>> >>>
>> >>> I've just discovered a bug in my code which boiled down to the
>> >>> following, where a symbol "y" was given the same SymPy name as an
>> >>> existing symbol.
>> >>>
>> >>> import sympy as sp
>> >>> x = sp.Symbol('x')
>>
On Sat, 13 Jun 2020 at 00:22, Aaron Meurer wrote:
>
> On Sun, Jun 7, 2020 at 4:08 PM Oscar Benjamin
> wrote:
> >
> > 3. What are the limitation of the new module? Where is it not implemented?
> >
> > The new assumptions were made a lot faster last Summer.
On Sun, 14 Jun 2020 at 07:10, Aaron Meurer wrote:
>
> On Sat, Jun 13, 2020 at 5:50 AM Oscar Benjamin
> wrote:
> >
> > On Sat, 13 Jun 2020 at 00:22, Aaron Meurer wrote:
> > >
> > > On Sun, Jun 7, 2020 at 4:08 PM Oscar Benjamin
> > > wrote:
>
On Fri, 17 Jul 2020 at 13:42, Faisal Riyaz wrote:
>
> How can I get a single solution of a diophantine equation when the solution
> is returned
> in terms of independent parameters?
>
> >>> from sympy.abc import x, y, z, t
> >>> from sympy import diophantine, Symbols
> >>> diophantine(x + y + z,
On Fri, 17 Jul 2020 at 15:02, Faisal Riyaz wrote:
>
> I think we should put this on the docs page of the diophantine.
I agree
>> Alternatively it should be possible to provide the symbols directly:
>>
>> sol, = diophantine(x + y + z, [t_0, t_1])
>
> If the user does not have any idea about the
Hi Nicolás,
This looks nice. Maybe it should go in the example notebooks:
https://github.com/sympy/sympy/tree/master/examples/notebooks
I don't know if those are hosted on the website rather than just github.
Oscar
On Tue, 30 Jun 2020 at 22:11, Nicolas Guarin wrote:
>
> I adapted Maxima's
On Sun, 27 Dec 2020 at 10:46, אוריאל מליחי wrote:
>
> Hello everyone!
Hi,
> As part of my final project in my computer science degree I would like to
> develop a class for linear inequalities simplifying.
That sounds like an excellent project. To be clear, are you intending
for this to
201 - 300 of 710 matches
Mail list logo
