Re: Issue 2047 in sympy: subs_atoms should omit more variables when doing subs in Integral
Updates: Labels: EasyToFix Comment #6 on issue 2047 by smi...@gmail.com: subs_atoms should omit more variables when doing subs in Integral http://code.google.com/p/sympy/issues/detail?id=2047 I believe this is fixed. This should be verified and then closed. -- 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 2216 in sympy: Module names are imported with from sympy import *
Comment #1 on issue 2216 by ronan.l...@gmail.com: Module names are imported with from sympy import * http://code.google.com/p/sympy/issues/detail?id=2216 Thanks for opening this, I should have done it myself. Importing * from a (sub)package brings all the public names of that package into the current namespace. The problem is that modules are necessarily part of the public interface of their parent package but shouldn't appear in their grandparent's namespace. I think that the only way to fix it is to avoid using import * in sympy/__init__.py and only use explicit imports instead. -- 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 1206 in sympy: Integer and Rational do not implement .args
Comment #5 on issue 1206 by asmeurer: Integer and Rational do not implement .args http://code.google.com/p/sympy/issues/detail?id=1206 Why would we have Integer(42)() == 42? I think the second option makes the most sense. The point of having Basic .args is so you can recurse through them. An Atom should be the base case of recursion. So I guess the question is, do Integer and Rational count as Atoms. In particular for Rational, should it be an Atom or should it act like Rational(3, 2).args == (Integer(3), Integer(2))? I see why they would't have .args, but why would they not have .func? Actually, to me, it seems that the best would be to have .args be (). This technically wouldn't hold the invariant, but I think it would play nicer with recursion algorithms. So I guess the question there is do we require that the base case be checked by looking for an empty .args, or by checking obj.is_Atom? -- 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 2216 in sympy: Module names are imported with from sympy import *
Comment #3 on issue 2216 by ronan.l...@gmail.com: Module names are imported with from sympy import * http://code.google.com/p/sympy/issues/detail?id=2216 __all__ defines which names in module/package should be considered public and should be set when the rule everything that doesn't start with an underscore is public doesn't work. It's used by 'import *' and by pydoc (help() uses pydoc). I'm not sure it should be used here. If we removed e.g. 'ode' from sympy.solvers.__all__[*], it would make 'ode' a private attribute of sympy.solvers (which means that end-users wouldn't be supposed to ever write 'sympy.solvers.ode'), and would basically mean that sympy.solvers pretends to be a module instead of a package. Concerning your docstring, I would just replace help(ode.ode_hintname) with `help(sympy.solvers.ode.ode_hintname)`. We should neither encourage our users to do 'from sympy import *' nor assume that they have done so. [*]: By 'sympy.solvers', I mean the package corresponding to the directory sympy/solvers. Currently, however, sympy.solvers is the module corresponding to sympy/solvers/solvers.py - due to the problem under discussion. -- 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 7 in sympy: implement relations (, ) solving
Updates: Labels: Assumptions Solvers Comment #6 on issue 7 by asmeurer: implement relations (, ) solving http://code.google.com/p/sympy/issues/detail?id=7 (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.
Re: Issue 2216 in sympy: Module names are imported with from sympy import *
Comment #4 on issue 2216 by asmeurer: Module names are imported with from sympy import * http://code.google.com/p/sympy/issues/detail?id=2216 OK, so let's just use explicit imports in all the __init__.py files. It's more bookkeeping, but adding new functions to the namespace is a rarity so it isn't too big of a deal. Concerning your docstring, I would just replace help(ode.ode_hintname) with `help(sympy.solvers.ode.ode_hintname)`. We should neither encourage our users to do 'from sympy import *' nor assume that they have done so. That's what I was thinking we should do too. And those docstrings are also available at http://docs.sympy.org/dev/modules/solvers/ode.html#hint-methods. -- 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 1206 in sympy: Integer and Rational do not implement .args
Comment #6 on issue 1206 by ronan.l...@gmail.com: Integer and Rational do not implement .args http://code.google.com/p/sympy/issues/detail?id=1206 Why would we have Integer(42)() == 42? If you have S(42).args == () and you want S(42).func(*S(42).args) == S(42), then S(42).func(*S(42).args) == S(42).func() and ... there's a hole in my argument. OK, actually, adding the following in Atom would work: def func(self): return 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 2215 in sympy: Failures in the examples
Updates: Status: Fixed Comment #3 on issue 2215 by asmeurer: Failures in the examples http://code.google.com/p/sympy/issues/detail?id=2215 These have all been fixed at https://github.com/sympy/sympy/pull/136. -- 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 1081 in sympy: implement Degree
Comment #1 on issue 1081 by tim.la...@gmail.com: implement Degree http://code.google.com/p/sympy/issues/detail?id=1081 How would one want this implemented? I don't think we can do sin(30 Degree) easily, but we can certainly can do sin(Degree(30)). Can we create a custom operator with the name Degree? I'm not certain about this aspect of python. -- 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 1081 in sympy: implement Degree
Comment #2 on issue 1081 by matt...@gmail.com: implement Degree http://code.google.com/p/sympy/issues/detail?id=1081 See sympy.physics.units module. Can be sin(30*degree). -- 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 1081 in sympy: implement Degree
Updates: Status: Fixed Comment #3 on issue 1081 by asmeurer: implement Degree http://code.google.com/p/sympy/issues/detail?id=1081 So this is already implemented. -- 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: [sympy] Re: General Relativity package based on Sympy
Øyvind,
Here is the logic in sympy.physics.quantum that handles the
representation of abstract entities in concrete bases:
https://github.com/sympy/sympy/blob/master/sympy/physics/quantum/represent.py
I think the code the pretty general, although for now we do assume
that the representations are regular matrices (not tensors). But I
think it could be generalized quite easily (the idea is super simple).
Cheers,
Brian
On Thu, Mar 17, 2011 at 12:01 PM, Øyvind Jensen jensen.oyv...@gmail.com wrote:
to., 17.03.2011 kl. 10.35 -0700, skrev Brian Granger:
On Thu, Mar 17, 2011 at 1:34 AM, Øyvind Jensen jensen.oyv...@gmail.com
wrote:
ma., 14.03.2011 kl. 11.00 -0700, skrev Ondrej Certik:
On Mon, Mar 14, 2011 at 3:11 AM, Øyvind Jensen jensen.oyv...@gmail.com
wrote:
Alexander, All,
How is it going with your tensor implementation? I put together some
code to implement variance of tensors and uploaded it to github in my
tensor_contractions branch [0]. If you would like to build on that,
feel free to do so. If you have already made your own implementation,
please just choose whatever works best for your framework.
Here is how it works in the advertised branch:
A = IndexedBase('A')
i = VarIdx('i')
A[i.up, i.down]
A[^i, _i]
get_indices(A[i.up, i.down])
(set(), {})
get_indices(A[i.up, j.down]*x[j.up])
(set([^i]), {})
This is great! Once either of these implementations is in sympy, I'll
update the relativity example to use it.
That would be very cool! What would be a good way to connect the
abstract tensor objects to its concrete representations? Perhaps
something like sympy.utilities.implemented_function could work?
Can you say more about what you are thinking. In the quantum stuff we
now have the notion of abstract objects and then concrete
representations (in a particular basis). Would this type of thing
cary over here?
Perhaps it can be applied here, I am not sure. The current abstract
tensor objects in my branch are nothing but symbols with other symbols
attached to them as indices. Otoh, it seems like the relativity example
calculates the content of different tensors, much like the elements of
a matrix or a vector. I think that this corresponds to the
representation in a particular basis, but I don't know exactly how.
Anyway, I think it could be useful to be able to mix the perspectives,
so that an expression can be manipulated in the abstract formulation
before it is converted to a concrete expression based on the content.
Something like
def concretization_handler(inds):
# return an expression determined from the indices
g = IndexedBase('g', content=concretization_handler)
g(i.up, j.down).subs({i:0, j:1})
# Here we should get the concrete representation of g^0_1.
I am not sure how this would work, and I am also not sure yet how useful
it would be... How did you implement, and how do you use the abstract
and concrete representations in the quantum module?
Øyvind
--
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.
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgran...@calpoly.edu
elliso...@gmail.com
--
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: how to edit modules vectorization of subs
Hello Hector, limit(sin(x),x,oo) means sin(x) evaluated, as x approaches to infinity from default positive side. It is an oscillatory limit, equal to k and not k/oo, where k can be anything in [-1,1]. The answer should be Nan, and not an error, as then, sympy would be more robust, and users will be able to use the math.isnan() function to check if a limit is defined or undefined. Regards, Sherjil On Fri, Mar 18, 2011 at 2:34 PM, Hector hector1...@gmail.com wrote: On Fri, Mar 18, 2011 at 4:57 AM, Aaron S. Meurer asmeu...@gmail.comwrote: For issue 2200, we didn't decide if limit(sin(x), x, oo) should raise an error or should return nan (or something else). Hello everyone, Hi Aaron, I was wondering why limit(sin(x),x,oo) should have any other value than 0 ? Is it not equal to k/oo where k is some finite number in [-1,1], which clearly tends to zero ? Please tell me is there any flow in my thinking or if I am missing something or is it because something related to SymPy. Aaron Meurer On Mar 17, 2011, at 1:25 PM, Chris Smith wrote: SherjilOzair wrote: Mr. Ronan, You've been a great help. Please help me start up my suggesting me a small project or patch. I would be very grateful. Issue 2180, 2198 or 2200. -- 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. -- -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. -- 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: how to edit modules vectorization of subs
Hector wrote: On Fri, Mar 18, 2011 at 4:57 AM, Aaron S. Meurer asmeu...@gmail.com wrote: For issue 2200, we didn't decide if limit(sin(x), x, oo) should raise an error or should return nan (or something else). Hello everyone, Hi Aaron, I was wondering why limit(sin(x),x,oo) should have any other value than 0 ? Is it not equal to k/oo where k is some finite number in [-1,1], which clearly tends to zero ? It is sin(x), not sin(x)/x that has the problem. This continues to oscillate between `+/-1` regardless of how large x becomes. -- 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: how to edit modules vectorization of subs
On Fri, Mar 18, 2011 at 2:44 PM, Sherjil Ozair sherjiloz...@gmail.comwrote: Hello Hector, limit(sin(x),x,oo) means sin(x) evaluated, as x approaches to infinity from default positive side. My apologies. I read it as sin(x)/x . It is an oscillatory limit, equal to k and not k/oo, where k can be anything in [-1,1]. The answer should be Nan, and not an error, as then, sympy would be more robust, and users will be able to use the math.isnan() function to check if a limit is defined or undefined. But why should it be NaN? As far as my little knowledge goes, NaN should be of the form 0/0 or oo/oo or 0*oo or 0**0 or 1**oo or oo**0. http://en.wikipedia.org/wiki/NaN ( Creation ) lim(sin(x),x,oo) is definitely not any of these types. Regards, Sherjil While checking for this things, I find something really wearied. In [33]: import sympy as syp In [34]: syp.limit(syp.abs(x)/x,x,0,dir='+') Out[34]: 1 In [35]: syp.limit(syp.abs(x)/x,x,0,dir='-') Out[35]: -1 In [36]: syp.limit? Type:function Base Class:type 'function' String Form:function limit at 0x8f7b64c Namespace:Interactive File:/usr/lib/pymodules/python2.6/sympy/series/limits.py Definition:syp.limit(e, z, z0, dir='+') Docstring: Compute the limit of e(z) at the point z0. z0 can be any expression, including oo and -oo. For dir=+ (default) it calculates the limit from the right (z-z0+) and for dir=- the limit from the left (z-z0-). For infinite z0 (oo or -oo), the dir argument doesn't matter. Now mathematically, limit x tending to 0, abs(x)/x should not exist. But SymPy doesn't warn about this during its execution nor in the documentation. This might be confusing for complete beginner or in other cases. On Fri, Mar 18, 2011 at 2:34 PM, Hector hector1...@gmail.com wrote: On Fri, Mar 18, 2011 at 4:57 AM, Aaron S. Meurer asmeu...@gmail.comwrote: For issue 2200, we didn't decide if limit(sin(x), x, oo) should raise an error or should return nan (or something else). Hello everyone, Hi Aaron, I was wondering why limit(sin(x),x,oo) should have any other value than 0 ? Is it not equal to k/oo where k is some finite number in [-1,1], which clearly tends to zero ? Please tell me is there any flow in my thinking or if I am missing something or is it because something related to SymPy. Aaron Meurer On Mar 17, 2011, at 1:25 PM, Chris Smith wrote: SherjilOzair wrote: Mr. Ronan, You've been a great help. Please help me start up my suggesting me a small project or patch. I would be very grateful. Issue 2180, 2198 or 2200. -- 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. -- -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. -- 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. -- -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] Re: how to edit modules vectorization of subs
18.03.2011 12:49, Hector пишет: Now mathematically, limit x tending to 0, abs(x)/x should not exist. Why not? (tendind from the right.) Consider definition of limit: the limit of f as x approaches 0 is L if and only if for every real ε 0 there exists a real δ 0 such that 0 x δ implies | f(x) − L | ε Yes, abs(x)/x at point 0 is not well defined, but the limit with this definition still exists. The same with sin(x)/x (but in this case there is question whether this function analytical or not, abs(x)/x is not). -- Alexey U. -- 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: how to edit modules vectorization of subs
18.03.2011 12:42, Chris Smith пишет: Hector wrote: On Fri, Mar 18, 2011 at 4:57 AM, Aaron S. Meurer asmeu...@gmail.com wrote: For issue 2200, we didn't decide if limit(sin(x), x, oo) should raise an error or should return nan (or something else). Hello everyone, Hi Aaron, I was wondering why limit(sin(x),x,oo) should have any other value than 0 ? Is it not equal to k/oo where k is some finite number in [-1,1], which clearly tends to zero ? It is sin(x), not sin(x)/x that has the problem. This continues to oscillate between `+/-1` regardless of how large x becomes. According strict mathematical definition of limits at infinity limit in this case is not exists. But, the nature aim of limit is the answer what is the behavior of function in infinity. So the question is only to determine the way how to tell to the user that sin(x) has arbitary value in range [-1, 1]. I offer split into steps of realization: 1. If limit is not exist then return Non or something else It is requirement. 2. If it is possible to known range ([-1, 1]) as in the sin(x) at oo example, then return it. But it is enchantment. -- Alexey U. -- 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: how to edit modules vectorization of subs
Of course the limit exists from either direction, but I think his point is that it doesn't exist in the normal sense (from any direction). The real definition of a limit says that |x| δ, i.e., -δ x δ, implies |f(x) - L| ε. Actually, SymPy computes limits from a single direction (from the right by default). I think there was an issue once to implement limit from both directions (it would basically check '+' and '-' and return the result only if they matched), but I can't find it now. Aaron Meurer On Mar 18, 2011, at 4:04 AM, Alexey U. Gudchenko wrote: 18.03.2011 12:49, Hector пишет: Now mathematically, limit x tending to 0, abs(x)/x should not exist. Why not? (tendind from the right.) Consider definition of limit: the limit of f as x approaches 0 is L if and only if for every real ε 0 there exists a real δ 0 such that 0 x δ implies | f(x) − L | ε Yes, abs(x)/x at point 0 is not well defined, but the limit with this definition still exists. The same with sin(x)/x (but in this case there is question whether this function analytical or not, abs(x)/x is not). -- Alexey U. -- 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: how to edit modules vectorization of subs
On Fri, Mar 18, 2011 at 3:34 PM, Alexey U. Gudchenko pr...@goodok.ruwrote: 18.03.2011 12:49, Hector пишет: Now mathematically, limit x tending to 0, abs(x)/x should not exist. Why not? (tendind from the right.) Consider definition of limit: the limit of f as x approaches 0 is L if and only if for every real ε 0 there exists a real δ 0 such that 0 x δ implies | f(x) − L | ε Hi Alexey, When we say - the limit of f as x *approaches* 0 , we are allowing x to approach 0 from any side. ( Here are only two ways of approaching to 0 viz '+ve' and '-ve' but its not true always. For function f(x,y) there are infinitely many ways of approaching to (0,0)). So when x approaches from +ve side the value of function will approach to +1 and when it approaches from -ve side the value of function approaches to -1 and you will never be able to find L in your definition. Hope the attachment will make my point clear. Yes, abs(x)/x at point 0 is not well defined, but the limit with this definition still exists. I agree with u here. Thats the whole point of defining limit in practical world The same with sin(x)/x (but in this case there is question whether this function analytical or not, abs(x)/x is not). I actually didn't get what exactly you are trying to convey. Can you please elaborate? -- Alexey U. -- 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. -- -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. attachment: sign.png
Re: [sympy] Re: how to edit modules vectorization of subs
18.03.2011 13:23, Aaron S. Meurer пишет: Of course the limit exists from either direction, but I think his point is that it doesn't exist in the normal sense (from any direction). The real definition of a limit says that |x| δ, i.e., -δ x δ, implies |f(x) - L| ε. Actually, SymPy computes limits from a single direction (from the right by default). I think there was an issue once to implement limit from both directions (it would basically check '+' and '-' and return the result only if they matched), but I can't find it now. Aaron Meurer As I understand smichr/2084 is merged with master already? So in master branch it is ok now: In [2]: limit(abs(x)/x, x, 0, dir=+) Out[2]: 1 In [3]: limit(abs(x)/x, x, 0, dir=-) Out[3]: -1 -- Alexey U. -- 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: how to edit modules vectorization of subs
18.03.2011 13:26, Hector пишет: On Fri, Mar 18, 2011 at 3:34 PM, Alexey U. Gudchenkopr...@goodok.ruwrote: 18.03.2011 12:49, Hector пишет: Now mathematically, limit x tending to 0, abs(x)/x should not exist. Why not? (tendind from the right.) Consider definition of limit: the limit of f as x approaches 0 is L if and only if for every real ε 0 there exists a real δ 0 such that 0 x δ implies | f(x) − L | ε Hi Alexey, Hi, When we say - the limit of f as x *approaches* 0 , we are allowing x to approach 0 from any side. ( Here are only two ways of approaching to 0 viz '+ve' and '-ve' but its not true always. For function f(x,y) there are infinitely many ways of approaching to (0,0)). Yes, it is a complexity (which involve Directional derivative, or Directional limit) in case of many variable. Now in sympy only right and left limits as you cited: For dir=+ (default) it calculates the limit from the right So when x approaches from +ve side the value of function will approach to +1 and when it approaches from -ve side the value of function approaches to -1 and you will never be able to find L in your definition. Hope the attachment will make my point clear. Now implemented dir=+ as default (in master branch of git repository): In [2]: limit(abs(x)/x, x, 0) Out[2]: 1 In [3]: limit(abs(x)/x, x, 0, dir=-) Out[3]: -1 From your remarks I see that you want to define dir=unknown or dir=both as default. And in this case of 'dir' limit should return None for abs(x)/x (when result differ between dir=- and dir=+). Right? -- Alexey U. -- 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: how to edit modules vectorization of subs
18.03.2011 13:23, Aaron S. Meurer пишет: Of course the limit exists from either direction, but I think his point is that it doesn't exist in the normal sense (from any direction). The real definition of a limit says that |x| δ, i.e., -δ x δ, implies |f(x) - L| ε. Actually, SymPy computes limits from a single direction (from the right by default). I think there was an issue once to implement limit from both directions (it would basically check '+' and '-' and return the result only if they matched), but I can't find it now. Aaron Meurer Sorry, I have not understand instantly what you mean. But in the message to Hecter it seems that I understand what you mean indeed: From your remarks I see that you want to define dir=unknown or dir=both as default. And in this case of 'dir' limit should return None for abs(x)/x (when result differ between dir=- and dir=+). Right? -- Alexey U. -- 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: how to edit modules vectorization of subs
On Fri, Mar 18, 2011 at 4:14 PM, Alexey U. Gudchenko pr...@goodok.ruwrote: 18.03.2011 13:26, Hector пишет: On Fri, Mar 18, 2011 at 3:34 PM, Alexey U. Gudchenkopr...@goodok.ru wrote: 18.03.2011 12:49, Hector пишет: Now mathematically, limit x tending to 0, abs(x)/x should not exist. Why not? (tendind from the right.) Consider definition of limit: the limit of f as x approaches 0 is L if and only if for every real ε 0 there exists a real δ 0 such that 0 x δ implies | f(x) − L | ε Hi Alexey, Hi, When we say - the limit of f as x *approaches* 0 , we are allowing x to approach 0 from any side. ( Here are only two ways of approaching to 0 viz '+ve' and '-ve' but its not true always. For function f(x,y) there are infinitely many ways of approaching to (0,0)). Yes, it is a complexity (which involve Directional derivative, or Directional limit) in case of many variable. Now in sympy only right and left limits as you cited: For dir=+ (default) it calculates the limit from the right So when x approaches from +ve side the value of function will approach to +1 and when it approaches from -ve side the value of function approaches to -1 and you will never be able to find L in your definition. Hope the attachment will make my point clear. Now implemented dir=+ as default (in master branch of git repository): In [2]: limit(abs(x)/x, x, 0) Out[2]: 1 In [3]: limit(abs(x)/x, x, 0, dir=-) Out[3]: -1 From your remarks I see that you want to define dir=unknown or dir=both as default. And in this case of 'dir' limit should return None for abs(x)/x (when result differ between dir=- and dir=+). Right? Yes, exactly. It seems more consistent that way. Has this issue already been discussed? If not, do we need to report this? Since I am looking forward to apply for GSoC, and would love to work with SymPy, this would be good start for me. If core developers/contributors agree, I would like to work on this regardless GSoC. Because with thing implemented, we can never go for limit of multi-variable functions. -- Alexey U. -- 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. -- -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] Re: how to edit modules vectorization of subs
18.03.2011 13:59, Hector пишет:
On Fri, Mar 18, 2011 at 4:14 PM, Alexey U. Gudchenkopr...@goodok.ruwrote:
From your remarks I see that you want to define dir=unknown or dir=both
as default. And in this case of 'dir' limit should return None for
abs(x)/x (when result differ between dir=- and dir=+). Right?
Yes, exactly.
It seems more consistent that way. Has this issue already been discussed? If
not, do we need to report this?
Since I am looking forward to apply for GSoC, and would love to work with
SymPy, this would be good start for me.
If core developers/contributors agree, I would like to work on this
regardless GSoC. Because with thing implemented, we can never go for limit
of multi-variable functions.
I don't know now the situation with organization of limit's branches
exactly (on some of them the job can be proceeding now).
Chris Smith or others can up to date about it.
And, as I understand, the algorithm of this behavior implementation
seems to be easy in real axes - it differ dir=+ and dir=-.
And, we must determine a little things, which variant is more convenient:
dir=unknown | both | any
I tend to unknown, any (keeping in mind multi variable case), though
one can imagine further the distinguish between any and unknown:
limit(abs(x)/x, x, 0, dir=+)
1
limit(abs(x)/x, x, 0, dir=unknown)
None
limit(abs(x)/x, x, 0, dir=any)
[{-1: dir=-}, {1: dir=+] # something like cases as Piecewise
(But towards to the future for multi variable cases, and *even for
complex variable* the algorithm it seems should be more intelligent)
That is all what I can write about this theme.
I think in a few hours, after others will add some remarks, issues will
be ready.
--
Alexey U.
--
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] Sets in sympy
The Set class of sympy is not complete. I plan to add a full FiniteSet class functionality which will inherit the Set class, we can also have an InfiniteSet abstract class later which Interval and Union can inherit. A FiniteSet would behave something like this, a=Set([1,2,3,4,5]) b=Set([4,5,6,7]) c=a+b // or c=a.union(b) print c [1,2,3,4,5,6] and similar behavior for intersection, complement, contains functions. Feel free to suggest me more features. With a good polys class, we can also add conversion from set-builder notation to list notation. I ask more experienced developers to tell me if there is any design flaw in this. I need the go-ahead to start coding this class. Thanks, Sherjil -- 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] Sets in sympy
Hello.
That's a good idea but you will have to explain what you mean by infinite
sets.
An easy task is to produce something for the reunions of intervals which can
contain {a} = [a, a].
I've made an incomplete code so as to work with intervals (I'm not sure that
all the classes work well). Feel free to correct it, and adapt and port it
to sympy.
Christophe BAL
=== My code - START ===
#!/usr/bin/env python
#coding=utf-8
# Code writing by BAL Christophe
# Mail : pyban...@gmail.com
def endPointsToUser(europeanEndpoints, notation):
# Lines automatically built by tool_simpleSets.py. = START
epEuropean_2_User = {}
# AM-erican notations.
epEuropean_2_User['am'] = {']]': '(]', '[[': '[)', '[]': '[]', '][':
'()'}
# CZ-ech notations.
epEuropean_2_User['cz'] = {']]': '(', '[[': ')', '[]': '', '][':
'()'}
# EU-ropean notations.
epEuropean_2_User['eu'] = {'[[': '[[', ']]': ']]', '][': '][', '[]':
'[]'}
# Lines automatically built by tool_simpleSets.py. = END
return epEuropean_2_User[notation][europeanEndpoints]
class Interval():
def __init__(self, minPoint=0, maxPoint=0, endpoints='', notation =
'am'):
# Lines automatically built by tool_simpleSets.py. = START
epNotationIsValid = {}
epUser_2_European = {}
# AM-erican notations.
epNotationIsValid['am'] = ['[]', '(]', '[)', '()']
epUser_2_European['am'] = [{'(': ']', '[': '['}, {')': '[', ']':
']'}]
# CZ-ech notations.
epNotationIsValid['cz'] = ['', '(', ')', '()']
epUser_2_European['cz'] = [{'(': ']', '': '['}, {')': '[', '':
']'}]
# EU-ropean notations.
epNotationIsValid['eu'] = ['[]', ']]', '[[', '][']
epUser_2_European['eu'] = [{'[': '[', ']': ']'}, {'[': '[', ']':
']'}]
# Lines automatically built by tool_simpleSets.py. = END
self.notation = notation
# An empty set ?
if endpoints == '':
minPoint = 0
minPoint = 0
endpoints = endPointsToUser('][', self.notation)
if minPoint=='+inf':
raise TypeError('The first value ' + str(minPoint) + ' is not
lower or equal to the second one ' + str(maxPoint) + '.')
elif maxPoint=='-inf':
raise TypeError('The first value ' + str(minPoint) + ' is not
lower or equal to the second one ' + str(maxPoint) + '.')
elif minPoint != '-inf' and maxPoint != '+inf':
if minPoint maxPoint:
raise TypeError('The first value ' + str(minPoint) + ' is
not lower or equal to the second one ' + str(maxPoint) + '.')
self.minPoint = minPoint
self.maxPoint = maxPoint
self.endpoints = endpoints
if self.endpoints not in epNotationIsValid[self.notation]:
raise TypeError('Unknown endpoints of interval : ' +
str(endpoints) + '')
# In the code we are gonning to work with the european notations.
if self.notation == 'eu':
self.europeanEndpoints = self.endpoints
else:
self.europeanEndpoints =
epUser_2_European[self.notation][0][self.endpoints[0]] +
epUser_2_European[self.notation][1][self.endpoints[1]]
#print 'self.notation = ' + self.notation
#print 'self.endpoints = ' + self.endpoints
#print 'self.europeanEndpoints = ' + self.europeanEndpoints
def __str__(self):
if self.minPoint == self.maxPoint:
if self.europeanEndpoints == '[]':
return '{' + str(self.minPoint) + '}'
else:
return 'Empty Set'
return self.endpoints[0] + str(self.minPoint) + ';' +
str(self.maxPoint) + self.endpoints[1]
# Thanks to Nicolas we explain me this trick.
@property
def isEmpty(self):
return str(self) == 'Empty Set'
def __and__(self, otherInterval):
# We reimplement the use of .
# The intersection is empty.
if self.isEmpty or otherInterval.isEmpty:
return Interval()
maxOfminPoints = max(self.minPoint, otherInterval.minPoint)
minOfmaxPoints = min(self.maxPoint, otherInterval.maxPoint)
if maxOfminPoints minOfmaxPoints:
return Interval()
# The intersection could be a set with a single element.
if minOfmaxPoints == maxOfminPoints:
if self.maxPoint == minOfmaxPoints:
if self.europeanEndpoints[1] == '[' or
otherInterval.europeanEndpoints[0] ==']':
return Interval()
else:
return Interval(minOfmaxPoints, minOfmaxPoints,
endPointsToUser('[]', self.notation), self.notation)
else:
if self.europeanEndpoints[0] == ']' or
otherInterval.europeanEndpoints[1] =='[':
return Interval()
else:
return Interval(minOfmaxPoints, minOfmaxPoints,
endPointsToUser('[]', self.notation), self.notation)
# What is the endpoints of the intersection ?
interEndPtMin = '['
if self.minPoint == maxOfminPoints :
Re: [sympy] Re: how to edit modules vectorization of subs
Actually, SymPy computes limits from a single direction (from the right by default). I think there was an issue once to implement limit from both directions (it would basically check '+' and '-' and return the result only if they matched), but I can't find it now. You have a better memory for these things than me, but I wonder if you would have seen an implementation of the checking of roots for equations that I did where I used this sort of approach (as I recall). /c -- You received this message because you are subscribed to the Google Groups sympy group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
[sympy] Introduction as a perspective student for GSoC
Hello everyone, My name is Prafullkumar P. Tale. I am a 4th year student at Indian Institute of Technology Roorkee, doing 5 years Integrated M.Sc. in Applied Mathematics. ( It is an integrated course offering graduate and post graduate degree with Math major). My area of interest lies preliminary in algorithms. I like coding for mathematical problems and spend most of my time for the same. Initially I stepped on wrong foot and started coding in MatLab. I spend 11/2 year, before finally switching to Python. I love Python. After attending Sage Days 25, India and SciPy 2010,India, I became a big fan of open source and would like to contribute back. I think GSoC would give me a structured platform and other incentives to work for open source projects. I would like to work for SymPy as it gives me an opportunity to work closely with mathematical concepts rather than solely coding. The projects ideas I am going through are- - improve the integration algorithm - definite integration integration on complex plane using residues - improve polynomial algorithms - implement efficient multivariate polynomials - improve simplification and term rewriting algorithms - implement symbolic global optimization (value, argument) with/without constraints - *improve the plotting module*s - generalized functions -- Dirac delta, P(1/x), etc... Convolution, Fourier and Laplace transforms - ordinary and partial differential equations - improve SymPy's interoperability with other CAS software I had one or two courses in most of the topics during my academic studies and worked with Sage, NumPy, matplotlib,etc. I am working to know how much I can implement in SymPy before finalizing my topic. I am following the directions/guidelines given to Sherjil Ozair in recent posts and I am thankful for that. If there are additional things, please let me know. Some of my earlier work can also be seen at - https://github.com/hector1618. Thanking you for your time. -- -Regards Hector Whenever you think you can or you can't, in either way you are right. P.S. - I often use Hector as my nickname. -- 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] numpy array for sympy
Hi, I'm working on a small base implementation of numpy-style array for sympy. Currently I've added component-wise addition, subtraction, multiplication, mult by integer. I've uploaded the code on GitHub. Here are some points of discussion. 1) If unequal-sized arrays are added, should an error be raised or should they still be force-added taking the missing elements as zero ? 2) Multiplication of two linear arrays should give another linear array, with component-wise multiplication ? Or an array of 2-tuples, like one does with Sets ? 3) If using component-wise multiplication, for unequal arrays, should the missing elements be taken as one ? Or should an error be raised ? 4) Power will be done component-wise ? But this depends on the answer to point 2. 5) Any more features ? Thanks, Sherjil Ozair -- 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] numpy array for sympy
18.03.2011 20:19, Sherjil Ozair пишет: This is the code with a few basic examples. The implementation is just a basic one. Please tell me if you want me to git this too. If so, please tell me where to git it ? If shortly: [1] http://help.github.com/pull-requests/ [2] http://help.github.com/fork-a-repo/ -- 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 Project
A possible suggestion for GSOC would be to looking into incorporating pydx - http://gr.anu.edu.au/svn/people/sdburton/pydx/doc/index.html into sympy. -- 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 Project
Le vendredi 18 mars 2011 à 16:05 -0400, Alan Bromborsky a écrit : A possible suggestion for GSOC would be to looking into incorporating pydx - http://gr.anu.edu.au/svn/people/sdburton/pydx/doc/index.html into sympy. pydx is GPL, so it can't be incorporated into sympy. -- 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 Project
On 03/18/2011 04:24 PM, Ronan Lamy wrote: Le vendredi 18 mars 2011 à 16:05 -0400, Alan Bromborsky a écrit : A possible suggestion for GSOC would be to looking into incorporating pydx - http://gr.anu.edu.au/svn/people/sdburton/pydx/doc/index.html into sympy. pydx is GPL, so it can't be incorporated into sympy. I was thinking of implementing the methods not incorporating the code. -- 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: how to edit modules vectorization of subs
On Mar 18, 2011, at 4:18 AM, Alexey U. Gudchenko wrote: 18.03.2011 12:42, Chris Smith пишет: Hector wrote: On Fri, Mar 18, 2011 at 4:57 AM, Aaron S. Meurer asmeu...@gmail.com wrote: For issue 2200, we didn't decide if limit(sin(x), x, oo) should raise an error or should return nan (or something else). Hello everyone, Hi Aaron, I was wondering why limit(sin(x),x,oo) should have any other value than 0 ? Is it not equal to k/oo where k is some finite number in [-1,1], which clearly tends to zero ? It is sin(x), not sin(x)/x that has the problem. This continues to oscillate between `+/-1` regardless of how large x becomes. According strict mathematical definition of limits at infinity limit in this case is not exists. But, the nature aim of limit is the answer what is the behavior of function in infinity. So the question is only to determine the way how to tell to the user that sin(x) has arbitary value in range [-1, 1]. I offer split into steps of realization: 1. If limit is not exist then return Non or something else It is requirement. 2. If it is possible to known range ([-1, 1]) as in the sin(x) at oo example, then return it. But it is enchantment. -- Alexey U. I agree that returning nan is better than raising an error. As to returning the range, I think it requires some more thought. If limit() return a Set object instead of an expression, then that might break a lot of things that expect an expression. Also, there are some other questions: - How exactly are we defining the set returned. Is it a tight bound set as the function goes to infinity, or is it just the closed set [lim inf f(x), lim sup f(x)]? The two are the same if the function is continuous, but for a counterexample, consider a combination of two of the functions discussed in this thread, abs(sin(x))/sin(x). This function takes on values of 1 and −1 forever to infinity. Would limit(abs(sin(x))/sin(x)) return [-1, 1] or set([-1, 1])? - Are there any algorithms to compute these things? - What does the interface look like? 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.
Re: [sympy] Re: how to edit modules vectorization of subs
Yes, exactly. It seems more consistent that way. Has this issue already been discussed? If not, do we need to report this? Since I am looking forward to apply for GSoC, and would love to work with SymPy, this would be good start for me. If core developers/contributors agree, I would like to work on this regardless GSoC. Because with thing implemented, we can never go for limit of multi-variable functions. -- -Regards Hector Whenever you think you can or you can't, in either way you are right. Search the issues, and if you can't find it, go ahead and open a new one. I remember suggesting this before in the issues, but it might have just been in a comment. By the way, we look forward to seeing you apply for GSoC! 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.
[sympy] Google Sumer of Code Acceptance!
Hi. As some of you have already noticed, we have ben accepted into the Google Summer of Code as a mentoring organization. Although we have participated in the past under the umbrella of other mentoring organizations like the Python Software Foundation and Portland State University, this is the first time we have been accepted as an organization. This is a very big step for SymPy. I would like to thank everyone who helped with the application process. In case you don't know, Google Summer of Code is a program run by Google every year where they pay college students all around the world to write code for open source projects. Each student has a mentor assigned to him/her, who helps the student get started with interacting with open source (most students who are accepted have never participated in open source before). So now that were are accepted, students are open to applications. The actual application period opens on March 28, and closes on April 8 (see http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline). To students: If you are interested in applying, please write the to mailing list and introduce yourself. The program is open to anyone worldwide who is 18 years of age or older who is enrolled in a higher education institution (this includes undergraduate and graduate). If you are interested in applying, here is what you should do (if you have not already): - As I said above, write to the list and introduce yourself. You might also join our IRC channel, which is #sympy on freenode. - Start thinking about what you want to apply to do. Our ideas page is at https://github.com/sympy/sympy/wiki/GSoC-2011-Ideas. However, we are open to ideas that are not on that page. Anything that fits in a computer algebra system would fit in SymPy. If you have an idea not on that page, please discuss it on our mailing list, so we can see if it has not already be implemented, and if it is fitting for SymPy and for a project. I recommend you apply to do something that you are interested in personally. - We require for any student to be accepted that he/she submit at least one patch to SymPy, which gets reviewed and pushed in. See http://code.google.com/p/sympy/issues/list?can=2q=label%3AEasyToFix for some easy to fix issues that are a good place to start. Don't worry if you do not know how to send in a patch or use git. We will help you (that is the whole point of the program). Just ask here, on the issue page, or on IRC. - You should start thinking about your application. Our template is at https://github.com/sympy/sympy/wiki/GSoC-2011-Application-Template (it will also soon be at our page on the Google site). If you like, you can start a page on our wiki to write your proposal. If you do this, we will help you edit it (though understand that we will not help you write it). Remember that we want you to get accepted just as much as you do, so you can help improve SymPy! To SymPy developers: - We need people who are willing to mentor students. If you are willing to mentor, please add your name to the bottom of the page at https://github.com/sympy/sympy/wiki/GSoC-2011-ideas. - Please edit the ideas page to improve formatting and add new ideas. Good luck to all students who plan on 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.
Re: [sympy] GSOC Project
Go ahead and add it to the ideas page at https://github.com/sympy/sympy/wiki/GSoC-2011-ideas. Aaron Meurer On Mar 18, 2011, at 2:43 PM, Alan Bromborsky wrote: On 03/18/2011 04:24 PM, Ronan Lamy wrote: Le vendredi 18 mars 2011 à 16:05 -0400, Alan Bromborsky a écrit : A possible suggestion for GSOC would be to looking into incorporating pydx - http://gr.anu.edu.au/svn/people/sdburton/pydx/doc/index.html into sympy. pydx is GPL, so it can't be incorporated into sympy. I was thinking of implementing the methods not incorporating the code. -- 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] Sets in sympy
Hi. This sounds like it could be a useful project, especially the support for infinite sets. For example, we could add support to solve() to return infinite solutions (like sin(x) = 0, or non-zero dimensional polynomial systems). We already have some sets implemented (intervals). On Mar 18, 2011, at 5:47 AM, SherjilOzair wrote: The Set class of sympy is not complete. I plan to add a full FiniteSet class functionality which will inherit the Set class, we can also have an InfiniteSet abstract class later which Interval and Union can inherit. A FiniteSet would behave something like this, a=Set([1,2,3,4,5]) b=Set([4,5,6,7]) c=a+b // or c=a.union(b) print c [1,2,3,4,5,6] and similar behavior for intersection, complement, contains functions. Feel free to suggest me more features. With a good polys class, we can also add conversion from set-builder notation to list notation. I ask more experienced developers to tell me if there is any design flaw in this. I need the go-ahead to start coding this class. I think you haven't given too much information yet on how you plan on designing this. So far, I think that the basic ideas are good. Aaron Meurer Thanks, Sherjil -- 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] Introduction as a perspective student for GSoC
Hi. We look forward to seeing your application. I recommend that you pick one or two of the below and stick with those. It is more important to write a high quality application than to submit many of them. I recommend doing a project that interests you the most. Also, doing projects for which you have prior mathematical background is also a good idea. So I recommend that you pick the one or two projects from your list that interest you the most and look at the code to see exactly what needs to be done, and start to develop a plan on how you plan to implement it. You should also discuss this with us on the list so you make sure your ideas of how to implement it match ours. You should do this now so that you have time to write your application (April 8 will come sooner than you think). Finally, in case you did not already know, we require all students to submit at least one patch to the project that gets accepted and pushed in. Since you clearly already know how to use git and GitHub, you should know that the best way to do this is to submit a pull request to SymPy on GitHub. Aaron Meurer On Mar 18, 2011, at 8:33 AM, Hector wrote: Hello everyone, My name is Prafullkumar P. Tale. I am a 4th year student at Indian Institute of Technology Roorkee, doing 5 years Integrated M.Sc. in Applied Mathematics. ( It is an integrated course offering graduate and post graduate degree with Math major). My area of interest lies preliminary in algorithms. I like coding for mathematical problems and spend most of my time for the same. Initially I stepped on wrong foot and started coding in MatLab. I spend 11/2 year, before finally switching to Python. I love Python. After attending Sage Days 25, India and SciPy 2010,India, I became a big fan of open source and would like to contribute back. I think GSoC would give me a structured platform and other incentives to work for open source projects. I would like to work for SymPy as it gives me an opportunity to work closely with mathematical concepts rather than solely coding. The projects ideas I am going through are- improve the integration algorithm definite integration integration on complex plane using residues improve polynomial algorithms implement efficient multivariate polynomials improve simplification and term rewriting algorithms implement symbolic global optimization (value, argument) with/without constraints improve the plotting modules generalized functions -- Dirac delta, P(1/x), etc... Convolution, Fourier and Laplace transforms ordinary and partial differential equations improve SymPy's interoperability with other CAS software I had one or two courses in most of the topics during my academic studies and worked with Sage, NumPy, matplotlib,etc. I am working to know how much I can implement in SymPy before finalizing my topic. I am following the directions/guidelines given to Sherjil Ozair in recent posts and I am thankful for that. If there are additional things, please let me know. Some of my earlier work can also be seen at - https://github.com/hector1618. Thanking you for your time. -- -Regards Hector Whenever you think you can or you can't, in either way you are right. P.S. - I often use Hector as my nickname. -- 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] numpy array for sympy
On Mar 18, 2011, at 11:53 AM, Alexey U. Gudchenko wrote:
18.03.2011 19:42, SherjilOzair пишет:
Hi,
Good evening.
I'm working on a small base implementation of numpy-style array for
sympy.
Currently I've added component-wise addition, subtraction,
multiplication, mult by integer. I've uploaded the code on GitHub.
Where is it?
Here are some points of discussion.
1) If unequal-sized arrays are added, should an error be raised or
should they still be force-added taking the missing elements as zero ?
2) Multiplication of two linear arrays should give another linear
array, with component-wise multiplication ? Or an array of 2-tuples,
like one does with Sets ?
3) If using component-wise multiplication, for unequal arrays, should
the missing elements be taken as one ? Or should an error be raised ?
4) Power will be done component-wise ? But this depends on the answer
to point 2.
5) Any more features ?
Thanks,
Sherjil Ozair
Sorry, I can entangle you, but:
May be it would be helpful for answering of your questions if the aims of
'numpy-style array' would be more clear (for me at least, I can't find
issues, aims or description of 'numpy-style array').
The purpose is to implement a basic version of numpy in sympy so that you do
not have to install numpy to use the basic array feature. Since numpy has to
be compiled, this will be very useful, since, for example, you can't install it
on the Google App Engine. Therefore, the implementation in SymPy should match
the numpy implementation.
Aaron Meurer
I can be mistaken, but as I understand the situation is that in sympy now
numpy.array is wildly used. But the roadmap is to replace it in core by pure
python implementation, (all that is related with symbolic calculations).
'numpy' now is used internally in matrices, linear algebra, indexes.
(Especially arrays related with indexes).
So, if this aim is true, it must be toke into consideration how numpy.array
used in sympy now. And what the multiplication f.e. is must (I think that
like a 'numpy')
Another possible aim is to use the 'array' object in sympy (instead numpy),
in command line interface ('isympy') too.
But even in this case, the behavior of this 'array' expected to be as numpy
too.
Formally, array is not related with mathematics, but indexes, linear
algebra, matricex are, and they now present in core somehow, btw.
So we must avoid the mixing of works with array and so on.
P.S.
Additionally, if you interesting, in sympy there are no mathematical Sequence
object [1].
It can be infinite (double sides) or finite. One dimension only.
Operation of multiplication are element wise (by default), but Cauchy product
must be implemented as separated method.
So it is the answer for your 2) in this case.
The answer 3): zero.
And for 5) I can write a lot (convergence, recurrence, other operations) that
are needed for series polishing.
[1] http://en.wikipedia.org/wiki/Sequence
--
Alexey U.
--
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] numpy array for sympy
On Fri, Mar 18, 2011 at 17:04, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 18, 2011, at 11:53 AM, Alexey U. Gudchenko wrote: 18.03.2011 19:42, SherjilOzair пишет: Hi, Good evening. I'm working on a small base implementation of numpy-style array for sympy. Currently I've added component-wise addition, subtraction, multiplication, mult by integer. I've uploaded the code on GitHub. Where is it? Here are some points of discussion. 1) If unequal-sized arrays are added, should an error be raised or should they still be force-added taking the missing elements as zero ? 2) Multiplication of two linear arrays should give another linear array, with component-wise multiplication ? Or an array of 2-tuples, like one does with Sets ? 3) If using component-wise multiplication, for unequal arrays, should the missing elements be taken as one ? Or should an error be raised ? 4) Power will be done component-wise ? But this depends on the answer to point 2. 5) Any more features ? Thanks, Sherjil Ozair Sorry, I can entangle you, but: May be it would be helpful for answering of your questions if the aims of 'numpy-style array' would be more clear (for me at least, I can't find issues, aims or description of 'numpy-style array'). The purpose is to implement a basic version of numpy in sympy so that you do not have to install numpy to use the basic array feature. Since numpy has to be compiled, this will be very useful, since, for example, you can't install it on the Google App Engine. Therefore, the implementation in SymPy should match the numpy implementation. That's not very informative. numpy ndarrays have a *lot* of functionality attached to them. It's a major project, beyond the capabilities and resources of a single GSoC student, to match *all* of their functionality. You need to clearly state exactly what features of numpy ndarrays you want duplicated. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- 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] numpy array for sympy
On Mar 18, 2011, at 4:13 PM, Robert Kern wrote: On Fri, Mar 18, 2011 at 17:04, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 18, 2011, at 11:53 AM, Alexey U. Gudchenko wrote: 18.03.2011 19:42, SherjilOzair пишет: Hi, Good evening. I'm working on a small base implementation of numpy-style array for sympy. Currently I've added component-wise addition, subtraction, multiplication, mult by integer. I've uploaded the code on GitHub. Where is it? Here are some points of discussion. 1) If unequal-sized arrays are added, should an error be raised or should they still be force-added taking the missing elements as zero ? 2) Multiplication of two linear arrays should give another linear array, with component-wise multiplication ? Or an array of 2-tuples, like one does with Sets ? 3) If using component-wise multiplication, for unequal arrays, should the missing elements be taken as one ? Or should an error be raised ? 4) Power will be done component-wise ? But this depends on the answer to point 2. 5) Any more features ? Thanks, Sherjil Ozair Sorry, I can entangle you, but: May be it would be helpful for answering of your questions if the aims of 'numpy-style array' would be more clear (for me at least, I can't find issues, aims or description of 'numpy-style array'). The purpose is to implement a basic version of numpy in sympy so that you do not have to install numpy to use the basic array feature. Since numpy has to be compiled, this will be very useful, since, for example, you can't install it on the Google App Engine. Therefore, the implementation in SymPy should match the numpy implementation. That's not very informative. numpy ndarrays have a *lot* of functionality attached to them. It's a major project, beyond the capabilities and resources of a single GSoC student, to match *all* of their functionality. You need to clearly state exactly what features of numpy ndarrays you want duplicated. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco Well, it was Ondrej's idea. Probably he could explain what he wants to see implemented better. 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.
[sympy] Potential student for GSoC (Symbolic QM)
Hello everyone, My name is Tomo Lazovich and I'm a senior Physics major (CS minor) at Harvard. I'm really interested in getting involved with sympy through Google Summer of Code, particularly the suggested project of symbolic quantum mechanics in SymPy. I tried to follow this link (http:// github.com/ellisonbg/sympy/tree/quantum) to see the sketched out design for the abstract dirac notation implementation, but it seems to be broken for me. Could someone point me to an updated link? On another note, does anyone here have more general advice for applying to the GSoC program? I love projects at the intersection of physics and CS and I'm really enthusiastic about having the chance to work on this. Any help at all would be greatly appreciated. Thanks so much! Tomo Lazovich -- 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] Google Sumer of Code Acceptance!
On Fri, Mar 18, 2011 at 2:26 PM, Aaron S. Meurer asmeu...@gmail.com wrote: Hi. As some of you have already noticed, we have ben accepted into the Google Summer of Code as a mentoring organization. Although we have participated in the past under the umbrella of other mentoring organizations like the Python Software Foundation and Portland State University, this is the first time we have been accepted as an organization. This is a very big step for SymPy. And also the Space Telescope Science Institute in 2007. I would like to thank everyone who helped with the application process. Indeed, this is terrific news. After 4 years of hard work, we got our chance now to be a standalone GSoC organization. That is a big honor (and also a big responsibility). Now it is up to us to make this the best GSoC summer ever. And I am sure we will do our best. In case you don't know, Google Summer of Code is a program run by Google every year where they pay college students all around the world to write code for open source projects. Each student has a mentor assigned to him/her, who helps the student get started with interacting with open source (most students who are accepted have never participated in open source before). So now that were are accepted, students are open to applications. The actual application period opens on March 28, and closes on April 8 (see http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline). To students: If you are interested in applying, please write the to mailing list and introduce yourself. The program is open to anyone worldwide who is 18 years of age or older who is enrolled in a higher education institution (this includes undergraduate and graduate). If you are interested in applying, here is what you should do (if you have not already): - As I said above, write to the list and introduce yourself. You might also join our IRC channel, which is #sympy on freenode. - Start thinking about what you want to apply to do. Our ideas page is at https://github.com/sympy/sympy/wiki/GSoC-2011-Ideas. However, we are open to ideas that are not on that page. Anything that fits in a computer algebra system would fit in SymPy. If you have an idea not on that page, please discuss it on our mailing list, so we can see if it has not already be implemented, and if it is fitting for SymPy and for a project. I recommend you apply to do something that you are interested in personally. - We require for any student to be accepted that he/she submit at least one patch to SymPy, which gets reviewed and pushed in. See http://code.google.com/p/sympy/issues/list?can=2q=label%3AEasyToFix for some easy to fix issues that are a good place to start. Don't worry if you do not know how to send in a patch or use git. We will help you (that is the whole point of the program). Just ask here, on the issue page, or on IRC. - You should start thinking about your application. Our template is at https://github.com/sympy/sympy/wiki/GSoC-2011-Application-Template (it will also soon be at our page on the Google site). If you like, you can start a page on our wiki to write your proposal. If you do this, we will help you edit it (though understand that we will not help you write it). Remember that we want you to get accepted just as much as you do, so you can help improve SymPy! To SymPy developers: - We need people who are willing to mentor students. If you are willing to mentor, please add your name to the bottom of the page at https://github.com/sympy/sympy/wiki/GSoC-2011-ideas. - Please edit the ideas page to improve formatting and add new ideas. If you are a sympy developer, unless you want to apply as a student, definitely sign up as a mentor --- you are not committing yourself to anything, if you are busy, you can just hang around. But if you have some time to spare, we will need help with reviewing applications, and even if you don't plan to be mentoring a project during the summer, you can still help us with the selection process, and it would be greatly appreciated. Then of course we will also need mentors for the actual projects. Simply get in touch with Aaron or me, and send us your link_id to google melange. Good luck to all students who plan on applying! Good luck. If you have any questions, just ask. Ondrej -- 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] Google Sumer of Code Acceptance!
On Mar 18, 2011, at 9:16 PM, Ondrej Certik wrote: On Fri, Mar 18, 2011 at 2:26 PM, Aaron S. Meurer asmeu...@gmail.com wrote: Hi. As some of you have already noticed, we have ben accepted into the Google Summer of Code as a mentoring organization. Although we have participated in the past under the umbrella of other mentoring organizations like the Python Software Foundation and Portland State University, this is the first time we have been accepted as an organization. This is a very big step for SymPy. And also the Space Telescope Science Institute in 2007. I would like to thank everyone who helped with the application process. Indeed, this is terrific news. After 4 years of hard work, we got our chance now to be a standalone GSoC organization. That is a big honor (and also a big responsibility). Now it is up to us to make this the best GSoC summer ever. And I am sure we will do our best. In case you don't know, Google Summer of Code is a program run by Google every year where they pay college students all around the world to write code for open source projects. Each student has a mentor assigned to him/her, who helps the student get started with interacting with open source (most students who are accepted have never participated in open source before). So now that were are accepted, students are open to applications. The actual application period opens on March 28, and closes on April 8 (see http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline). To students: If you are interested in applying, please write the to mailing list and introduce yourself. The program is open to anyone worldwide who is 18 years of age or older who is enrolled in a higher education institution (this includes undergraduate and graduate). If you are interested in applying, here is what you should do (if you have not already): - As I said above, write to the list and introduce yourself. You might also join our IRC channel, which is #sympy on freenode. - Start thinking about what you want to apply to do. Our ideas page is at https://github.com/sympy/sympy/wiki/GSoC-2011-Ideas. However, we are open to ideas that are not on that page. Anything that fits in a computer algebra system would fit in SymPy. If you have an idea not on that page, please discuss it on our mailing list, so we can see if it has not already be implemented, and if it is fitting for SymPy and for a project. I recommend you apply to do something that you are interested in personally. - We require for any student to be accepted that he/she submit at least one patch to SymPy, which gets reviewed and pushed in. See http://code.google.com/p/sympy/issues/list?can=2q=label%3AEasyToFix for some easy to fix issues that are a good place to start. Don't worry if you do not know how to send in a patch or use git. We will help you (that is the whole point of the program). Just ask here, on the issue page, or on IRC. - You should start thinking about your application. Our template is at https://github.com/sympy/sympy/wiki/GSoC-2011-Application-Template (it will also soon be at our page on the Google site). If you like, you can start a page on our wiki to write your proposal. If you do this, we will help you edit it (though understand that we will not help you write it). Remember that we want you to get accepted just as much as you do, so you can help improve SymPy! To SymPy developers: - We need people who are willing to mentor students. If you are willing to mentor, please add your name to the bottom of the page at https://github.com/sympy/sympy/wiki/GSoC-2011-ideas. - Please edit the ideas page to improve formatting and add new ideas. If you are a sympy developer, unless you want to apply as a student, definitely sign up as a mentor --- you are not committing yourself to anything, if you are busy, you can just hang around. But if you have some time to spare, we will need help with reviewing applications, and even if you don't plan to be mentoring a project during the summer, you can still help us with the selection process, and it would be greatly appreciated. Then of course we will also need mentors for the actual projects. Simply get in touch with Aaron or me, and send us your link_id to google melange. Alternately, you can apply to be a mentor to SymPy (see http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/userguide#depth_mentapply), and we will accept you. Like Ondrej said, you do not have to mentor a project if you apply as a mentor (unless you want to). We just need help with rating applications in the system to decide who to accept. Aaron Meurer Good luck to all students who plan on applying! Good luck. If you have any questions, just ask. Ondrej -- You received this message because you are subscribed to the Google Groups sympy group. To
Re: [sympy] Introduction as a perspective student for GSoC
Hi Hector, On Fri, Mar 18, 2011 at 7:33 AM, Hector hector1...@gmail.com wrote: Hello everyone, My name is Prafullkumar P. Tale. I am a 4th year student at Indian Institute of Technology Roorkee, doing 5 years Integrated M.Sc. in Applied Mathematics. ( It is an integrated course offering graduate and post graduate degree with Math major). My area of interest lies preliminary in algorithms. I like coding for mathematical problems and spend most of my time for the same. Initially I stepped on wrong foot and started coding in MatLab. I spend 11/2 year, before finally switching to Python. I love Python. After attending Sage Days 25, India and SciPy 2010,India, I became a big fan of open source and would like to contribute back. Indeed, welcome to the community. As you probably already noticed, the Python scientific community is interesting, because even if people work on different projects, they tend to know each other and help each other out. I am myself have been around many projects besides SymPy (Scipy, NumPy, Cython, IPython, Sage, ) and it has been a great experience. Aaron said everything important, so I wish you to have fun and enjoy the summer! Ondrej -- 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 - Cython core?
Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Is the idea to update and clean up sympyx and properly integrate it into sympy? On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). 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] numpy array for sympy
2011/3/18 Aaron S. Meurer asmeu...@gmail.com: On Mar 18, 2011, at 4:13 PM, Robert Kern wrote: On Fri, Mar 18, 2011 at 17:04, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 18, 2011, at 11:53 AM, Alexey U. Gudchenko wrote: 18.03.2011 19:42, SherjilOzair пишет: Hi, Good evening. I'm working on a small base implementation of numpy-style array for sympy. Currently I've added component-wise addition, subtraction, multiplication, mult by integer. I've uploaded the code on GitHub. Where is it? Here are some points of discussion. 1) If unequal-sized arrays are added, should an error be raised or should they still be force-added taking the missing elements as zero ? 2) Multiplication of two linear arrays should give another linear array, with component-wise multiplication ? Or an array of 2-tuples, like one does with Sets ? 3) If using component-wise multiplication, for unequal arrays, should the missing elements be taken as one ? Or should an error be raised ? 4) Power will be done component-wise ? But this depends on the answer to point 2. 5) Any more features ? Thanks, Sherjil Ozair Sorry, I can entangle you, but: May be it would be helpful for answering of your questions if the aims of 'numpy-style array' would be more clear (for me at least, I can't find issues, aims or description of 'numpy-style array'). The purpose is to implement a basic version of numpy in sympy so that you do not have to install numpy to use the basic array feature. Since numpy has to be compiled, this will be very useful, since, for example, you can't install it on the Google App Engine. Therefore, the implementation in SymPy should match the numpy implementation. That's not very informative. numpy ndarrays have a *lot* of functionality attached to them. It's a major project, beyond the capabilities and resources of a single GSoC student, to match *all* of their functionality. You need to clearly state exactly what features of numpy ndarrays you want duplicated. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco Well, it was Ondrej's idea. Probably he could explain what he wants to see implemented better. Indeed, Robert is right, that this project can become tricky if ill specified. My aim is to have some basic implementation of arrays, that would behave exactly like numpy.array, so that we can simply use them, for example on the app engine, and if the speed becomes an issue, you just install numpy and use it on your own hardware. I frequently use the numpy's array syntax for my own research, and I think it should be part of the basic language of Python, e.g. there should be some implementation, that always works (e.g. on the app engine), so it must be pure python. Now features, that I mainly use are the following: * [1, 2, 3] ** 3 operates on the elements, not the matrix exponentiation, sin([1, 2, 3]) again operates on the elements. * reading from a text file (numpy.loadtxt) * indexing, e.g. a[:, 2], and so on * min(), max(), average() * a = array([1, 2, 3]); a eps, so things like .all(), and .any() So to be totally specific, here is my current patch from a month ago (not yet in sympy): https://github.com/certik/sympy/commit/00a77c35dd0d603826aa29fe1c9528e34d08142e and we have a test, that tests numpy/sympy interoperability. This test file now partly works with my pure python implementation. So a very specific project is to make *all* the numpy/sympy tests work with the pure Python implementation. That is definitely a doable project, in fact, I wanted to finish this myself, before submitting the patch for review. The tests in sympy don't test much of the 2D/3D stuff, so possible extensions to the above are possible, but I think just making the basic stuff work is worthy, and doable. Ondrej -- 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 - Cython core?
On Fri, Mar 18, 2011 at 8:36 PM, Tim Lahey tim.la...@gmail.com wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Yes. Is the idea to update and clean up sympyx and properly integrate it into sympy? I think that the latest code is here: https://github.com/certik/sympyx unless somebody did some more work on it. I think so, it should be integrated into sympy. It's a nontrivial project though. On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). There are several options for that, I think virtualenv is one of them. I personally use my own project for it: http://qsnake.com/ it's similar to Sage (uses some packages from Sage), but I rebuilt the build system. It installs everything into a local directory and you can have as many qsnake installations as you want. I then develop using qsnake --shell and then I can call any installed package. At my work, I don't even have a root access to my computer, so qsnake (or something similar) is the only option. I didn't test this on a Mac for a long time, so probably more work would be needed, I only have time to test on Ubuntu though. Ondrej -- 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 - Cython core?
On Mar 18, 2011, at 9:36 PM, Tim Lahey wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Is the idea to update and clean up sympyx and properly integrate it into sympy? Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. If you want to create a virtual environment with Python, you can use virtualenv. Maybe someone else here can explain how to use it better than I can (I am still new to it), but I think you basically type virtualenv directory and then install things using the virtual python installed in that directory (I think I might be missing a step or two here, so look at the docs before trying). Also, an alternative to the system Python on Mac OS X is to use fink. That is what I do. Everything is installed in /sw/, and if you screw up the installation, you can completely trash /sw/ and start again if you want (it is completely independent of the system stuff). Aaron Meurer 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. -- 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 - Cython core?
On Fri, Mar 18, 2011 at 8:49 PM, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 18, 2011, at 9:36 PM, Tim Lahey wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Is the idea to update and clean up sympyx and properly integrate it into sympy? Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. Yes, this is precisely correct. Ondrej -- 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 - Cython core?
On Mar 18, 2011, at 9:49 PM, Ondrej Certik wrote: On Fri, Mar 18, 2011 at 8:36 PM, Tim Lahey tim.la...@gmail.com wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Yes. Is the idea to update and clean up sympyx and properly integrate it into sympy? I think that the latest code is here: https://github.com/certik/sympyx unless somebody did some more work on it. I think so, it should be integrated into sympy. It's a nontrivial project though. On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). There are several options for that, I think virtualenv is one of them. I personally use my own project for it: http://qsnake.com/ it's similar to Sage (uses some packages from Sage), but I rebuilt the build system. It installs everything into a local directory and you can have as many qsnake installations as you want. I then develop using qsnake --shell and then I can call any installed package. At my work, I don't even have a root access to my computer, so qsnake (or something similar) is the only option. I didn't test this on a Mac for a long time, so probably more work would be needed, I only have time to test on Ubuntu though. Ondrej As long as you didn't use any stuff specific to your linux distribution (like apt-get or something), it should work on the Mac. Mac OS X is full POSIX after all. 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.
Re: [sympy] GSoC - Cython core?
On 03-18-2011, at 11:49 PM, Aaron S. Meurer wrote: On Mar 18, 2011, at 9:36 PM, Tim Lahey wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Is the idea to update and clean up sympyx and properly integrate it into sympy? Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. So I guess looking at the polys branch (which is where exactly?) is a good idea to see how they do it. Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. I kind of guessed that the core would need to be cleaned up. Even if the work doesn't get finished as part of GSoC, at least things would be further along. So, if all I did was clean up the core and cythonize some of the core, things would be better. On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. If you want to create a virtual environment with Python, you can use virtualenv. Maybe someone else here can explain how to use it better than I can (I am still new to it), but I think you basically type virtualenv directory and then install things using the virtual python installed in that directory (I think I might be missing a step or two here, so look at the docs before trying). Also, an alternative to the system Python on Mac OS X is to use fink. That is what I do. Everything is installed in /sw/, and if you screw up the installation, you can completely trash /sw/ and start again if you want (it is completely independent of the system stuff). I'd rather not install Fink since I use Homebrew instead and I don't want duplication of system packages (except Python), so I'll look at qsnake. I realize that this is a non-trivial task, but the last time someone looked at this was June 2009 based upon Ondrej's repository. Someone has already done work on a new assumption system haven't they? I'm guessing it just isn't complete or is it complete and just not integrated? Thanks, 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 - Cython core?
On Mar 18, 2011, at 9:59 PM, Tim Lahey wrote: On 03-18-2011, at 11:49 PM, Aaron S. Meurer wrote: On Mar 18, 2011, at 9:36 PM, Tim Lahey wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Is the idea to update and clean up sympyx and properly integrate it into sympy? Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. So I guess looking at the polys branch (which is where exactly?) is a good idea to see how they do it. The cython stuff is already in the git master. See for example sympy/polys/densearith.py. The Makefile will give you more information on what happens with the Cython. Aaron Meurer Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. I kind of guessed that the core would need to be cleaned up. Even if the work doesn't get finished as part of GSoC, at least things would be further along. So, if all I did was clean up the core and cythonize some of the core, things would be better. On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. If you want to create a virtual environment with Python, you can use virtualenv. Maybe someone else here can explain how to use it better than I can (I am still new to it), but I think you basically type virtualenv directory and then install things using the virtual python installed in that directory (I think I might be missing a step or two here, so look at the docs before trying). Also, an alternative to the system Python on Mac OS X is to use fink. That is what I do. Everything is installed in /sw/, and if you screw up the installation, you can completely trash /sw/ and start again if you want (it is completely independent of the system stuff). I'd rather not install Fink since I use Homebrew instead and I don't want duplication of system packages (except Python), so I'll look at qsnake. I realize that this is a non-trivial task, but the last time someone looked at this was June 2009 based upon Ondrej's repository. Someone has already done work on a new assumption system haven't they? I'm guessing it just isn't complete or is it complete and just not integrated? Thanks, 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. -- 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 - Cython core?
On 03-19-2011, at 12:04 AM, Aaron S. Meurer wrote: The cython stuff is already in the git master. See for example sympy/polys/densearith.py. The Makefile will give you more information on what happens with the Cython. Thanks, I'll take a look at it. Has someone done a new version of the assumption system? I seem to recall someone working at it. Thanks, 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 - Cython core?
Hi, On 18 March 2011 21:04, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 18, 2011, at 9:59 PM, Tim Lahey wrote: On 03-18-2011, at 11:49 PM, Aaron S. Meurer wrote: On Mar 18, 2011, at 9:36 PM, Tim Lahey wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Is the idea to update and clean up sympyx and properly integrate it into sympy? Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. So I guess looking at the polys branch (which is where exactly?) is a good idea to see how they do it. The cython stuff is already in the git master. See for example sympy/polys/densearith.py. The Makefile will give you more information on what happens with the Cython. In polys this is *pure* Cython approach, i.e. no Cython source code, just compilation to native code of Python source code (less effort, less gain). Aaron Meurer Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. I kind of guessed that the core would need to be cleaned up. Even if the work doesn't get finished as part of GSoC, at least things would be further along. So, if all I did was clean up the core and cythonize some of the core, things would be better. On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. If you want to create a virtual environment with Python, you can use virtualenv. Maybe someone else here can explain how to use it better than I can (I am still new to it), but I think you basically type virtualenv directory and then install things using the virtual python installed in that directory (I think I might be missing a step or two here, so look at the docs before trying). Also, an alternative to the system Python on Mac OS X is to use fink. That is what I do. Everything is installed in /sw/, and if you screw up the installation, you can completely trash /sw/ and start again if you want (it is completely independent of the system stuff). I'd rather not install Fink since I use Homebrew instead and I don't want duplication of system packages (except Python), so I'll look at qsnake. I realize that this is a non-trivial task, but the last time someone looked at this was June 2009 based upon Ondrej's repository. Someone has already done work on a new assumption system haven't they? I'm guessing it just isn't complete or is it complete and just not integrated? Thanks, 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. -- 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.
Re: [sympy] Re: how to edit modules vectorization of subs
Le vendredi 18 mars 2011 à 16:29 +0530, Hector a écrit : Yes, exactly. It seems more consistent that way. Has this issue already been discussed? If not, do we need to report this? Since I am looking forward to apply for GSoC, and would love to work with SymPy, this would be good start for me. If core developers/contributors agree, I would like to work on this regardless GSoC. Because with thing implemented, we can never go for limit of multi-variable functions. I thought about this before, but I didn't reach the point where I could suggest a design. I think there needs to be an object describing the destination of a limit (i.e. 0, 0+, 0-, +oo, ...), so the syntax for limit would be limit(f(x), x, something that means 0+) instead of limit(f(x), x, 0, dir=+). These destination objects would also be used by series() and the like and would be passed around in the internal code. The proper mathematical notion corresponding to this is a filter[*]. It applies also in the multivariate case and allows to describe limits when |(x,y)| - 0, or when (x,y) - (0,0) along a particular ray or some more complicated curve, etc. [*]: See http://fr.wikipedia.org/wiki/Filtre_%28math%C3%A9matiques%29 (in French) - I couldn't find a good description in English. The en.Wikipedia article in particular is so full of category-theoretic abstract nonsense as to be useless. -- 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: how to edit modules vectorization of subs
On Mar 18, 2011, at 10:24 PM, Ronan Lamy wrote: Le vendredi 18 mars 2011 à 16:29 +0530, Hector a écrit : Yes, exactly. It seems more consistent that way. Has this issue already been discussed? If not, do we need to report this? Since I am looking forward to apply for GSoC, and would love to work with SymPy, this would be good start for me. If core developers/contributors agree, I would like to work on this regardless GSoC. Because with thing implemented, we can never go for limit of multi-variable functions. I thought about this before, but I didn't reach the point where I could suggest a design. I think there needs to be an object describing the destination of a limit (i.e. 0, 0+, 0-, +oo, ...), so the syntax for limit would be limit(f(x), x, something that means 0+) instead of limit(f(x), x, 0, dir=+). These destination objects would also be used by series() and the like and would be passed around in the internal code. The proper mathematical notion corresponding to this is a filter[*]. It applies also in the multivariate case and allows to describe limits when |(x,y)| - 0, or when (x,y) - (0,0) along a particular ray or some more complicated curve, etc. [*]: See http://fr.wikipedia.org/wiki/Filtre_%28math%C3%A9matiques%29 (in French) - I couldn't find a good description in English. The en.Wikipedia article in particular is so full of category-theoretic abstract nonsense as to be useless. Isn't a filter some kind of set of subsets that satisfies some properties? One of my professors introduced these to me when describing the hyperreal system. But I don't understand how that lets you define a limit path like you want. And I really don't understand how that could help with an implementation. I remember that when using filters to describe the hyperreal system, you have to use the axiom of choice to get what you want, i.e., it is only useful as a theoretical tool. 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.
Re: [sympy] GSoC - Cython core?
Le samedi 19 mars 2011 à 00:12 -0400, Tim Lahey a écrit : On 03-19-2011, at 12:04 AM, Aaron S. Meurer wrote: The cython stuff is already in the git master. See for example sympy/polys/densearith.py. The Makefile will give you more information on what happens with the Cython. Thanks, I'll take a look at it. Has someone done a new version of the assumption system? I seem to recall someone working at it. It's done (sort of). What we actually have is a good system for propositional logic (with an inconvenient API though) but it needs to be hooked up with the core and there are missing pieces (indexing the knowledge base, handling binary predicates,...). Also, the old assumption system is tightly integrated with the core and it's difficult to prise it out. I have some code lying around where I tortuously made a small bit of progress towards that goal - I'll try to update it and put it on GitHub. -- 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] Github Issues Application
For those who don't already know about this, I recommend the Github Issues Application, http://githubissues.heroku.com/ It gives an application-style interface to Github issues. One of the nice things is that you can add any repositories to it so you can track the issues for a number of repositories at once. For those that use Chrome, it's available through the Chrome Web Store. 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 - Cython core?
On 03-19-2011, at 12:46 AM, Ronan Lamy wrote: It's done (sort of). What we actually have is a good system for propositional logic (with an inconvenient API though) but it needs to be hooked up with the core and there are missing pieces (indexing the knowledge base, handling binary predicates,...). Also, the old assumption system is tightly integrated with the core and it's difficult to prise it out. I have some code lying around where I tortuously made a small bit of progress towards that goal - I'll try to update it and put it on GitHub. Ugh. Updating the core to use Cython is one thing, overhauling assumptions is a pretty major topic itself. Thanks, 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] Github Issues Application
Interesting. I think for the pull requests (which are the only thing we use on GitHub; our issues are at Google Code), the default interface is better because it puts the code right there, where as with this, the code is hidden. Do you know how it computes the priority? Aaron Meurer On Mar 18, 2011, at 10:47 PM, Tim Lahey wrote: For those who don't already know about this, I recommend the Github Issues Application, http://githubissues.heroku.com/ It gives an application-style interface to Github issues. One of the nice things is that you can add any repositories to it so you can track the issues for a number of repositories at once. For those that use Chrome, it's available through the Chrome Web Store. 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. -- 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 - Cython core?
On Fri, Mar 18, 2011 at 8:49 PM, Aaron S. Meurer asmeu...@gmail.com wrote: On Mar 18, 2011, at 9:36 PM, Tim Lahey wrote: Hi, I've been thinking about applying for GSoC and working on a Cython core. I'm assuming that it would be an optional thing? So, there would be two cores, an optimized one that's done in Cython and a pure Python one for when Cython isn't available. Is the idea to update and clean up sympyx and properly integrate it into sympy? Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. +1e100. The old assumptions definitely need to go before Cython is brought into the picture. In terms of the core, I think the assumptions work is one of the most important things that needs to be done. On a development note, is there a good way to have a separate python and packages (e.g., a sympy fork and cython) so I don't mess up my system python? I'm working on OS X, but I could install a Linux VM in Virtualbox (if so, which Linux?). virtualenv is great. If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. This is how we work. If you want to create a virtual environment with Python, you can use virtualenv. Maybe someone else here can explain how to use it better than I can (I am still new to it), but I think you basically type virtualenv directory and then install things using the virtual python installed in that directory (I think I might be missing a step or two here, so look at the docs before trying). Also, an alternative to the system Python on Mac OS X is to use fink. That is what I do. Everything is installed in /sw/, and if you screw up the installation, you can completely trash /sw/ and start again if you want (it is completely independent of the system stuff). Aaron Meurer 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. -- 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. -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- 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] Github Issues Application
On 03-19-2011, at 12:54 AM, Aaron S. Meurer wrote: Interesting. I think for the pull requests (which are the only thing we use on GitHub; our issues are at Google Code), the default interface is better because it puts the code right there, where as with this, the code is hidden. I didn't realize that the issues were still on Google Code. I thought the issues would be moved over when the repo when to Github. The advantage of using Github for issues is that you can have a commit automatically close an issue, by appropriate tagging in the commit description. I'm assuming it would work for when you merged a pull request as well. Do you know how it computes the priority? Priority isn't specifically determined, it's set. By default, if you go to the issues for a repository on Github, it's sorted by priority. If you're the owner, you can drag the issues into a new order to set the priority. So, issues at the top have the highest priority. The default priority is in order of creation (I think). So, the oldest issues would have the highest priority unless the order was changed. I find the Issues application useful because I'll create issues for my specific repositories. So, with the app I can see all the issues I have outstanding on all my repositories (in addition to important 3rd party ones). 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] numpy array for sympy
On Fri, Mar 18, 2011 at 9:42 AM, SherjilOzair sherjiloz...@gmail.com wrote: Hi, I'm working on a small base implementation of numpy-style array for sympy. Currently I've added component-wise addition, subtraction, multiplication, mult by integer. I've uploaded the code on GitHub. Cool. Here are some points of discussion. 1) If unequal-sized arrays are added, should an error be raised or should they still be force-added taking the missing elements as zero ? If we are going to have a numpy-like object for sympy expressions, it should have the same exact API as numpy arrays (probably other than the dtype stuff). 2) Multiplication of two linear arrays should give another linear array, with component-wise multiplication ? Or an array of 2-tuples, like one does with Sets ? 3) If using component-wise multiplication, for unequal arrays, should the missing elements be taken as one ? Or should an error be raised ? 4) Power will be done component-wise ? But this depends on the answer to point 2. Again, unless there is a really strong reason to diverge from numpy I *highly* recommend simply copying the API to the extent that you implement it (we don't have to implement everything, but what we do implement, we should copy numpy...). 5) Any more features ? I think more advanced indexing and broadcasting and then symbolic ufuncs would top my list... Cheers, Brian Thanks, Sherjil Ozair -- 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. -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- 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 - Cython core?
On 03-19-2011, at 1:07 AM, Brian Granger wrote: On Fri, Mar 18, 2011 at 8:49 PM, Aaron S. Meurer asmeu...@gmail.com wrote: Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. +1e100. The old assumptions definitely need to go before Cython is brought into the picture. In terms of the core, I think the assumptions work is one of the most important things that needs to be done. Should the assumption work be a GSoC project itself? virtualenv is great. Good to know. If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. This is how we work. Also good to know, but it wouldn't be helpful if I do plotting since I'd need a number of additional packages. As an alternate project, I was thinking about plotting. What back ends do people want? I'm guessing pyglet and matplotlib, but what else? I think ASCII art would be a bit tricky since you'd have to develop a whole new plotting back end rather than just interfacing with one. I'm not sure what specifically you'd want from Mathematica since I don't use it. 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] Github Issues Application
On Mar 18, 2011, at 11:09 PM, Tim Lahey wrote: On 03-19-2011, at 12:54 AM, Aaron S. Meurer wrote: Interesting. I think for the pull requests (which are the only thing we use on GitHub; our issues are at Google Code), the default interface is better because it puts the code right there, where as with this, the code is hidden. I didn't realize that the issues were still on Google Code. I thought the issues would be moved over when the repo when to Github. The advantage of using Github for issues is that you can have a commit automatically close an issue, by appropriate tagging in the commit description. I'm assuming it would work for when you merged a pull request as well. Yes, when a pull request is merged, it is automatically closed. From what I have seen, Google Code's issue tracker is still superior to GitHub's. And anyway, we have over 2000 issues in Google Code, which we do not want to lose (including the numbering, because various issues are referenced all over the place by number), so if we were to ever move to another issue tracker, they would all have to be transferred somehow. But at the moment, we are happy with using Google Code for the issue discussions and GitHub for the pull requests. In some ways, it is actually nice to separate the issue discussions from the discussions of specific patches. Do you know how it computes the priority? Priority isn't specifically determined, it's set. By default, if you go to the issues for a repository on Github, it's sorted by priority. If you're the owner, you can drag the issues into a new order to set the priority. So, issues at the top have the highest priority. The default priority is in order of creation (I think). So, the oldest issues would have the highest priority unless the order was changed. I see. So here is an example of where Google Code is better. It lets you sort the issues by various labels. Our issues are sorted by milestone, then priority, then by issue id by default, though you can manually choose any sorting you want. And the ability to do complex queries based on labels makes it easier to find issues. Aaron Meurer I find the Issues application useful because I'll create issues for my specific repositories. So, with the app I can see all the issues I have outstanding on all my repositories (in addition to important 3rd party ones). 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. -- 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 - Cython core?
On Mar 18, 2011, at 11:19 PM, Tim Lahey wrote: On 03-19-2011, at 1:07 AM, Brian Granger wrote: On Fri, Mar 18, 2011 at 8:49 PM, Aaron S. Meurer asmeu...@gmail.com wrote: Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. +1e100. The old assumptions definitely need to go before Cython is brought into the picture. In terms of the core, I think the assumptions work is one of the most important things that needs to be done. Should the assumption work be a GSoC project itself? Yes, I think it should. I would put such a project—one that removes the old assumptions and replaces them with the new—as top priority for SymPy, because there are so many things (like the Cython core) that are blocked on it, not to mention the fact that the new assumptions have the potential to be vastly superior to the old ones. virtualenv is great. Good to know. If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. This is how we work. Also good to know, but it wouldn't be helpful if I do plotting since I'd need a number of additional packages. Yes, you should use virtualenv in that case. As an alternate project, I was thinking about plotting. What back ends do people want? I'm guessing pyglet and matplotlib, but what else? I think ASCII art would be a bit tricky since you'd have to develop a whole new plotting back end rather than just interfacing with one. I think those are the most important. ASCII art would be cool, but probably too much work if a library doesn't already exist, and also less useful nowadays when most systems have a windowing system (I think Maple's ASCII art plots date back to the days when this was not the case). Also, you should look at integrating it well with IPython's new QT console (Brian Granger can tell you more about this). What really needs to be done is to create a good system that lets you plug in any (Python) plotting system with minimal work. By the way, you should be aware that we require all applicants to submit at least one patch that is reviewed and pushed in. I didn't see your name in the git log, so you should do this. Aaron Meurer I'm not sure what specifically you'd want from Mathematica since I don't use it. 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. -- 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: how to edit modules vectorization of subs
Le vendredi 18 mars 2011 à 22:40 -0600, Aaron S. Meurer a écrit : On Mar 18, 2011, at 10:24 PM, Ronan Lamy wrote: Le vendredi 18 mars 2011 à 16:29 +0530, Hector a écrit : Yes, exactly. It seems more consistent that way. Has this issue already been discussed? If not, do we need to report this? Since I am looking forward to apply for GSoC, and would love to work with SymPy, this would be good start for me. If core developers/contributors agree, I would like to work on this regardless GSoC. Because with thing implemented, we can never go for limit of multi-variable functions. I thought about this before, but I didn't reach the point where I could suggest a design. I think there needs to be an object describing the destination of a limit (i.e. 0, 0+, 0-, +oo, ...), so the syntax for limit would be limit(f(x), x, something that means 0+) instead of limit(f(x), x, 0, dir=+). These destination objects would also be used by series() and the like and would be passed around in the internal code. The proper mathematical notion corresponding to this is a filter[*]. It applies also in the multivariate case and allows to describe limits when |(x,y)| - 0, or when (x,y) - (0,0) along a particular ray or some more complicated curve, etc. [*]: See http://fr.wikipedia.org/wiki/Filtre_%28math%C3%A9matiques%29 (in French) - I couldn't find a good description in English. The en.Wikipedia article in particular is so full of category-theoretic abstract nonsense as to be useless. Isn't a filter some kind of set of subsets that satisfies some properties? One of my professors introduced these to me when describing the hyperreal system. But I don't understand how that lets you define a limit path like you want. And I really don't understand how that could help with an implementation. I remember that when using filters to describe the hyperreal system, you have to use the axiom of choice to get what you want, i.e., it is only useful as a theoretical tool. Yes, it's a set F of subsets with the properties Union(A, B) is in F for any A, B in F and if A is in F and B contains A, then B is in F, but you don't need the axiom of choice to define or use them. Basically, the limit of f along a filter F is y0 iff y0 is in the adherence of f(A) for every A in F (and is the only such point). For instance, the filter that defines the limit of a function in 0+ is the set of parts of R that contain an interval ]0, r[, with r0. But the actual definition of filters isn't terribly important for us - besides the fact that it exists and is consistent. What matters is that it captures well the notion of limit and that it's possible to do some arithmetic with them (1/0+ = +oo, 0- * 0- = 0+, ...) 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.
Re: [sympy] Re: how to edit modules vectorization of subs
On Mar 18, 2011, at 11:33 PM, Ronan Lamy wrote: Le vendredi 18 mars 2011 à 22:40 -0600, Aaron S. Meurer a écrit : On Mar 18, 2011, at 10:24 PM, Ronan Lamy wrote: Le vendredi 18 mars 2011 à 16:29 +0530, Hector a écrit : Yes, exactly. It seems more consistent that way. Has this issue already been discussed? If not, do we need to report this? Since I am looking forward to apply for GSoC, and would love to work with SymPy, this would be good start for me. If core developers/contributors agree, I would like to work on this regardless GSoC. Because with thing implemented, we can never go for limit of multi-variable functions. I thought about this before, but I didn't reach the point where I could suggest a design. I think there needs to be an object describing the destination of a limit (i.e. 0, 0+, 0-, +oo, ...), so the syntax for limit would be limit(f(x), x, something that means 0+) instead of limit(f(x), x, 0, dir=+). These destination objects would also be used by series() and the like and would be passed around in the internal code. The proper mathematical notion corresponding to this is a filter[*]. It applies also in the multivariate case and allows to describe limits when |(x,y)| - 0, or when (x,y) - (0,0) along a particular ray or some more complicated curve, etc. [*]: See http://fr.wikipedia.org/wiki/Filtre_%28math%C3%A9matiques%29 (in French) - I couldn't find a good description in English. The en.Wikipedia article in particular is so full of category-theoretic abstract nonsense as to be useless. Isn't a filter some kind of set of subsets that satisfies some properties? One of my professors introduced these to me when describing the hyperreal system. But I don't understand how that lets you define a limit path like you want. And I really don't understand how that could help with an implementation. I remember that when using filters to describe the hyperreal system, you have to use the axiom of choice to get what you want, i.e., it is only useful as a theoretical tool. Yes, it's a set F of subsets with the properties Union(A, B) is in F for any A, B in F and if A is in F and B contains A, then B is in F, but you don't need the axiom of choice to define or use them. Basically, the limit of f along a filter F is y0 iff y0 is in the adherence of f(A) for every A in F (and is the only such point). For instance, the filter that defines the limit of a function in 0+ is the set of parts of R that contain an interval ]0, r[, with r0. What is the adherence of f(A)? By the way, I think the axiom of choice is needed to choose a filter on R to use for a set of equivalence classes for the hyperreals (something like that). But the actual definition of filters isn't terribly important for us - besides the fact that it exists and is consistent. What matters is that it captures well the notion of limit and that it's possible to do some arithmetic with them (1/0+ = +oo, 0- * 0- = 0+, …) Yes, I think this is similar to the hyperreals. It seems to me like your 0+ is like an infinitesimal. Aaron Meurer 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.
Re: [sympy] GSoC - Cython core?
Tim, On Fri, Mar 18, 2011 at 10:19 PM, Tim Lahey tim.la...@gmail.com wrote: On 03-19-2011, at 1:07 AM, Brian Granger wrote: On Fri, Mar 18, 2011 at 8:49 PM, Aaron S. Meurer asmeu...@gmail.com wrote: Well, the hope is that we can use things like @cythonized decorators in the core, and make it just work either way (either it uses pure Python, or cython if the cython has been made). This is how the cython in the polys works right now. We will have to look at it to see if this will work for the core. Anyway, it would definitely be optional no matter how it is done, because we want people to be able to use SymPy using pure Python as the only dependency. Also, it was my understanding that the core needs a lot of cleanup before it can be properly cythonized. In particular, the old assumptions have to be completely removed and replaced with the new ones. Others know more about the state of the core and could probably answer your questions better, though. +1e100. The old assumptions definitely need to go before Cython is brought into the picture. In terms of the core, I think the assumptions work is one of the most important things that needs to be done. Should the assumption work be a GSoC project itself? Yes, please!!! I think a solid application focused on the assumptions system would be quite popular among the core developers. Cheers, Brian virtualenv is great. Good to know. If you are working on just SymPy, you can just work straight from the git repository. There is no need to install it. This is how we work. Also good to know, but it wouldn't be helpful if I do plotting since I'd need a number of additional packages. As an alternate project, I was thinking about plotting. What back ends do people want? I'm guessing pyglet and matplotlib, but what else? I think ASCII art would be a bit tricky since you'd have to develop a whole new plotting back end rather than just interfacing with one. I'm not sure what specifically you'd want from Mathematica since I don't use it. 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. -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com -- 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 - Cython core?
On 03-19-2011, at 1:29 AM, Aaron S. Meurer wrote: Yes, I think it should. I would put such a project—one that removes the old assumptions and replaces them with the new—as top priority for SymPy, because there are so many things (like the Cython core) that are blocked on it, not to mention the fact that the new assumptions have the potential to be vastly superior to the old ones. If I were to do a project on the assumptions, I'd probably need a fair bit of assistance since I don't know really know the topic. However, I'm fairly good a theory, so pointers to appropriate books/papers would be a good start if I did that. As an alternate project, I was thinking about plotting. What back ends do people want? I'm guessing pyglet and matplotlib, but what else? I think ASCII art would be a bit tricky since you'd have to develop a whole new plotting back end rather than just interfacing with one. I think those are the most important. ASCII art would be cool, but probably too much work if a library doesn't already exist, and also less useful nowadays when most systems have a windowing system (I think Maple's ASCII art plots date back to the days when this was not the case). Also, you should look at integrating it well with IPython's new QT console (Brian Granger can tell you more about this). What really needs to be done is to create a good system that lets you plug in any (Python) plotting system with minimal work. That's certainly what I'd like to see as well. By the way, you should be aware that we require all applicants to submit at least one patch that is reviewed and pushed in. I didn't see your name in the git log, so you should do this. I've done work related to Sage before. I'm looking through the issues tracker. I have code to do Euler-Lagrange equations that I wrote in Maple that should be fairly simple to add to sympy, if people are interested. Cheers, Tim. -- 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 - Cython core?
On Mar 18, 2011, at 11:51 PM, Tim Lahey wrote: On 03-19-2011, at 1:29 AM, Aaron S. Meurer wrote: Yes, I think it should. I would put such a project—one that removes the old assumptions and replaces them with the new—as top priority for SymPy, because there are so many things (like the Cython core) that are blocked on it, not to mention the fact that the new assumptions have the potential to be vastly superior to the old ones. If I were to do a project on the assumptions, I'd probably need a fair bit of assistance since I don't know really know the topic. However, I'm fairly good a theory, so pointers to appropriate books/papers would be a good start if I did that. Well, if you don't feel comfortable doing that project, don't feel pressured into doing it. I think the plotting idea is also something that is pretty important for SymPy. As an alternate project, I was thinking about plotting. What back ends do people want? I'm guessing pyglet and matplotlib, but what else? I think ASCII art would be a bit tricky since you'd have to develop a whole new plotting back end rather than just interfacing with one. I think those are the most important. ASCII art would be cool, but probably too much work if a library doesn't already exist, and also less useful nowadays when most systems have a windowing system (I think Maple's ASCII art plots date back to the days when this was not the case). Also, you should look at integrating it well with IPython's new QT console (Brian Granger can tell you more about this). What really needs to be done is to create a good system that lets you plug in any (Python) plotting system with minimal work. That's certainly what I'd like to see as well. By the way, you should be aware that we require all applicants to submit at least one patch that is reviewed and pushed in. I didn't see your name in the git log, so you should do this. I've done work related to Sage before. I'm looking through the issues tracker. I have code to do Euler-Lagrange equations that I wrote in Maple that should be fairly simple to add to sympy, if people are interested. Cheers, Tim. Yes, I remember you posting your Maple code on the list a while back. I think many people would indeed find that useful. 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.
