[sympy] Re: The Vectors and Electromagnetism GSoC projects

@Jason: I do not know if other's are willing to implement this. Anyway, so coding period start in 2 days. We need to decide what to do. Right now, we have an API that appears workable. If there are going to be any more major changes (like supporting mutability or not having reference frames as

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

I can implement Jason's idea, if you don't mind Prasoon. I had set some time in my timeline to work on the framework, and I can utilize it to implement the said functionalities via your API in mechanics. Since your module deals more with coordinates, I can deal with the 'time' and 'motion' part, wi

[sympy] solve() and it's argument type

Hello, As per the documentation, there is no explicit mention of solve() accepting a string as it's argument. However, this works: >>> from sympy.solvers import solve >>> solve('a**2 + 2*a + 1') [-1] Just to make sure, 'a' has no existence other than in the above string: >>> a Traceback (most

Re: [sympy] solve() and it's argument type

Anything that sympifies its arguments will allow string input. So input is limited to whatever can be sympified. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+u

Re: [sympy] solve() and it's argument type

On Sat, Jun 15, 2013 at 10:30 PM, Chris Smith wrote: > Anything that sympifies its arguments will allow string input. So input is > limited to whatever can be sympified. Thanks, I discovered 'sympify()' sometime back and also think it is a better alternative to using 'parse_expr()' directly, whic

Re: [sympy] solve() and it's argument type

I think you will find this useful: http://docs.sympy.org/tutorial/tutorial/index.html Especially the part about anti-patterns. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an e

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

I agree with Sachin: Prasoon continues with what he has described but does not care about time variables or kinematics, only about static orientation between reference frames. Sachin builds the time dependence, time derivatives and kinematics on top of that. Of course, you will probably address ea

[sympy] Re: The Vectors and Electromagnetism GSoC projects

Alright then. How should we proceed with this differentiation? My initial idea of having a CoordSys class *and* a RefFrame class can perhaps be used. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving ema

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

Actually I do not see any issue. You still have to do all coordinate transformations, translated and rotated references, etc. Just do not occupy yourself with time variables, angular velocity and linear velocity of the references. On 15 June 2013 16:06, Prasoon Shukla wrote: > Alright then. How

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

I agree. What we can do is, Prasoon can start building a CoordSys class, and as Jason suggested, I will start working on a RefFrame class (with your API) - this class will be a subclass of CoordSys, specially built for the physics module. Prasoon, could you clear up the wiki page, and paste your AP

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

I actually am very much against separating coordsys and refframe again. I really do not see the point. Prasoon just continues his work on the api he suggested last time and Sachin adds time derivatives. These two have nothing in common. -- You received this message because you are subscribed to t

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

Not a problem! Ok, what about the module/class structure? Where will the new code be located? On Sat, Jun 15, 2013 at 7:47 PM, Stefan Krastanov < krastanov.ste...@gmail.com> wrote: > I actually am very much against separating coordsys and refframe > again. I really do not see the point. Prasoon

Re: [sympy] solve() and it's argument type

On Sat, Jun 15, 2013 at 11:56 PM, Stefan Krastanov wrote: > I think you will find this useful: > > http://docs.sympy.org/tutorial/tutorial/index.html > > Especially the part about anti-patterns. Thanks Stefan, it certainly answers a lot of my queries. Which version of sympy is this built from? I

Re: [sympy] solve() and it's argument type

This is the new tutorial that Aaron is currently building (It should be merged soon). I guess it was a lot of work. It does a great job at clearing up many of the antipatterns that one can see (especially on stackoverflow answers). On 15 June 2013 16:44, Amit Saha wrote: > On Sat, Jun 15, 2013 at

Re: [sympy] solve() and it's argument type

The new tutorial is from my branch at https://github.com/sympy/sympy/pull/2106. But Stefan is mistaken. I have not incorporated this material into the tutorial yet. So far, it only lives on the wiki at https://github.com/sympy/sympy/wiki/Idioms-and-Antipatterns#strings-as-input. I am not sure wha

