SymEngine 0.1.0 released

[Ondřej Čertík]

Hi,

We just released SymEngine 0.1.0:

https://github.com/sympy/symengine/releases/tag/v0.1.0

SymEngine (https://github.com/sympy/symengine) is a standalone fast
C++ symbolic manipulation library. Optional thin wrappers allow usage
of the library from other languages, we currently have C, Python, Ruby
and Julia wrappers. The Python wrappers allow integration with SymPy
and Sage.

SymEngine was previously called CSymPy, but we renamed it, since it
can be used from any language, not just Python. Even though the Python
wrappers are the most developed, and I am personally heavily invested
in Python and my long term goal is to figure out how to port SymPy on
top of SymEngine, as well as Sage on top of SymEngine. So that we can
have just one symbolic library, that is fast, but also has a lot of
features, either in terms of SymPy in Python, or eventually in C++
(that way other languages can benefit as well).

Here are build instructions for Sage:
https://github.com/sympy/symengine/wiki/Building-SymEngine#installing-into-sage,
we tested it on Sage Math Cloud. You can then use Sage with SymEngine
in it to run your favorite benchmark.

We also have some automatic benchmarks, some timings are posted here:
https://github.com/sympy/symengine/pull/579


We benchmark both the Python wrappers (against Sage or SymPy), as well
as just the raw C++ library (against e.g. GiNaC).

Most of these benchmarks are synthetic, and so the problem with them
is that you can for example use a fast polynomial library to do them
faster. SymEngine seems to be faster than Sage on all of them, but if
you find some where Sage is faster, definitely let me know.

However, much better is to benchmark on some real applications. Here
is an example: https://github.com/certik/symengine/pull/10#issuecomment-129199481,
that uses symbolics (as it has square roots, fractions, sin, cos and
other things) and it is benchmarking how long it takes to do a
derivative (once the expression is fully converted to Sage, SymEngine
or SymPy). The expression comes up when calculating equations of
motion for a bicycle using PyDy (http://www.pydy.org/), you actually
need a Jacobian, but this is just one element of it.
And Sage seems 6x slower. The benchmark is here:
https://github.com/sympy/symengine/pull/580, it's the kane3.py. It
should be pointed out that Sage might arrange the final expression a
bit differently, so a meaningful benchmark is to do the whole bicycle
application, not just one derivative.

But so far my experience has been that SymEngine is faster than Sage
(sometimes significantly, I think 6x is a good speedup) and if you
find some application or a case when Sage is faster, please let me
know.


What is the best way to maintain a package like this for Sage --- we
currently create an spkg, but I read somewhere that spkgs will be
deprecated? Right now we want to maintain it ourselves and make it
easy for people to try out and if enough people like it, we can start
discussing more how to make Sage use it by default.

As I said, that is my long term goal, but it is a lot of work. If
successful though, users and developers of Sage can then contribute to
it and then anybody else who uses SymEngine outside of Sage will
immediately benefit, and vice versa. And by being in C++, not just
Python users will benefit, since the main development is done in C++.
There are lots of people in Ruby, Julia, even Haskell who ask for a
symbolic package. And this can be it.

The C++ code is truly cross platform, we test every commit with
gcc/clang on linux, gcc/apple clang on OS X and MSVC/mingw on Windows.
I also test manually with Intel and PGI compilers. See here for more
details: https://github.com/sympy/symengine/wiki/Compiler-Support

There will be bugs that you might discover during building it, but
they can be fixed if you report them. Inherently it should build using
any recent C++11 compiler on any platform.

If you try it out, we would be interested in any feedback, both
positive and negative. Isuru has spent most of the summer making it
working well with Sage and improving the code overall. And several
other GSoC students have been working on it as well.

Ondrej

[François Bissey]

Hi Ondřej,

Old fashioned .spkg are not in fashion anymore. In fact we very much
want to kill them as much as possible. The new process separate the
tarball from upstream (pristine as much as possible) and the building
script. In a similar fashion gentoo ebuild or hashtag recipe. Look at
https://github.com/sagemath/sage/tree/master/build/pkgs
for some example. spkg-install is still very much the recipe used.
So it should be done by pushing a branch on a sage ticket.
We should really finish to push cmake through at least as an
experimental package so this could also be in experimental.
Once we sort out cmake as optional SymEngine could also become
optional.

I can probably get it in sage-on-gentoo straight away though.

Francois

[William Stein]

On Mon, Aug 10, 2015 at 4:26 PM, Ondřej Čertík <ondrej...@gmail.com> wrote:

> What is the best way to maintain a package like this for Sage --- we
> currently create an spkg, but I read somewhere that spkgs will be
> deprecated? Right now we want to maintain it ourselves and make it
> easy for people to try out and if enough people like it, we can start
> discussing more how to make Sage use it by default.

I would like to strongly encourage you to make properly package and
distribute SymEngine in the way that is standard for Python libraries,
as in your issue 160:

https://github.com/sympy/symengine/issues/160

Then I can install SymEngine by typing

sage -sh
pip install SymEngine

And for what it is worth, I very strongly believe we should do
everything we can to transition Sage itself over to using current
standard current approaches to development and distribution. That
means fully supporting pip, using github (instead of a custom trac and
wiki install), and better integrating with Linux distro package
systems, etc. It would also mean trying to break up the full
SageMath library into smaller more manageable dependencies with
semantic versioning, and have pip bring those in. I'm very
curious whether other Sage developers agree with me that the time is
ripe to move in such a direction.

-- William, still tired of reinventing wheels...

>
> As I said, that is my long term goal, but it is a lot of work. If
> successful though, users and developers of Sage can then contribute to
> it and then anybody else who uses SymEngine outside of Sage will
> immediately benefit, and vice versa. And by being in C++, not just
> Python users will benefit, since the main development is done in C++.
> There are lots of people in Ruby, Julia, even Haskell who ask for a
> symbolic package. And this can be it.
>
> The C++ code is truly cross platform, we test every commit with
> gcc/clang on linux, gcc/apple clang on OS X and MSVC/mingw on Windows.
> I also test manually with Intel and PGI compilers. See here for more
> details: https://github.com/sympy/symengine/wiki/Compiler-Support
>
> There will be bugs that you might discover during building it, but
> they can be fixed if you report them. Inherently it should build using
> any recent C++11 compiler on any platform.
>
> If you try it out, we would be interested in any feedback, both
> positive and negative. Isuru has spent most of the summer making it
> working well with Sage and improving the code overall. And several
> other GSoC students have been working on it as well.
>
> Ondrej
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



--
William (http://wstein.org)

[Nathan Dunfield]

And for what it is worth, I very strongly believe we should do
everything we can to transition Sage itself over to using current
standard current approaches to development and distribution.   That
means fully supporting pip, using github (instead of a custom trac and
wiki install), and better integrating with Linux distro package
systems, etc.      It would also mean trying to break up the full
SageMath library into smaller more manageable dependencies with
semantic versioning, and have pip bring those in.       I'm very
curious whether other Sage developers agree with me that the time is
ripe to move in such a direction.

William,

Based on my experience using pip/PyPI/easy_install/etc. to distribute SnapPy as an amalgam of these packages

https://pypi.python.org/pypi?%3Aaction=search&term=dunfield&submit=search

--- which includes a stand-alone version of Sage's PARI interface --- one issue that comes to mind is that pip has limited support for binary "wheels" on Linux.  In fact, currently PyPI refuses to host Linux wheels (though OS X and Windows wheels are accepted).  We do provide binary Linux "eggs" that work with the deprecated easy_install on most reasonably recent Linux distros, but this requires some ugly hacks to deal with e.g. whether Python is compiled to use 2 or 4 byte unicode strings, as well as compiling the eggs themselves on virtual machines running really dated distros.

So using pip and PyPI on Linux would likely result in building each Python module from source.  For modules with modest-to-moderate amounts of C/C++ code, this is no problem, and even something larger but reasonably self-contained like PARI can be dealt with by having "setup.py" just execute some Makefile or whatever.  Things with dependencies on system libraries (e.g. OpenGL headers or whatever) can get tricky which is why it would be really nice to have binary wheels as a fallback...

Best,

Nathan

Best,

Nathan

[Ralf Stephan]

Nice. I'm looking forward to contribute, not the least

because of the review situation, but also because it

is useful for more than one project.