Thanks for the clarification. On Wednesday, August 1, 2012 3:24:48 PM UTC-7, Gilbert Gede wrote: > > Jason, > I don't think you can do that with Kane right now, as a lot of those > methods have no return (and thus return None). > > > On Wednesday, 1 August 2012 15:07:47 UTC-7, Jason Moore wrote: >> >> Joachim's idea is used in scipy's ode class: >> http://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.ode.html#scipy.integrate.ode >> >> The Kane class is basically like that and you can write it like: >> >> fr, frstar = Kane(N).coords(qi, qdep=qd, coneqs=qc).speeds(ui, udep=ud, >> coneqs=uc).kindiff(kindiff).kanes_equations(bodies, forces) >> >> and Angadh's Lagrange idea is similar. You can directly compare it to >> something like: >> >> fr, frstar = Kane(N, qi, ui, bodies, forces, kindiff, qdep=qd, conc=qc, >> udep=ud, conu=uc).kanes_equations() >> >> As far as I know the order doesn't matter in the method calls in the >> first version but they have to be called. >> >> Jason >> >> On Wednesday, August 1, 2012 11:09:37 AM 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/-/BIG6Nkv88vYJ. 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.
