[sympy] Re: Code of Conduct

On Monday, February 1, 2016 at 12:10:57 AM UTC+3, Aaron Meurer wrote: > > We have been discussing for a while about adding a code of conduct to > SymPy, so that it is very clear to everyone what kind of conduct we expect > from those who participate in the community. > Great news! I'm just cur

Re: [sympy] Re: hyperexpand returns incorrect result for negative coefficients

On Sun, Jan 31, 2016 at 8:06 PM, Ondřej Čertík wrote: > Regarding the legal question that arose in this thread, I have asked here: > http://programmers.stackexchange.com/questions/308909/how-to-manage-copyright-notices-from-contributors-to-a-bsd-licensed-project Ondrej, I'm sorry, but it's a wron

[sympy] Re: hyperexpand returns incorrect result for negative coefficients

FYI https://github.com/skirpichev/omg/pull/204 On Thursday, January 28, 2016 at 4:12:18 AM UTC+3, Ondřej Čertík wrote: > > GitHub is down, so I am reporting here for now: > > > It returns 0 for the following function, even though we can verify the > (correct) answer using .n(), that it is nonzer

Re: [sympy] Re: Issue : limit(abs(log(x)),x,0,'+')

On Thursday, February 12, 2015 at 10:26:32 PM UTC+3, Arnaud Usciati wrote: > > Maybe abs() function have to be reconsidered, because I found other issues > with abs... > All examples above are solved with patch from https://github.com/skirpichev/omg/pull/82 (on top of the https://github.com/skir

[sympy] Re: Wrong results for limits with sign() function

On Sunday, February 15, 2015 at 3:55:28 PM UTC+3, Arnaud Usciati wrote: > > If x = symbols('x', real=True). > > I found wrong results for limits with sign() function. > limit(sign(x), x, 0, '+') = 1, and limit(sign(x), x, 0, '-') = -1 ---> OK > > But : > - limit(sign(ln(x)), x, 1, '+') = 1 (OK) but

[sympy] Re: a bug in definite integration in sympy-0.7.6.1

This bug is in polylog eval method. It returns wrong type (builtin "int", not sympy's Integer). Fix is very simple: https://github.com/skirpichev/omg/pull/137 On Monday, November 30, 2015 at 10:26:24 PM UTC+3, Andrey Grozin wrote: > > grozin@elrond ~ $ python > Python 3.4.3 (default, Nov 8 201

Re: [sympy] Quitting

On Sunday, February 1, 2015 at 1:19:35 AM UTC+3, Joachim Durchholz wrote: > > Am 30.01.2015 um 17:35 schrieb Ondřej Čertík: > > The door is always open if you want to come back. > > I'll bring a revolving door :-D > > Some aspects I was made aware of in private mails have made that > quitting d

[sympy] Re: Quitting

On Friday, January 30, 2015 at 6:37:11 AM UTC+3, Joachim Durchholz wrote: > > B) Argue to the arbiters into sanctioning Sergey more so that he stops > his passive aggression. > They can't do more, I'm not part of this project. But Aaron, maybe you can remove me from whitelist for this maillis

Re: [sympy] debian package (to be orphaned)

On Thu, Jan 29, 2015 at 11:33 AM, Joachim Durchholz wrote: > Please clarify where I went wrong. I did. -- 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.

Re: [sympy] debian package (to be orphaned)

On Thursday, January 29, 2015 at 12:34:08 AM UTC+3, Joachim Durchholz wrote: > Policy is that if it's a function that users would expect, it should be > "depends" No, policy is not about this. Don't misguide people, please. Read the documentation. -- You received this message because you a

Re: [sympy] debian package (to be orphaned)

On Wednesday, January 28, 2015 at 10:48:25 PM UTC+3, Aaron Meurer wrote: > > What is the Debian policy? > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps > If a single function uses something is it a recommended dependency? > It depends on how important this functio

Re: [sympy] debian package (to be orphaned)

On Tuesday, January 20, 2015 at 6:51:48 PM UTC+3, Ondřej Čertík wrote: > > Thanks Sergey for maintaining it. I created the initial Debian > package, and now I am a Debian Developer, so I can upload it myself. > Good news. I think, you are member of the debian science team, so there no problems

