This works beautifully, thanks.
I have another small issue: I can't do substitutions in equality
expressions with terms in the free algebra. For instance, Sage tells me
"Not iterable"
var('c, pi, c, mu_0,epsilon_0,epsilon,mu,q,Q,e')
F.<curl,div,grad,d_t,d_x,d_y,d_z,J,I,K,P,p,E,V,Phi,D,B,A,H,M,m,rho,sigma,C,R,Z,L>
=
FreeAlgebra(SR,27,'curl,div,grad,d_t,d_x,d_y,d_z,J,I,K,P,p,E,V,Phi,D,B,A,H,M,m,rho,sigma,C,R,Z,L')
eqCGS = curl*H - (1/c)*d_t*D == 4*pi/c*K
### CGS expression on this line ###
eq =eqCGS* (1/2)*mu_0^(-1/2)*pi^(-1/2)
### Multiplicative factor on this line ###
assume(mu_0>0,epsilon_0>0,pi>0,c>0,e>0)
eq = sum(b.subs(c == mu_0^(-1/2)*epsilon_0^(-1/2))*F(a) for a,b in eq)
show('Original (CGS) version')
show(eqCGS)
show('MKS version')
show(eq)
Thanks again for your help.
On Sunday, September 7, 2014 5:25:31 PM UTC-5, Nils Bruin wrote:
>
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
