Hey all, checking in to see if there's been any movement on the Lua wrapper, and if there's any change in the suggestion to use the C++ API if completeness of the wrapper is the goal.
Best, Alex On Tuesday, November 17, 2015 at 10:01:36 AM UTC-5, Dibyendu Majumdar wrote: > > Hi Ondrej, > > On Monday, 16 November 2015, Ondřej Čertík <[email protected] > <javascript:>> wrote: >> >> >> On Sun, Nov 15, 2015 at 1:21 PM, Dibyendu Majumdar >> <[email protected]> wrote: >> > >> > >> > On Sunday, November 15, 2015 at 3:17:14 PM UTC, Ondřej Čertík wrote: >> >> >> >> On Fri, Nov 13, 2015 at 5:50 PM, Dibyendu Majumdar >> >> > I am keen to develop a Lua/Ravi binding for symengine. I would like >> to >> >> > understand a) how symengine compares to sympy with regards to >> >> > functionality, >> >> > and b) whether the C API of symengine is complete, i.e. does it >> expose >> >> > all >> >> > of the features of symengine. >> >> >> >> Thanks for your interest. To answer your questions: >> >> >> >> a) currently the functionality is limited to roughly sympy.core and >> >> matrices. We are developing series expansion now. If there is >> >> particular functionality that you would like, let us know. >> >> >> > >> > Ok thanks, I don't have a specific need right now, but can I assume that >> > over time symengine will support all of the sympy capabilities? I would >> like >> > to be able to provide the same to Lua users. >> >> It is my goal to eventually have all the core symbolic capabilities, >> to be specific, the scope of the C++ SymEngine repository is roughly >> along the lines of sympy.core, sympy.functions, sympy.polys, >> sympy.series, sympy.matrices, sympy.assumptions, sympy.integrals, >> sympy.solvers. SymPy's strength is in having the "batteries included" >> (like physics, tensors, geometry, ...), i.e. having modules for all >> kinds of useful things, and it all works together. My goal is to >> figure out how SymPy can eventually use SymEngine, or work with >> SymEngine. Either way, those modules would probably best live as >> separate repositories, depending on (a particular version of) >> SymEngine. Right now I am concentrating on subsets of the above scope, >> things that people use the most and that has benefits of the speedup >> that one gets with SymEngine, as well as things that people might want >> to use from other languages (like Lua in your case), since that >> increases the community of users and developers, but even in that case >> we are trying to have one of the fastest implementations in there. >> >> > That sounds great! > > > >> > >> >> >> >> b) The C API is doesn't yet expose all the features of symengine. You >> >> can, or we can easily expand it as needed. >> >> >> > >> > I can also directly use the C++ API if that is stable enough. >> >> We are not intentionally breaking anything, but until we hit the >> version 1.0, things can change. But typically changes are not >> difficult to fix. I would chose either C++ or C, depending on what is >> easier to wrap. For Python we use C++, since Cython support for it is >> good. For Julia we use C, since that's what makes the wrappers simple >> (C++ support for Julia is still a bit tricky). >> >> > C API would be easier but from what I can see the C wrapper is not > complete, so I will use the C++ api. > > > >> > >> >> >> >> Your Lua repository can then be hosted at: >> >> >> >> https://github.com/symengine >> >> >> >> probably as "symengine.lua" or something like that. >> >> >> > >> > That would be great. Please let me know the best way to proceed. My >> plan is >> > to start building out the bindings and keep expanding as symengine >> > implementatin grows. >> >> Just create a repository under your name first, get it tested by >> Travis etc. Once you have something that works and would like to have >> it hosted by us, just ping us, and we can move it to the `symengine` >> organization. The Python bindings are the most developed, so you can >> look there for inspiration how to test things on Travis robustly (e.g. >> we test against Sage, which is pretty big to install, etc.). > > > Cool, will get in touch when I am ready (will be a few months I think). > > >> >> Let me know if you need any help. You can also ask on Gitter >> (https://gitter.im/symengine/symengine), we have a pretty active >> channel there. >> >> > Thank you! > > regards > Dibyendu > > On Tuesday, November 17, 2015 at 10:01:36 AM UTC-5, Dibyendu Majumdar wrote: > > Hi Ondrej, > > On Monday, 16 November 2015, Ondřej Čertík <[email protected] > <javascript:>> wrote: >> >> >> On Sun, Nov 15, 2015 at 1:21 PM, Dibyendu Majumdar >> <[email protected]> wrote: >> > >> > >> > On Sunday, November 15, 2015 at 3:17:14 PM UTC, Ondřej Čertík wrote: >> >> >> >> On Fri, Nov 13, 2015 at 5:50 PM, Dibyendu Majumdar >> >> > I am keen to develop a Lua/Ravi binding for symengine. I would like >> to >> >> > understand a) how symengine compares to sympy with regards to >> >> > functionality, >> >> > and b) whether the C API of symengine is complete, i.e. does it >> expose >> >> > all >> >> > of the features of symengine. >> >> >> >> Thanks for your interest. To answer your questions: >> >> >> >> a) currently the functionality is limited to roughly sympy.core and >> >> matrices. We are developing series expansion now. If there is >> >> particular functionality that you would like, let us know. >> >> >> > >> > Ok thanks, I don't have a specific need right now, but can I assume that >> > over time symengine will support all of the sympy capabilities? I would >> like >> > to be able to provide the same to Lua users. >> >> It is my goal to eventually have all the core symbolic capabilities, >> to be specific, the scope of the C++ SymEngine repository is roughly >> along the lines of sympy.core, sympy.functions, sympy.polys, >> sympy.series, sympy.matrices, sympy.assumptions, sympy.integrals, >> sympy.solvers. SymPy's strength is in having the "batteries included" >> (like physics, tensors, geometry, ...), i.e. having modules for all >> kinds of useful things, and it all works together. My goal is to >> figure out how SymPy can eventually use SymEngine, or work with >> SymEngine. Either way, those modules would probably best live as >> separate repositories, depending on (a particular version of) >> SymEngine. Right now I am concentrating on subsets of the above scope, >> things that people use the most and that has benefits of the speedup >> that one gets with SymEngine, as well as things that people might want >> to use from other languages (like Lua in your case), since that >> increases the community of users and developers, but even in that case >> we are trying to have one of the fastest implementations in there. >> >> > That sounds great! > > > >> > >> >> >> >> b) The C API is doesn't yet expose all the features of symengine. You >> >> can, or we can easily expand it as needed. >> >> >> > >> > I can also directly use the C++ API if that is stable enough. >> >> We are not intentionally breaking anything, but until we hit the >> version 1.0, things can change. But typically changes are not >> difficult to fix. I would chose either C++ or C, depending on what is >> easier to wrap. For Python we use C++, since Cython support for it is >> good. For Julia we use C, since that's what makes the wrappers simple >> (C++ support for Julia is still a bit tricky). >> >> > C API would be easier but from what I can see the C wrapper is not > complete, so I will use the C++ api. > > > >> > >> >> >> >> Your Lua repository can then be hosted at: >> >> >> >> https://github.com/symengine >> >> >> >> probably as "symengine.lua" or something like that. >> >> >> > >> > That would be great. Please let me know the best way to proceed. My >> plan is >> > to start building out the bindings and keep expanding as symengine >> > implementatin grows. >> >> Just create a repository under your name first, get it tested by >> Travis etc. Once you have something that works and would like to have >> it hosted by us, just ping us, and we can move it to the `symengine` >> organization. The Python bindings are the most developed, so you can >> look there for inspiration how to test things on Travis robustly (e.g. >> we test against Sage, which is pretty big to install, etc.). > > > Cool, will get in touch when I am ready (will be a few months I think). > > >> >> Let me know if you need any help. You can also ask on Gitter >> (https://gitter.im/symengine/symengine), we have a pretty active >> channel there. >> >> > Thank you! > > regards > Dibyendu > > -- 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 https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e16c41fb-79c9-4a7b-9563-97c5418316e6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
