Lua binding for symengine

[Dibyendu Majumdar]

Hi,

I am the developer of Ravi (http://ravilang.org) - which ia dialect of Lua 5.3 and features limited optional static typing and LLVM JIT compiler.

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.

Many thanks

Regards
Dibyendu

[Ondřej Čertík]

Hi Dibyendu,

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.

b) The C API is doesn't yet expose all the features of symengine. You
can, or we can easily expand it as needed.

Your Lua repository can then be hosted at:

https://github.com/symengine

probably as "symengine.lua" or something like that.

If you look at our Julia repository:
https://github.com/symengine/SymEngine.jl, it only has few basic
features, but it is there and other people can contribute and help
improve it.

Ondrej

[Dibyendu Majumdar]

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.
 

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.
 

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.

Thanks and Regards
Dibyendu

[Ondřej Čertík]

Hi Dibyendu,

On Sun, Nov 15, 2015 at 1:21 PM, Dibyendu Majumdar
<mob...@majumdar.org.uk> 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.

>
>>
>> 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).

>
>>
>> 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.).

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.

Ondrej

>
> Thanks and 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 sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> 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/98736014-666a-42f0-a180-7d506422863f%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Dibyendu Majumdar]

Hi Ondrej,

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

 

[Alex W]

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

[Ondřej Čertík]

Hi Alex,

On Sun, Apr 3, 2016 at 4:47 PM, Alex W <ale...@gmail.com> wrote:
> Hey all, checking in to see if there's been any movement on the Lua wrapper,

I haven't heard from Dibyendu since his last email in this thread.

> and if there's any change in the suggestion to use the C++ API if
> completeness of the wrapper is the goal.

Our goal is to have a complete C API in SymEngine eventually, so that
you can use either C or C++ API for wrappers. The C wrapper is being
improved as part of Julia, Ruby and Haskell bindings.

Ondrej

[Alex Wiltschko]

Thanks for the info

--
You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/695egkleN9w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sympy+un...@googlegroups.com.

To post to this group, send email to sy...@googlegroups.com.

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/CADDwiVD5qCLrGhyvK70P2Fj0%2B84n%3DoL-LRfm5xCmrTETh-htRA%40mail.gmail.com.

[Dibyendu Majumdar]

Hi Ondřej,

On 4 April 2016 at 17:29, Ondřej Čertík <ondrej...@gmail.com> wrote:
> On Sun, Apr 3, 2016 at 4:47 PM, Alex W <ale...@gmail.com> wrote:
>> Hey all, checking in to see if there's been any movement on the Lua wrapper,
>
> I haven't heard from Dibyendu since his last email in this thread.
>
>> and if there's any change in the suggestion to use the C++ API if
>> completeness of the wrapper is the goal.
>

I have not yet started on this, unfortunately. It will be later part
of this year before I get some time to work on this.

Regards
Dibyendu