On Tuesday, February 17, 2015 at 3:29:00 AM UTC+9, Ondřej Čertík wrote:
>
> > (A) Most naive and least flexible approach - define functions s(t) and
> v(t),
> > build some simple equations around them and then ask for definition
> > of v(t) given that s(t) = x_0:
> >
> > import sympy as sym
> > import sympy.physics.mechanics as me
> > from sympy import init_printing
> >
> > x_0, t, g = sym.symbols('x_0 t g')
> > ua = sym.symbols('ua', positive=True) # acceleration is
> function of time, uniform acceleration is not
> > s, v = sym.symbols('s v', cls=sym.Function) # functions of t
> > initial = {v(0): 0, s(t): x_0}
> >
> > velocity_ds_eq = sym.Eq(v(t), s(t) / t)
> > unifaccel_dv_eq = sym.Eq(ua, (v(t) - v(0))/2/t)
> > eqs = [eq.subs(initial) for eq in [velocity_ds_eq,
> unifaccel_dv_eq]]
> > print(sym.solve(eqs, v(t), implicit=True))
> > # -> []
>
> I think you have to specify two unknowns to solve for, if you have a
> system of two equations,
Oh, I see. I thought that it's rather because t is parameter of v(t). So
there is a hard requirement
that len(f) == len(symbols)? (Maybe sym.solve() should just throw an
exception if that's not the
case then?)
Basically, this requirement is a bit troublesome for me. Basically, I know
that:
- I'm interested in v(t)
- I don't want to solve for ua and x_0 (these are parameters)
So I don't know that I want to also solve for t, and I don't care about
this solution. Here it might
be simple to just walk the expression and take note that t is the only
other possible variable,
but I may also have other completely irrelevant equations for v(t), with
other variables.
What I would have *thought* would work is sym.solve(eqs, exclude=[ua,
x_0]), but that returns
> NotImplementedError: could not solve -2*t*ua + v(t)
and it turns out the issue here is that the implicit list of free symbols
does not return v(t).
Is this a bug? Or does it make sense not to include undefined functions in
free symbols list
in some situations?
In my pretty limited experiments, the issue could have been fixed by
unconditionally appending
the auto-generated list of free symbols to the passed list of symbols:
print(sym.solve(eqs, [v(t), ua, x_0, t]))
# -> [{v(t): -sqrt(2)*sqrt(ua)*sqrt(x_0), t:
-sqrt(2)*sqrt(x_0)/(2*sqrt(ua))}, {v(t): sqrt(2)*sqrt(ua)*sqrt(x_0), t:
sqrt(2)*sqrt(x_0)/(2*sqrt(ua))}]
Does this sound sensible? (It would probably have to be done only in
_solve_system(),
specifically after elimination of unrelated equations.)
Then I could in addition pass exclude parameter listing all the parameter
symbols for which
I really don't want a solution.
e.g. change v(t) -> [v(t), t], as you did in
> your second try:
>
> In [15]: print solve(eqs, [v(t), t])
> [(-sqrt(2)*sqrt(ua)*sqrt(x_0), -sqrt(2)*sqrt(x_0)/(2*sqrt(ua))),
> (sqrt(2)*sqrt(ua)*sqrt(x_0), sqrt(2)*sqrt(x_0)/(2*sqrt(ua)))]
>
> Then it works.
>
> Why do you use "implicit=True"? It seems it doesn't work with it.
>
Oh. I'm a bit dumbfounded here, I'm pretty sure I tried that too, but I
must have missed this. Thanks!
Obviously I didn't like to use implicit=True (if I understand what it does
from the documentation)
but I must have made some error in my experiments without it.
> >
> > Here's the kick - if I apply three rather arbitrary changes to the
> > last code segment, I *do* get a solution I'm after (thanks to
> > @vramana for helping me out with this!):
> >
> > velocity_ds_eq = sym.Eq(v(t) * t, s(t))
> > unifaccel_dv_eq = sym.Eq(ua * t, (v(t) - v(0))/2)
> > eqs = [eq.subs(initial) for eq in [velocity_ds_eq,
> unifaccel_dv_eq]]
> > print(sym.solve(eqs, [v(t), t], implicit=True))
> > # -> [(-sqrt(2)*ua*sqrt(x_0/ua), -sqrt(2)*sqrt(x_0/ua)/2),
> (sqrt(2)*ua*sqrt(x_0/ua), sqrt(2)*sqrt(x_0/ua)/2)]
> >
> > However, I don't understand why is it required to do either of these
> > changes - that is, solving for [v(t),t] (hmm, maybe I do have an
> idea
> > but not sure) and especially converting /t to *t in both of the
> > equations (doing that only in the first one will yield
> > {v(t): x_0/t, t: x_0/(2*t*ua)} - I guess I could deal with that).
> > The latter two changes give me an impression of a brittle approach
> > that might break randomly in more complex cases than the toy
> problem.
>
> I don't think multiplying by "t" has anything to do with the result,
> see my comment above.
>
> After we find a solution that you like, I can look at the other
> problems you mentioned.
>
> Ondrej
>
> >
> > (Of course I would prefer to represent velocity and acceleration as
> > vectors etc., but I got stuck much sooner than that!)
> >
> >
> > (B) Inspired by "Taming math and physics using SymPy", representing
> > velocity as integrated acceleration and position as integrated
> > velocity. I originally aimed to make both functions of time:
> >
> > import sympy as sym
> > import sympy.physics.mechanics as me
> > from sympy import init_printing
> >
> > t, a, v_0, x_0 = sym.symbols('t a v_0 x_0')
> > v, x = sym.symbols('v x', cls=sym.Function) # functions of (t)
> > # initial = {x_0: 100, v_0: 0, a: -9.8}
> > initial = {v_0: 0}
> >
> > eqv = sym.Eq(v(t), v_0 + sym.integrate(a, (t, 0,t)))
> > eqx = sym.Eq(x(t), x_0 + sym.integrate(v(t), (t, 0,t)))
> > eql = sym.Eq(x(t), 0)
> > eqs = [eq.subs(initial) for eq in eqx,eqv,eql]
> > print(sym.solve(eqs, [v(t), t], implicit=True))
> > # -> []
>
Note that based on the insights above, I tried to replace this with
print(sym.solve(eqs, [v(t), t, x(t)]))
but that didn't help.
Thanks!
Petr
--
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 [email protected].
To post to this group, send email to [email protected].
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/d1fe1199-7714-42b2-b28e-4488720174da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
