On Wed, Aug 1, 2012 at 4:23 PM, Gilbert Gede <[email protected]> wrote: > A number of points here... > > What is returned from the class: I setup the Kane class to return just the > differential equations that it calculates, and not do any rearranging. In > order to get rearranged quantities, I used (@property) attributes, to return > things which had negligible computational costs - just concatenating > existing expressions. I would argue for the same approach in Lagrange: > return just the bare differential equations first, then rearranged > quantities as property attributes. If the user wants the differential > equations in a form which can be easily sent to an integration routine, they > could call a method which does that matrix inversion for them (as others > have suggested). > > One of the reasons I set up the Kane class to be the way it is now, is that > a lot of the operations involved in getting to the equations of motion could > be relatively expensive. When there are nonholonomic (motion) constraints, > some matrix inversion needs to happen, and I chose to separate that > operation from the other steps involved in setting up the class before > generating the equations of motion. Looking at it now, the methods I wrote > could probably be kept, and just called by __init__() upon initialization of > the Kane class using keyword args - and any tracebacks would show which > function it was possibly hung up in. > > That is the reason the Lagrange class has been proposed in its current > fashion - to match the Kane class. That does bring up a point though: should > we change Kane to be mostly formed on initialization? I think it would be > best if they both used as similar an interface as possible. The way I > approached the Kane class, the following quantities were needed: > > Kane - > > An inertial ReferenceFrame > Coordinates (and possibly configuration constraints & identification of > dependent coordinates) > Speeds (and potentially velocity constraints & identification of > dependent speeds, and possible identification of auxiliary speeds) *possibly > expensive > Kinematic Differential equations *possibly expensive, but not likely > A list of Forces, and a list of Bodies/Particles *probably expensive > > > So, there are between 6 and 13 things that need to be supplied. > > With the Lagrange class, there aren't as many things. > > Lagrange - > > A Lagrangian > Coordinates (possibly configuration and/or velocity constraints) > (possibly nonconservative forces & an inertial ReferenceFrame for them) > > > We have between 2 and 6 things that need to be supplied. > > Both of these classes are fairly narrow in scope - take in the necessary > quantities, perform some math, give the basic results, and possibly do some > more manipulation of those results. I'm not sure if they should be defined > in a way which allows them to generate equations of motion (which will only > happen once) in fewer setup calls, or in a way that is easier to follow, or > if these two things are the same. I would argue for the following > priorities: user written code would be easy for others to read -> user can > write code easily -> as few setup calls as possible. I'm not sure what > others' opinions would be on what is easiest to read though. > > I don't like the approach: > >> Builder(required1, required2).setOptional1(5).setOptional47(Blah) > > as the methods are order dependent (some things need to be supplied before > others, or at least simultaneously), and I don't see it as being much of an > improvement over the current implementation in Kane in terms of readability > - the kwargs approach is preferable if a change is going to be made.
I agree with this. You (the Kane class) know much better than the user what order things should happen in. So unless there really are situations where the user would know best what order things ought to be done in, I would hide this information from the user using keyword arguments, or via some other inherently unordered mechanism. Even if the order does matter in one case and only the user would know, it might be easier to just convert that to some keyword argument (like a_before_b=True or something) (sorry for being a little generic, but I don't know enough mechanics to know what case actually applies here). Aaron Meurer > > > As for the need to supply coordinates - if someone has coordinates in their > system which are specified functions of time (but not degrees of freedom), > they will be "dynamicssymbols" (undefined functions of time), just as actual > coordinates would be. But you would not want them to be treated as > coordinates, as that would give incorrect equations of motion. That's why > the user needs to specify which ones are coordinates (and every other > dynamicsymbol will be assumed to not be a degree of freedom). > > > -Gilbert > > > On Wednesday, 1 August 2012 11:09:37 UTC-7, Joachim Durchholz wrote: >> >> Am 01.08.2012 16:31, schrieb Jason Moore: >> > The __init__ method should require the bare >> > minimum arguments (lagrangian, generlized coords) and all the others be >> > optional, probably as keyword arguments. >> >> I'd insist on keyword arguments. At about three positional arguments, it >> starts to become easy to miscount argument positions so that values are >> getting passed to some other parameter than expected. >> >> > It can be handled with something >> > like __init__(lagragian, coordinates, **kwargs). >> >> There's an alternative: Split the thing in two, a "builder" object >> that's mutable. You can then write stuff like >> Builder(required1, required2).setOptional1(5).setOptional47(Blah) >> and still have something with 47 optional parameters manageable. >> That chaining style is particularly useful for adding to a list (e.g. >> you can add series of boundary conditions without having to set them up >> as a list). >> Once you're done with the Builder object, you use a toEquation() (or >> build() or whatever) method and get an immutable object, useful for >> equation munging and other fun transformations. >> These are all ideas from the Java world, where such stuff is >> indispensable because Java has no keyword arguments, no hash literals, >> and clumsy list pseudoliterals. The need is far less pressing in Python, >> but I think it's good to be aware of alternative approaches just in case >> the standard approach doesn't work well enough. >> > > On Wednesday, 1 August 2012 11:09:37 UTC-7, Joachim Durchholz wrote: >> >> Am 01.08.2012 16:31, schrieb Jason Moore: >> > The __init__ method should require the bare >> > minimum arguments (lagrangian, generlized coords) and all the others be >> > optional, probably as keyword arguments. >> >> I'd insist on keyword arguments. At about three positional arguments, it >> starts to become easy to miscount argument positions so that values are >> getting passed to some other parameter than expected. >> >> > It can be handled with something >> > like __init__(lagragian, coordinates, **kwargs). >> >> There's an alternative: Split the thing in two, a "builder" object >> that's mutable. You can then write stuff like >> Builder(required1, required2).setOptional1(5).setOptional47(Blah) >> and still have something with 47 optional parameters manageable. >> That chaining style is particularly useful for adding to a list (e.g. >> you can add series of boundary conditions without having to set them up >> as a list). >> Once you're done with the Builder object, you use a toEquation() (or >> build() or whatever) method and get an immutable object, useful for >> equation munging and other fun transformations. >> These are all ideas from the Java world, where such stuff is >> indispensable because Java has no keyword arguments, no hash literals, >> and clumsy list pseudoliterals. The need is far less pressing in Python, >> but I think it's good to be aware of alternative approaches just in case >> the standard approach doesn't work well enough. >> > > On Wednesday, 1 August 2012 11:09:37 UTC-7, Joachim Durchholz wrote: >> >> Am 01.08.2012 16:31, schrieb Jason Moore: >> > The __init__ method should require the bare >> > minimum arguments (lagrangian, generlized coords) and all the others be >> > optional, probably as keyword arguments. >> >> I'd insist on keyword arguments. At about three positional arguments, it >> starts to become easy to miscount argument positions so that values are >> getting passed to some other parameter than expected. >> >> > It can be handled with something >> > like __init__(lagragian, coordinates, **kwargs). >> >> There's an alternative: Split the thing in two, a "builder" object >> that's mutable. You can then write stuff like >> Builder(required1, required2).setOptional1(5).setOptional47(Blah) >> and still have something with 47 optional parameters manageable. >> That chaining style is particularly useful for adding to a list (e.g. >> you can add series of boundary conditions without having to set them up >> as a list). >> Once you're done with the Builder object, you use a toEquation() (or >> build() or whatever) method and get an immutable object, useful for >> equation munging and other fun transformations. >> These are all ideas from the Java world, where such stuff is >> indispensable because Java has no keyword arguments, no hash literals, >> and clumsy list pseudoliterals. The need is far less pressing in Python, >> but I think it's good to be aware of alternative approaches just in case >> the standard approach doesn't work well enough. >> > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sympy/-/zZ4nLEWSLy8J. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
