Hi Nate, You can use sympy solve (i.e. by passing it symengine expressions it will convert it to sympy expressions, and then you can convert back). If you want to use a C++ solver due to speed reasons, then currently we only have linear solvers implemented here:
https://github.com/symengine/symengine/blob/e5660d01b62e9f68e2e865dae83d8a453a5f2bdb/symengine/matrix.h#L58 You can use them from Python using the solve method: https://github.com/symengine/symengine.py/blob/83c1a70cd2516a597a7a8a12ef0c0ce21ed825de/symengine/lib/symengine_wrapper.pyx#L1199 Let us know if you need faster non-linear solvers than the ones in sympy, and which ones. Ondrej On Tue, Nov 10, 2015 at 1:40 PM, Nathan Woods <[email protected]> wrote: > 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. -- 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/CADDwiVCwu09BAO0Yi45dnuCgkEOzunGN6UHOZPsTkCSEANTr3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
