Re: [sympy] Re: Bug in limit?

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

[sympy] Re: Bug in limit?

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

[sympy] Re: Diophantine Equations Module for GSoC 2013

A good example implementation for linear and quadratic equations is Dario Alpern's calculator at http://www.alpertron.com.ar/QUAD.HTM His calculator gives both an answer and a generally helpful explanation of the algebraic manipulations it used to arrive at the answer. He provides java source c

Re: [sympy] Diophantine Equations Module for GSoC 2013

You should start by collecting some resources that you will use to implement the algorithms. The more explicitly they describe the algorithms, the better. I myself can't really give you any good pointers, but others on this list may be able to. Aaron Meurer On Sun, Apr 7, 2013 at 5:39 PM, Rishabh

[sympy] Diophantine Equations Module for GSoC 2013

Hello everyone, I am Rishabh Dixit a pre-final year undergraduate student from BITS, Pilani, India. I am well versed with python and have been using sympy for quite some time and would like to work on for a GSoC project for sympy this year. I am planning to have the implementation of Diophantine

Re: [sympy] Re: Bug in limit?

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

Re: [sympy] Re: Bug in limit?

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

Re: [sympy] Re: Bug in limit?

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

Re: [sympy] use of \operatorname{} in latex

Sure, just send the pull request. Even if you are unsure about a change, just send a pull request, as it's much easier to discuss code changes on a pull request than on the mailing list. Aaron Meurer On Apr 7, 2013, at 4:49 PM, hac man wrote: I noticed something about rendering of symbolic func

[sympy] use of \operatorname{} in latex

I noticed something about rendering of symbolic functions into latex. Currently, \operatorname is applied to all functions, even single letter ones when they are rendered with an argument, but not when they are rendered without the argument. The following code in SymPy Live illustrates this point:

Re: [sympy] Primality Test

On Sun, Apr 7, 2013 at 3:32 PM, Sushant Hiray wrote: > > @Aaron > Even I think the same. I guess I will start working on the patch right away. > :) > > Any suggestions on the implementation of AKS algorithm? Can't help you there. > > Also I will implement the algorithm in the "primetest.py" itse

Re: [sympy] allModels() for sympy's logic module

Changing the API of satisfiable will have to be discussed, since it is a public function. Probably you should just add a new function, or a flag to satisfiable. Aaron Meurer On Sun, Apr 7, 2013 at 3:23 PM, Eli Rose wrote: > Okay, great. Do you mean that it would be kosher to rewrite satisfiable(

Re: [sympy] Re: Bug in limit?

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)) -

Re: [sympy] Primality Test

@Aaron Even I think the same. I guess I will start working on the patch right away. :) Any suggestions on the implementation of AKS algorithm? Also I will implement the algorithm in the "primetest.py" itself. It is fine, right? Regards, Sushant -- You received this message because you are s

Re: [sympy] Re: Bug in limit?

@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

Re: [sympy] allModels() for sympy's logic module

Okay, great. Do you mean that it would be kosher to rewrite satisfiable() to have this functionality (return all models if the expr is satisfiable, and False otherwise?). That would work well with a generator, because no one who wanted the old satisfiable() functionality would have to wait for

Re: [sympy] allModels() for sympy's logic module

To submit a patch, you need to send a pull request to SymPy on GitHub. See https://github.com/sympy/sympy/wiki/Development-workflow. I think this would be useful. Probably satisfiable itself can be extended to do this. The function should probably be implemented as a generator so that it can give

[sympy] allModels() for sympy's logic module

Hi, I just found out about sympy a week ago, and I think it's super cool. I was looking at the logic module and satisfiable() in particular, and was wondering if it would be useful to have a function that returns *all*models satisfying the expression, instead of just one [I couldn't tell if th

Re: [sympy] Re: Bug in limit?

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,

Re: [sympy] Re: Bug in limit?

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

Re: [sympy] Re: Bug in limit?

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

Re: [sympy] series expansions

I don't think any of the ideas listed on the ideas page about series have been implemented yet. Can you elaborate more on what you mean by complex series expansion and analysis of functions? Aaron Meurer On Sun, Apr 7, 2013 at 10:05 AM, Anuj Mahajan wrote: > Hi > > I was going through the propo

Re: [sympy] Automatic evaluation (or simplification)

Performance doesn't just mean it can be slow. Suppose we do a bunch of intermediate calculations that essentially combine terms with a series expansion. With your way, the series will be reevaluated at each step. But by holding off on the calculation, we can do it all at once at the end, which can

Re: [sympy] Primality Test

Sure, it could be useful to have a deterministic test, probably not called by default though (or at least not for numbers less than 10**16), depending on the relative performance to the existing pseudoprime tests. Aaron Meurer On Sun, Apr 7, 2013 at 2:48 AM, Sushant Hiray wrote: > > > @David > O

Re: [sympy] Re: Bug in limit?

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

Re: [sympy] Re: Partial Differential Equations - Really Basic Doubt.

Yes, I did manage to understand it from this reference Viktor Grigoryan, "Partial Differential Equations" . I also implemented a simple homogeneous variant of it in this PR. By the way, I also tried to factor out the common code in a separate utils.py. https://github.com/sympy/sympy/pull/1970 It

[sympy] Re: Bug in limit?

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

[sympy] Re: Bug in limit?

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

[sympy] Bug in limit?

Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> from sympy import * >>> x=Symbol('x') >>> limit((1+1/x)**x,x,oo) E >>> limit(1+(1+1/x)**x,x,oo) 2 >>> -- You received this message because you

[sympy] series expansions

Hi I was going through the proposed ideas list and found series expansion particularly interesting. I also looked up for complex support in python which seemed to be limited so i wish to implement the complex series expansion and analysis of functions. along with the associated integration and d

Re: [sympy] Automatic evaluation (or simplification)

On Sunday, April 7, 2013 3:38:23 AM UTC+4, Aaron Meurer wrote: > > I already gave my arguments why I don't think it's a good idea on the > issue page. I would like to see other opinions, if any. > Calling doit or series again is not that hard, and you > gain the ability to write such things,

Re: [sympy] Primality Test

@David On Sunday, April 7, 2013 1:27:25 AM UTC+5:30, David Joyner wrote: > > > Have you looked at what nzmath has for this? It is also BSD licensed and > written in pure python. > > I checked into nzmath. So as of now they implement various psuedo prime checking algorithms namely: spsp

Re: [sympy] GSoC 2013 Digital Signal Processing

My apologies I was thinking that you were referring to the properties of integral transforms in a more general way and it did not strike me that you were referring to DFT , DTFT On Sun, Apr 7, 2013 at 12:20 PM, Ankit Agrawal wrote: > Hi Abinash, > > The reason I feel there are only con