I think Gilbert has a point. Some users may want to just convert the vector
wrt the basis vectors, without substituting the coordinate vars. Maybe a
'vars' arg to express?
So, if I want the coordinate vars also to be converted, express(vect,
vars=True)
by default, express(vect, vars=False)
On
Sorry for the late reply. Was busy with assignments.
Anyway, so here's how we can proceed with this. First, we need to have all
the base vectors and base scalars changed to rectangular coordinates. That
I think, will be easy using the methods that I have written.
Next comes the conversion of
It won't cause a recursion error. If we define a helper function to just do
the 'multiply DCM with the column vector' part, then that's all that we
will have to call to convert the Pos vector of B wrt A, in terms of A
(since they won't contain coordinate variables).
Hence, the actual 'express'
Okay, I'll try this approach and report back.
--
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 to
@All: This is a cry for help.
I am completely stumped at the *express* method. The implementation that I
had before had a flaw that I hadn't noticed until now (until Gilbert's PR
on by branch). Anyway, let me try to describe the situation.
Initially, I had an separate method that would take a
You may want to use the method I used while hacking the old mechanics
module to do the kind of re-expression we want to achieve. say a vector v
from frame A to frame B
First, we need to calculate the coordinate variables of frame A in terms of
those of B.
We can do this using -
[vector of A's
(I am Cc-ing this to Gilbert and Stefan too. Guys, please read the last 2
messages in this thread.)
I do not think that the method is quite as simple. For starters, we have
different coordinate systems - not just rectangular coordinates. But I
suppose, that can be taken care of.
Let us
Ya, I agree quite a bit of handling-the-symbols would be required. Maybe,
we could cache the relationships (dicts) between coordinate variables of
different frames?
Then, when 'express' is called, just iterate through the atoms of the
vector expression and note the systems whose variables we come
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
Thank you Prasoon. This year's GSoC is a year later than it usually
is, so we are going to be seeing more of this before the end
unfortunately, both for the students and some of the mentors (myself
included).
Aaron Meurer
On Wed, Jul 17, 2013 at 10:58 PM, Prasoon Shukla
prasoon92.i...@gmail.com
Hello all. I just wanted you to know that I haven't been able to work for
the last two days. This is because a new semester just started in college
and there was a *lot* to get done and there still is.
I will try to cover up for this lost time in the weekend.
Thanks.
--
You received this
Hmm. I tried that going from frame[99] -frame[0] -frame[98].
Just finding out frame[99] - frame[0] was taking forever so I stopped the
process.
Nevertheless, I tried a few test and I think that going through global
might take longer after all - not for all the situations, but for most.
Sachin
@Prasoon, maybe I misunderstood what you suggest, but on first glance it
seems it will work awfully in the following case:
coordinate systems:
A (carthesian) - B - many more - U - V
where U and V have the same origin and orientation but U is carthesian
while V is polar.
How will something
@Stefan : For the case you mention, there's another step that converts
between coordinate systems. For the case of U and V (as you mentioned),
we'll just convert from U to V. Here are the steps:
1. We substitute for x, y, z (base scalars of U) in terms of rho, phi, z
(base scalars of V). Then,
When Gilbert used the base scalars in the vector expression, the equation
was just the mathematical way to convert the base scalars from one frame to
another. It wasnt a position vector per say. The point was, that the
relations that you would get between the variables on the lhs and rhs are
the
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'm having some problems with implementing the `express` function. This
function would be called on a vector and would take a CoordSys object as
and argument. The function should return a vector expressed in the CoordSys
provided to this method.
Now, as a first step, we need to take care of
DCM helps in modeling of relationship between base vectors as well as base
scalars.
The re-expression of a vector V in a frame A should proceed in three steps-
1) Substitute base scalars of all other frames except A, in terms of A, in V
2) Separate the vector we get from step1 into its
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
+
+1 to Gilbert's idea of not going to global frame. That's what I was doing
initially, but we can get rid of that method by using a _frame_path
function which will give the tree 'path' between any two frames. In this
'path', the pos vector and DCM of every frame wrt its former will be
defined (as
Sachin, I responded to your question in the PR.
I think I'll go with Gilbert's approach. As far as the second part was, we
will take the first approach - the reason is that we have three different
classes that handle vectors - and we need to be able to apply those
operation on each class.
Hmm. It seems Python allows one-to-one relationships between objects. So, I
did this:
In [64]: class Vector(object):
: def __init__(self, coord_sys):
: self.coord_sys = coord_sys
:
In [65]: class CoordSys(object):
: def __init__(self):
@Gilbert, @Sachin, @Stefan : I am facing a bit of a problem that I have
written about in this week's blog
herehttp://musingsofafriend.wordpress.com/2013/07/06/gsoc-week-3-sympy-development-finishing-the-basic-structure/.
Please see the second part of the blog where I mention about a cache to
Two things-
1.) I think we should stick to the current mechanics framework's ideology
of not letting the user initialize a base scalar/vector. As I have
commented on your PR, we can define __getattr__ and __getitem__ methods for
the CoordSys class, which would enable a user to use the 3rd (say)
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
Okay, so since there hasn't been any activity on this thread, let me post
the link to my code :
http://github.com/prasoon2211/sympy/tree/vector
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails
Make a pull request please, so we can have diffs and line comments
visible for everybody.
On 25 June 2013 13:11, Prasoon Shukla prasoon92.i...@gmail.com wrote:
Okay, so since there hasn't been any activity on this thread, let me post
the link to my code :
Alright then, I'll make one in a few hours.
On Tuesday, June 4, 2013 2:46:22 AM UTC+5:30, Stefan Krastanov wrote:
Today we had the first discussion with Prasoon and Sachin about their
projects.
We did not progress much but at least we outlined the two general
approaches that we can use
@ Everyone : I couldn't do any work today - I had to make an unexpected
trip to a certain city and back. Traveled a total of 15+ hours and got
stuck in a 3 km long traffic jam. I had thought that I'll be able to work
while travelling - I have never been more wrong :(
Anyway, I just got back.
Thanks for the summary. I will be on IRC at the specified time.
On 16 June 2013 21:24, Prasoon Shukla prasoon92.i...@gmail.com wrote:
I, Gilbert and Sachin met up today on the IRC. We talked about how exactly
will we implement the Reference Frames - that is - how the data regarding
position
Okay so I just talked with Sachin on this. As Gilbert says, we should plan
before we start work.
Initially, my proposal had a distinction between a CoordSys class and a
RefFrame class. We are at a similar point now. Nevertheless, the two ways
we thought this could work was by:
a) Subclassing
Maybe I am simply missing something, but I do not understand why
anything more complicated than option (a) would be considered. Prasoon
just implements vector fields as they are meant in math (with static
orientations) and Sachin adds a parametrization to these orientations
(the parameter being
Considering IRC - I can attend on Monday for instance (in the
morning for the West Coast, evening in Europe and India)
On 16 June 2013 12:16, Stefan Krastanov krastanov.ste...@gmail.com wrote:
Maybe I am simply missing something, but I do not understand why
anything more complicated than option
Yeah. I can be there at 9:30
On Sun, Jun 16, 2013 at 6:33 PM, Prasoon Shukla prasoon92.i...@gmail.comwrote:
Alright then. We will go with option (a). @Gilbert and @Sachin, can you
come on the IRC tonight?
--
You received this message because you are subscribed to a topic in the
Google
I, Gilbert and Sachin met up today on the IRC. We talked about how exactly
will we implement the Reference Frames - that is - how the data regarding
position and orientation will be stored. Here's the conclusion we reached:
1. The vector module will have a RefFrame class that supports
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 wonder if it would be best to remove the concept of a reference frame
from Prasoon's api design. Then the mechanics and electromagnetics modules
will need to implement that on our side on top of the coordinate system
classes.
Jason
moorepants.info
+01 530-601-9791
On Fri, Jun 14, 2013 at
@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
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,
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
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
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 prasoon92.i...@gmail.com
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
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
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
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
@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
Why the asymmetry Mul vs VectAdd?
On 14 June 2013 09:48, Prasoon Shukla prasoon92.i...@gmail.com wrote:
Alright then. Looking at the answers that Matthew has provided, here's what
we will do:
Coordinate systems and reference frames will not be implemented separately.
There will be RefFrame
Any additional methods that are provided will _not work_ if they do
not have access to the RefFrame objects (in order to know how to
transform between coordinates). Your proposal does not explain how
these RefFrame objects will be accessed.
Because of this, the only advantage of subclassing Add
Also, Gilbert and I had a small question. How do you plan to implement
expression of Vectors in different frames? Also, the relationships between
the frames? Could you give an API and the basic idea of how those methods
will work?
The main concern the mechanics group has, is the modeling of
Any additional methods that are provided will _not work_ if they do
not have access to the RefFrame objects (in order to know how to
transform between coordinates). Your proposal does not explain how
these RefFrame objects will be accessed.
But they do.
I'll try to explain the
I see. This makes sense. I dislike the creation of a new class just
for the sake of adding helper methods (it mixes functions and data in
an unaesthetic way), but this is just my preference, so I will not
raise an objection if this is what you prefer.
The big issue now is how well will this work
On Friday, June 14, 2013 3:39:20 PM UTC+5:30, Sachin Joglekar wrote:
Also, Gilbert and I had a small question. How do you plan to implement
expression of Vectors in different frames? Also, the relationships between
the frames? Could you give an API and the basic idea of how those methods
Ok. So I guess same will apply when we want to express some VectAdd in one
frame.
And there is going to be a BaseScalarField class right? To enable
expression of scalar fields in particular frames?
On Fri, Jun 14, 2013 at 5:38 PM, Prasoon Shukla prasoon92.i...@gmail.comwrote:
On Friday, June
We will need to have symbols for different frames, so yes, we will have a
BaseScalar like class that just instantiates the symbols to be used.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from
Also, Gilbert and I had a small question. How do you plan to implement
expression of Vectors in different frames? Also, the relationships between
the frames? Could you give an API and the basic idea of how those methods
will work?
The main concern the mechanics group has, is the modeling of
@Matthew Rocklin:
Can you please tell what exactly would be the advantage of having a
separate VectAdd class? I mean I don't see the problems with using the
current Add and Mul classes.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe
I don't remember enough of the details to give you a comprehensive answer.
Here are a few thoughts that come to mind.
You won't be able to change much of the Add and Mul code to handle Vectors.
For example you won't be able to add shape checking at construction time.
This forces you to follow
Personally, I like Mathew's idea of using MatrixExprs to represent vectors.
This will not just ensure smooth functioning with the rest of sympy, but
will also help in easing the 'garbage detection' process. Plus,
representation (as well as stuff like pretty printing) would get easier.
The only
I do not see any problem with using MatExpr instead of Expr for this
GSoC project. The only difference from what we discussed on IRC
yesterday is that instead of using Symbol as a superclass for
BaseScalarField (i.e. x y z) and BaseVector (i.e. the unit vectors
along x y z) you will use
@Stefan, I think we should let Prasoon put forth his idea of the API as
discussed yesterday first. We will discuss it and ensure that we cover all
ground. If alls well with it, we can move forward with that. Just a thought.
On Thu, Jun 13, 2013 at 7:27 PM, Stefan Krastanov
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
It seems like mechanics applications operate on a deep tree of objects. Is
it correct to put all of these inside SymPy? The lower levels should
certainly be SymPy objects but perhaps some of the higher levels are
sufficiently application-centric and require enough performance that they
should
I just feel that we are getting stuck with and spending too much time on
things that we shouldn't be taking this much time. Therefore, I request again
to all parties involved : Please voice your views/problems with these
structural changes suggested so that we can move ahead with things.
I
Well alright. Since the discussion is supposed to be done publicly, I think
Sachin and I can discuss this on IRC. So, I have written an email to him
inviting him to IRC, today 21:00 IST.
Also, the API suggested by Stefan looks like something to go forward with,
albeit with some changes.
For
Lets get together on the irc one time today. Lets settle this so that we
can come to a consensus. Prasoon and I will be there in 1.5-2 hours. If
possible, @Stefan, do come online
On Wed, Jun 12, 2013 at 7:52 PM, Stefan Krastanov
krastanov.ste...@gmail.com wrote:
For the mutability issue :
For the mutability issue : Just as Aaron suggested, we do really need the
objects to be mutable. Doing something as
If I understand correctly, Aaron's main point was that mutability is
useful only in certain cases and I do not think that the current
module requires it. Most of the arguments in
On Wednesday, June 12, 2013 7:52:34 PM UTC+5:30, Stefan Krastanov wrote:
For the mutability issue : Just as Aaron suggested, we do really need
the
objects to be mutable. Doing something as
If I understand correctly, Aaron's main point was that mutability is
useful only in certain
Stefan,
I just read through your proposed API. In general it seems reasonable but
Luke, Gilbert and I spoke last night on irc (logs:
http://colabti.org/irclogger/irclogger_log/sympy?date=2013-06-12) about how
to deal with immutability/mutability, subclassing from Basic/Expr, and
garbage in/out.
about immutability and reference frame: I guess I do not understand
the details of what you describe. Anyway, I will not be against
immutability if it does not mess up with `__eq__` and `__hash__` so it
depends on the implementation.
about Vector: if it is not a subclass of Expr it will not be
Can we define our own simplify method for Vector that simplify(Vector) will
call?
Also, if Vector will is a subclass of Expr, how can we avoid something like
unit_vector * unit vector or Scalar+Vector?
On Tue, Jun 11, 2013 at 1:40 PM, Stefan Krastanov
krastanov.ste...@gmail.com wrote:
about
For an example of successive rotations, check out the second code block
here: http://docs.sympy.org/0.7.2/modules/physics/mechanics/examples.html
Regarding Vector, should the user being to perform any action they could on
another Expr object on a Vector object? If it inherits from Expr, would
You can define and _eval_simplify method:
That is cool. But many such methods will have to be defined and most
of the time it will be just copy pasting from Expr with maybe minor
changes. Fixed done to the core or changes of api will have to be
redone for Vector. And many sympy methods simply
Maybe we could subclass from Basic, maybe even Expr.
We should just ensure *wrong* operations on Vectors return an error. (One
of which Gilbert mentioned)
Stefan, could you put up your idea of the API for the stress test on the
wiki? That would give us (Prasoon and me) a direction.
On Tue, Jun
I will do it in the evening. And obviously my suggestions can be
flawed, but I will try to explain why I prefer it in places where it
differs from what you suggest.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop
Let us get some things clear here. Vector is going to be subclassed from
Basic. Also, after seeing the discussions/problems above, Vector + Vector
will give an Add on which we can call something akin to a .doit() to result
in a Vector. I do not see any problems with this approach.
Next,
@Prasoon, Vector + Vector is fine. What about vector * vector or scalar +
vector or any other such nonsense operation? If you are going to subclass
from Basic, this can be done with handling of the operators as I have
already pointed out. But how we will do this without operator overloading
in
I'm only skimming over this thread but I noticed that the Basic/Expr
question came up.
MatrixExpressions used to inherit from Expr for exactly the reasons Stefan
said (lots of things work out of the box). This was great for startup but
eventually became a major pain. At some point I rewrote
This is also one of the ways to go forward. I personally dislike it because:
- A non trivial amount of functionality needs reimplementation
(flatten for instance)
- We do not have standard correct way to interface with functions
like factor, symplify, had, get, atoms, etc, so it is hard to be
A non trivial amount of functionality needs reimplementation (flatten for
instance)
True, however I think you'll find that flatten does things that you don't
want. Much of the Expr code makes scalar assumptions that might not apply.
I tried to generalize some of my work in matrix expressions
What does it mean to factor vectors exactly?
I was thinking about a*unit_vector + b*unit_vector - (a+b)*unit_vector
But as you said there are many others that do not make sense for vectors.
In contrast the other way has proven to work in physics.quantum. They're
both reasonable.
And also
On Tue, Jun 11, 2013 at 10:14 AM, Stefan Krastanov
krastanov.ste...@gmail.com wrote:
What does it mean to factor vectors exactly?
I was thinking about a*unit_vector + b*unit_vector - (a+b)*unit_vector
My solution was the generic version in sympy/strategies/rl.py. This
particular operation
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.
I am catching up here, so just some random comments on things that
were mentioned:
- Regarding the quantum module, they actually went the opposite route
from MatrixExprs. Originally, they used their own QAdd, QMul, etc.,
but then later it was changed to use the core Add, Mul, etc. I don't
I have made some comments on the wiki. Let us get the API decided so that
both I and Sachin can get started with some work. Thanks.
--
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
+1.
I added one or two comments, they are mostly just clarifications. But I
guess we agree on the basics now.
I will post some hand-written scanned stuff about the math of Stefan's
stress test on my blog in a day, mainly to clarify things in my own mind as
well.
Prasoon, could you expand on the
@Gilbert
If you have the same scalar field, written in a rectangular coordinate
system as x * y * z and in a spherical coordinate system as
r*sin(theta)*cos(phi) * r*sin(theta)*sin(phi) * r*cos(theta), and these two
coordinate systems have the same orientation and origin, the scalar fields
@Stefan. I agree about the tree traversals part. However, I still feel
there must be a way for the user to check if two scalar fields expressed in
different ways are mathematically equivalent. Could you suggest a way?
Maybe just another function?
Also, have a look at the __eq__ function of the
@Stefan. I agree about the tree traversals part. However, I still feel there
must be a way for the user to check if two scalar fields expressed in
different ways are mathematically equivalent. Could you suggest a way? Maybe
just another function?
This is described in one of the first pages
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
Stefan and Prasoon, could you comment on what you gather from that article?
What I got was this -
A reference frame is essentially about a state of motion. Every reference
frame can have various coordinate systems attached to it. These systems may
be oriented (rotated and translated) in certain
@Everyone:
I have added a separate heading towards the end of the wiki page. I would
have done so yesterday but my internet had given up on me yesterday.
Anyway, a few things I'd like to mention before you read it.
First, I did not read the existing wiki page before adding content to it.
This
I have added more questions. I strongly dislike the separation between
CoordSys and RefFrame: such an abstraction is a nice idea, but the current
suggestion is very confusing and some parts of the definitions seem
unnecessary.
At both of you: I still do not see why is there a need for ScalarField
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
Gilbert, could you check what Sachin has written on the wiki about
`ScalarField`, namely the part that it is necessary when using different
origins for the time variable.
IMO this is unnecessary complication, but maybe I am missing something.
On 5 June 2013 14:02, Prasoon Shukla
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 krastanov.ste...@gmail.com
Okay then. I have read everyone's comments and also the stress test. At the
moment, I believe that using the things we have discussed in the last two
days, we can have a mock session for this stress test without much
difficulty.
I still think that some of the things I mentioned in the proposal
97 matches
Mail list logo
