On Sunday, September 7, 2014 10:28:02 AM UTC-7, Chris Thron wrote:
>
> (1) I have expressions like curl*H - c^(-1)*d_t*D, where curl and d_t
> express derivatives. In the process of conversion, sage switches the order
> and outputs:
>
> H*curl - D*d_t/c
>
Are you sure D and d_tand H and curl get swapped? I don't see that. Free
algebras are defined to have their base ring in the centre, so H and c will
commute with curl, d_t, H and D. Indeed, it will coefficients to the left
of monomials in your free algebra generators.
> I thought of defining a free algebra over a symbolic ring, but this turns
> out to have problems. Apparently expand and simplify are not defined for
> expressions in a free algebra. Sage chokes on the following code.
>
> var('c, pi, c, mu_0,epsilon_0')
> F.<curl,H,d_t,D,J> = FreeAlgebra(SR,5,'curl,H,d_t,D,J')
>
> eqCGS = curl*H - c^(-1)*d_t*D
> ### CGS expression on this line ###
>
> eq = eqCGS * (1/2)*mu_0^(-1/2)*pi^(-1/2)
> ### Multiplicative factor on this line ###
>
> assume(c>0,mu_0>0,epsilon_0>0)
> eq = eq.subs({c == mu_0^(-1/2)*epsilon_0^(-1/2)})
>
That's right: substituting c is something that needs to happen in SR. You
can do this coefficient-wise:
sage: eq = sum(b.subs(c == mu_0^(-1/2)*epsilon_0^(-1/2))*F(a) for a,b in
eq); eq
1/2/(sqrt(mu_0)*sqrt(pi))*curl*H + (-1/2*sqrt(epsilon_0)/sqrt(pi))*d_t*D
(if you realize FreeAlgebra can also be defined over GF(p), QQ, ZZ then you
see why it can't delegate "subs" calls to its coefficients as well)
eq = eq.subs({H:2*H})
>
eq = eq.subs({D : 2*pi^(1/2)*epsilon_0^(-1/2)*D})
>
eq = eq.subs({J : (1/2)*pi^(-1/2)*epsilon_0^(-1/2)*J})
>
These work because they're on free algebra level.
> eq = eq.expand()
> eq = eq.simplify()
>
These methods don't exist because on free algebra level, there's no
expanding or simplifying to do. Elements are always expanded. Perhaps you
want to do it on coefficients, in which case you can use the same
coefficient-wise trick:
eq = sum([b.expand()*F(a) for a,b in eq])
eq = sum([b.simplify()*F(a) for a,b in eq])
(neither has any actual effect for your example)
Furthermore, the code does not substitute for c.
>
For reasons explained above.
> Any guidance would be appreciated
>
Be aware that FreeAlgebra assumes its base ring to actually be a ring. SR
isn't really a ring (e.g., it can have floats in it, so precision problems
might creep in). For your applications, SR might be close enough to a ring
for things to work, but use at your own peril.
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
