Gilbert,
I prefer this notation:
>>> B = ReferenceFrame('B')
and then to access the basic vectors of that frame, to use one of the
following approaches:
B.x, B.y, B.z or, B.i, B.j, B.k
You could view the ReferenceFrame class as a container object for the
basis vectors and implement the __iter__() method to iterate over the
basis vectors in the following way:
v = a*B.i + b*B.j + B.k
for basisvector in B:
dot(v, basisvector)
Since we are restricting ourself to basis vectors in R^3, we probably
don't need all the other methods typical of a container object, I
think __iter__() would be enough.
My vote is to go with the ijk or xyz syntax and not use the
__getitem__() method that allows for B[1]. This will mean some work
to change things from how they are currently implemented in PyDy, but
I think the syntax is cleaner and more concise. What do other people
think about this?
Another thing to think about though is how you will print the basis
vectors, both to the screen and to LaTeX. Currently, PyDy prints
UnitVectors as b1>, b2>, b3>, and it uses unicode to make the color
bright so you can distinguish UnitVectors from the scalar multiplier.
For LaTeX printing, this I think should be \boldsymbol{b}_{1},
\boldsymbol{b}_x or \boldsymbol_{i}. If you go with the ijk syntax,
bi>, bj>, bk> might work but in most physics/math books I have seen
they typically only use \hat{\boldsymbol{i}}, etc, and typically this
is in settings where you don't have many different reference frames to
distinguish between, so the syntax isn't ambiguous. On the other
hand, I have seen \boldsymbol{b}_x, etc, so perhaps this might be more
common and familiar to some users? It is a pretty minor difference,
so I say you pick one you think is most likely to appeal to the widest
audience and stick with it. This might also be something that could
have a default value, but could be customized -- I have seen
subscripts of ijk, xyz, 012, or 123 in various classical mechanics
literature.
The problem with the numbered subscripts is that while B.y or B.j
would work, B.2 wouldn't work since 2 isn't a valid variable name.
I'm not sure what the best solution would be for this if we were to
try to allow for customizing the subscripts. I guess this is why the
syntax of:
b1, b2, b3, B = ReferenceFrame('B')
might be desirable, I just feel like it might be more typing than is
desirable in most cases.
Do any of the physics people out there have thoughts on what syntax
would be nicest for physics students? We definitely want to keep the
syntax familiar to that potential user base, but we also need to make
sure we can accommodate many different reference frames which is
common in multibody dynamics.
~Luke
On Fri, May 13, 2011 at 6:29 PM, Gilbert gede <gilbertg...@gmail.com> wrote:
> 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 each basis vector and the frame they belong to,
> and the outer list will store the inner list for each frame. It will
> be something like:
> [[(1,2,1),B],[(4,2,1),N]]
>
> As for operations, we're currently leaning towards writing operators
> for Vector, and then wrapping them with Dot, Cross, etc.
> So if A & B are Vectors, and t a scalar:
> A*t would call Vector.__mul__
> Dot(A,B) would call Vector.__and__ , maybe? We're still deciding on
> which operators to use for dot and cross products.
> Does this seem like an good solution? Allowing one user interface
> that is unambiguous but longer and a shorter, rougher option?
>
> I think this will all work out nicely, as once you have the basis
> vectors instantiated, you'll control what is returned by every
> operation. This leads to the final thing we're trying to decide; how
> to use the three basis vectors.
> It's between calling something like:
> b1,b2,b3,B = ReferenceFrame('B'), where b1 is a Vector with contents
> [[(1,0,0),B]], etc
> or
> B = ReferenceFrame('B')
> and then access the basis vectors as B[1], B[2], B[3] or B.x,B.y,B.z
> or B.i, B.j, B.k
> What are people's opinions here? Should the basis vectors be linked
> with the frame they are created with? Or should they be independent
> in the namespace?
>
> -Gilbert
>
>
>
>
> On May 11, 1:18 pm, Ronan Lamy <ronan.l...@gmail.com> wrote:
>> Le mardi 10 mai 2011 à 11:37 -0700, Luke a écrit :
>>
>> > The dot and cross products are implemented at the lowest level in
>> > UnitVector, and the Vector class simply calls these methods on all of
>> > the UnitVector objects that comprise it when these methods are called
>> > on a Vector class.
>>
>> > dot and cross functions are provided as convenience wrapper functions
>> > around the class methods, so the user can choose to use whichever
>> > approach is more natural to them.
>>
>> Not making a choice between the two options might seem easiest in the
>> short term but it's actually the worst decision in the long term. And
>> this is Alex Martelli's opinion[1], not mine, so it must be true!
>>
>> The function interface suggests that the operation is something that
>> depends equally on the two operands. The method interface suggests that
>> it's something that the first operand does to the second, or that it's a
>> characteristic of the first operand influenced by the second. I think
>> the first interpretation makes more sense. In any case, the current
>> implementation shouldn't dictate what the interface looks like, because
>> implementations can always be changed, but modifying an interface is
>> much more painful.
>>
>> [1]: See his Pycon 2011 talk
>> [http://python.mirocommunity.org/video/4230/pycon-2011-api-design-anti...]
>> from 26:38 and, more specifically, from 29:08. Slides for the talk:
>> [http://www.aleax.it/pycon11_adap.pdf]
>>
>>
>>
>>
>>
>>
>>
>> > ~Luke
>>
>> > On Tue, May 10, 2011 at 11:02 AM, Vinzent Steinberg
>> > <vinzent.steinb...@googlemail.com> wrote:
>> > > On 10 Mai, 03:30, Ronan Lamy <ronan.l...@gmail.com> wrote:
>> > >> Please, try to make the interface dot(v1, v2), and not v1.dot(v2).
>>
>> > > While I agree that it looks cleaner for the simple case, I would
>> > > prefer
>>
>> > > v1.dot(v2).dot(v3)
>>
>> > > over
>>
>> > > dot(dot(v1, v2), v3)
>>
>> > > For the dot product it does of course not make sense to multiply three
>> > > vectors in a row, but I think we should keep this in mind in general
>> > > for user defined operations.
>>
>> > > Vinzent
>>
>> > > --
>> > > 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 unsubscribe from this group, send email to
>> > > sympy+unsubscr...@googlegroups.com.
>> > > For more options, visit this group
>> > > athttp://groups.google.com/group/sympy?hl=en.
>>
>> > --
>> > "Those who would give up essential liberty to purchase a little
>> > temporary safety deserve neither liberty nor safety."
>>
>> > -- Benjamin Franklin, Historical Review of Pennsylvania, 1759
>
> --
> 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 unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>
--
"Those who would give up essential liberty to purchase a little
temporary safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759
--
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 unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
