Vectors Module Contribution

[Justin]

Hey all,

I posted a message on the message board about contributing to the SymPy package… definitely a bit premature!  I talked about helping with differential equations and got responses about debugging it.  After spending some time looking through the test cases, I must say the system seems stressed enough.  

After taking my time to look through the parts I feel I’d be able to contribute to and comparing that to the level of development, I feel I would be most useful in expanding the vectors module.  I have two years of grad school level physics (Georgia Tech) under my belt, if you were curious.  Is there a team looking to develop this more, specifically adding spherical, cylindrical, and curvilinear coordinate systems to the module? If so, could you put me in touch with them?  If not, let me know and I’ll see what I can do to help out.  There would need to be options added across the board (integration, del operators, etc.) and don’t want to embark on this process if someone else is working on it already!

Also, I really feel this should be done in sympy and not the sympy/physics module; I feel this falls under core mathematics, and they seem to focus on reference frames and what-have-you.

Cheers,

Justin

[Jason Moore]

Justin,

We'd definitely love help with the vector module. As a start you could help review this PR:

https://github.com/sympy/sympy/pull/9937

Note that we have two vector packages. The physics one is older and is specifically designed for doing mechanics. The newer one was designed to be more general, but it is still limited to 3D vectors.

Jason
moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d5d3c49e-49a7-4d51-9155-26995263fe69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin]

Jason,

Ok, I was looking through the changes earlier (and will continue tomorrow).  I have made two important checks thus far:

1) div(curl(A)) = 0

2) curl(grad(f)) = 0

They both check out.  Next, something will have to be done for dot products to check:

3) grad(fg) = f laplacian(g) + 2 * grad(f) (dot) grad(g) + g laplacian(f)

And, the laplacian will need added to deal with vector laplacian to check:

4) curl(curl(A)) = grad(div(A)) - laplacian(A)

I will see what I can do for this as well.  For the time being I'll stay in the dev environment under his branch.  If we are working simultaneously we might need to do some special merges.  I'll see if I can get a hold of him and see where he is at (or, if you (Upabjojr) keep up with posts, message me on here).  I am afraid some sort of pprint() will need to be arranged for this spherical stuff because, as of now, the base scalars and base vectors append spherical_ on the normal ones (x, y, z, i, j, k).

I'll keep in touch.

Cheers,

Justin Blythe

jbly...@gmail.com

[Francesco Bonazzi]

On Monday, 19 October 2015 07:37:12 UTC+2, Justin wrote:

Ok, I was looking through the changes earlier (and will continue tomorrow).  I have made two important checks thus far:

1) div(curl(A)) = 0

2) curl(grad(f)) = 0

Something I'd really like to see changed in the vector module, is the dependence of these operators on the coordinate system. That is, you define the grad, curl, div operators for every coordinate system. This is not necessary, because base_scalars and base_vectors all contain a reference to their coordinate system instance.

In SymPy, remember to access to parameters passed to the constructor with obj.args

They both check out.  Next, something will have to be done for dot products to check:

3) grad(fg) = f laplacian(g) + 2 * grad(f) (dot) grad(g) + g laplacian(f)

And, the laplacian will need added to deal with vector laplacian to check:

4) curl(curl(A)) = grad(div(A)) - laplacian(A)

I will see what I can do for this as well.  For the time being I'll stay in the dev environment under his branch.  If we are working simultaneously we might need to do some special merges.

Did you write some code? Did you post it on github?

 I'll see if I can get a hold of him and see where he is at (or, if you (Upabjojr) keep up with posts, message me on here).

Hello there!
 

I am afraid some sort of pprint() will need to be arranged for this spherical stuff because, as of now, the base scalars and base vectors append spherical_ on the normal ones (x, y, z, i, j, k).

Best would be to pass the names while constructing the coordinate system, as it is done in the differential geometry module:
http://docs.sympy.org/latest/modules/diffgeom.html#sympy.diffgeom.CoordSystem

