Well, this week was the start of Google Summer of Code 2011. Unfortunately, the quarter is still not over for me, so I didn’t make as much progress as I would like. But, it looks like some of the questions about rewriting the Vector class have been answered.
When doing dynamics problems by hand, basis vectors are typically written as:
Where e is the reference frame within which the basis vectors are “standard”. One thing that is immediately obvious is that the numbering starts from 1, unlike most programming languages, which start indices at 0. PyDy is going to be printing out equations to LaTeX, for use in publication; this would most certainly use 1 indexing. This leads to some conflicting things, where e[0] in the code is 
My decision to keep the basis vectors in the ReferenceFrame class, versus generating them upon some function call, ultimately came down to the same issue. If you named a set of basis vectors b1,b2,b3 , but they were in frame “Foo”, printing them would give foo1>, foo2>, foo3>. This again, would be unacceptable. This situation is also fairly likely to come up, as one usually wants to take shortcuts (I know I have when using Autolev). It also ties into what I guess is my last point for this topic: readability for non-python programmers.
The professor who will teach the graduate multibody dynamics course next year said that he would consider teaching the students PyDy next winter quarter. This is going to mean that the code should be readable by people who aren’t familiar with Python. Here, by code, I mean the scripts that people will write to generate their equations of motion. Anyways, readability for non-Python users, while still trying to be Pythonic, will be an important consideration this summer.
Next is finishing up the Vector and ReferenceFrame classes. I’m trying to reuse as much code as possible, and definitely not lose any functionality. It seems to be going OK so far and hopefully it will stay that way.
Gilbert Gede's Blog 
Good idea with the indexing. Since you always have exactly three indices, you could argue that using three properties makes more sense anyway.
That’s exciting about your professor wanting to use PyDy.
When does your quarter actually end?
I think the quarter officially ends June 10. However, I only have 2 things left to turn in, then I’m done. One is due this Tuesday (May 31) and I hope to turn in the other later in the week. So I think that next week is when the coding will really start.
Yeah, we’re really excited about PyDy being taught; it will mean about 15 people who know it and have used it.
I don’t really agree with the idea that you shouldn’t have the zero indexing available at all. I think it should be an option because you may want to iterate through the basic vector for a frame for some reason. You should be able to do this either with E[i] i= 0, 2, 3 or with some kind of iterator built in to handle the E.x, E.y, E.z. But I can’t think of a specific example when this is needed, but putting the unit vectors as attributes erases any kind of value you get when treating the basic vectors as a set.
Also, be careful about writing the code for this particular class and professor. It can certainly pigeon hole you into doing things for a small subset of folks that isn’t generally acceptable for a broader audience. If this module was written in C, then the students would have to learn C, if it was written in matlab, then they have to learn matlab. This is no different for python. I think your code should be pythonic at it’s core and can be used in a pythonic way. If you want to wrap something that makes it look like matlab or autolev on the outside for a particular user group, that is fine but I wouldn’t make it priority. (matplotlib wraps code to act more like matlab with a lot of functionality and I think it is rather clunky) I think writing the program so it works well, is easy to edit, extend and debug are more valuable than catering to your audience’s limited language background. If the code works well and can be demonstrated to your audience, they will learn the language. If the acceptance by engineers and this class is priority, then maybe we should be writing this software in matlab…
Well, I guess it’s clear that I disagree, as I’ve already implemented it with x, y, z… In any case, you could still make a list of the 3 basis vectors, l = [E.x, E.y, E.z] and iterate through that. The option is still there, it is just an extra step. Considering that a default behavior based on iterators could result in typing E[0] to the console and getting e1> or e1 in LaTeX output, I think that it is a good tradeoff.
I don’t think the code will be written for MAE 223 specifically, but that the possibility of it being taught provides a great opportunity for us. I think that in the code I am writing, being pythonic is very important, and I am trying to keep it in mind. But for the user scripts, I don’t think anything will be pythonic or not pythonic; I think the scripts will be too simple to take advantage of python’s features. Think about your autolev code; you just declare a bunch of variables, define bodies, rotations, and speeds, then define output qualities. I think we’re shooting for something better than autolev, but I feel the process for Kane’s Method is pretty much the same (or any other dynamics method).
Alternatively, look at Luke’s previous PyDy examples; there is not much which is not pythonic or pythonic. Using python’s lists and class member attributes and methods are most likely the only things that users will encounter which could be unfamiliar, and even then, one of the things that is great about python, readability, will make it pretty clear what is going on.
I have to disagree about using MATLAB; if anything, the lack of flexibility that we have in creating objects and code for MATLAB would make the user interface for the code much worse, as we would have to implement non-standard ways of doing everything. Readability of the user scripts is important for the dynamics people who we hope use this; being pythonic for the code which lets their scripts work is important for us; I think these are two seperate areas.
Being “Pythonic” is about more than just making list indices start at 0 (this is actually more of a C thing, which was just borrowed by Python for convenience).
“Pythonic” means writing code using native Python constructs instead of trying to write some other language in Python (for example, I see a lot of people try to write Java in Python, and it looks bad). For example, you should take full advantage of the fact that Python is a dynamically typed language. This means using “duck typing,” which menas that you don’t bother to check what the type of an object is. You just use the object, and if it works, then it works, and if it doesn’t, then there was some error in the caller and it raises an exception, which propagates up. For example, don’t write “if callable(f): f(x)”. Just write “f(x)”. isinstance() is another function that you really don’t need to use all that often.
“Pythonic” is also a philosophy of coding. Due to its syntax and general style, programs written in Python tend to be very clean and readable, and “Pythonic” code tries to maintain this as much as possible. To get an idea of the “Pythonic” philosophy, type “import this” in a Python interpreter.
Just define __iter__ on your vector objects. Then “for i in E” will work as expected, and you won’t ever have to let E[1] work.
I agree that you should make it Pythonic though. You have a good compromise, I think, for the indexing question, but in general, you should try to write your APIs in the clean Python style (remember why it’s beneficial to have a library written in Python and not C or matlab or something else in the first place).
Yeah, I’ve implemented __iter__ now, so you can iterate through basis vectors.
I liked the “Zen of Python”.
In the code I’m writing, I’m trying to be Pythonic, although any review of it would be appreciated.
I think setting up my code, interfaces, and examples well will result in user scripts that are Pythonic.