On Mon, Mar 14, 2011 at 10:24 PM, Chris Kees <[email protected]> wrote: > On Mon, Mar 14, 2011 at 10:40 PM, Ondrej Certik <[email protected]> wrote: >> Hi Chris, >> >> On Mon, Mar 14, 2011 at 9:08 AM, Chris Kees <[email protected]> wrote: >>> Hi, >>> >>> I'm new to the list and have done very little with symbolic math so >>> I'm hoping there is a simple way to do what I need to do. I have two >>> scalar functions f and g defined on the 6 dimensional space of >>> symmetric tensors. I need to calculate Df, Dg, and D^2 g and then >>> generate optimized C++ code to evaluate everything. Df and Dg can be >>> stored as 6x1 matrices and D^2g as 6x6. I wrote a simple script to >>> do that by building up the expressions for f and g and then calling >>> diff to build lists of the derivatives and then ccode to write >>> everything to an inline function. The problem is that the resulting >>> expressions are extremely large and my naive attempt at using the >>> simplify function crashed after using up all the memory on my machine >>> (8G). >> >> I run the scripts, and it takes quite a while to finish, so I would >> start with something manageable so that we can debug it. Would it make >> sense to let's say work with Df only for now and try to simplify it? >> > > Yes, I will focus on Df for now. > >>> >>> The functions f and g are really just functions of the 3 tensor >>> invariants so if I were to do this by hand I'd build the gradient and >>> Hessian of each invariant and the gradient and Hessian of f and g and >>> then build Df, Dg, and D^2g by the chain rule. That would catch a lot >>> of repeated subexpressions and a few more simplifications could be >>> identified due to the fact that the tensor invariants contain rational >>> and trigonometric functions that tend to be repeated in the >>> derivatives. I doubt the hand generated code would be optimal though. >>> Does this seem like something the cse module or some of the other >>> specialized simplification support in sympy can handle? I'm pasting >>> the short python script in below. >> >> I think the cse() could do a good job, but if the expression is >> extremely large, it might be quite slow. >> >> Since you know what has to be done, another option is to do the chain >> rule "by hand" in sympy, and keep expressions in variables, so that it >> doesn't grow large. >> >> By saying, that the "hand generated code will not be optimal", which >> of these do you mean: >> >> 1) generating by hand (literally) would take months, thus will not be optimal >> 2) generating by hand using sympy will be fast to implement, however, >> the resulting expressions will still be very complex and more >> simplification is needed >> >> and if you mean 2), what other simplifications should be done? >> > > I mean 2), the generated code will still not be optimal in that it > will still have a lot of common subexpressions. I ran cse on a list of > intermediate expressions used to build Df, and it pulled out 25 > subexpressions, which is probably already beyond what I would do by > hand. I will work on reorganizing the calculation to make the > expressions shorter.
I see. Cool, keep us posted. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. 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.