Look at the definition of rect "with provided names".

[Justin]

Hi,

 

Something I'd really like to see changed in the vector module, is the dependence of these operators on the coordinate system. That is, you define the grad, curl, div operators for every coordinate system. This is not necessary, because base_scalars and base_vectors all contain a reference to their coordinate system instance.

In SymPy, remember to access to parameters passed to the constructor with obj.args

So I did some playing around here and found that when a vector is constructed with VectorAdd or VectorMul the system reference is lost in obj.arg as you mentioned.  It's still there, just buried in tuples of BaseScalar and BaseVector instances.  Should we add a system property to the classes for basis dependent classes (basisindependent.py).

 

They both check out.  Next, something will have to be done for dot products to check:

Dot products are fine... granted one puts parenthesis around them.  For example:

>>> r + r * dr & dr

TypeError: r cannot be interpreted correctly

>>> r + r * (dr & dr)

2 * spherical_r

So something will need to be added to the order of operations handler... any idea on how to start on this?  Is that an error from decorators.py?

 

3) grad(fg) --> laplacian(fg) = f laplacian(g) + 2 * grad(f) (dot) grad(g) + g laplacian(f)

Whoops! 

 

4) curl(curl(A)) = grad(div(A)) - laplacian(A)

Did you write some code? Did you post it on github?

Following Jason's post I fetched the branch from your repo and started doing testing.  I haven't done much coding; I did add the laplacian to functions.py. Should I push to you on a different branch or stop, fork and continue?

 I'll see if I can get a hold of him and see where he is at (or, if you (Upabjojr) keep up with posts, message me on here).

Hello there!

Hi back! 

