Thanks for the bug report Souvik.
Can you please open an issue on GitHub rather than post here? Also can
you extract the code from the notebook and just post a minimal block
of code that reproduces the problem?
--
Oscar
On Wed, 24 Aug 2022 at 21:50, SOUVIK CHAKRABORTY
wrote:
>
> Kindly look int
Hi Souvik,
As it stands, your post does not give us enough information to be able to
reproduce the bug and figure out how to solve it. We need more information.
It would be great if you can share the code with us, and even better if you
can simplify the code (by removing the unnecessary bits) an
Thanks, yes.
But the bug is still there, a totally innocent convergent integral and
sympy gives the wrong result.
On 2/4/22, Chris Smith wrote:
> If you replace `0.5` with S.Half the answer is `2*pi`.
>
> /c
>
> On Friday, February 4, 2022 at 9:06:52 AM UTC-6 Daniel wrote:
>
>> This is clearly w
If you replace `0.5` with S.Half the answer is `2*pi`.
/c
On Friday, February 4, 2022 at 9:06:52 AM UTC-6 Daniel wrote:
> This is clearly wrong:
>
> >>> integrate( 1 / ( x**2 + 0.5**2 ) / ( ( x - 1 )**2 + 0.5**2 ), ( x,
> -oo, oo ) ).evalf( )
> 0
>
> With sympy 1.7.1.
>
>
> --
> Did Crypto Cra
Ok thanks for letting me know!
On Tuesday, April 21, 2020 at 8:47:18 AM UTC-7, Nicolas Guarin wrote:
>
> My OS is Android 5.0, Python 3.7.2 and SymPy 1.5.1.
>
> But I just realized I did not type the same polynomial. When using the
> same one I get the same error. Also happens in Windows 10, Pyt
My OS is Android 5.0, Python 3.7.2 and SymPy 1.5.1.
But I just realized I did not type the same polynomial. When using the same
one I get the same error. Also happens in Windows 10, Python 3.7.3 SymPy
1.5.1.
On Tuesday, April 21, 2020 at 10:23:23 AM UTC-5, Tiam Koukpari wrote:
>
> That's weird
That's weird. What OS are you using? And what version of Python/Sympy?
On Tuesday, April 21, 2020 at 6:03:25 AM UTC-7, Nicolas Guarin wrote:
>
>
> I was not able to reproduce your error. This is what I get instead
>
> print(sol)
> [CRootOf(x**5 - 6*x**3 - 6*x**2 - 6, 0), CRootOf(x**5 - 6*x**3 - 6*
I found that use nsimplify() can bypass this problem
c = b = q2*sin(q1)**2 + q2*cos(q1)**2 + nsimplify(0.1)*sin(q1)**2 +
nsimplify(0.1)*cos(q1)**2
simplify(c) will give result q2 + 1/10
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe f
On Saturday, August 29, 2015 at 9:05:34 PM UTC+3, Preet Singh Khalsa wrote:
>
> Hey!
> I am new to open source. I would like to fix bug #9869 (label: easy to
> fix). Can someone please get me started?
> Thanking in anticipation,
> Preet.
>
It seems to be already taken care of by
https://github
limit(sin(x)**15,x,0,'+') works
limit(sin(x)**15,x,0,'-') hangs
Actually, both are working. But the second limit is slow.
Confirming for Python 2.6.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving
On Monday, June 22, 2015 at 11:25:24 PM UTC+3, Paul Royik wrote:
>
> limit(sin(x)**15,x,0,'+') works
> limit(sin(x)**15,x,0,'-') hangs
>
Actually, both are working. But the second limit is slow.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To u
Yes, It is a bug Indeed.
Thanks for reporting.
Fixed in this PR: https://github.com/sympy/sympy/pull/9231
Please have a look.
*Reference:*
http://functions.wolfram.com/ElementaryFunctions/ArcCosh/02/
http://www.wolframalpha.com/input/?i=ArcCosh%5B-z%5D
On Tuesday, March 31, 2015 at 8:10:18 PM U
Or it's possible that you meant to do lambdify((x, y), x*cos(y)) to create
a two-argument function.
Aaron Meurer
On Sat, Jan 10, 2015 at 3:44 PM, James Crist wrote:
> `lambdify` is intended for numeric evaluation (but can be made to evaluate
> symbolically). By default, the functions `sin`, `co
`lambdify` is intended for numeric evaluation (but can be made to evaluate
symbolically). By default, the functions `sin`, `cos`, etc... are pulled
from `math` or `numpy`, which expect floats (and if not given a float, they
attempt to convert to float).
What's happening here, is you're passing
You can also do `from __future__ import division` to get 1/2 to not reduce
to 0.
--
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
If I use *S(1)/4* or *1./4*, all works as expected.
I have understood that is normal because 1/4 is an euclidean division.
Sorry, I always use Python 3 where 1/4 is a float division.
2014-05-04 15:24 GMT+02:00 Christophe Bal :
> Hello.
>
> The folowing code gives a wrong output in IPython. Inde
I think it's more advanced than that. It uses the algorithm described
in Dominik Gruntz's PhD thesis.
Aaron Meurer
On Mon, Apr 8, 2013 at 1:34 AM, Rene Grothmann wrote:
> I understand.
>
> It seems gruntz works like Maxima's tlimit
>
gruntz(1+(1+1/x)**x,x,oo)
> 1 + E
gruntz((1+1/x)**x-
I understand.
It seems gruntz works like Maxima's tlimit
>>> gruntz(1+(1+1/x)**x,x,oo)
1 + E
>>> gruntz((1+1/x)**x-E,x,oo)
0
>>> gruntz(((1+1/x)**x-E)*x,x,oo)
-E/2
>>> gruntz1+1/x)**x-E)*x+E/2)*x,x,oo)
11*E/24
That's fine.
--
You received this message because you are subscribed to the Goo
The problem is that to change the behavior of things like 1**oo, we
would have to completely change the way to core works. We can't just
temporarily change it inside of limit. gruntz on the other hand uses a
completely different approach based on series expansions which is
algorithmic and mathemati
I am the original poster. I am not an expert of Python, just a
mathematician.
I understand that SymPy uses heuristics for limits, which are most likely
"known cases". But if I were to program such heuristics, only cases with
infinity would have to look for a heuristic. This includes 1^oo, whic
Actually they're all consistant if you use float('inf') instead of oo.
Aaron Meurer
On Sun, Apr 7, 2013 at 5:28 PM, Aaron Meurer wrote:
> 0**0 follows Python conventions. The rest are likely equally useful.
>
> By the way, 0*oo does give nan as it should.
>
> Aaron Meurer
>
> On Apr 7, 2013, at
0**0 follows Python conventions. The rest are likely equally useful.
By the way, 0*oo does give nan as it should.
Aaron Meurer
On Apr 7, 2013, at 4:59 PM, "hacm...@gmail.com" wrote:
Why are the indeterminate forms oo/oo, 0/0, and oo-oo recognized as nan,
but not 1**oo, 0**0, 0*oo, oo**0?
On S
Why are the indeterminate forms oo/oo, 0/0, and oo-oo recognized as nan,
but not 1**oo, 0**0, 0*oo, oo**0?
On Sunday, April 7, 2013 2:38:14 PM UTC-4, Aaron Meurer wrote:
>
> That's because subs just works dumbly, so it produces (1 + 1/oo)**oo,
> which gives 1**oo, which gives 1. A limit procedur
Speed is not an issue for that specific example, but it might come
into play for larger sums, or more complicated ones.
Aaron Meurer
On Sun, Apr 7, 2013 at 3:25 PM, Ankit Agrawal wrote:
> @Sergey : Ha. I thought the same thing, but hesitated as it would not
> support limit(Sum(1/x, (x, 1, y)) -
@Sergey : Ha. I thought the same thing, but hesitated as it would not
support limit(Sum(1/x, (x, 1, y)) - 1/y, y, oo).
Also, I tried timing gruntz(1 + 1/x**5,x,oo) and limit(1 + 1/x**5,x,oo), (a
function involving is_Add) and the results on my 4GB 32-bit ubuntu were
0.023188829422 and 0.0009610
Great, let's do it. If you search the issues, you will find similar
wrong result bugs (or maybe not wrong result but limit gives an error
and gruntz gives an answer) that are likely improved in this branch.
Aaron Meurer
On Sun, Apr 7, 2013 at 2:45 PM, Sergey B Kirpichev wrote:
> On Sun, Apr 07,
On Sun, Apr 07, 2013 at 12:38:14PM -0600, Aaron Meurer wrote:
> I really think that we should scrap these limit heursitics. They have
> lead to dozens of wrong results like this one, where limit() is wrong,
> but gruntz() is right.
Well, if we just kill the "if e.is_Add" branch in limit(), there i
A temporary fix:
https://github.com/sympy/sympy/pull/1980
--
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 post to this group, se
That's because subs just works dumbly, so it produces (1 + 1/oo)**oo,
which gives 1**oo, which gives 1. A limit procedure doesn't fall into
this trap because it knows that 1**oo is an indeterminate form (for
exactly this reason). We could probably "fix" this by making 1**oo
give nan, but that woul
On Sunday, April 7, 2013 11:25:11 PM UTC+5:30, Sergey Kirpichev wrote:
>
> Yes. This is a bug in the limit() heuristic.
>
gruntz() works well:
> In [5]: from sympy.series import gruntz
> In [6]: gruntz(1+(1+1/x)**x,x,oo)
> Out[6]: 1 + ℯ
>
> Yes. I tried to narrow down the root of the bug an
Yes. This is a bug in the limit() heuristic.
gruntz() works well:
In [5]: from sympy.series import gruntz
In [6]: gruntz(1+(1+1/x)**x,x,oo)
Out[6]: 1 + ℯ
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receivin
I am still having problems with the new patch. See my notes on the issue
1630. I will work on extra tests for now.
Ryan
On Wed, Sep 9, 2009 at 7:20 PM, smichr wrote:
>
> Yes, I refactored some of the code there. Try the patch that I
> attached at Issue 1630.
>
> /c
> >
>
--~--~-~--~-
Yes, I refactored some of the code there. Try the patch that I
attached at Issue 1630.
/c
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To
Thanks for writing the patch and preventing me from duplicating your
efforts. I am having trouble applying your patch. The only difference
between my repo and the current sympy main repo is line 732 of core/mul.py:
r...@ryan-duo-laptop|07:56 AM|sympy (master)$ git di
diff --git a/sympy/core/mul.
This is issue 1630.
/c
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com
To unsubscribe from this group, send email to sympy+unsubscr...@google
You can use your example below as a test. Also, you could try putting
a print statement on line 733 to see what tests use it and modify them
to use negative exponents (by the way, looking at the code, it looks
like someone just miscopied it. Line 735 should match line 733, but
it instead
On Mon, Sep 7, 2009 at 10:37 AM, Ryan Krauss wrote:
> I would be glad to, but I think I need to understand the code better to
> write a valid test. Should that line get executed any time there is 1/term
> in the experssion?
In any case, let's write your test case as a test and then fix that lin
I would be glad to, but I think I need to understand the code better to
write a valid test. Should that line get executed any time there is 1/term
in the experssion?
On Mon, Sep 7, 2009 at 12:32 PM, Aaron S. Meurer wrote:
>
> If you run the coverage script in bin/, you will find that that line
If you run the coverage script in bin/, you will find that that line
is not covered by the test suite, so it is quite possible that it is
wrong. Indeed, if I make the change you specify, the tests still all
pass. Could you create a patch that fixes it and includes a test?
Aaron Meurer
On
Along these same lines, should this substitution work:
In [12]: temp30
Out[12]: -EI*c4*beta**3/L**3
In [13]: temp30.subs(L**2/EI, a)
Out[13]: -EI*c4*beta**3/L**3
I have to invert both inputs to subs to get the result I was hoping for:
In [14]: temp30.subs(EI/(L**2), 1/a)
Out[14]: -c4*beta**3/(
On Fri, Jul 10, 2009 at 3:52 AM, Priit Laes wrote:
>
> Hey!
>
> Can someone confirm, that code below is valid and I am not abusing
> anything? :)
>
> #!/usr/bin/python
> from sympy import *
> F = Function('F')
> x, y, t = symbols('x y t')
> a = Symbol('a', Real=True)
> eq = Derivative(F(x, t), x)
On Fri, Jul 10, 2009 at 5:52 AM, Priit Laes wrote:
>
> Hey!
>
> Can someone confirm, that code below is valid and I am not abusing
> anything? :)
>
> #!/usr/bin/python
> from sympy import *
> F = Function('F')
> x, y, t = symbols('x y t')
> a = Symbol('a', Real=True)
> eq = Derivative(F(x, t), x)
On Mon, Feb 9, 2009 at 10:48 PM, Robert Kern wrote:
>
> On Mon, Feb 9, 2009 at 21:33, Ondrej Certik wrote:
>
>> So I think it's a bug. Thanks a lot for reporting it. The problem is
>> with this code:
>>
>>if not (cond_type is bool or issubclass(cond_type, Relational) or
>> \
>>
On Mon, Feb 9, 2009 at 21:33, Ondrej Certik wrote:
> So I think it's a bug. Thanks a lot for reporting it. The problem is
> with this code:
>
>if not (cond_type is bool or issubclass(cond_type, Relational) or \
>issubclass(cond_type, Number)):
>rai
Hi jtaylor74,
On Mon, Feb 9, 2009 at 6:43 PM, jtaylor74 wrote:
>
> I don't know if this is a bug or not, but what I want is to evaluate a
> lambdify'ed expression at a numpy.ndarray of points.
>
> Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
> [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
>
On Sat, Dec 27, 2008 at 6:32 PM, Alan Bromborsky wrote:
>
> Ondrej Certik wrote:
>> On Sat, Dec 27, 2008 at 5:44 PM, Alan Bromborsky wrote:
>>
>>> Sometimes in the html output of Sphinx 'file' in the .rst file is
>>> printed as 'fle' in the .html file, but not always. If I go into the
>>> .rst
Ondrej Certik wrote:
> On Sat, Dec 27, 2008 at 5:44 PM, Alan Bromborsky wrote:
>
>> Sometimes in the html output of Sphinx 'file' in the .rst file is
>> printed as 'fle' in the .html file, but not always. If I go into the
>> .rst file and change 'file' to fiile' then 'file' is printed out in
Ondrej Certik wrote:
> On Sat, Dec 27, 2008 at 5:44 PM, Alan Bromborsky wrote:
>
>> Sometimes in the html output of Sphinx 'file' in the .rst file is
>> printed as 'fle' in the .html file, but not always. If I go into the
>> .rst file and change 'file' to fiile' then 'file' is printed out in t
On Sat, Dec 27, 2008 at 5:44 PM, Alan Bromborsky wrote:
>
> Sometimes in the html output of Sphinx 'file' in the .rst file is
> printed as 'fle' in the .html file, but not always. If I go into the
> .rst file and change 'file' to fiile' then 'file' is printed out in the
> .html file.
That's a s
Alan Bromborsky wrote:
> Ondrej Certik wrote:
>
>> On Thu, Oct 2, 2008 at 2:08 PM, Alan Bromborsky <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Ondrej Certik wrote:
>>>
>>>
On Thu, Oct 2, 2008 at 2:09 AM, william ratcliff
<[EMAIL PROTECTED]> wrote:
Ondrej Certik wrote:
> On Thu, Oct 2, 2008 at 2:08 PM, Alan Bromborsky <[EMAIL PROTECTED]> wrote:
>
>> Ondrej Certik wrote:
>>
>>> On Thu, Oct 2, 2008 at 2:09 AM, william ratcliff
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
I'l let you know how it goes. The real application is rath
On Thu, Oct 2, 2008 at 2:08 PM, Alan Bromborsky <[EMAIL PROTECTED]> wrote:
>
> Ondrej Certik wrote:
>> On Thu, Oct 2, 2008 at 2:09 AM, william ratcliff
>> <[EMAIL PROTECTED]> wrote:
>>
>>> I'l let you know how it goes. The real application is rather cute. In
>>> condensed matter, we often measur
Alan Bromborsky wrote:
> Ondrej Certik wrote:
>
>> On Thu, Oct 2, 2008 at 2:09 AM, william ratcliff
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I'l let you know how it goes. The real application is rather cute. In
>>> condensed matter, we often measure the elementary excitations of solids
Ondrej Certik wrote:
> On Thu, Oct 2, 2008 at 2:09 AM, william ratcliff
> <[EMAIL PROTECTED]> wrote:
>
>> I'l let you know how it goes. The real application is rather cute. In
>> condensed matter, we often measure the elementary excitations of solids. In
>> simple magnets, these excitations
On Thu, Oct 2, 2008 at 2:09 AM, william ratcliff
<[EMAIL PROTECTED]> wrote:
> I'l let you know how it goes. The real application is rather cute. In
> condensed matter, we often measure the elementary excitations of solids. In
> simple magnets, these excitations are spin-waves. What I'm trying
I'l let you know how it goes. The real application is rather cute. In
condensed matter, we often measure the elementary excitations of solids. In
simple magnets, these excitations are spin-waves. What I'm trying to do is
make an application so that if you have an insulator and define the
intera
On Wed, Oct 1, 2008 at 11:09 PM, william ratcliff
<[EMAIL PROTECTED]> wrote:
> First, thanks for the response!
>
>>Is there a good reason for using numpy.pi instead of sympy.pi? With
>>sympy.pi, the complex exponential will simplify symbolically to a real
>>number.
>
> In this case, there is not--
First, thanks for the response!
>Is there a good reason for using numpy.pi instead of sympy.pi? With
>sympy.pi, the complex exponential will simplify symbolically to a real
>number.
In this case, there is not--However, this was a toy example. I am doing a
symbolic calculation which results in a
On Wed, Oct 1, 2008 at 10:50 PM, william ratcliff
<[EMAIL PROTECTED]> wrote:
> I believe there is a glitch in evalf when complex numbers are involved:
>
> import sympy
> import numpy as N
> import scipy.linalg
>
> pi=N.pi
> g=sympy.exp(2*pi*sympy.I)
> A=N.matrix([[g,0],[0,g]])
>
> scipy.linalg.eig
59 matches
Mail list logo
