Re: [sympy] Re: Lagrangian Mechanics

On Wednesday, August 1, 2012 5:23:52 PM UTC-5, Gilbert Gede wrote: > > A number of points here... > > What is returned from the class: I setup the Kane class to return just the > differential equations that it calculates, and not do any rearranging. In > order to get rearranged quantities, I us

Re: [sympy] Location for Tr operation

For matrices it looks like this: http://en.wikipedia.org/wiki/Kronecker_product Cheers, Brian On Wed, Aug 1, 2012 at 4:26 PM, Matthew Rocklin wrote: > Can you define tensor product then? Are you referring to hadamard / > elementwise product? > > On Aug 1, 2012 6:02 PM, "Brian Granger" wrote:

Re: [sympy] Re: Lagrangian Mechanics

On Wednesday, August 1, 2012 11:59:19 AM UTC-5, Luke wrote: > > I like the approach Jason outlined though I'm not 100% sure whether > mass_matrix & forcing should be properties or methods. If these > matrices are being formed when you call: > > lag.lagrange_equations(simplify=True) > > then

Re: [sympy] Location for Tr operation

Can you define tensor product then? Are you referring to hadamard / elementwise product? On Aug 1, 2012 6:02 PM, "Brian Granger" wrote: > On Wed, Aug 1, 2012 at 1:55 PM, Matthew Rocklin > wrote: > > I'll reply more substantially in a bit (busy at work now) but I'll put > in a > > quick word now.

[sympy] Re: Lagrangian Mechanics

On Wednesday, August 1, 2012 9:31:52 AM UTC-5, Jason Moore wrote: > > I'm of the opinion that you should supply all the necessary information in > the __init__ method of the Lagrange versus having all the setter methods. > Stefan points this out too. The __init__ method should require the bare

Re: [sympy] Re: Lagrangian Mechanics

On Wed, Aug 1, 2012 at 4:23 PM, Gilbert Gede wrote: > A number of points here... > > What is returned from the class: I setup the Kane class to return just the > differential equations that it calculates, and not do any rearranging. In > order to get rearranged quantities, I used (@property) attri

Re: [sympy] Lagrangian Mechanics

On Wednesday, August 1, 2012 7:35:20 AM UTC-5, Stefan Krastanov wrote: > > > 1.) Upon having done the kinematics and subequently developing a > lagrangian, > > the user initializes the lagrange object where the lagrangian, L, is the > > argument. > > > > l = Lagrange(L) > What is L? Just an

Re: [sympy] Location for Tr operation

On Wed, Aug 1, 2012 at 1:55 PM, Matthew Rocklin wrote: > I'll reply more substantially in a bit (busy at work now) but I'll put in a > quick word now. > > I think that an optimal version of SymPy would have a dedicated tensor > module. I think that MatrixExpr would subclass TensorExpr. I should c

Re: [sympy] Re: Lagrangian Mechanics

On Wed, Aug 1, 2012 at 12:09 PM, Joachim Durchholz wrote: > Am 01.08.2012 16:31, schrieb Jason Moore: > >> The __init__ method should require the bare >> minimum arguments (lagrangian, generlized coords) and all the others be >> optional, probably as keyword arguments. > > > I'd insist on keyword

Re: [sympy] Re: Lagrangian Mechanics

Jason, I don't think you can do that with Kane right now, as a lot of those methods have no return (and thus return None). On Wednesday, 1 August 2012 15:07:47 UTC-7, Jason Moore wrote: > > Joachim's idea is used in scipy's ode class: > http://docs.scipy.org/doc/scipy/reference/generated/scipy.

Re: [sympy] Re: Lagrangian Mechanics

A number of points here... What is returned from the class: I setup the Kane class to return just the differential equations that it calculates, and not do any rearranging. In order to get rearranged quantities, I used (@property) attributes, to return things which had negligible computational

Re: [sympy] Re: Lagrangian Mechanics

Joachim's idea is used in scipy's ode class: http://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.ode.html#scipy.integrate.ode The Kane class is basically like that and you can write it like: fr, frstar = Kane(N).coords(qi, qdep=qd, coneqs=qc).speeds(ui, udep=ud, coneqs=uc).kindi

Re: [sympy] Location for Tr operation

I'll reply more substantially in a bit (busy at work now) but I'll put in a quick word now. I think that an optimal version of SymPy would have a dedicated tensor module. I think that MatrixExpr would subclass TensorExpr. Matrix expressions would inherit a lot from tensor expressions but I still

Re: [sympy] Location for Tr operation

