Am I correct in noticing that symengine.py does not yet have Solve (or equivalent)? That's kind of a dealbreaker, unfortunately.
On Tuesday, November 3, 2015 at 9:56:43 AM UTC-7, Björn Dahlgren wrote: > > > > On Tuesday, 3 November 2015 16:46:39 UTC+1, Nathan Woods wrote: >> >> 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. >> > > Interesting. If you are only doing numerical (double precision) > evaluations and are only using the lambdified expressions once, symengine > should > be quite a bit faster. I wrote this shim which makes symengine.Lambdify > work like sympy.lambdify: > > https://gist.github.com/anonymous/7c6d7a5e80e1e5f6b39e > > You can try to see if you see a speed up. > > >> >> Nathan Woods >> >> On Friday, October 30, 2015 at 3:33:19 PM UTC-6, 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? >>> >>> Aaron Meurer >>> >>> On Fri, Oct 30, 2015 at 4:23 PM, Anthony Scopatz <[email protected]> >>> wrote: >>> > Hello All, >>> > >>> > As many of you probably know, earlier this month Aaron joined my >>> research >>> > group at the University of South Carolina. He'll be working on adding >>> / >>> > improving SymPy's capabilities with respect to being an optimizing >>> compiler. >>> > >>> > There are more details about this vision below, but right now we are >>> in the >>> > process of doing a literature review of sorts, and trying to figure >>> out what >>> > (SymPy-specific) is out there. What has been done already. Aaron et >>> al, have >>> > started putting together a page on the wiki that compiles some of this >>> > information. We'd really appreciate it if you know of anything that is >>> not >>> > on this page if you could let us know. >>> > >>> > We also would be grateful if you could let us know (publicly or >>> privately) >>> > about any use cases that you might have for a symbolic optimizing >>> compiler. >>> > There are many examples where different folks have done various pieces >>> of >>> > this (chemreac, dengo, pydy, some stuff in pyne), but these examples >>> tend to >>> > be domain specific. This effort is supposed to target a general >>> scientific >>> > computing audience, and to do that we want to have as many possible >>> > scenarios in mind at the outset. >>> > >>> > And of course, we'd love it if other folks dived in and helped us put >>> this >>> > thing together :). >>> > >>> > Thanks a million! >>> > Be Well >>> > Anthony >>> > >>> > Vision >>> > ------------ >>> > Essentially, what we want to build is an optimizing compiler for >>> symbolic >>> > mathematical expressions in order to solve simple equations, ODEs, >>> PDEs, and >>> > perhaps more. This compiler should be able to produce very fast code, >>> though >>> > the compiler itself may be expensive. >>> > >>> > Ultimately, it is easy to imagine a number of backend targets, such as >>> C, >>> > Fortran, LLVM IR, Cython, pure Python, etc. It is also easy to imagine >>> a >>> > couple of meaningful frontends - SymPy objects (for starters) and >>> LaTeX >>> > (which could then be parsed into SymPy). >>> > >>> > We are aiming to have an optimization pipeline that is highly >>> customizable >>> > (but with sensible defaults). This would allow folks to tailor the >>> result to >>> > their problem or add their own problem-specific optimizations. There >>> are >>> > likely different levels to this (such as on an expression vs at full >>> > function scope). Some initial elements of this pipeline might include >>> CSE, >>> > simple rule-based rewriting (like a/b/c -> a/(b*c) or a*exp(b*x) -> >>> > A*2^(B*x)), and replacing non-analytic sub-expressions with >>> approximate >>> > expansions (taylor, pade, chebychev, etc) out to an order computed >>> based on >>> > floating point precision. >>> > >>> > That said, we aren't the only ones thinking in this area. The chemora >>> > (http://arxiv.org/pdf/1410.1764.pdf, h/t Matt Turk) code does >>> something like >>> > the vision above but using Mathematica, for HPC applications only, and >>> with >>> > an astrophysical bent. >>> > >>> > I think a tool like this is important because it allows the >>> exploration of >>> > more scientific models more quickly and with a higher degree of >>> > verification. The current workflow for most scientific modeling is to >>> come >>> > up with a mathematical representation of the problem, a human then >>> > translates that into a programming language of choice, they may or may >>> not >>> > test this translation, and then execution of that model. This compiler >>> aims >>> > to get rid of the time-constrained human in those middle steps. It >>> won't >>> > tell you if the model is right or not, but you'll sure be able to pump >>> out a >>> > whole lot more models :). >>> > >>> > >>> > -- >>> > >>> > Asst. Prof. Anthony Scopatz >>> > Nuclear Engineering Program >>> > Mechanical Engineering Dept. >>> > University of South Carolina >>> > [email protected] >>> > Office: (803) 777-7629 >>> > Cell: (512) 827-8239 >>> > Check my calendar >>> > >>> > -- >>> > 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/CAPk-6T453AxDYt1UCmBj_7vrzr_HikC2U03UP%2Bzz5_RtDA9NDA%40mail.gmail.com. >>> >>> >>> > 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/2b52bf0f-4396-4c7a-9dbc-372fc7666a54%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