So, I think for now I will focus on adding a system property to the BasisDependent(Add)Mul classes and then debug the order of operations issue.  Let me know how you would like to handle the push (it should be fine to push to you because I'm on a different branch and will have to submit a pull request to you anyways).

 

[Jason Moore]

> So something will need to be added to the order of operations handler... any idea on how to start on this?  Is that an error from decorators.py?

This is fixed in Python and is not something we can change. My opinion is that overloading the operators like this at all is a bad idea in Python. I'd rather not have them there at all.

Jason
moorepants.info
+01 530-601-9791

--

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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/a43cffe0-c8f1-4654-8c3b-ac319a0a66ad%40googlegroups.com.

[Justin]

Here are some of the changes that were requested.  I will continue to work but I'm afraid I'm going to need to take a full day to work out the SymPy Expr Tree (focusing on vectors) to do any kind of symbolic vector programming.  Here is the link to my commit:

https://github.com/jbbskinny/sympy/commit/793539fe13c1136750452a8796b16a5516863d51 -- Forked from Upabjojr/sympy:vector_all_coord_sys

This is fixed in Python and is not something we can change. My opinion is that overloading the operators like this at all is a bad idea in Python. I'd rather not have them there at all.

Out of curiosity, which Python function does this?  Adding a whole new operator is interesting.. and, of course, debatable.

Cheers,

Justin

[Justin]

Meant to mention that something will need to be added for limit handling.  For example:

>>> laplacian(1/r)

0

Which is correct when r does not equal zero, but we should have the full answer:

>>> laplacian(1/r)

-4 * Pi * Dirac_Delta(r*dr)

I can't imagine how to go about this right now, but will keep it in mind when mapping out the class hierarchy.  Any thoughts on implementing the divergence theorem in special cases like these, or plans for the dirac delta?

Cheers,

Justin

[Francesco Bonazzi]

On Wednesday, 21 October 2015 07:47:21 UTC+2, Justin wrote:

Here are some of the changes that were requested.  I will continue to work but I'm afraid I'm going to need to take a full day to work out the SymPy Expr Tree (focusing on vectors) to do any kind of symbolic vector programming.  Here is the link to my commit:

https://github.com/jbbskinny/sympy/commit/793539fe13c1136750452a8796b16a5516863d51 -- Forked from Upabjojr/sympy:vector_all_coord_sys

Oh, that's nice.

Create a PR, so we can comment on the code there. I'd also suggest to fork the master branch if your edit is unrelated to mine, unless you want to go on with my PR.

Also have a look at: http://docs.sympy.org/latest/modules/utilities/runtests.html

 

This is fixed in Python and is not something we can change. My opinion is that overloading the operators like this at all is a bad idea in Python. I'd rather not have them there at all.

Out of curiosity, which Python function does this?  Adding a whole new operator is interesting.. and, of course, debatable.

Defining a new operator is a very fast operation, you just add a new method to a class. The drawback is that debugging the code becomes less clear, if you are not familiar it also gets less readable, compare del*r to gradient(r), the latter is straightforward, while the first is a little harder to read.

[Aaron Meurer]

Python 3.5 has the new @ operator, which has the same precedence as *.
You won't be able to use it in library code, but it could be useful as
one of the operators.

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/CAP7f1AhXKJkmYW7v%3Drw_aD4oXpMjG0LkgDQ50Xxd4SvKMzDTYw%40mail.gmail.com.

[Alan Bromborsky]

You might want to look at -

https://github.com/brombo/galgebra

especially galgbra.pdf in the doc directory.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JN77y4PLyWWnhPWMZX_ach5h0vX8N-fOjLTuN7t7U5AA%40mail.gmail.com.

[Jason Moore]

Justin,

If you haven't read this yet: https://github.com/sympy/sympy/wiki/introduction-to-contributing you should. I will help you get your dev environment setup and give info on how to make PRs, etc.

Jason
moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALOxT-mP6Lcb-AFsdrwVq9kMJoaiKpQoYBoH8GDL2pkJX3OUGQ%40mail.gmail.com.

[Francesco Bonazzi]

On Wednesday, 21 October 2015 17:37:31 UTC+2, Jason Moore wrote:

 I will help you get your dev environment setup and give info on how to make PRs, etc.

I'd recommand using PyCharm, it has excellent Python code analysis, debugger and github integration.

https://www.jetbrains.com/pycharm/download/

Community Edition is free and open source.

[Justin]

On Wednesday, 21 October 2015 17:37:31 UTC+2, Jason Moore wrote:

 I will help you get your dev environment setup and give info on how to make PRs, etc.

Hey Jason, I have my dev environment set up per the development workflow wiki.  I would like some information on how and when to make the pull requests... vectors are a deep subject and when I feel what I coded is ready, surely something will be missing.

Also, if there are any more wiki's you feel I should look at, let me know.

 

I'd recommand using PyCharm, it has excellent Python code analysis, debugger and github integration.

https://www.jetbrains.com/pycharm/download/

Community Edition is free and open source.

I actually googled that when reviewing your PR!  Awesome IDE!! Been using Eclipse for a while when break points are useful and I hated it the whole time.

[Jason Moore]

Justin,

We like to see "atomic" PRs that are shorter rather than longer so that they are easy to review. Most super long PRs take forever to review and get merged, so send in smaller updates in general. And the atomic portion means that you pick one complete thing to add per PR which generally includes the addition, unit tests, and doc changes. You can also submit PRs early in your writing stage and make their title start with "[WIP]" to indicate it is a work in progress and you want feedback as you go along.

Jason

Jason
moorepants.info
+01 530-601-9791

--

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+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/af67bd50-bf8f-49d8-8b3a-bb3d4109c4aa%40googlegroups.com.

[Aaron Meurer]

Submit early and submit often. The earlier you make a pull request the
earlier people can start commenting on your work.

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/CAP7f1Ah%2BEB%2B45ezT5HL6T%2B8LGfcqRyEZTe0DFuB-w7H64SiYcA%40mail.gmail.com.