Vector Debate

[Justin]

Hey all,

There is a debate on whether or not that when defining vectors, should there be a TypeError when adding vectors in different coordinate systems. For example:

In [1]: C1 = CoordSysCartesian('C1')

In [2]: C2 = CoordSysCartesian('C2')

(+1) In [3]: vector = C1.x * C1.i + C2.y * C2.j

(-1)  In [3]: vector = C1.x * C1.i + C2.y * C2.j

        TypeError: The vector should be well-defined.

Please vote with +1 or -1 below.  The current representation is +1.

Thanks,

Justin

[Justin]

-1

[Aaron Meurer]

What would be the output if it worked? Don't you need a way to
translate between the systems to make sense of that (which I gather
from the definition you don't have a priori)?

Aaron Meurer

On Fri, Oct 23, 2015 at 5:25 PM, Justin <jbly...@gmail.com> wrote:
> -1
>
> --
> 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/64f23108-97d0-4b1e-b968-c8b17380b89e%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Jason Moore]

Justin,

I don't think there is a debate. We have a very nice vector representation in the physics package, but it is based on mutable types and isn't very general. We created the sympy.vector package to make a more general vector object that was based on immutable types with the idea that the physics vector could eventually be deprecated. Our new implementation may not be general enough for the mathematicians' taste and we are willing to improve it so that it is, but we would still want it to eventually allow us to deprecate sympy.physics.vector. The addition of vectors from different coordinate systems is essential to this plan. So whatever you want to do to improve the package will have my support but I hope that you will keep this intended use case in mind when you think about bigger design changes.

Note that it took us two GSoC summers (something like 1000 hrs of work) to get the new vector package to the state that it is. You may want to check the old GSoC proposals, mailing list conversations, and PR/issue discussion to help provide some perspective.

A good rule of thumb would be to avoid changing tests, just add new ones to increase functionality. But if the best way forward is to remove functionality or to change the public API, then you'll need to start the discussion as to why that is and get consensus from the interested parties.

My vote is to keep the current behavior.

Jason

Jason
moorepants.info
+01 530-601-9791

[Justin]

I have a terrible way of wording things.. more of a discussion between myself and the author where he mentioned that I should ask the community what they think.

On Friday, October 23, 2015 at 6:43:51 PM UTC-4, Jason Moore wrote:

Justin,

I don't think there is a debate. We have a very nice vector representation in the physics package, but it is based on mutable types and isn't very general. We created the sympy.vector package to make a more general vector object that was based on immutable types with the idea that the physics vector could eventually be deprecated. Our new implementation may not be general enough for the mathematicians' taste and we are willing to improve it so that it is, but we would still want it to eventually allow us to deprecate sympy.physics.vector. The addition of vectors from different coordinate systems is essential to this plan. So whatever you want to do to improve the package will have my support but I hope that you will keep this intended use case in mind when you think about bigger design changes.

I come from a physics background and can't see when or why this would be useful so my opinion is certainly biased.  As to the generality of the package there are no constrains on doing this and, bias and all, this tells me there ought to be some.  I am new to contributing so I will keep my head down and add functionality as you mentioned.  I am not trying to step on toes here...

I will remove the post in 10 minutes.

Regards,

Justin

 

[Justin]

The output for (+1) is as typed.  No linkages between coordinate systems are required.  

[Nathan Goldbaum]

A vector (e.g. the mathematical object, not necessarily its representation) should be independent of the coordinate system, no?  So long as there are well-defined translations between the coordinate systems, it should certainly be possible to do arithmetic operations on two vectors whose representations are written down in different coordinate systems.

 

I will remove the post in 10 minutes.

Regards,

Justin

 

--

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/62ee7903-d029-4c59-9a87-7d45c5354bb2%40googlegroups.com.

[Aaron Meurer]

I think it's fine to discuss things. I don't know if Jason intended to
discourage that, but discussions (or debates or whatever) are fine,
even if they just end up with one person learning more about the
mathematics or the design intent of some code.

Aaron Meurer

