On Saturday, June 14, 2014 4:55:37 PM UTC-7, William wrote:
>
> On Sat, Jun 14, 2014 at 3:53 PM, <jeanbi...@gmail.com <javascript:>>
> wrote:
> >>
> >>
> >
> > This is very helpful, thanks.
> >
> > In Sympy, I did the following:
> > var('A B C D u v', real=True)
> > qi = 1/(u - I*v)
> > qf = (A + B/qi)/(C + D/qi)
> > expand(1/qf,
> complex=True)A2+2ABu+B2u2+B2v2+ADuA2+2ABu+B2u2+B2v2-iADvA2+2ABu+B2u2+B2v2+BCuA2+2ABu+B2u2+B2v2+iBCvA2+2ABu+B2u2+B2v2+BDu2A2+2ABu+B2u2+B2v2+BDv2A2+2ABu+B2u2+B2v2
>
>
> >
> > I got a reasonable 7 term expansion of 1/qf so long as I defined
> real=True in the var statement (I learned that via the Sympy group).
> Before I learned that step, the expansion was gigantic.
> >
> >
> > In Sage, I did
> > var('A B C D u v', domain = 'real')
> > defined qi, qf, and 1/qf as above
> >
> > When I tried
> > (1/qf)._sympy_().expand(complex = True)
> > I got a huge expression similar to the one Sympy gave me before I
> learned about the real=True setting on the initial variables.
>
>
> That seems like a bug in the _sympy_ conversion, in that it is
> discarding that the variables are assumed real.
>
> Could you just directly use sympy for what you're doing? Note that
> you'll have to turn off the Sage preparser, since
> with it on, you'll run into (surprising) trouble like this:
>
> sage: A,B,C,D,u,v = sympy.var('A B C D u v', real=True)
> sage: type(u)
> <class 'sympy.core.symbol.Symbol'>
> sage: type(1/u)
> <type 'sage.symbolic.expression.Expression'>
>
> where you've just left the world of sympy behind. Ugh.
>
>
> >
> > So, it looks like the method you suggested does work. I'll dig deeper
> into Sage to see how I can get the results to be the same. There may be
> something in addition to domain='real' that I need to set and/or send into
> Sympy.
>
> I couldn't figure out how to set it.
>
> By the way, Dima claimed above that Sage uses Maxima for expand, which
> is NOT correct (It was true 5 years ago, but not today). The vast
> majority of the symbolic computation in Sage is implemented in the C++
> library Ginac http://www.ginac.de/. It's easy to convert back and
> forth between Ginac and Maxima though.
>
> z = var('A B C D u v')
> qi = 1/(u - I*v)
> qf = (A + B/qi)/(C + D/qi)
> s = 1/qf
> s._maxima_()
>
>
> I don't know what problem you're trying to solve, but maybe this code
> is relevant:
>
> z = var('A B C D u v', domain='real')
> qi = 1/(u - I*v)
> qf = (A + B/qi)/(C + D/qi)
> s = 1/qf
> s.real()
>
> which outputs:
>
> B*D*u^2/(B^2*u^2 + B^2*v^2 + 2*A*B*u + A^2) + B*D*v^2/(B^2*u^2 +
> B^2*v^2 + 2*A*B*u + A^2) + B*C*u/(B^2*u^2 + B^2*v^2 + 2*A*B*u + A^2) +
> A*D*u/(B^2*u^2 + B^2*v^2 + 2*A*B*u + A^2) + A*C/(B^2*u^2 + B^2*v^2 +
> 2*A*B*u + A^2)
>
> WARNING! If you first do this in a session:
>
> z = var('A B C D u v')
>
> then the above will *NOT* work. As far as I can tell, you cannot
> redeclare a variable to be real if you ever made it without making it
> real before in the same session. Similarly, you can't change things
> with assume, e.g., this works fine:
>
> X, Y = var("X Y", domain = 'real')
> (X+I*Y).real()
>
> but this (surprisingly) fails:
>
> X, Y = var("X Y")
> assume("X", 'real')
> assume("Y", 'real')
> (X+I*Y).real()
>
>
> It appears that the assume command with second argument a "domain" is
> dangerously broken in Sage.
>
> So the main upshot for you is to start a new session and declare your
> variables to be real from the get go.
>
>
> William
>
William,
Very interesting. I am able to reproduce the result you found by using
s.real(). I checked and there is an s.imag() for the complex piece. I'll
do a term-by-term comparison a little later with the Sympy result and see
if they match. I'll keep the cautions in mind about
redefinitions/reassignments as well as I go further in all of these
languages.
The expressions I am evaluating come up in the propagation of Gaussian
optical beams such as the ones generated by many types of laser. We use
them to calculate beam parameters such as spot sizes and divergences as
various pieces of optics work on an input beam. The A, B, C, and D
parameters become specific when considering pure propagation, lenses,
mirrors, etc. An entire optical train can be considered by multiplying
matrices together. Provide an input parameter qi and the output parameter
is easily evaluated. The real part of q is a beam's radius of curvature,
the complex part is related to the size of the spot.
The above equations are very standard stuff and since I know what the
answers ought to be, they are a good way for me to get familiar with
Python, Sympy, Sage, etc. I expect that I will mix and match tools as
needed down the line when I need to consider more involved problems where I
won't know the answer beforehand. There are sophisticated programs that do
this kind of thing of course but it is always good to have alternatives,
especially ones that are not proprietary, when "prototyping" in the R&D
sense.
Dima writes:
"there is nothing wrong with using a bit of pure mathematics for
applied problems; e.g. cryptographers do this all the time... "
Agreed. My formal education was from a time when fields, groups, and such
were not common undergraduate fare. I have some other references that I am
using for my self-edumacation in these topics. Some of these suggest
having a CAS on-hand for checking calculations and developing
understanding, hence another reason for looking at Sympy/Sage etc.
Excuse the top-posting, the google groups UI is not as convenient for
excerpting as emacs and a good Usenet server...
JBB
--
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.