[sympy] sqrt

In the latest build is there anyway to specify that the sympy expression/function (not symbol) you are taking the sqrt of is real and positive? -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails f

Re: [sympy] sqrt

This is possible in new assumptions In [1]: expr = x**2 In [2]: ask(Q.positive(expr + 1), Q.positive(expr)) Out[2]: True On Sat, Jun 15, 2013 at 12:21 PM, Alan Bromborsky wrote: > In the latest build is there anyway to specify that the sympy > expression/function (not symbol) you are taking t

Re: [sympy] sqrt

And more specifically, to simplify square roots, use refine In [50]: refine(sqrt((x + 1)**2), Q.positive(x + 1)) Out[50]: x + 1 Aaron Meurer On Sat, Jun 15, 2013 at 12:24 PM, Matthew Rocklin wrote: > This is possible in new assumptions > > In [1]: expr = x**2 > > In [2]: ask(Q.positive(expr + 1

Re: [sympy] sqrt

On 06/15/2013 01:24 PM, Matthew Rocklin wrote: This is possible in new assumptions In [1]: expr = x**2 In [2]: ask(Q.positive(expr + 1), Q.positive(expr)) Out[2]: True On Sat, Jun 15, 2013 at 12:21 PM, Alan Bromborsky > wrote: In the latest build is there an

Re: [sympy] sqrt

On 06/15/2013 01:27 PM, Aaron Meurer wrote: And more specifically, to simplify square roots, use refine In [50]: refine(sqrt((x + 1)**2), Q.positive(x + 1)) Out[50]: x + 1 Aaron Meurer On Sat, Jun 15, 2013 at 12:24 PM, Matthew Rocklin wrote: This is possible in new assumptions In [1]: expr

Re: [sympy] sqrt

Ah, that's a deficiency in refine(). It doesn't recognize that the product of Abs is the Abs of the product. If you don't set the symbols to be positive in the first place, you won't get Abs, and it will work. To replace Abs with its argument, you can do expr.replace(Abs, Id). That will replace al

Re: [sympy] solve() and it's argument type

Oh, sorry. I remembered reading both the antipatterns page and the tutorial and mistakenly "remembered" that they were both at the same place. On 15 June 2013 18:50, Aaron Meurer wrote: > The new tutorial is from my branch at > https://github.com/sympy/sympy/pull/2106. > > But Stefan is mistaken.

Re: [sympy] sqrt

On 06/15/2013 01:47 PM, Aaron Meurer wrote: Ah, that's a deficiency in refine(). It doesn't recognize that the product of Abs is the Abs of the product. If you don't set the symbols to be positive in the first place, you won't get Abs, and it will work. To replace Abs with its argument, you can

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

I am against this. It is far too easy to just say we'll figure out the details later. It will only lead to more problems when attempting to implement the ignored functionality. When is the next time everyone can meet on IRC? -- You received this message because you are subscribed to the Google

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

@Gilbert: Can you come over right now to the IRC? -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email

[sympy] Evaluating limit of curvature of a bezier at a cusp

Hello. I working on some bezier-related algorithms and need to be able to provide the curvature of a bezier at any queried point. Now when cubic beziers have cusps, their curvature is infinite. However the infinity can be positive or negative. The question is how to find out the sign of this infin

Re: [sympy] Evaluating limit of curvature of a bezier at a cusp

Did you try using limit()? subs() just inserts the value into the expression, which means that it won't always compute things at infinity correctly. SymPy's limit() implements a powerful algorithm due to Gruntz, which can take some pretty complicated limits (it is much more powerful than l'Hopital

Re: [sympy] Evaluating limit of curvature of a bezier at a cusp

A trick I like is to do a two step substitution: >>> from sympy import * var('x'>>> var('x') x >>> var('p',positive=True) p >>> eq=1/x >>> eq.subs(x,x-p).subs(x,0).subs(p,0) -oo >>> eq.subs(x,x+p).subs(x,0).subs(p,0) oo -- You received this message because you are subscribed to the Google Groups