I'm solving a number of different equations, but one example I've used (using sympy syntax) might be:
sympy.solve(x**2+y**2+z**2-1, x) I'm definitely hoping for the speed improvements; that's the main reason not to simply use Sympy. On Tuesday, November 10, 2015 at 3:33:23 PM UTC-7, Ondřej Čertík wrote: > > 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] > <javascript:>> 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] <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/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/a2455201-de4f-41dc-97fc-3b2793fa3b30%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
