my use case for sympy expressions is like this: I have some "arbitrary" correlations/metamodels as input from text file to the sympy parser. These expressions are converted into functions using lambdify, and the backend is numpy only.
These definitions are then passed to scipy optimizer to perform non-linear regression on these equations with some "experimental" data to calculate the best estimate for tuning parameters. This works pretty well for me currently and I'm interested in trying out the common correlations from zunzun library for best metamodels. Also ND chebyshev polynomials look promising. On Tuesday, November 3, 2015 at 10:56:43 AM UTC-6, 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/9058b30f-a59b-4dd5-8d76-28a8fa2a3d88%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
