Re: Issue 2125 in sympy: Using Integers as python slices.
Comment #21 on issue 2125 by nicolas@gmail.com: Using Integers as python slices. http://code.google.com/p/sympy/issues/detail?id=2125 I opened a pull request: https://github.com/sympy/sympy/pull/178 (Patch content has not change since http://code.google.com/p/sympy/issues/detail?id=2125#c5, but I think it would be easier to review). -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2125 in sympy: Using Integers as python slices.
Comment #22 on issue 2125 by nicolas@gmail.com: Using Integers as python slices. http://code.google.com/p/sympy/issues/detail?id=2125 One remark more: In current master: In [2]: S(2)*[1,1] --- TypeError Traceback (most recent call last) /home/nicolas/Programmation/sympy/ipython console in module() TypeError: can't multiply sequence by non-int of type 'Integer' So, for now, S(2)*[1,1] is not allowed at all, and adding Integer.__index__() won't break anything. One may still discuss issue 1838 later. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Comment #5 on issue 360 by pr...@goodok.ru: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 Sorry, is it possible to implement zoo*(1 + I) == zoo too? -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Comment #6 on issue 360 by ness...@googlemail.com: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 It obviously should … my bad. Will fix. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 1300 in sympy: series() gives less terms than expected
Comment #2 on issue 1300 by pr...@goodok.ru: series() gives less terms than expected http://code.google.com/p/sympy/issues/detail?id=1300 This issue is fixed two weeks ago or more, and it is in master now. In [3]: (cos(x)**2).series(x, 0, 10) Out[3]: 1 - x**2 + x**4/3 - 2*x**6/45 + x**8/315 + O(x**10) In [4]: (sin(x)**2).series(x, 0, 10) Out[4]: x**2 - x**4/3 + 2*x**6/45 - x**8/315 + O(x**10) -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Comment #7 on issue 360 by ness...@googlemail.com: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 Done. [Man I feel bad for you catching all these basic shortcomings... thanks a lot for that.] -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Updates: Labels: -NeedsBetterPatch PassedReview Comment #8 on issue 360 by pr...@goodok.ru: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Issue 2246 in sympy: Global directive to switch strict transformations
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 2246 by yuri.kar...@gmail.com: Global directive to switch strict transformations http://code.google.com/p/sympy/issues/detail?id=2246 It is vitally to differential equation module to add ability to switch behavior of sympy so it can make nonstrict computation e.g. tan(x).inverse() = atan so atan(tan(x)) = x despite the range of x After such changes we'll be able to solve wide class of DEs e.g. dsolve(diff(f(x),x)+f(x)**2+1) f(x) = tan(C₁ - x) instead of atan(f(x)) = C₁ - x -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2237 in sympy: FockState wraps its arguments with tuple()
Updates: Status: Fixed Comment #13 on issue 2237 by nicolas@gmail.com: FockState wraps its arguments with tuple() http://code.google.com/p/sympy/issues/detail?id=2237 That's in. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Issue 2247 in sympy: Problem with coth
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 2247 by yuri.kar...@gmail.com: Problem with coth http://code.google.com/p/sympy/issues/detail?id=2247 In [11]: coth(acoth(x))==x Out[11]: False -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2246 in sympy: Global directive to switch strict transformations
Comment #1 on issue 2246 by asmeurer: Global directive to switch strict transformations http://code.google.com/p/sympy/issues/detail?id=2246 This is related to issue 1572. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Issue 2248 in sympy: Operator == not symmetric for Real and others
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 2248 by ness...@googlemail.com: Operator == not symmetric for Real and others http://code.google.com/p/sympy/issues/detail?id=2248 Currently (2*pi) == (2*pi).evalf() False (2*pi).evalf() == (2*pi) True Similarly for e.g. cos(0.1, evaluate=False) in place of 2*pi. Real.__eq__ does too much magic. [patch follows] -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2248 in sympy: Operator == not symmetric for Real and others
Comment #1 on issue 2248 by ness...@googlemail.com: Operator == not symmetric for Real and others http://code.google.com/p/sympy/issues/detail?id=2248 Pull request: https://github.com/sympy/sympy/pull/179 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2247 in sympy: Problem with coth
Comment #1 on issue 2247 by yuri.kar...@gmail.com: Problem with coth http://code.google.com/p/sympy/issues/detail?id=2247 I also will add such identities: tanh(acoth(x))=1/x coth(atanh(x))=1/x coth(asinh(x))=sqrt(x**2+1)/x coth(acosh(x))=x/(sqrt(x-1)sqrt(x+1)) sinh(acoth(x))=1/(sqrt(x-1)sqrt(x+1)) cosh(acoth(x))=x/(sqrt(x-1)sqrt(x+1)) -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2246 in sympy: Global directive to switch strict transformations
Comment #2 on issue 2246 by yuri.kar...@gmail.com: Global directive to switch strict transformations http://code.google.com/p/sympy/issues/detail?id=2246 Sure it is part of issue 1572, but they can be solved separately. This issue - for elementary and special function (because it's straight-forward generalization of existing functionality) and issue 1572 for any generic function f(x). -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 821 in sympy: multiple arguments for max and other improvements
Updates:
Owner: pr...@goodok.ru
Labels: -NeedsReview NeedsBetterPatch
Comment #23 on issue 821 by Vinzent.Steinberg: multiple arguments for max
and other improvements
http://code.google.com/p/sympy/issues/detail?id=821
Thanks, this looks good, the code works as it should and the tests pass. I
made a few suggestion about the documentation on github.
I just noticed this:
In [10]: Max(I,1,zoo)
Out[10]: Max(1, zoo, ⅈ)
This is not related to this patch, but we should probably also check that
the input is always real.
Removing 'nargs' is fine. I'm not sure about evaluate=False, but I don't
know another easy way. Maybe calling __new__ directly?
@classmethod is only intended if your method does not need an instance.
Consider
Max.method
vs.
x = Symbol('x')
Max(1,x).method
So in your case the use of this decorator is fine (you are operating
on 'cls' and not 'self').
--
You received this message because you are subscribed to the Google Groups
sympy-issues group.
To post to this group, send email to sympy-issues@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2247 in sympy: Problem with coth
Updates: Status: Accepted Comment #2 on issue 2247 by asmeurer: Problem with coth http://code.google.com/p/sympy/issues/detail?id=2247 Do those identities agree with the branch cuts agreed upon in issue 564? -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2246 in sympy: Global directive to switch strict transformations
Updates: Status: Accepted Comment #3 on issue 2246 by asmeurer: Global directive to switch strict transformations http://code.google.com/p/sympy/issues/detail?id=2246 I think they could be solved together. solve() should have a keyword option that lets it ignore little niceties like atan(x) = y =| x = tan(y), and then dsolve() should just use that when calling solve() on the solution. But first, solve needs to be able to handle inverses well, which is issue 1572. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2247 in sympy: Problem with coth
Comment #3 on issue 2247 by yuri.kar...@gmail.com: Problem with coth http://code.google.com/p/sympy/issues/detail?id=2247 There's no foliation in these cases so there's no need in cuts of Rieman surface: tanh(acoth(x))=1/x coth(atanh(x))=1/x coth(acoth(x))=x The others is agreed with sqrt foliation, because sqrt(4) 2 Let's proove this formula coth(asinh(x))=sqrt(x**2+1)/x asinh(x)=t so by definition sinh(t)=x coth(t)**2=cosh(t)**2/sinh(t)**2=(1+sinh(t)**2)/sinh(t)**2=(1+x**2)/x**2 as positive branch of sqrt are chosen than coth(t)=sqrt(1+x**2)/x So it seems we should not think about issue's 564 agreement. Sorry if I present too much details. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2246 in sympy: Global directive to switch strict transformations
Comment #4 on issue 2246 by yuri.kar...@gmail.com: Global directive to switch strict transformations http://code.google.com/p/sympy/issues/detail?id=2246 Sure they could. But still it will be better to divide this problem into two subproblems (it could be one issue): 1st - change standard and special functions to be able to call inverse (using some cut agreements) if the keyword nonstrict or may be foliation or whatever are set to true. 2nd - do what you say in previous comment. The profit of such differentiation is that the other functions like evalf will be able to use nonstrict computation, so the functionality won't be doubled for any function that need it (and this will be so if we implement it all inside solve function). Anyway I will be glad to help. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 821 in sympy: multiple arguments for max and other improvements
Updates: Labels: -NeedsBetterPatch NeedsReview Comment #24 on issue 821 by pr...@goodok.ru: multiple arguments for max and other improvements http://code.google.com/p/sympy/issues/detail?id=821 Thanks a lot for detailed and useful remarks here and there! I have updated the pull now. Regarding the comparison of incomparable arguments. I consider them as unjoined vertexes, for generalization in common case: whether they have boolean relation or not (`is_connected` method). Besides, by that I move the problem and tuning of Max behaviour to ``, `==`, `` operators in SymPy core. What to do with concrete comparison of complex number I don't know. I think that complex numbers comparable only by norm, but user can tune it manually, supplying appropriate arguments. At the same Max can consider as ordinary unevaluated expression, e.g. Max(cos(x), sin(x)) Max(cos(x), sin(x)) with the aim to further Max(cos(x), sin(x)).subs(x, 0) 1 For this aim I should not like the checking of inputs for real. And also, I've forgotten to notice it in previous message, in one place (`def remove_duplicates`) I used python 2.5 technique, guided by [1]. Is it acceptably for next milestone? [1] http://docs.python.org/faq/programming.html#how-do-you-remove-duplicates-from-a-list -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2246 in sympy: Global directive to switch strict transformations
Comment #5 on issue 2246 by ronan.l...@gmail.com: Global directive to switch strict transformations http://code.google.com/p/sympy/issues/detail?id=2246 Having a global switch is always a bad idea, I think. Such things tend to cause a lot of trouble. Even as an option, turning it on would cause a lot of wrong results to be returned. But actually, nonstrict computation is already the default and wrong results are returned at present, for example solve(sin(x), x) - [0]. Anyway, concerning the examples above, strict vs nonstrict isn't the issue. tan(atan(x)) is always equal to x, so atan(x) = y always implies x = tan(y). -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2242 in sympy: A general way to describe and test for singularities is needed
Comment #1 on issue 2242 by pr...@goodok.ru: A general way to describe and test for singularities is needed http://code.google.com/p/sympy/issues/detail?id=2242 Just to keep it in one place, add link to the this theme in mail-list. Tom Bachmann On a general representation for singularities and infinities http://groups.google.com/group/sympy/browse_thread/thread/73f7e90aef508882?pli=1 -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 564 in sympy: series expansion of acosh and acoth
Comment #14 on issue 564 by pr...@goodok.ru: series expansion of acosh and acoth http://code.google.com/p/sympy/issues/detail?id=564 Regarding the wolframalpha. I observed that it have many questions too, therefore can be considered as etalon with accuracy. Mathematically, `coth(0) == zoo` is true only in the case of when user asks CAS about the extension of reals to complex numbers. But I, e.g. can ask CAS to do not extend reals (then oo must the right answer), or even can ask to extent reals to the similar so called `semi-complex` numbers. Second, coth(0) have singularity at this point: And I supposed that walframalpha try to show this for us by returning `zoo`. Or simply return `zoo` like S(1)/S.Zero oo But I think that right way is return more general singularity description (formally, coth(o) has no value, only infinite limit at this point) So, the question, what coth(0) must result, I think is related with issue 2242 (A general way to describe and test for singularities) and so on. Returning to the title of issue. Both answers of sympy and maxima are correct. Except the remarks about branches, but branches (multi-valued function) are not used now for definitions of functions in sympy and it is a separated question. There is only definition what branches for multi-valued function are chosen as main. since the range of sinh(x) in the reals is (-1,1). It is arguably. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 821 in sympy: multiple arguments for max and other improvements
Updates: Labels: Milestone-Release0.7.1 Comment #25 on issue 821 by asmeurer: multiple arguments for max and other improvements http://code.google.com/p/sympy/issues/detail?id=821 Sure, feel free to set the milestone. Those are half superficial anyway since they just get postponed if no one has time to work on the issue :) As to complex numbers, there are multiple ways to compare them, none of which are actual comparison in the sense of what Max is doing, so I think we should just not allow them. On the other hand, pragmatically, it can be a pain to assure that everything is explicitly assumed to be real, so maybe it should just assume it is real unless it is explicitly otherwise (e.g., a symbol is complex by default, but Max(x, 1) will assume it is real; on the other hand Max(1, I) will not work because I cannot be real). I think this is already in some ways the standard for the inequalities, and probably should become that way (unless others have other thoughts). -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2246 in sympy: Global directive to switch strict transformations
Comment #6 on issue 2246 by asmeurer: Global directive to switch strict transformations http://code.google.com/p/sympy/issues/detail?id=2246 Yes, I agree about global switches, if just because of the fact that they are testing nightmares. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 564 in sympy: series expansion of acosh and acoth
Comment #15 on issue 564 by asmeurer: series expansion of acosh and acoth http://code.google.com/p/sympy/issues/detail?id=564 Well, since symbols are complex by default in SymPy, I think it only makes sense for functions to be complex by default as well. Someday, the new assumptions will make it easy to work only with the reals if you want. But until then, making things complex by default is the most general way to do it (e.g., if you only care about reals, you at least know that zoo means +/- oo). -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 564 in sympy: series expansion of acosh and acoth
Comment #16 on issue 564 by pr...@goodok.ru: series expansion of acosh and acoth http://code.google.com/p/sympy/issues/detail?id=564 A agree that default plane for function's result can be considered as complex plane, but I am not sure that it is the straight consequence from the knowledge of that that symbols are complex by default. I am worry about that, because I plan to involved in sympy split-complex numbers. And it is interesting how can I switch, with the help of assumptions, the field of the functions's result, in the case of when supplying arguments are *strictly real*. e.g. real zero. And about `new assumptions`. Is it that what is described in issue 1047 ? btw: S.Zero.is_complex True 1/S.Zero oo Or I do not understand `is_complex` attribute, or it is must be return zoo by the above assumptions. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2011 in sympy: less self-confident simplify
Comment #19 on issue 2011 by nicolas@gmail.com: less self-confident simplify http://code.google.com/p/sympy/issues/detail?id=2011 All tests pass now in https://github.com/wxgeo/sympy/tree/2011. -- You received this message because you are subscribed to the Google Groups sympy-issues group. To post to this group, send email to sympy-issues@googlegroups.com. To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en.
Re: Issue 2125 in sympy: Using Integers as python slices.
Comment #21 on issue 2125 by nicolas@gmail.com: Using Integers as python slices. http://code.google.com/p/sympy/issues/detail?id=2125 I opened a pull request: https://github.com/sympy/sympy/pull/178 (Patch content has not change since http://code.google.com/p/sympy/issues/detail?id=2125#c5, but I think it would be easier to review). -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Comment #4 on issue 360 by ness...@googlemail.com: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 Done. -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Comment #5 on issue 360 by pr...@goodok.ru: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 Sorry, is it possible to implement zoo*(1 + I) == zoo too? -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Comment #6 on issue 360 by ness...@googlemail.com: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 It obviously should … my bad. Will fix. -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Comment #7 on issue 360 by ness...@googlemail.com: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 Done. [Man I feel bad for you catching all these basic shortcomings... thanks a lot for that.] -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 360 in sympy: Arithmetic with complex infinity
Updates: Labels: -NeedsBetterPatch PassedReview Comment #8 on issue 360 by pr...@goodok.ru: Arithmetic with complex infinity http://code.google.com/p/sympy/issues/detail?id=360 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 2237 in sympy: FockState wraps its arguments with tuple()
Updates: Status: Fixed Comment #13 on issue 2237 by nicolas@gmail.com: FockState wraps its arguments with tuple() http://code.google.com/p/sympy/issues/detail?id=2237 That's in. -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 2248 in sympy: Operator == not symmetric for Real and others
Updates: Status: Accepted Labels: NeedsReview ness987 Comment #2 on issue 2248 by asmeurer: Operator == not symmetric for Real and others http://code.google.com/p/sympy/issues/detail?id=2248 (No comment was entered for this change.) -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 821 in sympy: multiple arguments for max and other improvements
Updates: Labels: -NeedsBetterPatch NeedsReview Comment #24 on issue 821 by pr...@goodok.ru: multiple arguments for max and other improvements http://code.google.com/p/sympy/issues/detail?id=821 Thanks a lot for detailed and useful remarks here and there! I have updated the pull now. Regarding the comparison of incomparable arguments. I consider them as unjoined vertexes, for generalization in common case: whether they have boolean relation or not (`is_connected` method). Besides, by that I move the problem and tuning of Max behaviour to ``, `==`, `` operators in SymPy core. What to do with concrete comparison of complex number I don't know. I think that complex numbers comparable only by norm, but user can tune it manually, supplying appropriate arguments. At the same Max can consider as ordinary unevaluated expression, e.g. Max(cos(x), sin(x)) Max(cos(x), sin(x)) with the aim to further Max(cos(x), sin(x)).subs(x, 0) 1 For this aim I should not like the checking of inputs for real. And also, I've forgotten to notice it in previous message, in one place (`def remove_duplicates`) I used python 2.5 technique, guided by [1]. Is it acceptably for next milestone? [1] http://docs.python.org/faq/programming.html#how-do-you-remove-duplicates-from-a-list -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 821 in sympy: multiple arguments for max and other improvements
Updates: Labels: Milestone-Release0.7.1 Comment #25 on issue 821 by asmeurer: multiple arguments for max and other improvements http://code.google.com/p/sympy/issues/detail?id=821 Sure, feel free to set the milestone. Those are half superficial anyway since they just get postponed if no one has time to work on the issue :) As to complex numbers, there are multiple ways to compare them, none of which are actual comparison in the sense of what Max is doing, so I think we should just not allow them. On the other hand, pragmatically, it can be a pain to assure that everything is explicitly assumed to be real, so maybe it should just assume it is real unless it is explicitly otherwise (e.g., a symbol is complex by default, but Max(x, 1) will assume it is real; on the other hand Max(1, I) will not work because I cannot be real). I think this is already in some ways the standard for the inequalities, and probably should become that way (unless others have other thoughts). -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: Issue 2011 in sympy: less self-confident simplify
Comment #19 on issue 2011 by nicolas@gmail.com: less self-confident simplify http://code.google.com/p/sympy/issues/detail?id=2011 All tests pass now in https://github.com/wxgeo/sympy/tree/2011. -- You received this message because you are subscribed to the Google Groups sympy-patches group. To post to this group, send email to sympy-patches@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
Re: [sympy] Re: GSoC: Sparse Matrix Implementation
On 03-29-2011, at 1:44 AM, Andy Ray Terrel wrote: There are some major confusions on this list about the difference between algorithms and storage. I'm not confused and I'm not sure if other people are. I just think storage alone isn't suitable for a GSoC project. Certainly one could just implement storage techniques behind the scenes and no algorithms, but that would only save space, not computation time. Yes, it is typical to use iterative algorithms with sparse matrices and factorizations with dense, but this is because sparse matrices are typically very large (1M -- 10^12 entries with 1000 -- 2B non-zeros). One will switch to things that don't fill in the matrix but SymPy will probably never be at this level. With symbolic matrices, the computation time for each calculation is much higher than with numerical matrices so the benefit of sparse matrix techniques occur at much smaller matrix sizes. One can implement some Krylov subspace iteration algorithms, but its somewhat pointless (how do you evaluate a residual in symbols). Another algorithm ILU versus LU is also silly (basically it throws away small fill in entries but we have no way of saying what is small in symbolics). For this reason I suggest just implementing standard factorizations and dealing with the fill in as it happens if we get to the point that we need to do UMFPACK style direct factorizations we can do that the next summer. We practitioners only use algorithms suited for sparse matrices because of the size of the matrices which will not be an issue in SymPy. I've already stated that storage isn't suitable for a GSoC project. It's very true that residual based methods will have problems, so will others. That's what I've been saying. The reasons the different methods will have problems will vary. How can you say that size won't be an issue? I've seen very large symbolic sparse matrices in CAS before. In fact, a friend of mine who was working on a project built on top of Maple wrote his own sparse matrix algorithms because Maple only handled dense matrices and bogged down at about 7x7 matrices, which isn't uncommon. I've personally wanted matrices with 10^4 -- 10^6 order entries with symbolic entries. Certainly not as large as a lot of some of the numerical sparse matrices, but still a reasonable size when each entry has several terms in it, rather than just a single number. It would be good if you listed what algorithms are better for sparse matrices and we go from there. It is a weak project to just do the storage by itself, and unless there are many people who will use sparse matrices, it's not particularly relevant. For example I just use scipy or petsc4py for sparse things in python. With that said, some day SymPy will be much faster than it is today (or at least I hope) and such structures may be commonplace if they are there. I'm mainly counselling being careful about the algorithms. I've seen work done on this area, but I don't have the references handy, since I don't actually work on this for my research. There can be clever ways of doing standard dense linear algebra for sparse matrices. While I'd personally use scipy for sparse matrices now, I'd prefer to do more symbolically. Because the of the nature of my sparse matrices, if I had them symbolically, I'd be able to simplify things before I converted to numerical sparse matrices. The project becomes much more interesting if you take Ronan's point of view of redesigning the Matrix class or perhaps implementing more matrix factorizations (LU, QR, Cholesky, diagonalization, eigenvalues: L\Lambda R should be achievable over the summer). I think implementing matrix factorizations are a good idea for somebody and but I think sparse matrices (both algorithms and storage) are a good idea too. Certainly factorization and eigenvalues would be of use with symbolic sparse matrices as well. Cheers, Tim. --- Tim Lahey PhD Candidate, Systems Design Engineering University of Waterloo http://about.me/tjlahey -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] GSoC 2011
Hi Riccardo!
On Mon, Mar 28, 2011 at 4:51 PM, norok2 riccardo.met...@gmail.com wrote:
Hello everybody!
I'm an Italian Physics Master student at University of Trento and I
have a bachelor degree from University of Pisa. I would like to
partecipate to contribute to sympy development through Google Summer
of Code 2011 program.
Welcome!
I have very recently discovered sympy as my Python experience is quite
at the beginning. I am a frequent user of maxima (usually through
wxMaxima) where apparently there is no clean way to deal with QM
formalism. I therefore find quite interesting to have the opportunity
to develop - and, later on, use :-) - a symbolic tool to deal with QM
problems. I find particularly interesting all Fourier transform
related formalism because this is very basic to any linear system (not
just QM). I also find of interest QM analythic solutions as they are
very helpful both to serve as a basis for many advanced methods in QM
Try to play with the QM stuff and browse and play with sympy more to
get an idea what it can or cannot do. And ask questions. Indeed, we
would be very interested in having several good QM applications. Feel
free to also discuss with the other GSoC applicants.
QM is very nice, because it requires quite a bit of CAS, and so it
tests sympy quite a lot, and then it is a real application, that
people need. And there are not many QM symbolic packages out there, so
QM will be one of the selling points of sympy.
I'd like to encourage other people, with other interests, for example
mechanics, or other fields, to also contribute and create
physics/engineering modules for their fields. This adds tremendous
value to sympy, and at the end, everybody benefits.
and to test out numerical approaches. Moreover, in my quick survey to
this CAS I have not found (and I believe it could be useful) a LaTeX
converter.
We have the latex() function, try it in isympy like this:
$ bin/isympy
IPython console for SymPy 0.6.7-git (Python 2.6.5)
These commands were executed:
from __future__ import division
from sympy import *
x, y, z, t = symbols('x y z t')
k, m, n = symbols('k m n', integer=True)
f, g, h = map(Function, 'fgh')
Documentation can be found at http://sympy.org/
In [1]: latex?
[...]
it will print help.
As far as my programming skills are concerned, I can say that I
believe to know quite well C and C++, while I have a limited
experience in other programming / scripting / markup languages,
including Python, Bash, PHP, Javascript, HTML, LaTeX, Lisp (listed
with no specific order). I understand this project is essentially
Python but I believe with some further study I can get acquainted with
it quite well.
Python is not hard to learn. As long as you work hard, you'll pick it
up. That's what we (mentors) are here for.
I hope I'm writing into the right place and I will be getting
attention from people interested in discussing this topics.
Definitely.
Regards,
Riccardo Metere.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: GSoC: Sparse Matrix Implementation
On Tue, Mar 29, 2011 at 9:13 AM, Tim Lahey tim.la...@gmail.com wrote: On 03-29-2011, at 1:44 AM, Andy Ray Terrel wrote: There are some major confusions on this list about the difference between algorithms and storage. I'm not confused and I'm not sure if other people are. I just think storage alone isn't suitable for a GSoC project. Certainly one could just implement storage techniques behind the scenes and no algorithms, but that would only save space, not computation time. On modern hardware, computation is free memory is expensive. Yes, it is typical to use iterative algorithms with sparse matrices and factorizations with dense, but this is because sparse matrices are typically very large (1M -- 10^12 entries with 1000 -- 2B non-zeros). One will switch to things that don't fill in the matrix but SymPy will probably never be at this level. With symbolic matrices, the computation time for each calculation is much higher than with numerical matrices so the benefit of sparse matrix techniques occur at much smaller matrix sizes. One can implement some Krylov subspace iteration algorithms, but its somewhat pointless (how do you evaluate a residual in symbols). Another algorithm ILU versus LU is also silly (basically it throws away small fill in entries but we have no way of saying what is small in symbolics). For this reason I suggest just implementing standard factorizations and dealing with the fill in as it happens if we get to the point that we need to do UMFPACK style direct factorizations we can do that the next summer. We practitioners only use algorithms suited for sparse matrices because of the size of the matrices which will not be an issue in SymPy. I've already stated that storage isn't suitable for a GSoC project. I respectfully disagree. Furthermore I find it distasteful for one applicant to tell another that their idea is not suitable. It's very true that residual based methods will have problems, so will others. That's what I've been saying. The reasons the different methods will have problems will vary. How can you say that size won't be an issue? I've seen very large symbolic sparse matrices in CAS before. In fact, a friend of mine who was working on a project built on top of Maple wrote his own sparse matrix algorithms because Maple only handled dense matrices and bogged down at about 7x7 matrices, which isn't uncommon. I've personally wanted matrices with 10^4 -- 10^6 order entries with symbolic entries. Certainly not as large as a lot of some of the numerical sparse matrices, but still a reasonable size when each entry has several terms in it, rather than just a single number. I would have to see the problem to believe you. In a field where a single equation can bog down, I find it impossible to separate such concerns. You wishes are the future GSOC is about today, I'm more interested in projects that will be successful over the summer. It would be good if you listed what algorithms are better for sparse matrices and we go from there. It is a weak project to just do the storage by itself, and unless there are many people who will use sparse matrices, it's not particularly relevant. For example I just use scipy or petsc4py for sparse things in python. With that said, some day SymPy will be much faster than it is today (or at least I hope) and such structures may be commonplace if they are there. I'm mainly counselling being careful about the algorithms. I've seen work done on this area, but I don't have the references handy, since I don't actually work on this for my research. There can be clever ways of doing standard dense linear algebra for sparse matrices. While I'd personally use scipy for sparse matrices now, I'd prefer to do more symbolically. Because the of the nature of my sparse matrices, if I had them symbolically, I'd be able to simplify things before I converted to numerical sparse matrices. My approach, which is managable today, is to do symbolics at a very coarse level, then push to numerics at a fine level via Full Approximation Schemes. -- Andy The project becomes much more interesting if you take Ronan's point of view of redesigning the Matrix class or perhaps implementing more matrix factorizations (LU, QR, Cholesky, diagonalization, eigenvalues: L\Lambda R should be achievable over the summer). I think implementing matrix factorizations are a good idea for somebody and but I think sparse matrices (both algorithms and storage) are a good idea too. Certainly factorization and eigenvalues would be of use with symbolic sparse matrices as well. Cheers, Tim. --- Tim Lahey PhD Candidate, Systems Design Engineering University of Waterloo http://about.me/tjlahey -- 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,
[sympy] Re: GSOC Introduction
Hi,
I am looking at Issue 834 http://code.google.com/p/sympy/issues/detail?id=834.
I feel I understand the problem and how I would fix it. But would I be
able to get feedback on what fix would be best so I can practice
submitting a patch? I've added a comment to the issue with my
questions about the issue.
Ben M
On Mar 28, 9:08 am, Aaron S. Meurer asmeu...@gmail.com wrote:
Yes, the present use case is only for integers. We do not really use
floating point numbers (our numerical library, mpmath, has its own arbitrary
precision floating point implementation).
This can be expanded, though, to cover other C types, like arrays for
lists/tuples.
Aaron Meurer
On Mar 27, 2011, at 5:22 AM, Ben M wrote:
Hey,
I’m learning about SymPy’s use of Cython at the moment so I can write
my proposal. I've been looking at past discussions and the code.
The ‘cythonized’ decorator seems to cast all given variables to local
C int types ('cython.int'). Why only ints and no decimals? Is this
because SymPy has its own way of representing rational numbers and
will other modules only make use of ints? Thanks.
Ben M
On Mar 26, 3:22 pm, Ben M mcdonald@gmail.com wrote:
Hi. I'm continuing to look at Cython. I've added a wiki
page.https://github.com/sympy/sympy/wiki/Optimising-SymPy-using-Cython...
Ben M
On Mar 24, 1:10 pm, Aaron S. Meurer asmeu...@gmail.com wrote:
Yes, maybe you could look at cythonizing the logic code (ilke the SAT
solver). Another idea that comes to mind is the matrices. The other
really big main part aside from the core is the polys, but Mateusz has
already been working on cythonizing the core of that. Maybe you could
see what he has done and if more could be done (see the @cythonized
decorators in some of the files in sympy/polys/).
Aaron Meurer
On Mar 23, 2011, at 5:44 PM, Ronan Lamy wrote:
Le mercredi 23 mars 2011 à 16:09 -0700, Friedman a écrit :
Thanks for the link Aaron.
What other parts of SymPy could be optimised without working on
deprecated code? I could try to produce a dependence graph to find the
most referenced modules.
I read in that thread that removing the old assumptions could be a
challenging project. What skills does it rely on? Is it more
mathematics or software engineering? I have more experience in the
later doing a Comp. Sc. degree (encapsulation, modularity, OO design
patterns).
I think it's mostly software engineering (refactoring, interface
design, ...) with a side dish of hardcore CS/AI topics (knowledge base
maintenance and indexing, inductive reasoning, ...) We probably also
need to implement simplification of boolean expressions.
On Mar 24, 7:56 am, Aaron S. Meurer asmeu...@gmail.com wrote:
You might read through this thread from a few days
agohttp://groups.google.com/group/sympy/browse_thread/thread/18f0197965e
Note that there might be a problem with the Cythonizing the core
because we still need to remove the old assumptions (this would itself
be a whole GSoC project).
However, if you are still interested in Cython, you might look at
cythonizing other core parts of SymPy.
Aaron Meurer
On Mar 23, 2011, at 5:20 AM, Friedman wrote:
Hello SymPy people,
I’m a Computer Science student currently completing my Master’s thesis
at the University of Canterbury, New Zealand.
I am looking to participate in gsoc this year. I would like to
contribute to sympy because I have both an interest in mathematics and
Python. Python is currently my language of choice. I use Python in my
studies and I also tutor Python in undergraduate classes.
I’m considering the Cython project to optimise the core. I used Cython
in Master’s project to optimise processor/memory intensive methods.
With Cython I increase the performance of my code while leaving the
original Python code unchanged by adding Cython headers (.pyx) to
modules to convert the Python into C++. It would be very interesting
to be involved in doing the same to sympy.
Currently looking through the discussion topics to see what would be
required of the Cython project. Just wanted to express my interest in
this project at this moment.
Ben M.
--
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...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sympy?hl=en.
--
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...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sympy?hl=en.
--
You received this message because you are subscribed to
[sympy] Re: On a general representation for singularities and infinities
My primary use case is for code in sympy to be able to understand the
result of a limiting operation. In particular there is currently no
(good) way to interpret the result of e.g. limit(Wild('a')*x, x, oo)
as being infinity (to the end user a*oo is visibly infinity, but
(a*oo).is_unbounded is None)
Why do you use Wild('a')?
Hm. I think somewhere I found something like acos(1+a*x**2).series(x).
Perhaps just using y instead of a would be more sensible. In any case
this code should return an error. It has to evaluate the
limit(acos(1+a*x**2).diff(x),x,0) which currently returns I*a*oo.
A simpler example would be limit(y*x, x, oo). What should this return?
It currently returns y*oo which is perhaps helpful for the user, but
not for code. How is code supposed to interpret this - in fact how
even recognise it?
Strictly speaking of course, the limit should either be left
unevaluated, or returned as a case expression {oo: y0, -oo: y0, 0:
y==0}. Anyway there should be a way for the above code to figure out
that in some cases this is unbounded, and hence should return an
error.
I initially suggested simply to add a .is_potentially_unbounded flag,
but goodok objected that this was not the mathematically right
way (and I agree, hence my longer proposal).
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
[sympy] Re: GSoC 2011 - Oleksandr Gituliar
Dear Mr.Granger,
On Mar 28, 10:40 pm, Brian Granger elliso...@gmail.com wrote:
On Thu, Mar 24, 2011 at 6:41 AM, oleksandr gituliar gitul...@gmail.com
wrote:
On Mar 23, 5:31 pm, Brian Granger elliso...@gmail.com wrote:
On Wed, Mar 23, 2011 at 12:51 AM, oleksandr gituliar gitul...@gmail.com
wrote:
* For QCD related things, I think it would be *very* interesting to
implement SU(N), in a similar manner to how we have implemented spin
(see sympy.physics.quantum.spin).
Concerning SU(N) representations of the rotation group I agree that it
would be extremely interesting to work on it especially in a symbolic/
analytical form. As for the same things in QCD, did you mean Lorentz
group SU(N) representations (with bispinors, 4-vectors, relativistic
objects with a higher spin)?
I was simply thinking that when doing various types of computations in
QCD, it would be useful for have access to all the SU(N) machinery in
symbolic/numerical form.
I'm still wondering what do you mean on SU(N) machinery?
Generators, commutation/anticommutation relations, structure
constants, representations as matrices, eigenstates, etc.
Basically everything that is normally done for spin (see
sympy.physics.quantum.spin).
Those features seems worth to be implemented for Relativistic QM at
first since it is much simpler than any of field theories (ones where
number of states vary via creation/annihilation operators with QED and
QCD among them). Moreover, one needs to re-implement all basic
features for relativistic case (states: 4-vectors, bispinors, etc.,
operators and everything that depends on that) in order to have
objects to apply those features to. Personally I'd prefer to have a
particular example of a problem one would like to solve (do you have
one?) and use it as a basis for implementing those features in
contrast to the opposite approach. I guess this task worth a separate
GSoC idea thread and is extremely interesting BTW, however I think
that similar features for non-relativistic case should be completed at
first. What do you think, Mr.Granger?
Here [1] I started a new branch in order to refactor existing
sympy.physics.quantum module that I hope will be more simpler for the
end-user. I'd appreciate to have any suggestions and criticism from
you.
This look mostly like things we have implemented already. Also, in
terms of the Hilbert Space stuff.
More or less. QM formalism was already implemented 100 years ago and
it seems nothing left to work on there from mathematical point of
view. The main challange is to port it to computer systems where
design skills are mainly required in tandem with a solid QM
background.
We found that for discrete quantum
systems, the notion of hilbert space was pretty clear. You do run
into some issues for spaces with symbolic/infinite dimension.
Technically, matrix*vector is substituted by operator*function when N-
oo limit is considered. I hope that SymPy deals equally well with
both operations (at least it is supposed to). Thus again the issue is
to design a whole interface in a clean and simple way with lots of
examples and docs.
But for continuous systems (x, p) Hilbert Space is quite complicated
and to do it right you have to introduce a huge amount of complexity
with little benefit. Instead of going that route, we have kept it
simple. What this means is that (just like in real life) the
HilbertSpaces attached to states and operators are sort of in the
background. You can ask a state or operator what HilbertSpace it
belongs to using the .hilbert_space attribute, but the whole approach
is not very formal (which is on purpose).
It looks that currently a Hilbert space is attached somehow
automatically when a state is created, that I think should work an
opposite way round since it has no sense to have a state in some
abstract space with no dimensions. Just try to run:
k1 = Ket('psi')
k1.hilbert_space
H
How many dimensions does H have? That's simple, right:
k1.hilbert_space.dimension
NotImplementedError: This Hilbert space has no dimensions.
Quite unexpected :(
k2 = Ket('phi')
k2.hilbert_space
H
Does k1.hilbert_space == k2.hilbert_space?
k1.hilbert_space == k2.hilbert_space
True
Why is that so, how to make them to be different?
And finally:
k = 3*k1 + 4*k2
type(k)
class 'sympy.core.add.Add
Wow, it is supposed to be class 'sympy.physics.quantum.state.Ket',
right?
All those are very simple questions but still very important since
without correctly answering them one will not be able to build more
complicated things like perturbative methods, rotation group
representations (spin and angular momentum).
Summing up, as my GSoC 2011 proposition I'll probably go with an idea
of implementing all those basic features for QM in tandem with
building a solid set of documentation and examples for as many QM
topics as possible (I'll put more details on my wiki
Re: [sympy] Re: GSoC 2011 - Oleksandr Gituliar
On 03/29/2011 06:08 AM, oleksandr gituliar wrote:
Dear Mr.Granger,
On Mar 28, 10:40 pm, Brian Grangerelliso...@gmail.com wrote:
On Thu, Mar 24, 2011 at 6:41 AM, oleksandr gituliargitul...@gmail.com wrote:
On Mar 23, 5:31 pm, Brian Grangerelliso...@gmail.com wrote:
On Wed, Mar 23, 2011 at 12:51 AM, oleksandr gituliargitul...@gmail.com wrote:
* For QCD related things, I think it would be *very* interesting to
implement SU(N), in a similar manner to how we have implemented spin
(see sympy.physics.quantum.spin).
Concerning SU(N) representations of the rotation group I agree that it
would be extremely interesting to work on it especially in a symbolic/
analytical form. As for the same things in QCD, did you mean Lorentz
group SU(N) representations (with bispinors, 4-vectors, relativistic
objects with a higher spin)?
I was simply thinking that when doing various types of computations in
QCD, it would be useful for have access to all the SU(N) machinery in
symbolic/numerical form.
I'm still wondering what do you mean on SU(N) machinery?
Generators, commutation/anticommutation relations, structure
constants, representations as matrices, eigenstates, etc.
Basically everything that is normally done for spin (see
sympy.physics.quantum.spin).
Those features seems worth to be implemented for Relativistic QM at
first since it is much simpler than any of field theories (ones where
number of states vary via creation/annihilation operators with QED and
QCD among them). Moreover, one needs to re-implement all basic
features for relativistic case (states: 4-vectors, bispinors, etc.,
operators and everything that depends on that) in order to have
objects to apply those features to. Personally I'd prefer to have a
particular example of a problem one would like to solve (do you have
one?) and use it as a basis for implementing those features in
contrast to the opposite approach. I guess this task worth a separate
GSoC idea thread and is extremely interesting BTW, however I think
that similar features for non-relativistic case should be completed at
first. What do you think, Mr.Granger?
Here [1] I started a new branch in order to refactor existing
sympy.physics.quantum module that I hope will be more simpler for the
end-user. I'd appreciate to have any suggestions and criticism from
you.
This look mostly like things we have implemented already. Also, in
terms of the Hilbert Space stuff.
More or less. QM formalism was already implemented 100 years ago and
it seems nothing left to work on there from mathematical point of
view. The main challange is to port it to computer systems where
design skills are mainly required in tandem with a solid QM
background.
We found that for discrete quantum
systems, the notion of hilbert space was pretty clear. You do run
into some issues for spaces with symbolic/infinite dimension.
Technically, matrix*vector is substituted by operator*function when N-
oo limit is considered. I hope that SymPy deals equally well with
both operations (at least it is supposed to). Thus again the issue is
to design a whole interface in a clean and simple way with lots of
examples and docs.
But for continuous systems (x, p) Hilbert Space is quite complicated
and to do it right you have to introduce a huge amount of complexity
with little benefit. Instead of going that route, we have kept it
simple. What this means is that (just like in real life) the
HilbertSpaces attached to states and operators are sort of in the
background. You can ask a state or operator what HilbertSpace it
belongs to using the .hilbert_space attribute, but the whole approach
is not very formal (which is on purpose).
It looks that currently a Hilbert space is attached somehow
automatically when a state is created, that I think should work an
opposite way round since it has no sense to have a state in some
abstract space with no dimensions. Just try to run:
k1 = Ket('psi')
k1.hilbert_space
H
How many dimensions does H have? That's simple, right:
k1.hilbert_space.dimension
NotImplementedError: This Hilbert space has no dimensions.
Quite unexpected :(
k2 = Ket('phi')
k2.hilbert_space
H
Does k1.hilbert_space == k2.hilbert_space?
k1.hilbert_space == k2.hilbert_space
True
Why is that so, how to make them to be different?
And finally:
k = 3*k1 + 4*k2
type(k)
class 'sympy.core.add.Add
Wow, it is supposed to beclass 'sympy.physics.quantum.state.Ket',
right?
All those are very simple questions but still very important since
without correctly answering them one will not be able to build more
complicated things like perturbative methods, rotation group
representations (spin and angular momentum).
Summing up, as my GSoC 2011 proposition I'll probably go with an idea
of implementing all those basic features for QM in tandem with
building a solid set of documentation and examples for as many QM
topics as possible (I'll put more
[sympy] GSoC
I am a sophomore undergraduate at IIT Bombay. I have a very strong mathematical background. I have spent the last one year exploring various areas of theoretical computer science - from graph theory to communication complexity to streaming algorithms through various RD Projects. In the meanwhile I have collaborated with a friend on a paper- http://arxiv.org/abs/1102.1636. Previous summer I spent Interning at Affordable Solution Labs, IIT Bombay in building various tools for a Govt of India Project to advertise e-learning. The summer of 2008, I attended a nurture camp where topics in Group, Ring and Field Theory, Linear Algebra were introduced. And previous to that my summers were spent in attending the International Mathematical Olympiad Training Camp. Up to date I have written around 5 lines of code mostly in C++. Are there any projects which I might be able to do (further considering my inclination for theoretical computer science and algorithms and also the fact that I am comfortable with C++ and to some extent JAVA and C), taking into account the constraint that I am a sophomore? Thanks Karthik PS: I have not written even a line of code in python, however I have great affection for mathematics, logic and natural sciences. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. inline: --static--liam_crowdsurfer_bottom.gif
[sympy] Re: Update on integral equation solver
On Mar 29, 6:53 am, Saptarshi Mandal sapta.iit...@gmail.com wrote: Any pointers on how I could render visualizations of graphs using Sympy? See [1] and [2]. Vinzent [1] http://docs.sympy.org/dev/modules/plotting.html [2] http://docs.sympy.org/dev/modules/mpmath/plotting.html -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Re: Solving PDE's
Hi Everyone, Thanks for the reply. @ Vinzent: I am interested in developing the capability of SymPy further by enabling the solution of PDEs. For GSoC, I was thinking of writing FDM based solvers for simple PDEs like heat equation, hyperbolic PDE's, etc. The solvers can be implicit or explicit. If time permits we may add further functionality, but for this we may have to discuss possible options. Also working on ODE's is fine with me. Please tell me your views on this . @ Ondrej: I have uploaded a FDM solver for inviscid supersonic nozzle flow written by me at the following link. Its a stand alone solver and you may get an idea of my capability by looking at it. The solver is entirely coded by me. I have also coded numerous simple PDE's using many other FDM algorithms but I presume that this alone would suffice as all the 3 basic governing equations for fluid flow (Conitnuity, Momentum Energy) have been coded for this solver. This code is written in MATLAB but since Python is also shell based language like MATLAB and have some similarity in their syntactical rules, I believe that I won't have much problem with coding in Python. http://codeviewer.org/view/code:18dc In addition to this I have also coded a FVM solver for supersonic combustion in C++ and ported it OpenFOAM(just like the present case where we have to port our code to SymPy). Its location is below. Please have a look at these and tell me your views regarding my plans for GSoC mentioned above. http://www.cfd-online.com/Forums/openfoam/82851-new-solver-supersonic-combustion.html Thanks Nakul -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: GSoC: Sparse Matrix Implementation
On Mar 29, 2011, at 12:51 AM, Andy Ray Terrel wrote: On Tue, Mar 29, 2011 at 9:13 AM, Tim Lahey tim.la...@gmail.com wrote: On 03-29-2011, at 1:44 AM, Andy Ray Terrel wrote: There are some major confusions on this list about the difference between algorithms and storage. I'm not confused and I'm not sure if other people are. I just think storage alone isn't suitable for a GSoC project. Certainly one could just implement storage techniques behind the scenes and no algorithms, but that would only save space, not computation time. On modern hardware, computation is free memory is expensive. Yes, it is typical to use iterative algorithms with sparse matrices and factorizations with dense, but this is because sparse matrices are typically very large (1M -- 10^12 entries with 1000 -- 2B non-zeros). One will switch to things that don't fill in the matrix but SymPy will probably never be at this level. With symbolic matrices, the computation time for each calculation is much higher than with numerical matrices so the benefit of sparse matrix techniques occur at much smaller matrix sizes. One can implement some Krylov subspace iteration algorithms, but its somewhat pointless (how do you evaluate a residual in symbols). Another algorithm ILU versus LU is also silly (basically it throws away small fill in entries but we have no way of saying what is small in symbolics). For this reason I suggest just implementing standard factorizations and dealing with the fill in as it happens if we get to the point that we need to do UMFPACK style direct factorizations we can do that the next summer. We practitioners only use algorithms suited for sparse matrices because of the size of the matrices which will not be an issue in SymPy. I've already stated that storage isn't suitable for a GSoC project. I respectfully disagree. Furthermore I find it distasteful for one applicant to tell another that their idea is not suitable. Let's remain civil. I think it is important to decide what is needed and what is less needed, or what will be better than the current (dense) implementation and what will actually end up being worse. Perhaps the only way we will really know for sure what sparse methods will work best is to implement a bunch (in a modular way) and see what performs the best. By in a modular way, I mean they should be wrapped around classes in such a way that choosing a different sparse method should be trivial and the algorithms should be unaware to what is being used (except for the cases where it matters because one algorithm will be more efficient for one data type). It's very true that residual based methods will have problems, so will others. That's what I've been saying. The reasons the different methods will have problems will vary. How can you say that size won't be an issue? I've seen very large symbolic sparse matrices in CAS before. In fact, a friend of mine who was working on a project built on top of Maple wrote his own sparse matrix algorithms because Maple only handled dense matrices and bogged down at about 7x7 matrices, which isn't uncommon. I've personally wanted matrices with 10^4 -- 10^6 order entries with symbolic entries. Certainly not as large as a lot of some of the numerical sparse matrices, but still a reasonable size when each entry has several terms in it, rather than just a single number. I would have to see the problem to believe you. In a field where a single equation can bog down, I find it impossible to separate such concerns. You wishes are the future GSOC is about today, I'm more interested in projects that will be successful over the summer. Well, I admit that I am no expert in the area (I have only taken that standard theoretical undergraduate courses in linear algebra for a math major). However, I have personally see the current (dense) module be bogged down solving a sparse system. Take a look at http://code.google.com/p/sympy/issues/detail?id=1441. When computing integrate((sin(1/x) - x*exp(x))/((-sin(1/x) + x*exp(x))*x + x*sin(1/x))), x), the heurisch algorithm sets up and tries to solve a very sparse system of about 600 equations in about 450 variables with rational coefficients (very sparse meaning quite a few of the equations are nothing more than something like 5*x23 = 0). (hopefully I remembered that all correctly) For this reason, the above integral will hang indefinitely and never return anything, even if you leave it running for a very long time. If you are interested, put a debug break point or a print statement at line 364 of risch.py (it will take 10-30 min. to reach that point because there is also another slow line in the file related to expansion). So while I don't know for sure, it really seems to me when I look at those equations that a good sparse solver should be able to return very fast with them (by the way, this particular system is
[sympy] GSoC Introduction
Hi, I am a student at the Indian Institute of Technology, Kharagpur. I'm a third year undergraduate student studying mathematics and computing. I have gone through the Ideas page and I am interested on working on 'Efficient Groebner bases and their application'.(Introduction to Abstract Algebra is one of my courses in the current semester.) I am going through the code and I'll submit a patch soon. I have a bit of coding experience in C/C++, Java, Perl, Python. I hope to contribute to Sympy. Regards, Nishant. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] GSoC 2011 - Luis Garcia
Hi everyone, My name is Luis F. Garcia, I'm a Physics junior undergrad in Tec de Monterrey, a university in México. I've been browsing the accepted mentor programs for this year's GSoC and SymPy really caught my attention. First a bit of my background. My completed coursework so far has included: Classical mechanics, Electromagnetic Theory, Calculus, Vector Calculus, Mathematical methods for Physics, ODE/PDE, Computational Physics (a numerical methods class applied to Physics, we coded almost entirely in Matlab), Linear Algebra, Data Structures. Some of my current classes are: Quantum Mechanics, Quantum Information Processing, Electrodynamics. I've grown quite fond of QM and quantum computing so far and I am excited to see that SymPy has projects for both areas. On the technical side I have mainly coded in Java, C#, C+ +, Matlab and I've played around for a bit with Python but nothing too complicated. The past two summers I've been an intern with Microsoft, first on the Servers and Tools division and then in a team within the Office org. While working in Microsoft was a great learning experience I want to get more experience with scientific computing since it's more related to my field of study. I saw the ideas page already and I'm interested in the Abstract Dirac Notation, the one of implementing known analytical solutions of q.systems, and the one of symbolic quantum computing. I'll be playing around with sympy.physics to see what's already implemented but could anyone give me some guidance as to what is implemented, known issues, or anything relevant about the module? I'll also get a look at the open issues to get a patch in to the system. Thanks and I'll try to get a draft application in the wiki and the system before the end of this week. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] GSoC Student Applications Open
Tip to other students rewriting their application on the GSoC webpage. I had fair success just ripping some html off of the wiki page and dumping it into the GSoC page (there is an html button). The syntax highlighting went away in code examples but other than that it was painless. 2011/3/28 Aaron S. Meurer asmeu...@gmail.com Attention all GSoC students! Google has opened up student applications for GSoC. To apply for SymPy, go to http://www.google-melange.com/gsoc/org/google/gsoc2011/sympy and click on the Register button under students: apply! (under the picture of a bunch of people). You will then have to fill out some forms, and hopefully be taken to somewhere where you can fill out an application for SymPy (it's hard to say exactly what it will look like, since I am not a student in the system, but the new interface should be pretty easy to follow). I would recommend that *all* students who have a draft of their application submit it now. You can edit your application on the site up until the deadline, which is April 8, 1900 UTC. I recommend that you submit your application well before that time, in case there are technical difficulties with the site. Once again, you can edit your application after it is submitted until the deadline, so do not worry about it being perfect before putting it in the system. We cannot accept your application unless it is submitted through the site (obviously). Good luck to all students applying! Aaron Meurer -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] physics.quantum documentation
Hello all, I was looking at the stable and dev documentation and it seems to me that there is nothing on the physics module. Am I right? Are there any tutorials or references that are not automatically generated? If not, where is the best place to look for a consistent overview of the functionality (the source or some references)? Regards Stefan Krastanov -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: GSoC: Sparse Matrix Implementation
On Tue, Mar 29, 2011 at 7:22 PM, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 29, 2011, at 12:51 AM, Andy Ray Terrel wrote: On Tue, Mar 29, 2011 at 9:13 AM, Tim Lahey tim.la...@gmail.com wrote: On 03-29-2011, at 1:44 AM, Andy Ray Terrel wrote: There are some major confusions on this list about the difference between algorithms and storage. I'm not confused and I'm not sure if other people are. I just think storage alone isn't suitable for a GSoC project. Certainly one could just implement storage techniques behind the scenes and no algorithms, but that would only save space, not computation time. On modern hardware, computation is free memory is expensive. Yes, it is typical to use iterative algorithms with sparse matrices and factorizations with dense, but this is because sparse matrices are typically very large (1M -- 10^12 entries with 1000 -- 2B non-zeros). One will switch to things that don't fill in the matrix but SymPy will probably never be at this level. With symbolic matrices, the computation time for each calculation is much higher than with numerical matrices so the benefit of sparse matrix techniques occur at much smaller matrix sizes. One can implement some Krylov subspace iteration algorithms, but its somewhat pointless (how do you evaluate a residual in symbols). Another algorithm ILU versus LU is also silly (basically it throws away small fill in entries but we have no way of saying what is small in symbolics). For this reason I suggest just implementing standard factorizations and dealing with the fill in as it happens if we get to the point that we need to do UMFPACK style direct factorizations we can do that the next summer. We practitioners only use algorithms suited for sparse matrices because of the size of the matrices which will not be an issue in SymPy. I've already stated that storage isn't suitable for a GSoC project. I respectfully disagree. Furthermore I find it distasteful for one applicant to tell another that their idea is not suitable. Let's remain civil. I think it is important to decide what is needed and what is less needed, or what will be better than the current (dense) implementation and what will actually end up being worse. Please give me your guide of civility so I can rip out every page and use it as toilet paper. Perhaps the only way we will really know for sure what sparse methods will work best is to implement a bunch (in a modular way) and see what performs the best. By in a modular way, I mean they should be wrapped around classes in such a way that choosing a different sparse method should be trivial and the algorithms should be unaware to what is being used (except for the cases where it matters because one algorithm will be more efficient for one data type). It's very true that residual based methods will have problems, so will others. That's what I've been saying. The reasons the different methods will have problems will vary. How can you say that size won't be an issue? I've seen very large symbolic sparse matrices in CAS before. In fact, a friend of mine who was working on a project built on top of Maple wrote his own sparse matrix algorithms because Maple only handled dense matrices and bogged down at about 7x7 matrices, which isn't uncommon. I've personally wanted matrices with 10^4 -- 10^6 order entries with symbolic entries. Certainly not as large as a lot of some of the numerical sparse matrices, but still a reasonable size when each entry has several terms in it, rather than just a single number. I would have to see the problem to believe you. In a field where a single equation can bog down, I find it impossible to separate such concerns. You wishes are the future GSOC is about today, I'm more interested in projects that will be successful over the summer. Well, I admit that I am no expert in the area (I have only taken that standard theoretical undergraduate courses in linear algebra for a math major). However, I have personally see the current (dense) module be bogged down solving a sparse system. Take a look at http://code.google.com/p/sympy/issues/detail?id=1441. When computing integrate((sin(1/x) - x*exp(x))/((-sin(1/x) + x*exp(x))*x + x*sin(1/x))), x), the heurisch algorithm sets up and tries to solve a very sparse system of about 600 equations in about 450 variables with rational coefficients (very sparse meaning quite a few of the equations are nothing more than something like 5*x23 = 0). (hopefully I remembered that all correctly) For this reason, the above integral will hang indefinitely and never return anything, even if you leave it running for a very long time. If you are interested, put a debug break point or a print statement at line 364 of risch.py (it will take 10-30 min. to reach that point because there is also another slow line in the file related to expansion). So while I
Re: [sympy] Re: GSoC: Sparse Matrix Implementation
Hi, On Tue, Mar 29, 2011 at 11:43 AM, Andy Ray Terrel andy.ter...@gmail.com wrote: On Tue, Mar 29, 2011 at 7:22 PM, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 29, 2011, at 12:51 AM, Andy Ray Terrel wrote: On Tue, Mar 29, 2011 at 9:13 AM, Tim Lahey tim.la...@gmail.com wrote: On 03-29-2011, at 1:44 AM, Andy Ray Terrel wrote: There are some major confusions on this list about the difference between algorithms and storage. I'm not confused and I'm not sure if other people are. I just think storage alone isn't suitable for a GSoC project. Certainly one could just implement storage techniques behind the scenes and no algorithms, but that would only save space, not computation time. On modern hardware, computation is free memory is expensive. Yes, it is typical to use iterative algorithms with sparse matrices and factorizations with dense, but this is because sparse matrices are typically very large (1M -- 10^12 entries with 1000 -- 2B non-zeros). One will switch to things that don't fill in the matrix but SymPy will probably never be at this level. With symbolic matrices, the computation time for each calculation is much higher than with numerical matrices so the benefit of sparse matrix techniques occur at much smaller matrix sizes. One can implement some Krylov subspace iteration algorithms, but its somewhat pointless (how do you evaluate a residual in symbols). Another algorithm ILU versus LU is also silly (basically it throws away small fill in entries but we have no way of saying what is small in symbolics). For this reason I suggest just implementing standard factorizations and dealing with the fill in as it happens if we get to the point that we need to do UMFPACK style direct factorizations we can do that the next summer. We practitioners only use algorithms suited for sparse matrices because of the size of the matrices which will not be an issue in SymPy. I've already stated that storage isn't suitable for a GSoC project. I respectfully disagree. Furthermore I find it distasteful for one applicant to tell another that their idea is not suitable. Let's remain civil. I think it is important to decide what is needed and what is less needed, or what will be better than the current (dense) implementation and what will actually end up being worse. Please give me your guide of civility so I can rip out every page and use it as toilet paper. I don't think that will serve you well, civility is very important: http://www.codesimplicity.com/post/open-source-community-simplified/ - see 'Encourage a total absence of personal negativity'. http://producingoss.com/en/setting-tone.html see 'Nipping rudeness in the bud' Best, Matthew -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] Re: Update on integral equation solver
Also, if someone gets accepted to do a project with plotting, you should work with that person to get it to work. Aaron Meurer On Tue, Mar 29, 2011 at 8:03 AM, Vinzent Steinberg vinzent.steinb...@googlemail.com wrote: On Mar 29, 6:53 am, Saptarshi Mandal sapta.iit...@gmail.com wrote: Any pointers on how I could render visualizations of graphs using Sympy? See [1] and [2]. Vinzent [1] http://docs.sympy.org/dev/modules/plotting.html [2] http://docs.sympy.org/dev/modules/mpmath/plotting.html -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] GSoC 2011 - Luis Garcia
We look forward to seeing your application. Aaron Meurer On Tue, Mar 29, 2011 at 9:59 AM, Pipen ppn.onl...@me.com wrote: Hi everyone, My name is Luis F. Garcia, I'm a Physics junior undergrad in Tec de Monterrey, a university in México. I've been browsing the accepted mentor programs for this year's GSoC and SymPy really caught my attention. First a bit of my background. My completed coursework so far has included: Classical mechanics, Electromagnetic Theory, Calculus, Vector Calculus, Mathematical methods for Physics, ODE/PDE, Computational Physics (a numerical methods class applied to Physics, we coded almost entirely in Matlab), Linear Algebra, Data Structures. Some of my current classes are: Quantum Mechanics, Quantum Information Processing, Electrodynamics. I've grown quite fond of QM and quantum computing so far and I am excited to see that SymPy has projects for both areas. On the technical side I have mainly coded in Java, C#, C+ +, Matlab and I've played around for a bit with Python but nothing too complicated. The past two summers I've been an intern with Microsoft, first on the Servers and Tools division and then in a team within the Office org. While working in Microsoft was a great learning experience I want to get more experience with scientific computing since it's more related to my field of study. I saw the ideas page already and I'm interested in the Abstract Dirac Notation, the one of implementing known analytical solutions of q.systems, and the one of symbolic quantum computing. I'll be playing around with sympy.physics to see what's already implemented but could anyone give me some guidance as to what is implemented, known issues, or anything relevant about the module? I'll also get a look at the open issues to get a patch in to the system. Thanks and I'll try to get a draft application in the wiki and the system before the end of this week. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] GSoC Student Applications Open
Don't worry too much about the formatting in Melange. I know from my past two years' experience that the formatting in their forms is very difficult to do without it screwing it up for you. Aaron Meurer On Tue, Mar 29, 2011 at 11:22 AM, Matthew Rocklin mrock...@gmail.com wrote: Tip to other students rewriting their application on the GSoC webpage. I had fair success just ripping some html off of the wiki page and dumping it into the GSoC page (there is an html button). The syntax highlighting went away in code examples but other than that it was painless. 2011/3/28 Aaron S. Meurer asmeu...@gmail.com Attention all GSoC students! Google has opened up student applications for GSoC. To apply for SymPy, go to http://www.google-melange.com/gsoc/org/google/gsoc2011/sympy and click on the Register button under students: apply! (under the picture of a bunch of people). You will then have to fill out some forms, and hopefully be taken to somewhere where you can fill out an application for SymPy (it's hard to say exactly what it will look like, since I am not a student in the system, but the new interface should be pretty easy to follow). I would recommend that *all* students who have a draft of their application submit it now. You can edit your application on the site up until the deadline, which is April 8, 1900 UTC. I recommend that you submit your application well before that time, in case there are technical difficulties with the site. Once again, you can edit your application after it is submitted until the deadline, so do not worry about it being perfect before putting it in the system. We cannot accept your application unless it is submitted through the site (obviously). Good luck to all students applying! Aaron Meurer -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] GSoC Application Hector1618 Complex Analysis
Hello people, Following is my application for GSoC 2011. https://github.com/sympy/sympy/wiki/GSoC-2011-Application-Hector1618-:-Complex-Analysis I need to work on Benefits and adding external links for reference. Any suggestions, comments, criticism are always welcome. Looking forward for reply. -- -Regards Hector Whenever you think you can or you can't, in either way you are right. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
Re: [sympy] GSoC Application Hector1618 Complex Analysis
Hi, On 29 March 2011 15:49, Hector hector1...@gmail.com wrote: Hello people, Following is my application for GSoC 2011. https://github.com/sympy/sympy/wiki/GSoC-2011-Application-Hector1618-:-Complex-Analysis I need to work on Benefits and adding external links for reference. Any suggestions, comments, criticism are always welcome. After briefly reading your proposal, I have a comment regarding the following statement: As I mentioned, currently only polynomials with complex variable are solvable in SymPy. I want to extend this to make sure that every function which is solvable by any other CAS system will be solvable by SymPy. This is a big statement that you would like to solve *every* function (it could be a GSoC proposal on its own). I would be more specific here and say what classes of functions you would like to support and in what terms solutions should be computed (e.g. do you plan to implement/extend symbolic representation of zeros of functions if there is no closed form, etc.). Looking forward for reply. -- -Regards Hector Whenever you think you can or you can't, in either way you are right. -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en. Mateusz -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Re: Update on integral equation solver
No no I meant the *other* graph :) Although I do get the point, I could use pyglet. Alternatively exporting Svgs seems like a good idea too. On Mar 29, 10:03 am, Vinzent Steinberg vinzent.steinb...@googlemail.com wrote: On Mar 29, 6:53 am, Saptarshi Mandal sapta.iit...@gmail.com wrote: Any pointers on how I could render visualizations of graphs using Sympy? See [1] and [2]. Vinzent [1]http://docs.sympy.org/dev/modules/plotting.html [2]http://docs.sympy.org/dev/modules/mpmath/plotting.html -- 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...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
