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
15 matches
Mail list logo