On Wed, Aug 1, 2012 at 11:02 AM, Matthew Rocklin wrote: > What about having a Trace(Expr) object, a PartialTrace(MatrixExpr) object > (which must be strictly a partial trace, not a full one, I.e. indices can > not equal all_indices) and a function that provides a general interface. That is a poss

Re: [sympy] Location for Tr operation

Matthew, On Wed, Aug 1, 2012 at 10:47 AM, Matthew Rocklin wrote: > I am still -1 on this. There is a larger discussion lurking here though. Right now, the vision of matrix expressions leaves out a huge class of operation involving matrices, namely those related to tensor products. Many operati

Re: [sympy] Re: Lagrangian Mechanics

Am 01.08.2012 16:31, schrieb Jason Moore: The __init__ method should require the bare minimum arguments (lagrangian, generlized coords) and all the others be optional, probably as keyword arguments. I'd insist on keyword arguments. At about three positional arguments, it starts to become easy

Re: [sympy] Location for Tr operation

What about having a Trace(Expr) object, a PartialTrace(MatrixExpr) object (which must be strictly a partial trace, not a full one, I.e. indices can not equal all_indices) and a function that provides a general interface. I would be much happier with this. I would still push for 1) _eval_trace belo

Re: [sympy] Location for Tr operation

I am still -1 on this. I have no problem to an unevaluated PartialTrace object living in matrix/expressions. I just think that it should be separate. Here are some of my concerns. >From a user perspective having two separate classes is simpler in expectation. 99% of the time a user will want Tra

Re: [sympy] Location for Tr operation

Guru, Thanks for summarizing things and making a recommendation. I agree with your proposal. On Wed, Aug 1, 2012 at 9:33 AM, Guru Devanla wrote: > I went through the entire thread again, I feel we should just move the > > 1. Tr module into matrices/expressions > 2. Decide between inheriting f

Re: [sympy] Re: Lagrangian Mechanics

I like the approach Jason outlined though I'm not 100% sure whether mass_matrix & forcing should be properties or methods. If these matrices are being formed when you call: lag.lagrange_equations(simplify=True) then it seems like they should be properties rather than methods. However, this opens

Re: [sympy] Location for Tr operation

I went through the entire thread again, I feel we should just move the 1. Tr module into matrices/expressions 2. Decide between inheriting from Expr or MatExpr. I would let it inherit from MatExpr, but set is_Matrix = false, if indices = all_indices. 3. And *not* have 2 classes, since except

Re: [sympy] Experiences with sympy in teaching?

We gave a python course for engineering students this semester (and in Spring 2011). It was quite mechanical-oriented (3D Visualization, Multibody-Systems, ...) but included one lecture about sympy (Lagrangian equations). This maybe might serve as a application example. see http://www1.inf.tu-dr

[sympy] Re: Lagrangian Mechanics

I'm of the opinion that you should supply all the necessary information in the __init__ method of the Lagrange versus having all the setter methods. Stefan points this out too. The __init__ method should require the bare minimum arguments (lagrangian, generlized coords) and all the others be option

Re: [sympy] Lagrangian Mechanics

> 1.) Upon having done the kinematics and subequently developing a lagrangian, > the user initializes the lagrange object where the lagrangian, L, is the > argument. > > l = Lagrange(L) What is L? Just an expression? > > 2.) The user then supplies a list of generalized coordinates using the > coor

[sympy] Lagrangian Mechanics

I have been working on the addition of lagrangian mechanics to sympy.physics.mechanics and I was hoping to get some input, suggestions or recommendations on it. Equations of motion are generated using Lagrange's equations of the second kind

Re: [sympy] Experiences with sympy in teaching?

On 08/01/2012 04:08 AM, Ingolf Schäfer wrote: Dear all, I am a lecturer for mathematics and considering to use Sympy in a supplemental calculus course for future math teachers. Does anyone have experiences with sympy in this context and is willing to share them? Yours, Ingolf -- You receive

Re: [sympy] Experiences with sympy in teaching?

I don't have personal experience myself, but I've heard from others who teach with Python (not necessarily with SymPy) that the IPython notebook is a great tool for this. You can use it in conjunction with sympy by using the --profile=sympy option, which will start it with everything from SymPy im

[sympy] Experiences with sympy in teaching?

Dear all, I am a lecturer for mathematics and considering to use Sympy in a supplemental calculus course for future math teachers. Does anyone have experiences with sympy in this context and is willing to share them? Yours, Ingolf -- You received this message because you are subscribed to th