to
a wiki page shortly:
https://docs.google.com/document/d/1Egkw9VkXcIYOiXonKFGRU00gycoA7w4Oq4M085d0fAg/edit?hl=en
-Gilbert Gede
--
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 unsubscri
Hi,
I wanted to let everyone know that I've uploaded my proposal to the github
wiki pages, if you wanted to read more about the plans for PyDy. Thanks.
https://github.com/sympy/sympy/wiki/GSoC-2011-Application-Gilbert-Gede:-PyDy
-Gilbert
--
You received this message because you are subsc
In PyDy (which we plan to merge into SymPy.physics.classical this summer)
Vector is one of the classes already implemented (along with UnitVector).
Vectors extend Basic, and UnitVector extend Expr.
The way it works now, you can't use Vector as part of a SymPy expression:
In [57]: test
Out[57]: x*n
So I think we've decided to make a new Vector class, to replace the
previous UnitVector and Vector classes, and it will not extend any
other sympy classes. It will use sympy's matrix class. The current
plan is for each vector to have a list of lists; the inner list will
be the coefficients of eac
Hi,
I was trying to implement some functionality for PyDy for this year's GSoC,
and was looking for some advice.
In dynamics problems, you usually have time-varying quantities, like
generalized coordinates, speeds, and accelerations. Often, you want to take
the partial derivative of an expression
ols. I don't think I've
> ever seen anyone suggest extending Symbol to hold a time derivative, which is
> essentially just a more formal way of doing the substation method. It might
> work.
>
> Aaron Meurer
>
> On Jun 3, 2011, at 6:05 PM, Gilbert Gede wrote:
>
>
&g
I guess I should have asked this as well; is it considered bad to
write diff() and replace the current Sympy diff() within my code? Or
is that OK?
-Gilbert
On Jun 3, 6:38 pm, Gilbert gede wrote:
> Yeah, I had read some of them. I had already thought of writing my
> own Diff met
g _eval_derivative()?
>
> Aaron Meurer
>
>
>
>
>
>
>
> On Fri, Jun 3, 2011 at 7:48 PM, Gilbert gede wrote:
> > I guess I should have asked this as well; is it considered bad to
> > write diff() and replace the current Sympy diff() within my code? Or
> &
Yeah, if you try diff(x,y), the method is not called.
Ronan, I'm not sure how to do what you're describing? How would I
call that?
-Gilbert
On Jun 3, 7:32 pm, Ronan Lamy wrote:
> Le vendredi 03 juin 2011 à 19:16 -0700, Gilbert gede a écrit :
>
> > You're talking ab
.
-Gilbert
On Jun 3, 9:09 pm, Tim Lahey wrote:
> On Fri, Jun 3, 2011 at 8:05 PM, Gilbert Gede wrote:
> > Can anyone give some insight into how I could get this desired behavior,
> > taking the derivative of an expression wrt a time-differentiated symbol, to
> > work in
Right now, I made a timevaryingsymbol class; it's diff is indeed
rewritten and works. The problem is once you put that inside an add
or mul, it's diff method no longer gets called.
On Jun 3, 9:28 pm, Renato Coutinho wrote:
> On Sat, Jun 4, 2011 at 1:18 AM, Gilbert gede wrote:
&
Adding Symbol('t') to the free_symbols property of my class worked!
Here's what it can do now:
In [1]: run kinematics.py
In [2]: x = TVS('x')
In [3]: y = TVS('y')
In [4]: t = Symbol('t')
In [5]: diff(2 * x**2 + 4 + y,t)
Out[5]: 4*x*xdt + ydt
In [7]: diff(diff(2 * x**2 + 4 + y,t),TVS('xdt'))
O
My Summer of Code project is writing a submodule of SymPy for creation of
symbolic equations of motion for multibody systems. As part of this, I've
implemented classes to represent vectors and dyadics. I have currently
implemented three ways to do mathematical operations on vectors: an
operator, a
I chose the & to represent dot product specifically because of its
meaning of and/interection in Python; that is how I view the dot
product of two vectors, as the common component between two vectors. I
decided to only use * for scalar multiplication, to further reinforce
that operations between ve
So, for my Summer of Code project, I'm writing a submodule to generate
equations of motion for multibody systems. Sometimes the expressions
in these equations are very large. I'm finding some of these
expressions are prohibitively large when printing. Here is an example
of one element in one of the
On Aug 17, 1:46 am, Mateusz Paprocki wrote:
> Hi,
>
> On 17 August 2011 09:50, Gilbert gede wrote:
>
> > So, for my Summer of Code project, I'm writing a submodule to generate
> > equations of motion for multibody systems. Sometimes the expressions
> > in
ure right now. My
other option is just changing the _print_Add and _print_Mul methods in
my custom printer to get the speed I want, if people don't like the
idea of adding that option to the main SymPy printer?
-Gilbert
On Aug 17, 11:48 am, Gilbert gede wrote:
> On Au
d be useful. Please also do it for the
> other printers, and add a note do the docstring(s) noting that it can
> be used to increase the speed of printing large expressions.
>
> Aaron Meurer
>
>
>
>
>
>
>
> On Fri, Aug 19, 2011 at 10:42 PM, Chris Smith w
, with the option {'order':"unsorted"} added to your
> printer, it takes 34 seconds.
>
> And by the way, 30 seconds is just the setup time. The rest is the
> actual printing.
>
> Aaron Meurer
>
>
>
>
>
>
>
> On Sat, Aug 20, 2011 at 11:17
.3099880219
**2 - 110.837440014
**3 - 670.745126009
no printing speed-ups
KM.mass_matrix
**1 - 264.041971922
**2 - > 3600
On Aug 28, 11:32 am, Aaron Meurer wrote:
> On Sat, Aug 27, 2011 at 3:58 PM, Gilbert gede wrote:
> > Not 100% clear on this: a
Two problems here:
First: you've added a torque term which applies to ReferenceFrame B,
tau*A.z. There are 2 potential issues with this. One, if possible,
you should describe the torque in the same ReferenceFrame in which the
angular velocity of the "torqued" frame is described in. Here,
B.ang_vel
I might still be misunderstanding.
>
> updated gist:https://gist.github.com/1665634
>
> On Jan 23, 8:14 pm, Gilbert gede wrote:
>
>
>
>
>
>
>
> > Two problems here:
> > First: you've added a torque term which applies to ReferenceFrame B,
> > t
Angadh was one of the students who had to learn how to use
physics.mechanics for class this past quarter. I think he would be in
a good position to improve the documentation for this submodule,
considering he just had to learn it on his own. I think I did a good
job on the documentation, but just d
While the idea of a System class is initially appealing, there could
be some serious negative implications of attempting this.
For multibody systems, there can be a large number of internal forces
in contacts and joints (non-contributing forces). With Kane's Method
or Lagrange's Method, you do not
Tim,
I can try and explain why a few of these things are the way they are.
As we have learned to deal with inertias for multibody systems, it has
made the most sense to use dyadics, as they are reference frame
independent (as Jason stated).
I understand your confusion with the RigidBody example n
Inertia dyadics are fixed to the frame they are originally defined in;
you cannot rotate a fixed vector/dyadic in its frame, but you can
rotate the frame they are fixed in relative to another frame. What you
can then do, for both dyadics and vectors, is express them in this
different rotated frame.
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
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.
Hi Wolter,
I suppose there are a few questions that need to be answered to determine
if the physics/mechanics module would suit your needs. My first question:
are the systems you are going to study statically determinate (can the
reaction forces be solved for algebraically)? If the answer is no,
I added a few more points to our entry on the Ideas page, and my name as a
mentor.
We came up with a rough roadmap for PyDy (http://pydy.org/roadmap), and I
actually think there is enough work for a student's GSoC project that would
be entirely within SymPy. That being said though, at this poin
I've had similar problems using lambdify with symbols with funny characters
or unfriendly formatting. My solution was to substitute in Dummy symbols
for everything I knew would be problematic, which solved my problem. Is
there a case when that behavior could be bad, or would implementing this
m
This sounds like it could be a good project (or rather a decent part of a
GSoC project). Vector/ReferenceFrame were indeed written for the needs of
the mechanics module, and not for general SymPy use. This meant a slight
focus on time (as Stefan mentioned) and a big focus on multiple reference
This is a good discussion. As Jason mentioned, us mechanics people have
been discussing a bigger "world" environment lately. Specifically, we've
been trying to understand where analytical formulations fit in a world of
numerical simulation. Unfortunately, and unsurprisingly, we haven't made
muc
Hi Eduardo,
I'm not sure how closely this aligns with the type of problems you're
working with, but the physics.mechanics submodule was written for multibody
dynamics problems (http://docs.sympy.org/0.7.2/modules/physics/mechanics).
Right now, what it does well is generate the symbolic equations
I think Stefan probably did a better job with the terminology than I could
do, and covered a lot of points. Unfortunately, as a mechanical engineer,
my terminology is a bit sloppy on these topics.
What ReferenceFrame really does, is provide a set of orthonormal basis
vectors to define other vec
I think Stefan has already covered many good points here.
I would request that in addition to the mock sympy sessions, you also write
out (by hand or using something like LaTeX) the problems and make them
available on the same wiki page. I find it helpful to see the notations
people are working wi
Monday (10:00) for me works. How about we all log onto IRC at that time,
and decide where to work/discuss then?
-Gilbert
On Fri, May 31, 2013 at 4:03 AM, Prasoon Shukla wrote:
> Monday is good for me. I will be done with the project by Saturday night.
> Time for the meet doesn't matter mostly f
Sachin,
I like where you are going with this. If I'm interpreting it correctly,
each CoordinateSystem has to be attached to a ReferenceFrame, and is fixed
(although possibly rotated and/or translated upon coordinate system
definition) with respect to that ReferenceFrame? Prasoon, Stefan, others -
w
I believe that the part about different origin for the time variable has
been taken out? I agree though, it seemed to add an unnecessary level of
complication.
But I left some comments and questions throughout the wiki.
On Thu, Jun 6, 2013 at 2:48 AM, Stefan Krastanov wrote:
> Gilbert, could y
Sachin put a link to this wikipedia article in the wiki:
http://en.wikipedia.org/wiki/Frame_of_reference#Different_aspects_of_.22frame_of_reference.22
The way I have read the page is that coordinate systems should not change
relative to the reference frame they are defined in; the conclusion I
deve
Stefan,
I think I disagree about Reference Frames being immutable. If you are going
to create a series of Reference Frames when performing successive
rotations, you are going to need to need to be able to modify the original
frame to point to the new frames. There is a similar issue for setting the
rn phi*unit_vector.
>
>
>
> On 11 June 2013 02:39, Gilbert Gede wrote:
> > Stefan,
> > I think I disagree about Reference Frames being immutable. If you are
> going
> > to create a series of Reference Frames when performing successive
> rotations,
> &g
Prasoon,
That option does not work for ReferenceFrame. If I have a ReferenceFrame A,
and another ReferenceFrame B, and want to set the angular velocity of B in
A as
w_1*b_1 + w_2_* b_2 + w_3 * b_3
I need access to the basis vectors of B, which I won't have until after the
frame is initialized. Anot
I'd like to reiterate the concerns of the mechanics people, in that there
needs to be a more serious consideration of ReferenceFrames and the
end-users' ability to make changes to them after they are instantiated.
It's easy to gloss over this problem when you're looking at one or two
frames, but wh
Yes Stefan, I think you are articulating our concerns well. And while I've
never done the rect/spherical/rect transform, just going back and forth
between rect. frames causes similar issues with trig expressions not
collapsing.
I'd like to know more about the mutability of diffgeom's CoordSystems
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
I think Sachin has some good suggestions. I would advocate something
similar (which is also similar to what mechanics currently has): why not
just create the base scalars and basis vectors upon initialization of a
coordinate system? There should only be one set of basis vectors and base
scalars for
Prasoon,
My first question is this - can position vectors be written using
coordinate variables (base scalars in your codebase, I believe) - i.e. if
the user has CoordSys "A" with coordinates ax, ay, az, can they define a
new coordinate system using the position vector p = ax * e_A_x + ay * e_A_y
+
Yes, perhaps I wasn't clear. That first vector p = ax * e_A_x + ay * e_A_y
+ az * e_A_z is not the same as the vector p^{AB}, as I was assuming you
could not define position vectors in that form (ax * e_A_x + ...).
The vector p^{AB} would be something like p1 * e_A_x + p2 * e_A_y + p3 *
e_A_z. The
I think you should split the operation into 2 steps: 1) expression of basis
vectors in new frame and 2) expression of coordinates in new frame. This
way, if the user only wants to do one or the other, they are able to.
I think you should have the order for the complete re-expression being 1)
and t
Yeah, in the PR Aaron pointed out there is some code profiling I pastebin'd
in the comments.
I haven't gotten around to implementing the expand functionality yet - I
still had some questions for you Aaron. When you sugessted we promote
_expand_hint() to a user-level function, what did you mean by t
So, just applying @cacheit to Derivative.new() provides the 60% reduction
in time for the bike test, and all SymPy tests pass. I also tried cacheing
Basic.free_symbols. That (combined with the Derivative.new() cache) gave a
87% reduction in time for the bike test (~150s -> ~20s). Unfortunately, a
l
130 MB w/ no caching added, 150 MB w/ Derivative.new() cached, 160 MB w/
Derivative.new() and Basic.free_symbols() cached.
I'm going to work on this semi-localized cache thing right now.
On Wed, Aug 7, 2013 at 6:44 PM, Aaron Meurer wrote:
> On Wed, Aug 7, 2013 at 6:04 PM, Gilb
Hi,
I've started to play around with localized caching, but in order to
(effectively) do that, I needed to get the test suite to pass with the
cache turned off. I've opened a PR with some changes
(https://github.com/sympy/sympy/pull/2387) but it still has 2 errors, from
diffgeom and strategies
Prasoon,
Is this from PR 2208? If so, it looks like the only ._args for a
BaseScalar are the associated CoordSys and the position, and not the name
itself. Obviously if they have the same position the second args will be
equal. I bet if the CoordSys are evaluating as True, that is the cause of
you
Prasoon,
Take a look at these outputs.
In [5]: cs.theta.args
Out[5]: ()
In [7]: cs.theta._hashable_content()
Out[7]: ()
cs.theta.__eq__ uses Basic's .__eq__, which in turn compares
_hashable_content() between the two objects. So, I think you should be
using .args instead of .coord_sys and .posit
ambdify.py#L279don't
> make a lot of sense to me. I'm not sure why the dummify is set to
> True only under those specific conditions.
>
> If dummify is overridden to always be true, the function seems to work as
> expected.
>
> Gilbert Gede made those changes.
13 at 12:02 PM, Gilbert Gede
> wrote:
> > Looks like in lambdify one of the checks for dummification is broken.
> I'll
> > open a PR in a minute here.
> >
> > The dummification was only supposed to happen on numerical translation
> > though, so modules='sympy
ication is
needed, and there are implemented functions or the desired module is
'sympy'? If so, we should add dummification as a flag.
-Gilbert
On Sunday, September 1, 2013 4:24:36 PM UTC-7, Matthew Brett wrote:
>
> Hi,
>
> On Sun, Sep 1, 2013 at 12:38 PM, Gilbert Gede
>
and it is completely backwards compatible.
>
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Wed, Sep 4, 2013 at 3:16 AM, Matthew Brett
>
> > wrote:
>
>> Hi,
>>
>> On Tue, Sep 3, 2013 at 8:08 PM, Gilbert Gede
>> >
>> wrot
Hi,
I've playing around with implementing a different caching strategy:
"user-level" functions within which the cache is enabled and after which
the cache is cleared. I've opened a PR for the work in progress here:
https://github.com/sympy/sympy/pull/2448
I'm not sure if it's the best approach
I think a really common example that came up in mechanics was with trig
expressions. Here's a simple example (simple relative to actual mechanics
expressions):
sin(q1(t))*sin(q2(t))*cos(q1(t)) / (sin(q1(t))*sin(q2(t)) +
sin(q1(t))*cos(q2(t)))
When I substitute in q1(t) = 0, q2(t) = 0, I get nan.
In physics.mechanics, I actually tried to side-step this entire problem, by
just using .x, .y, and .z for the three directions. We also allowed for
users to define a custom string for an index, and access that direction via
a dictionary using the index they defined (['1'], ['2'], ['3'], or ['i'],
[
I always thought an interesting approach would be a handwriting -> LaTeX
translator, and then a LaTeX -> SymPy translator (although I'm not sure if
it would be LaTeX code, or an actual LaTeX document). Seemed like it would
allow for a little more flexibility and would be made of smaller, more
tract
Jason, I've definitely seen examples where small errors in subtraction can
lead to larger errors later on - especially if things are supposed to
cancel out. In our domain, I think it pops up in mass/inertia division
operations. I'm not sure how often it happens with real-world examples vs.
academic
65 matches
Mail list logo
