Asst. Prof. Anthony Scopatz
Nuclear Engineering Program
Mechanical Engineering Dept.
University of South Carolina
sco...@cec.sc.edu
Office: (803) 777-7629
Cell: (512) 827-8239
Check my calendar
Pyomo can convert optimization problems written in Python to AML modeling language.
Fast matrix exponentiation:
I would also love to hear from those of you who are using SymPy to do
code generation or would like to use SymPy to do code generation, what
is your wishlist for SymPy? What do you wish it could do that it can't
do or what do you wish it could do better?
Since a picture is worth a thousand words I tried to summarize my efforts here (http://hera.physchem.kth.se/~bjorn/overview.png):
The repos are at https://github/bjodah
I've tried to summarize some of my more general experince here:
That said, I think the most common idioms that keep reoccurring should definitely be collected in a "template" library along with convenience functions to render those
from SymPy expressions (e.g. code that populates a jacobian matrix - possibly banded).
I was quite surprised to hear that compiler CSE elimination was so slow in one of Anthony Scopatz's projects - that is a nice motivation to do this in SymPy already.
On Friday, 30 October 2015 22:33:19 UTC+1, Aaron Meurer wrote:I would also love to hear from those of you who are using SymPy to do
code generation or would like to use SymPy to do code generation, what
is your wishlist for SymPy? What do you wish it could do that it can't
do or what do you wish it could do better?
I took the liberty to answer some questions inline in the wiki.
The work that I've done with codegeneration using SymPy was motivated by either:
- Solving systems of nonlinear equations numerically
- Integrating (nonlinear) systems of ordinary differential equations
Since a picture is worth a thousand words I tried to summarize my efforts here (http://hera.physchem.kth.se/~bjorn/overview.png):
The repos are at https://github/bjodah
I've tried to summarize some of my more general experince here:
- Using templates is almost a must, and then rather a powerful templating engine (e.g. Mako) rather than jinja2 or the like.
That said, I think the most common idioms that keep reoccurring should definitely be collected in a "template" library along with convenience functions to render those
from SymPy expressions (e.g. code that populates a jacobian matrix - possibly banded).
- Code generation can quite easily impede your speed of development.
Example: you generate a Cython file, for every change both the Cython file and the resulting C file have to be recompiled.
I tried to get distutils to only recompile what had changed and cache object files, I couldn't get it to work so I wrote pycompilation to do that instead.
Another solution would be to JIT code but then it is much harder to adapt your code for various libraries used in HPC environments for example.- Even if one use code-generation it is nice to be able to use `lambdify` so if the API can be made agnostic of that choice it's a great bonus.
See also our recent effort in implementing a faster lambdify in symengine: https://github.com/symengine/symengine.py/pull/11
(I believe we can do better still, perhaps using LLVM jiting for medium sized expressions)
- `Indexed` objects in sympy have been quite useful for representing discretized data points, but it could definitely be improved further.
I was quite surprised to hear that compiler CSE elimination was so slow in one of Anthony Scopatz's projects - that is a nice motivation to do this in SymPy already.
--
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 sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
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/f86e0fed-9c74-456e-a803-e7dac427cfd3%40googlegroups.com.
On Mon, Nov 2, 2015 at 2:13 PM, Björn Dahlgren <bjo...@gmail.com> wrote:
On Friday, 30 October 2015 22:33:19 UTC+1, Aaron Meurer wrote:I would also love to hear from those of you who are using SymPy to do
code generation or would like to use SymPy to do code generation, what
is your wishlist for SymPy? What do you wish it could do that it can't
do or what do you wish it could do better?
I took the liberty to answer some questions inline in the wiki.Thanks.
The work that I've done with codegeneration using SymPy was motivated by either:
- Solving systems of nonlinear equations numerically
- Integrating (nonlinear) systems of ordinary differential equations
Since a picture is worth a thousand words I tried to summarize my efforts here (http://hera.physchem.kth.se/~bjorn/overview.png):
The repos are at https://github/bjodah
So are the items in the top image that aren't in the bottom still supported?
I didn't see symvarsub. It looks like it is very similar to autowrap. Any reason it shouldn't be in SymPy itself?
I've tried to summarize some of my more general experince here:
- Using templates is almost a must, and then rather a powerful templating engine (e.g. Mako) rather than jinja2 or the like.
That said, I think the most common idioms that keep reoccurring should definitely be collected in a "template" library along with convenience functions to render those
from SymPy expressions (e.g. code that populates a jacobian matrix - possibly banded).
- Code generation can quite easily impede your speed of development.
Example: you generate a Cython file, for every change both the Cython file and the resulting C file have to be recompiled.
I tried to get distutils to only recompile what had changed and cache object files, I couldn't get it to work so I wrote pycompilation to do that instead.
Another solution would be to JIT code but then it is much harder to adapt your code for various libraries used in HPC environments for example.- Even if one use code-generation it is nice to be able to use `lambdify` so if the API can be made agnostic of that choice it's a great bonus.
See also our recent effort in implementing a faster lambdify in symengine: https://github.com/symengine/symengine.py/pull/11
(I believe we can do better still, perhaps using LLVM jiting for medium sized expressions)In my view, lambdify *is* code generation. lambdarepr generates Python/NumPy code from a SymPy expression, and lambdify "compiles" that code into a Python function (it also uses some namespace tricks on top of lambdarepr, which admittedly isn't the cleanest design).
I don't know what lambdify means in terms of symengine. Is it the same thing?
For LLVM, you can wrap your lambdified function with numba.jit or numba.vectorize. In my tests, that works quite well (in a very simple test that I did it ended up being just as fast as autowrap via f2py).
My use case for Sympy code generation is somewhat different from most, it seems. I'm primarily interested in numerical quadrature on a grid, which means a LOT of evaluations of similar functions. I'm only using lambdify currently, because the compile-time associated with codegen is worse than the Python call-back overhead. The real gotcha for me is that I need to do a complete Solve-Generate-Integrate loop many, many times, so the performance of the generation step matters a lot.
I would also love to hear from those of you who are using SymPy to do
code generation or would like to use SymPy to do code generation, what
is your wishlist for SymPy? What do you wish it could do that it can't
do or what do you wish it could do better?
what is your wishlist for SymPy?
what is your wishlist for SymPy?ND-Arrays
Visit this group at https://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/9198f1ea-b0e8-4f54-b559-8d2e6cedae41%40googlegroups.com.