>
> I will remove the post in 10 minutes.
>
> Regards,
> Justin
>
>

> --
> 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/62ee7903-d029-4c59-9a87-7d45c5354bb2%40googlegroups.com.

[Justin]

On Friday, October 23, 2015 at 7:27:45 PM UTC-4, Nathan Goldbaum wrote:

On Fri, Oct 23, 2015 at 6:25 PM, Justin <jbly...@gmail.com> wrote:

I have a terrible way of wording things.. more of a discussion between myself and the author where he mentioned that I should ask the community what they think.

On Friday, October 23, 2015 at 6:43:51 PM UTC-4, Jason Moore wrote:

Justin,

I don't think there is a debate. We have a very nice vector representation in the physics package, but it is based on mutable types and isn't very general. We created the sympy.vector package to make a more general vector object that was based on immutable types with the idea that the physics vector could eventually be deprecated. Our new implementation may not be general enough for the mathematicians' taste and we are willing to improve it so that it is, but we would still want it to eventually allow us to deprecate sympy.physics.vector. The addition of vectors from different coordinate systems is essential to this plan. So whatever you want to do to improve the package will have my support but I hope that you will keep this intended use case in mind when you think about bigger design changes.

I come from a physics background and can't see when or why this would be useful so my opinion is certainly biased.  As to the generality of the package there are no constrains on doing this and, bias and all, this tells me there ought to be some.  I am new to contributing so I will keep my head down and add functionality as you mentioned.  I am not trying to step on toes here...

A vector (e.g. the mathematical object, not necessarily its representation) should be independent of the coordinate system, no?  So long as there are well-defined translations between the coordinate systems, it should certainly be possible to do arithmetic operations on two vectors whose representations are written down in different coordinate systems.

The way I see it is that well are defining two different (or the same) coordinate systems with different (or the same) basis and allowing arithmetic operations between these two different (or the same) coordinate system.  The thing is we don't know until we make some definitions of the coordinate system whether the vector is well defined. For example:

Say C1 is defined and the origin is set at (0,0,0).  C2 is defined where it's y-axis aligns along C1's x-axis and origin is set at (0,0,0).  Any scaling could be set on C2 wrt C1. Is the operation 

C1.x * C1.i + C2.y * C2.j a well-defined vector?

[Jason Moore]

I'm not trying to quell debate and discussion. I just wanted to bring up the reason we created the package in the first place and encourage its consideration in future design decisions.

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/e1c47552-167f-4cb1-aa33-19bb896af677%40googlegroups.com.

[Justin Blythe]

Jason,

I see now. You want to keep it open for people who know how to define vectors in multiple coordinate systems.  I do feel that it should be expressed in the documentation (might already be, not at comp). 

Justin

Sent from my iPhone

You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/63HmWN4GgCU/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAP7f1AgFKCvB3BnyZejf-kCvGmoPE3%3DYqRMUF78C3mNwuMKffw%40mail.gmail.com.

[Francesco Bonazzi]

I don't see the point at all in removing the ability to represent expressions like C1.x * C1.i + C2.y * C2.j , it is perfectly desirable and has a well-defined behavior under differential operators (since it's an addition).

The point I brought up on github, is about the behavior of differential operators on expressions like divergence(C2.y * C1.i) or gradient(x*r) where x is the Cartesian coordinate, and r is the radius in spherical coordinates.

• gradient(x+r) = gradient(x) + gradient(r) = v_x + v_r  ===> this is straightforward
  
  
• gradient(x*r) = gradient(x*sqrt(x**2+y**2+z**2)) = gradient(r**2*sin(theta)*cos(phi)) ===> what should it return?
  What if there does not exist a conversion between x and r (e.g. if scalars of an other coordinate system)?

In my opinion, the second case should raise an exception. It's about calculating a differential operator, not about building the expression which should always be possible.

[Justin]

I don't think there is a debate.

I finally understand why you need to keep vectors open to multiple coordinate systems.  If you did not then operations like mag(r - r') would not be possible.