[sympy] Re: Wow. (was: Add pep8 config, use pep8 in travis (#8538))

Hello, I feel it would be a bad idea to quit silently. Probably, I should explain this action for others (without "fair warings" and so on). This thread - probably the best place, due to context. I got several private messages about the "tone in pull requests" and so on. Actually, besides the c

[sympy] debian package (to be orphaned)

Hello, I'll stop maintain the debian sympy package too. Is there anyone interested in supporting this? Package now is in the debian-science repo: http://anonscm.debian.org/cgit/debian-science/packages/sympy.git/ In the NEW queue there is an upload, that fixes all reported debian bugs: https://ft

[sympy] Re: substitute sympy function with arbitrary arguments

You could use pattern matching in the replace method: In [12]: var('a b') Out[12]: (a, b) In [13]: c = Wild('c') In [14]: f = Function('f') In [15]: f(a + b).replace(f(c), 2*c) Out[15]: 2⋅a + 2⋅b On Thursday, January 15, 2015 at 1:50:21 AM UTC+3, Craig Stringham wrote: > > This should be an e

[sympy] Re: summation of function

On Wednesday, January 14, 2015 at 12:56:40 PM UTC+3, Gaurav Dhingra wrote: > > Hi > Is this a bug ? > Sure, it's. https://github.com/sympy/sympy/issues/8822 Sympy's bugtracker is here: https://github.com/sympy/sympy/issues/ -- You received this message because you are subscribed to the Google

[sympy] Re: Unable to solve 2*x*cos(2*x) + sin(2*x)

On Wednesday, January 14, 2015 at 1:14:01 AM UTC+3, Amit Saha wrote: > > Thanks for any insights into this and whether there is a workaround. > What do you expect instead and why? Not all algebraic equations have analytic solutions. Mathematica can't do this eq as well. -- You received this m

[sympy] Re: limit() and assumptions

On Friday, January 9, 2015 at 4:46:53 PM UTC+3, Amit Saha wrote: > > NotImplementedError: Result depends on the sign of sign(log(x)) > > What does it mean? Can a more user friendly error be given? > What's unfriendly here? Very clear error message, IMHO. > I understand that mathematically, i

Re: [sympy] new idea

On Wednesday, January 7, 2015 6:13:54 PM UTC+3, Joachim Durchholz wrote: > > Adding a GUI? > That's a really large project. > In some sense, we have GUI. It is the Ipython Notebook. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe fro

Re: [sympy] Re: How about removing unused imports?

On Wed, Jan 7, 2015 at 6:31 PM, Joachim Durchholz wrote: > I'm not sure that that is possible. That's bad news. > With any other order, the next person to git pull will get a nasty surprise: > all their bin/test runs will fail with those newly tested-for errors, so > they can't rely on that "I c

[sympy] Re: How about removing unused imports?

On Wednesday, January 7, 2015 1:15:48 PM UTC+3, Joachim Durchholz wrote: > > Hey all, > > I'd like to work on cutting down the number of unused imports; a sample > pull request is on https://github.com/sympy/sympy/pull/8761 . > If we can first add a test for this in the code quality module - I'

Re: [sympy] Re: transcendental equation solving

On Wednesday, January 7, 2015 10:48:38 AM UTC+3, Harsh Gupta wrote: > > * There is a clear code level and interface level separation between > solvers for equations in complex domain and equations in real domain. > To be fair - this is a very subjective sentence. The clear advantage is new outpu

[sympy] Re: mpmath missing, installation instructions fail

Hello, On Tuesday, January 6, 2015 11:38:29 PM UTC+3, Joachim Durchholz wrote: > > I have to say that my fears have fully become reality: The process of > installing mpmath, while simple, isn't described in a way that "just > works", and still invites subtle error. > Lets hope, I can understan

Re: [sympy] Re: transcendental equation solving

On Tuesday, January 6, 2015 7:16:42 PM UTC+3, Luv Agarwal wrote: > > In GSoC last year there was a project on improvising solvers. I wanted to > know how much of that is implemented (the ideas page of this year is not > updated yet) as I am interested in working on solvers. > See https://github

[sympy] Re: Unbundle mpmath

FYI: now #2192 was merged. Please be aware about new installation instructions for SymPy: https://github.com/sympy/sympy#installation https://github.com/sympy/sympy/wiki/Development-workflow#install-mpmath On Friday, June 28, 2013 5:42:07 PM UTC+4, Sergey Kirpichev wrote: > > There is

[sympy] Re: What's the consensus about multiples-of-four indentation?

On Friday, January 2, 2015 11:39:09 AM UTC+3, Joachim Durchholz wrote: > > 2a) Should the rule be applied to continuation lines? > Typical case as found by me in the codebase: > a = self.fubar_the_worg(A, x) \ >+ make_me_happy(x, y, z) > No errors here. And this other category of

[sympy] Re: Wow. (was: Add pep8 config, use pep8 in travis (#8538))

On Friday, January 2, 2015 10:37:40 AM UTC+3, Joachim Durchholz wrote: > > Wow. Locked out without fair warning. No community consensus either. > Yes. I would like to see constructive discussion in that thread. When (and if) consensus will be reached among collaborators, we can unlock the threa

[sympy] Re: Want to contribute to SymPy

https://github.com/sympy/sympy/wiki/introduction-to-contributing On Tuesday, December 30, 2014 8:28:02 PM UTC+3, Karan Mangla wrote: > > Hi > I am Karan.I am a student of Computer Science and Engineering at > IIIT-Hyderabad(India). I am a Mathematics and Science enthusiast . > I am new to SymPy

[sympy] Re: using Interval method

On Tuesday, December 23, 2014 9:30:28 AM UTC+3, Gaurav Dhingra wrote: > > > from sympy.sets.sets import Interval > > Interva(0, 1) > [0, 1] > Pretty-printing is not an exact representation of objects. But in this case, [0,1] returned by repr() - I think this is a bug: In [2]: print(str(Int

Re: [sympy] A modest proposal for typed expressions

On Sunday, December 21, 2014 7:39:37 AM UTC+3, Richard Fateman wrote: > > It seems to me this can cause problems if, inside some scope, you need > to create or manipulate SymPy symbols for local > usage. (It can be done by "gensym" in Lisp, so maybe you do this?) > You can use Dummy: x1 = Dummy

Re: [sympy] A modest proposal for typed expressions

On Friday, December 19, 2014 2:47:44 AM UTC+3, Richard Fateman wrote: > > Please forgive me if this is off track -- I've never used assumptions in > sympy, and > don't know much about sympy implementation. > Actually, we have two: sympy/core/assumptions.py (old one) and sympy/assumptions/ (new)

[sympy] Re: Help to choose a first task

Hello, https://github.com/sympy/sympy/wiki/introduction-to-contributing On Friday, December 19, 2014 3:13:56 AM UTC+3, Willian Moreira wrote: > > Hello, > > I am Willian, a CS student from Brazil. I want to start contributing to > sympy developing. I got the code from the git repo, and now I am

[sympy] Re: How to run Sympy Test on a module or patch.

https://github.com/sympy/sympy/wiki/Development-workflow#be-sure-that-all-tests-of-sympy-pass see also file bin/test in the sympy's sources: ./bin/test --help On Monday, December 15, 2014 2:16:02 PM UTC+3, Adrián Ashley wrote: > > Hello Everyone! > > I am new to unit testing. It would be great if

[sympy] Re: Wish to contribute to SymPy

https://github.com/sympy/sympy/wiki/introduction-to-contributing -- 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 gro

[sympy] Re: Error in symbolic integration

On Wednesday, December 10, 2014 3:28:44 PM UTC+3, ali...@gmail.com wrote: > > When integrating with sympy something goes wrong - maybe a bug: > x = Symbol('x') > s = (cos(x)**2 / (1 + sin(x)**2)) > integrate(s, (x, 0, pi)) > > the answer from sympy is -pi > >From which version of the sympy? I se

[sympy] Re: GitHub multiple CI services

On Monday, December 8, 2014 11:41:00 PM UTC+3, Aaron Meurer wrote: > > It also > means we can take a second look at > https://github.com/sympy/sympy/pull/1960 >

[sympy] Re: Factor options

In [6]: factor(x**4 + 1, extension=[I, sqrt(2)]) Out[6]: ⎛ ___ ___ ⎞ ⎛ ___ ___ ⎞ ⎛ ___ ___ ⎞ ⎛ ___ ⎜╲╱ 2╲╱ 2 ⋅ⅈ⎟ ⎜╲╱ 2╲╱ 2 ⋅ⅈ⎟ ⎜╲╱ 2╲╱ 2 ⋅ⅈ⎟ ⎜╲╱ 2 ⎜x - ─ - ───⎟⋅⎜x - ─ + ───⎟⋅⎜x + ─ - ───⎟⋅⎜x + ─ + ⎝

Re: [sympy] SymPy 0.7.6 is released

On Tuesday, November 25, 2014 2:53:05 AM UTC+3, François wrote: > > Thank you. I had finally worked it out from sympy's github repo. I > guess 0.18 + 1 commit not yet in mpmath. > Yes there are some commits in bundled mpmath's tree which exists only in newer mpmath versions. -- You received th

Re: [sympy] Python 2.6 support

On Sunday, November 23, 2014 10:22:23 PM UTC+3, Ondřej Čertík wrote: > > Btw, IPython also doesn't support Python 2.6, and I bet IPython is > used by more people than SymPy, so if it is good for IPython, I think > it will be good for us as well. > IPython doesn't support 3.2 too. Should we dro

[sympy] Re: Issue #7335: FiniteSet not accepting iterables

On Sunday, November 23, 2014 5:21:42 AM UTC+3, Amit Saha wrote: > > Hi, > > I only am realizing that I cannot do FiniteSet[1, 2, 3, 4]) any more. > I did find it very useful to create a set from the elements of a set. > Anyway, it's probably way late for that. > So, what is the recommended way

[sympy] Re: Release notes in the wiki vs with the source

See this thread: https://groups.google.com/d/msg/sympy/qkP3WAuWwbc/k3mi2NDea9MJ In my view, we should adopt some tagging for merge commits (e.g. with pr headers). This can help us with automatic generation of the release notes. Something like the scipy project. Take for example our last relea

[sympy] Re: SymPy plans for the future: 1.0 on the horizon

On Friday, November 21, 2014 12:49:40 AM UTC+3, Aaron Meurer wrote: > > A few I'd like to propose: > New solve is another important stuff for 1.0, see https://github.com/sympy/sympy/pull/7523 > - mpmath should be made a dependency of SymPy (it should no longer be > bundled). Let's wait until

Re: [sympy] SymPy 0.7.6 release candidate 2

On Thursday, November 20, 2014 12:09:46 AM UTC+3, Aaron Meurer wrote: > > Thanks for everyone for testing this. I haven't heard of any issues so I > will do the final release tomorrow. If anyone else was planning on testing > this, please do so now. > Are we sure that our benchmarks work: http

Re: [sympy] fixes #8239

On Sunday, November 16, 2014 5:21:45 PM UTC+3, Joachim Durchholz wrote: > > Look into the Travis logs and see what errors have been reported. > Fix them, then re-push to your Github repository and see what Travis > reports. > A slight correction: "Fix them" -> "Fix them, test locally" See h

[sympy] Re: new to Sympy

https://github.com/sympy/sympy/wiki/introduction-to-contributing On Thursday, November 6, 2014 3:57:01 PM UTC+3, Ankush wrote: > > Hi everyone, > I am new to sympy and really interested in this topic. I > want to contribute in this community. Can anybody guide me how to proceed

Re: [sympy] A goof-up in symbolic math software

On Friday, October 31, 2014 1:49:23 AM UTC+3, Richard Fateman wrote: > > If they knew anything about debugging and SymPy, which is not so probable. > The point is - it's ultimately improbable for closed-source program. -- You received this message because you are subscribed to the Google Groups

[sympy] Re: sympy and IVP

On Thursday, October 16, 2014 12:08:30 AM UTC+4, ali...@gmail.com wrote: > > I have a problem in solving IVP's with sympy [...] Do you have any hints? > We don't support initial conditions yet (issue 4720). Please read documentation. However, in this case you can find a generic solution for t

[sympy] Re: Why 1/3 == S(1)/3 is True ?

On Thursday, October 2, 2014 5:02:10 PM UTC+4, Christophe Bal wrote: > > For me the fact that 1/3 == S(1)/3 has value True sounds like a bug > because 1/3 is a float, and S(1)/3 a rational. > Looks as a bug, please report one on https://github.com/sympy/sympy/issues (through please sea

[sympy] Re: git rebase question

On Thursday, October 2, 2014 12:46:25 AM UTC+4, Colin Macdonald wrote: > > [replying to maillist instead of issue tracker] > > Would this latter case include cleaning up a (sordid) history that has > approaches > tried but latter reverted? > It's ok, but only as a last resort, after the review wa

[sympy] Re: Find a issue about the doc

On Monday, September 29, 2014 12:18:33 PM UTC+4, Garvin Li wrote: > > When I clone the project,and try to"make html".There is something > wrong happened. > Yes. You forgot to read the docs first ) > I think many computer may not have the "rsvg-convert" > why not add a judgement

[sympy] Re: elliptic_e._eval_conjugate for one arg?

On Sunday, September 28, 2014 2:18:42 PM UTC+4, Kalevi Suominen wrote: > > > The one-argument form of elliptic-e is useless (in is present form) > because the modulus has no default value. > Oh, no. It's just the Legendre complete elliptic integral of the second kind. Please read the docs.

[sympy] Re: elliptic_e._eval_conjugate for one arg?

On Sunday, September 28, 2014 5:15:06 AM UTC+4, Chris Smith wrote: > > elliptic_e can take 1 or two args but the _eval_conjugate assumes 2 (and > fails in a branch I am working on). The following mod works without > returning anything for the 1 arg case, but can someone tell me if I should > b

[sympy] Metaclass and comparison ops

I see that some strange things happens for classes, that define comparison ops AND use metaclasses. Sometimes, the interpreter do "flip" of operands and executes e.g for a < b first b.__gt__(a), not a.__lt__(b). And example: https://github.com/sympy/sympy/issues/7951 Simple tests: https://githu

Re: [sympy] [RFC] what test to add for an issue

On Wednesday, September 3, 2014 6:44:06 AM UTC+4, Aaron Meurer wrote: > > I think such situations are OK, as long as you understand why the test > failed before and verified that the new test really tests the same > thing. > 1. We can make mistakes here. 2. Probably, we want to be sure, that we

[sympy] Re: A plan for the assumptions

On Sunday, August 24, 2014 9:46:40 PM UTC+4, Aaron Meurer wrote: > > Some of you may have seen Sergey started a pull request to remove uses of > the new assumptions in the code, because it's confusing to users who set > the old assumptions and it doesn't work. > BTW, if we decide to use this app

[sympy] Re: SymPy 0.7.6 release

On Wednesday, August 27, 2014 8:10:31 AM UTC+4, Aaron Meurer wrote: > > Now that GSoC is over, let's start thinking about doing a 0.7.6 release. > Are there any major pull requests from GSoC that are still to be merged? > Avichal Dayal's pull requests aren't merged yet: https://github.com/sympy/

Re: [sympy] Re: A plan for the assumptions

>> Or I don't understand your problem [about the problem with calling for >> arg in the new assumptions handler] >> > The problem is that arg is written using old assumptions, so unless you > rewrite arg to use the new assumptions and pass assumptions along to it, Yes. In particular, if we add a

[sympy] Re: A plan for the assumptions

On Tuesday, August 26, 2014 9:32:29 AM UTC+4, Chris Smith wrote: > > I know that the new system can handle "is_true" expressions and can handle > assumptions involving Or (while the old assumptions only allow And-based > assumptions: var('x', integer=True, positive=True). > Not just Or-ed, but t

[sympy] Re: A plan for the assumptions

On Sunday, August 24, 2014 9:46:40 PM UTC+4, Aaron Meurer wrote: > > You make a good point. However, if you are going to spend time on this, it > would be better spent improving the new assumptions (and let's finally > merge my branch as a start to this), or merging the two. I still maintain >

Re: [sympy] Benefit of XFAIL over SKIP?

On Sat, Aug 23, 2014 at 11:36 PM, Aaron Meurer wrote: > Maybe it would help to finish implementing > https://github.com/sympy/sympy/issues/7044. The biggest issue with XFAIL > is that there will be some silly error in the way the test is written so > that it never XPASSes, even when it should.

Re: [sympy] Benefit of XFAIL over SKIP?

On Thursday, August 7, 2014 7:52:26 PM UTC+4, Ondřej Čertík wrote: > > On Thu, Aug 7, 2014 at 9:49 AM, Harsh Gupta wrote: > >> What is the is benefit of all these XFAIL'ed tests? > > > > A passed XFAIL'ed test is reported. Just as a seemly unrelated change > > can make a test fail, a seemly un

[sympy] Re: summation over tuple of symbols

Hmm. I have no idea of what you want, but... In [32]: A = IndexedBase('A') In [33]: n=Symbol('n', integer=True) In [34]: Sum(A[n],(n,0,2)) Out[34]: 2 ___ ╲ ╲ A[n] ╱ ╱ ‾‾‾ n = 0 In [35]: _.doit() Out[35]: A[0] + A[1] + A[2] On Monday,

[sympy] Re: unexpected behavior with partial derivatives of order greater than one

Looks as a bug for me. Our bugtracker: https://github.com/sympy/sympy/issues On Tuesday, July 29, 2014 1:29:59 AM UTC+4, J. S. Oishi wrote: > > Hi all, > > I'm using sympy 0.7.4.1, and I've come across an issue I don't quite > understand. If I do > > from sympy import * > x,z,t = symbols('x, z,

Re: [sympy] Draft for a new pattern matcher

On Monday, July 14, 2014 11:36:19 AM UTC+4, F. B. wrote: > > x = Wild('x') > x.is_integer().OddQ() > > Hmm. What's wrong with x = Wild('x', integer=True, odd=True), like Symbol? -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this

[sympy] Re: Implementation of equation solvers.

On Wednesday, July 2, 2014 5:32:56 PM UTC+4, Harsh Gupta wrote: > > The ideas is to see equation solving techniques as transformation on > equations > which takes an equation as input and produces a *simpler* equation which > has > the same solutions as the input. > Sounds good so far. But plea

[sympy] Re: Behavior of Float objects with .format() method

On Monday, June 9, 2014 5:35:34 AM UTC+4, Amit Saha wrote: > > I came across this: > > >>> from sympy import Float > >>> Float(1.25343) > 1.253430 > > >>> '{0:.2f}'.format(Float(1.25343)) > Traceback (most recent call last): > File "", line 1, in > ValueError: Unknown format cod

[sympy] Re: Erroneous series expansion of tan(x)

This does work in my order-point branch, see https://github.com/sympy/sympy/pull/2427 In [1]: tan(x).series(x,pi/2,10) Out[1]: 35 7 9 ⎛π⎞ ⎛π⎞⎛π⎞ ⎛ π⎞

[sympy] Re: Lazy and relaxed series

On Tuesday, June 3, 2014 10:22:14 PM UTC+4, Camille Gillot wrote: > > I wanted to know if there is any interest in lazy power series computation > in Sympy. > Yes, there is. > I would like to contribute by coding a kind of "series field operations > module", implementing series with on-demand

[sympy] Re: Unbundle mpmath

On Friday, June 28, 2013 5:42:07 PM UTC+4, Sergey Kirpichev wrote: > > There is a long term issue [1] to make mpmath an external dependency. It > was suggested by > Aaron (see discussion in PR [2]), that we should discuss this on the > mailing list. > > Perhaps, the main reaso

Re: [sympy] Re: Are all sympy Floats rational?

On Friday, April 4, 2014 6:44:11 PM UTC+4, Sergey Kirpichev wrote: > > In [13]: f2=Add(x1, Add(x2, -x3, evaluate=False), evaluate=False) > In [14]: f1 > Out[14]: -1.0*x + 0.001*x + 1.1*x > A little typo, should be: In [13]: f2=Add(x1, Add(x2, -x3, evaluate=False), evaluate=Fal

Re: [sympy] Re: Are all sympy Floats rational?

On Mon, Mar 31, 2014 at 02:17:56PM -0700, Richard Fateman wrote: >I think the answer from a practical perspective is that you can't exclude >floats. But why we need them as a class, derived from Number and Basic? An example of real issue: In [1]: n1=Float(0.001) In [2]: n2=Float(1.1) In [

Re: [sympy] Re: Issue migration from Google Code to GitHub

people in cc list). If you disagree or have better ideas how to do this - please reply. On Friday, March 28, 2014 7:10:10 PM UTC+4, Sergey Kirpichev wrote: > > On Fri, Mar 28, 2014 at 11:02:53AM -0400, Jason Moore wrote: > >Yes, applause! Thanks for doing this. > >Jason &g

Re: [sympy] Re: Are all sympy Floats rational?

On Sat, Mar 29, 2014 at 01:28:54PM -0700, Richard Fateman wrote: >Common Lisp uses floating-point arithmetic for floats, exact arithmetic >for the data type used for rationals. Good news. Python does same. >If you stick with integers and ratios of integers, Common >Lisp does math

Re: [sympy] Re: Are all sympy Floats rational?

On Monday, March 31, 2014 7:38:48 AM UTC+4, Richard Fateman wrote: > > Does python allow you to just write very long integers, e.g. > x: := 213456789123456789123456789 ? > Yes. And almost every contemporary language allow you to do so. -- You received this message because you are subscribed

Re: [sympy] Python 3.2 support

On Monday, March 31, 2014 6:30:31 PM UTC+4, Aaron Meurer wrote: > > Ok, that's fine. I didn't realize some Linux distros were still on 3.2. > Debian! -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving

Re: [sympy] Re: Are all sympy Floats rational?

On Saturday, March 29, 2014 8:34:36 AM UTC+4, Richard Fateman wrote: > > Your problem is that the notions of + and - in your computer programming > language > are apparently inadequate. > In which one? Python, CLisp? > It is certainly possible to do this correctly by converting a,b,c > into

[sympy] Re: ProductSet implementation

On Wednesday, March 26, 2014 5:18:41 PM UTC+4, Amit Saha wrote: > > IMO, a product set is a set (at least Wikipedia tells me so). So, > shouldn't it rather be the following? > > {(1,2), (1,3), (2,2), (2,3)} > 1) It *is* a set: In [8]: isinstance(p, Set) Out[8]: True 2) Yes, maybe for FiniteSe

Re: [sympy] subset() : why not is_subset() ?

On Tuesday, March 25, 2014 2:14:10 PM UTC+4, Amit Saha wrote: > > Before I work on the patch, what is the strategy to make backward > incompatible changes? Since, existing users may be surprised if we > suddenly remove the method and replace it by another one and even > break their existing co

Re: [sympy] Re: Are all sympy Floats rational?

On Monday, March 24, 2014 4:58:02 AM UTC+4, Richard Fateman wrote: > > So is every double-precision IEEE float (except inf and NaN) convertible > to the > exact rational number which it represents in the form integer/integer. > It was noted in this thread several times: we are not interested i

[sympy] Re: Are all sympy Floats rational?

On Thursday, March 20, 2014 4:19:24 PM UTC+4, Kalevi Suominen wrote: > > This leads to problems if used as a basis for decisions. > Sure. Julien, can you comment this? This was introduced by commit 9c359bc (and this is not tested!). In my view, it's wrong. Floats are inexact numbers, we sho

Re: [sympy] Re: GSOC 2014: Solvers

On Tuesday, March 18, 2014 8:20:31 PM UTC+4, Harsh Gupta wrote: > > We will have to be "very" careful while rewriting the solvers. I just came > across another of Professor Fateman's paper which describes why the > solution of z**w == y for z isn't simply y**(1/w). > > http://www.cs.berkeley.ed

[sympy] Re: Simplify expression

On Friday, March 14, 2014 9:30:24 PM UTC+4, ecir...@gmail.com wrote: > > 3. If I knew that one term is in the form of "(a - b)", would the help? > Yes, for example: In [2]: e = a**4 - 4*a**3*b + 6*a**2*b**2 - 4*a*b**3 - a + b**4 In [3]: e Out[3]: 4 32 234 a - 4⋅

Re: [sympy] Re: Can sympy do tensor based Euler-Lagrange?

On Thursday, March 13, 2014 7:29:40 PM UTC+4, brombo wrote: > > If you are talking about Lagrangian field theory the question is how do > you take a derivative with respect to the field and the gradient of the > field and not with respect to the position vector the field is a function > of. >

Re: [sympy] Re: Discussion regarding the series expansion project

On Friday, March 14, 2014 6:24:15 PM UTC+4, pr...@goodok.ru wrote: > > Do you meant Laurent series? > Yep, sorry -- 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 sym

Re: [sympy] Re: Discussion regarding the series expansion project

Hello, On Fri, Mar 7, 2014 at 3:29 AM, Avichal Dayal wrote: > It would be great if you could look at my proposal (just an initial draft) > and give suggestions:- > https://github.com/sympy/sympy/wiki/GSoC-2014-Application-Avichal-Dayal-Series-Expansion > Formal Power Series: What about Lambert

[sympy] Re: Can sympy do tensor based Euler-Lagrange?

On Monday, March 10, 2014 9:24:27 PM UTC+4, Joseph Smidt wrote: > >Does anyone know if sympy is equipped to handle tensor based > Eular-Lagrange equations equations such as these? > Yes, with euler_equations from calculus module. But it doesn't support tensor notation directly. -- You rec

[sympy] Re: The place where the func and args attribute is set for sympy objects

On Thursday, March 13, 2014 9:32:47 AM UTC+4, Tschijnmo Tschau wrote: > > It looks like AssocOp only have got one level of super class in Sympy, the > Basic class, whose constructor sets the _args attribute but not for the > func and args attribute. > The Basic class has *properties* func and a

Re: [sympy] Re: Issue migration from Google Code to GitHub

Everything is on the github. https://github.com/sympy/sympy/issues/7235 On Thursday, March 6, 2014 12:32:21 AM UTC+4, Aaron Meurer wrote: > > This is done. It took some time because I was only able to update 200 > issues at a time. I accidentally sent out an email on one of them, so > sorry abo

Re: [sympy] Addition of 'BigInteger' to Numbers

On Wednesday, March 5, 2014 5:08:47 AM UTC+4, Ondřej Čertík wrote: > > Can you post your code where you need large integers in Python that > runs out of memory? > A good example is this one: http://code.google.com/p/sympy/issues/detail?id=3736 :) But I think it's a very different (and very diff

[sympy] Re: complex numbers

On Tuesday, March 4, 2014 9:38:22 AM UTC+4, Chris Smith wrote: > > Something that seems a little counter-intuitive to me (having now worked > with the assumptions a bit) is the decision to let 2, I and 2 + I all be > considered complex > I'm little surprised, what could be counter-intuitive here

Re: [sympy] Re: Issue migration from Google Code to GitHub

code and github. On Monday, February 17, 2014 10:32:35 PM UTC+4, Sergey Kirpichev wrote: > > Hello, > > On Sun, Feb 16, 2014 at 1:05 PM, Sergey Kirpichev > wrote: > > > [...] > > Other tasks for volunteers (in random order): > > 1) Find problems in the test impo

[sympy] Re: asymptotic expansion of sin and cos at infinity

On Saturday, March 1, 2014 5:35:01 PM UTC+4, Avichal Dayal wrote: > > Perhaps, something to indicate an error. > > But there are instances where series(sin(x), x, oo) is used by other > methods > For e.g.:- gruntz((sin(x) + cos(x)/x**2, x, oo) tries to find that series > If we raise an error, the

[sympy] Re: asymptotic expansion of sin and cos at infinity

On Friday, February 28, 2014 9:02:25 PM UTC+4, Avichal Dayal wrote: > > Currently the series method does not allow to return only the Order term. > Why do you think so? In [2]: O(1).series(x,n=100) Out[2]: O(1) > Since sin and cos do not converge at infinity and are bounded functions, > in my op

[sympy] Re: Discussion regarding the series expansion project

On Friday, February 28, 2014 12:01:10 AM UTC+4, Avichal Dayal wrote: > > Yes, that's very *big* amount of work. >> > You mean enough for the summer > or too much for the summer? > It depends on what is exactly you are planning to do. -- You received this message because you are subscribed to the

[sympy] Re: Discussion regarding the series expansion project

On Thursday, February 27, 2014 9:14:30 AM UTC+4, Avichal Dayal wrote: > > I am planning to work on formal power series, asymptotic expansion and > order > term arithmetic. Will that be the right amount of work for the summer? > > Yes, that's very *big* amount of work. btw, I think now (see pr #2

Re: [sympy] Re: New PEP for infix operator

On Wednesday, February 26, 2014 11:49:47 PM UTC+4, Aaron Meurer wrote: > > > Because it turn python to be a DSL for numeric computations. > > How is that a bad thing? Python is already used heavily for numeric > computations. It's good for this specific domain, but bad for the Python in genera

Re: [sympy] Re: New PEP for infix operator

On Wed, Feb 26, 2014 at 2:35 PM, Christophe Bal wrote: > I'm not sure but it seems that Ruby syntax can be a solution. Here is an > example. Ruby can't do this as flexible as Haskell. AFAIK, only few predefined operators can be used. > class matrix(): > ... >def @(self, mat): >

Re: [sympy] Discussion regarding the series expansion project

On Wednesday, February 26, 2014 6:03:22 AM UTC+4, Aaron Meurer wrote: > > There was some paper about computing limits with oscillating > functions. Maybe you can find the reference if you search the mailing > list archives (or probably Raoul will remember it). > Probably, it's a good idea to

Re: [sympy] Re: New PEP for infix operator

Just like a usual function. http://en.wikipedia.org/wiki/Haskell_features#Function_calls http://en.wikibooks.org/wiki/Haskell/More_on_functions#Operators_and_sections -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and s

[sympy] Re: New PEP for infix operator

On Tuesday, February 25, 2014 8:31:02 PM UTC+4, Aaron Meurer wrote: > > Some people on this list might be interested in this. Some folks are > giving another shot at writing a PEP to add a new operator to Python > for matrix multiplication. The discussion is at > https://github.com/numpy/numpy/p

  1   2   >