On Monday, 2 November 2015 21:46:56 UTC+1, Aaron Meurer wrote: > > > > On Mon, Nov 2, 2015 at 2:13 PM, Björn Dahlgren <[email protected] > <javascript:>> 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? >>> >>> >> <https://lh3.googleusercontent.com/-dsiD_NRFl6o/Vje9tVtxcMI/AAAAAAAABLU/TMTBLBgtf48/s1600/overview.png> >> >> 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): >> >> >> <https://lh3.googleusercontent.com/-dsiD_NRFl6o/Vje9tVtxcMI/AAAAAAAABLU/TMTBLBgtf48/s1600/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? >
There should only have been one image, google-groups messed it up. The linked image (http://hera.physchem.kth.se/~bjorn/overview.png) is the correct one. I'd like to support all which is there but I'm spread thin, and the earlier efforts should most probably be refactored (I've simply learnt things along the way). > > I didn't see symvarsub. It looks like it is very similar to autowrap. Any > reason it shouldn't be in SymPy itself? > Well, since it depends on pycompilation and pycodeexport it would introduce dependencies unless they were incorporated as well. And I suppose that incorporating pycompilation/pycodeexport would require testing on OS X and windows which I currently lack access to/cannot motivate spending the time myself. > > >> 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 >> <http://github.com/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). > Yes, in SymPy it definitely is. I am quite surprised how fast the lambdified expressions are (not construction though). > I don't know what lambdify means in terms of symengine. Is it the same > thing? > In symengine Isuru Fernando implemented a visitor <https://github.com/symengine/symengine/pull/623> using C++ lambda functions so there is no code generation there. > > 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). > Yes, I am planning to do some real world benchmarks (for problems I've come across in my research) where I would compare sympy.lambdify, symengine.Lambdify and numba.jit(sympy.lambdify(...)), etc. > > Aaron Meurer > >> >> - `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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] <javascript:> >> . >> 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 >> >> <https://groups.google.com/d/msgid/sympy/f86e0fed-9c74-456e-a803-e7dac427cfd3%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/fc6c7146-2334-4823-8c69-e9cc76e8414c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
