Refactoring/modularization work on the Symbolic Ring

Matthias Koeppe

unread,

Aug 25, 2021, 2:05:41 AM8/25/21

to sage-devel

https://trac.sagemath.org/ticket/32386 proposes to merge the pynac sources as src/sage/symbolic/ginac into the Sage source tree. This will solve packaging issues and also make it easier for developers to work on symbolics issues.

As this is a large change, this ticket will benefit from thorough testing and reviews.

Dima Pasechnik

unread,

Aug 25, 2021, 6:19:15 AM8/25/21

to sage-devel

I don't think this ticket is a very good idea long term, mainly due to pynac being essentially abandonware: no active contributor to Sage understands some details of pynac, there is a seemingly endless stream of bugs coming from it, etc.

I am not saying this ticket should not go forward, but having this C++ code in the body of Sage is more harmful than when it is separate.

The main problem of pynac is not that the present setup makes it hard to work on symbolic issues, but that Sage depends on it at all.

Dima

On Wed, 25 Aug 2021, 09:05 Matthias Koeppe, <matthia...@gmail.com> wrote:

https://trac.sagemath.org/ticket/32386 proposes to merge the pynac sources as src/sage/symbolic/ginac into the Sage source tree. This will solve packaging issues and also make it easier for developers to work on symbolics issues.

As this is a large change, this ticket will benefit from thorough testing and reviews.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/fae9f540-d0cc-4a8e-9034-d2bc9ad21074n%40googlegroups.com.

Nils Bruin

unread,

Aug 25, 2021, 12:37:20 PM8/25/21

to sage-devel

On Wednesday, 25 August 2021 at 03:19:15 UTC-7 dim...@gmail.com wrote:

The main problem of pynac is not that the present setup makes it hard to work on symbolic issues, but that Sage depends on it at all.

Aren't these separate issues? It may be the case that we should switch symbolic engine (which is a big job!), but without a candidate that's not something we can plan on right now. So, it looks to me we're bound to pynac for the foreseeable future. Since sage is the sole user of pynac, any work on pynac will happen in the context of sage. From that perspective, putting the code itself in the sage source seems to make sense. Doing so doesn't preclude throwing it out later (although it might grow other dependencies, making that harder).

So, perhaps we should make a quick assessment if moving to another symbolic engine is something that's on the horizon? Sympy has grown ... would that be sufficiently high-performance? (Sage has changed symbolic engines before and it is a huge pain. It will cause all kinds of incompatible changes to happen that are very hard to patch up -- and patching some of them will be very unattractive because backwards-compatibility changes tend to ruin the conceptual consistency of the new solution)

Dima Pasechnik

unread,

Aug 25, 2021, 12:58:04 PM8/25/21

to sage-devel

On Wed, 25 Aug 2021, 19:37 Nils Bruin, <nbr...@sfu.ca> wrote:

On Wednesday, 25 August 2021 at 03:19:15 UTC-7 dim...@gmail.com wrote:
The main problem of pynac is not that the present setup makes it hard to work on symbolic issues, but that Sage depends on it at all.
Aren't these separate issues? It may be the case that we should switch symbolic engine (which is a big job!), but without a candidate that's not something we can plan on right now.

symengine appears to be such a candidate:

https://symengine.org/

So, it looks to me we're bound to pynac for the foreseeable future. Since sage is the sole user of pynac, any work on pynac will happen in the context of sage. From that perspective, putting the code itself in the sage source seems to make sense. Doing so doesn't preclude throwing it out later (although it might grow other dependencies, making that harder).

So, perhaps we should make a quick assessment if moving to another symbolic engine is something that's on the horizon? Sympy has grown ... would that be sufficiently high-performance? (Sage has changed symbolic engines before and it is a huge pain. It will cause all kinds of incompatible changes to happen that are very hard to patch up -- and patching some of them will be very unattractive because backwards-compatibility changes tend to ruin the conceptual consistency of the new solution)

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a45b37bd-6176-431c-b792-b3b272ea1c6en%40googlegroups.com.

William Stein

unread,

Aug 25, 2021, 1:08:08 PM8/25/21

to sage-devel

On Wed, Aug 25, 2021 at 9:58 AM Dima Pasechnik <dim...@gmail.com> wrote:
>
>
>
> On Wed, 25 Aug 2021, 19:37 Nils Bruin, <nbr...@sfu.ca> wrote:
>>
>> On Wednesday, 25 August 2021 at 03:19:15 UTC-7 dim...@gmail.com wrote:
>>>
>>> The main problem of pynac is not that the present setup makes it hard to work on symbolic issues, but that Sage depends on it at all.
>>
>> Aren't these separate issues? It may be the case that we should switch symbolic engine (which is a big job!), but without a candidate that's not something we can plan on right now.
>
>
> symengine appears to be such a candidate:
> https://symengine.org/

(1 minute thought) That website says that sympy uses symengine as a
backend for speed. In that case, maybe we can switch to sympy more...
and contribute to sympy making better use of symengine, if necessary?

>
>
>> So, it looks to me we're bound to pynac for the foreseeable future. Since sage is the sole user of pynac, any work on pynac will happen in the context of sage. From that perspective, putting the code itself in the sage source seems to make sense. Doing so doesn't preclude throwing it out later (although it might grow other dependencies, making that harder).
>>
>> So, perhaps we should make a quick assessment if moving to another symbolic engine is something that's on the horizon? Sympy has grown ... would that be sufficiently high-performance? (Sage has changed symbolic engines before and it is a huge pain. It will cause all kinds of incompatible changes to happen that are very hard to patch up -- and patching some of them will be very unattractive because backwards-compatibility changes tend to ruin the conceptual consistency of the new solution)
>>
>> --
>> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a45b37bd-6176-431c-b792-b3b272ea1c6en%40googlegroups.com.
>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0N7FBETRevL9sWo05dmosH4Nq%3DxJfmiWXz9Fj7Nki32g%40mail.gmail.com.

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

Matthias Koeppe

unread,

Aug 25, 2021, 1:10:58 PM8/25/21

to sage-devel

On Wednesday, August 25, 2021 at 9:37:20 AM UTC-7 Nils Bruin wrote:

perhaps we should make a quick assessment if moving to another symbolic engine is something that's on the horizon?

I think a combination of Sympy and symengine would be the only candidate; but I think it is completely unrealistic to expect developers to step up to prepare a wholesale replacement of our symbolics implementation.

More narrowly focused work is more realistic. For example, the symbolic assumptions subsystem in Sage is in very poor shape. In https://trac.sagemath.org/ticket/31958, I propose to replace this with subsystem with sympy.

Matthias Koeppe

unread,

Aug 25, 2021, 1:17:50 PM8/25/21

to sage-devel

On Wednesday, August 25, 2021 at 10:08:08 AM UTC-7 wst...@gmail.com wrote:

On Wed, Aug 25, 2021 at 9:58 AM Dima Pasechnik <dim...@gmail.com> wrote:
> symengine appears to be such a candidate:
> https://symengine.org/

(1 minute thought) That website says that sympy uses symengine as a
backend for speed. In that case, maybe we can switch to sympy more...
and contribute to sympy making better use of symengine, if necessary?

Yes, sympy can use symengine but AFAIK it has to be explicitly enabled: See https://github.com/sympy/sympy/blob/master/sympy/core/backend.py

Sage already has symengine (and its Python bindings) as optional packages.

I don't know if anyone has tested whether enabling symengine brings performance gains for the parts of SymPy that Sage uses.

Dima Pasechnik

unread,

Aug 25, 2021, 2:09:00 PM8/25/21

to sage-devel

symengine appears to have less coverage than pynac, judging by

if USE_SYMENGINE:
from symengine import (Symbol, Integer, sympify, S,
SympifyError, exp, log, gamma, sqrt, I, E, pi, Matrix,
sin, cos, tan, cot, csc, sec, asin, acos, atan, acot, acsc, asec,
sinh, cosh, tanh, coth, asinh, acosh, atanh, acoth,
lambdify, symarray, diff, zeros, eye, diag, ones,
expand, Function, symbols, var, Add, Mul, Derivative,
ImmutableMatrix, MatrixBase, Rational, Basic)
from symengine.lib.symengine_wrapper import gcd as igcd
from symengine import AppliedUndef

in sympy/core/backend.py

E.g. it looks like integration is not there.

>
>
>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6865327a-c967-4cfe-8903-7c6580113124n%40googlegroups.com.

kcrisman

unread,

Aug 26, 2021, 7:25:50 AM8/26/21

to sage-devel

E.g. it looks like integration is not there.

If I recall correctly, we use ginac/pynac only for symbolics proper (i.e. not calculus), as well as for differentiation. I don't know if symengine is something to switch to (and Matthias is surely right about developer time, given the amazing and very long effort involved in switching to pynac all these years ago), but integration isn't something to worry about with that. (Whether it's time to start having sympy as default integration engine is another question.)

Emmanuel Charpentier

unread,

Aug 27, 2021, 4:42:13 AM8/27/21

to sage-devel

Le jeudi 26 août 2021 à 13:25:50 UTC+2, kcrisman a écrit :

E.g. it looks like integration is not there.

If I recall correctly, we use ginac/pynac only for symbolics proper (i.e. not calculus), as well as for differentiation. I don't know if symengine is something to switch to (and Matthias is surely right about developer time, given the amazing and very long effort involved in switching to pynac all these years ago), but integration isn't something to worry about with that. (Whether it's time to start having sympy as default integration engine is another question.)

To which the answer is currently “Hell no ! “ :

sage: import sympy
sage: from sympy import sympify
sage: var("a, b", domain="positive")
(a, b)
sage: dgamma(x, a, b)=x^(a-1)*(1-x)^(b-1)/beta(a, b)
sage: %time integrate(dgamma(x, a, b), x, 0, 1)
CPU times: user 5.34 ms, sys: 0 ns, total: 5.34 ms
Wall time: 5.54 ms
1
sage: %time sympy.integrate(*map(sympify, (dgamma(x, a, b).subs({a:a+1, b:b+1}), (x, 0, 1)))).simplify()._sage_().subs({a:a-1, b:b-1})
CPU times: user 2.08 s, sys: 10 µs, total: 2.08 s
Wall time: 2.08 s
1
sage: %time integrate(x*dgamma(x, a, b), x, 0, 1).simplify_factorial()
CPU times: user 30.9 ms, sys: 0 ns, total: 30.9 ms
Wall time: 31.1 ms
a/(a + b)
sage: %time sympy.integrate(*map(sympify, (x*dgamma(x, a, b).subs({a:a+1, b:b+1}), (x, 0, 1)))).simplify()._sage_().subs({a:a-1, b:b-1})
CPU times: user 2.72 s, sys: 3 µs, total: 2.72 s
Wall time: 2.72 s
a/(a + b)
sage: %time integrate((x-(a/(a+b)))^2*dgamma(x, a, b), x, 0, 1).simplify_full()
CPU times: user 398 ms, sys: 0 ns, total: 398 ms
Wall time: 312 ms
a*b/(a^3 + (3*a + 1)*b^2 + b^3 + a^2 + (3*a^2 + 2*a)*b)
sage: %time sympy.integrate(*map(sympify, ((x-(a/(a+b)))^2*dgamma(x, a, b).subs({a:a+1, b:b+1}), (x, 0, 1)))).simplify()._sage_().subs({a:a-1, b:b-1})
CPU times: user 30.5 s, sys: 4.03 ms, total: 30.5 s
Wall time: 30.5 s
((a - 1)^2*(b - 1) + (a - 1)*(b - 1)^2 + 2*(a - 1)^2 - 2*(a - 1)*(b - 1) + 2*(b - 1)^2)/((a + b + 1)*(a + b)*(a + b - 2)^2)

and sympy.integrate(*map(sympify, (dgamma(x, a, b), (x, 0, 1)))).simplify()._sage_() never returns. Res ipsa loquitur…

BTW : many Sympy integrations result in Sympy’s Piecewise expressions (correctly transcripted as Sage’s cases) involving logical expressions using Sympy’s symbolic logical functions/operators And, Or and Not, which have currently no equivalent in Sage (but see Trac#31911…)

Dima Pasechnik

unread,

Aug 27, 2021, 5:21:29 AM8/27/21

to sage-devel

How are these integrals above computed by Sage? Via Maxima, or in some
other way?

> and sympy.integrate(*map(sympify, (dgamma(x, a, b), (x, 0, 1)))).simplify()._sage_() never returns. Res ipsa loquitur…
>
> BTW : many Sympy integrations result in Sympy’s Piecewise expressions (correctly transcripted as Sage’s cases) involving logical expressions using Sympy’s symbolic logical functions/operators And, Or and Not, which have currently no equivalent in Sage (but see Trac#31911…)
>

> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/eb1cfbc2-3339-4031-8e24-fc0ceca307ben%40googlegroups.com.

William Stein

unread,

Aug 27, 2021, 1:45:20 PM8/27/21

to sage-devel, Richard Fateman

On Fri, Aug 27, 2021 at 2:21 AM Dima Pasechnik <dim...@gmail.com> wrote:
> How are these integrals above computed by Sage? Via Maxima, or in some
> other way?

When I implemented this, they were all computed in Maxima by default,
unless otherwise requested. Thus symbolic integration may be
orthogonal to the pynac vs symengine discussion. You can browse some
of the beautiful decades(!) old Maxima lisp code for integration
starting here:
https://github.com/andrejv/maxima/blob/master/src/defint.lisp
I'm cc'ing RJF in case he has some perspective to add.

Pynac has a lot of I think nontrivial efficient hooks back into Sage
for working with various data types, and doing things like equality
testing, fast evaluation of expression (fast_float, etc.), so it'll be
quite a lot of work to switch away from. I created pynac as a fork
of ginac only because there was a very talented student trying for a
year to do something similar more from scratch in Cython, and I got
impatient. It's too bad pynac is unmaintained now; I think the basic
idea wasn't so bad, and the performance was pretty good.

-- William

> > and sympy.integrate(*map(sympify, (dgamma(x, a, b), (x, 0, 1)))).simplify()._sage_() never returns. Res ipsa loquitur…
> >
> > BTW : many Sympy integrations result in Sympy’s Piecewise expressions (correctly transcripted as Sage’s cases) involving logical expressions using Sympy’s symbolic logical functions/operators And, Or and Not, which have currently no equivalent in Sage (but see Trac#31911…)
> >
> > --
> > 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/eb1cfbc2-3339-4031-8e24-fc0ceca307ben%40googlegroups.com.
>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0kcukS4RfSJ4oaxNM0yZHt3n5zFvdGk%2BuRr34M6YZ2SA%40mail.gmail.com.

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

Isuru Fernando

unread,

Aug 27, 2021, 1:56:39 PM8/27/21

to sage-devel

Hi,

A SymEngine maintainer here.

> Pynac has a lot of I think nontrivial efficient hooks back into Sage
for working with various data types, and doing things like equality
testing, fast evaluation of expression (fast_float, etc.),

With SymEngine, we do have fast evaluation of expressions with

several backends. One backend is LLVM, where we compile the function

using LLVM and generate a callable C function using that.

As part of my GSoC project 5 years ago, I added a lot of functionality

that was missing in SymEngine like MPFR types, MPC types, etc.

We also have sage interoperability where we can use an arbitrary

pynac/sympy function object and pass it around in C++ and evaluate when

necessary.

I think the biggest obstacle would be the quirks of different CASs

instead of the functionality needed.

Some design decisions would impact a lot of downstreams.

For eg: SymEngine doesn't expand 2*a - (b + a) automatically

unless specifically asked to, while SymPy does.

If there's specific functionality you are looking for, please let us know and

we'll probably be able to find someone to do it through GSoC.

Isuru Fernando

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GBhpFYXvbfqE8u-AU42cdDN8dQP320znbPHRkvivPXVRA%40mail.gmail.com.

Dima Pasechnik

unread,

Aug 27, 2021, 1:59:59 PM8/27/21

to sage-devel, Richard Fateman

On Fri, 27 Aug 2021, 20:45 William Stein, <wst...@gmail.com> wrote:

On Fri, Aug 27, 2021 at 2:21 AM Dima Pasechnik <dim...@gmail.com> wrote:
> How are these integrals above computed by Sage? Via Maxima, or in some
> other way?

When I implemented this, they were all computed in Maxima by default,
unless otherwise requested. Thus symbolic integration may be
orthogonal to the pynac vs symengine discussion. You can browse some
of the beautiful decades(!) old Maxima lisp code for integration
starting here:
https://github.com/andrejv/maxima/blob/master/src/defint.lisp
I'm cc'ing RJF in case he has some perspective to add.

Pynac has a lot of I think nontrivial efficient hooks back into Sage
for working with various data types, and doing things like equality
testing, fast evaluation of expression (fast_float, etc.), so it'll be
quite a lot of work to switch away from. I created pynac as a fork
of ginac only because there was a very talented student trying for a
year to do something similar more from scratch in Cython, and I got
impatient. It's too bad pynac is unmaintained now; I think the basic
idea wasn't so bad, and the performance was pretty good.

ginac, in fact, continues to be maintained, and even developed, after a long hiatus. But the pynac fork diverged from it long time ago, and naturally backporting new code/fixes from ginac appears to be very hard.

-- William

> > and sympy.integrate(*map(sympify, (dgamma(x, a, b), (x, 0, 1)))).simplify()._sage_() never returns. Res ipsa loquitur…
> >
> > BTW : many Sympy integrations result in Sympy’s Piecewise expressions (correctly transcripted as Sage’s cases) involving logical expressions using Sympy’s symbolic logical functions/operators And, Or and Not, which have currently no equivalent in Sage (but see Trac#31911…)
> >
> > --
> > 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/eb1cfbc2-3339-4031-8e24-fc0ceca307ben%40googlegroups.com.
>
> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0kcukS4RfSJ4oaxNM0yZHt3n5zFvdGk%2BuRr34M6YZ2SA%40mail.gmail.com.

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

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GBhpFYXvbfqE8u-AU42cdDN8dQP320znbPHRkvivPXVRA%40mail.gmail.com.

William Stein

unread,

Aug 27, 2021, 2:23:22 PM8/27/21

to sage-devel

Hello Isuru -- thanks for popping in to comment!

On Fri, Aug 27, 2021 at 10:56 AM Isuru Fernando <isu...@gmail.com> wrote:
>
> Hi,
>
> A SymEngine maintainer here.
>
> > Pynac has a lot of I think nontrivial efficient hooks back into Sage
> for working with various data types, and doing things like equality
> testing, fast evaluation of expression (fast_float, etc.),
>
> With SymEngine, we do have fast evaluation of expressions with
> several backends. One backend is LLVM, where we compile the function
> using LLVM and generate a callable C function using that.

Wow, that's very cool. Do you know how it compares to Sage's
fast_float and fast_callable "compilers" in terms of speed? Sage's
don't actually depend on having LLVM installed (they aren't compiling
to machine code), so I assume might be significantly slower, except
that the people (=Robert Bradshaw) who wrote them are very clever, so
you never know. It's probably also interesting to benchmark the
compile time itself.

> As part of my GSoC project 5 years ago, I added a lot of functionality
> that was missing in SymEngine like MPFR types, MPC types, etc.
> We also have sage interoperability where we can use an arbitrary
> pynac/sympy function object and pass it around in C++ and evaluate when
> necessary.

That's fantastic! It's really, really impressive how usable to the
broad community SymEngine can be.

Again, many thanks for your comments and SymEngine.

William

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voOtDmTgwQAN-t1f%3DUDBGpwWmeh75DXOfRvcjXBiMTZpbw%40mail.gmail.com.

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

Isuru Fernando

unread,

Aug 27, 2021, 3:14:18 PM8/27/21

to sage-devel

Hi,

On Fri, Aug 27, 2021 at 1:23 PM William Stein <wst...@gmail.com> wrote:

Hello Isuru -- thanks for popping in to comment!

On Fri, Aug 27, 2021 at 10:56 AM Isuru Fernando <isu...@gmail.com> wrote:
>
> Hi,
>
> A SymEngine maintainer here.
>
> > Pynac has a lot of I think nontrivial efficient hooks back into Sage
> for working with various data types, and doing things like equality
> testing, fast evaluation of expression (fast_float, etc.),
>
> With SymEngine, we do have fast evaluation of expressions with
> several backends. One backend is LLVM, where we compile the function
> using LLVM and generate a callable C function using that.

Wow, that's very cool. Do you know how it compares to Sage's
fast_float and fast_callable "compilers" in terms of speed? Sage's
don't actually depend on having LLVM installed (they aren't compiling
to machine code), so I assume might be significantly slower, except
that the people (=Robert Bradshaw) who wrote them are very clever, so
you never know. It's probably also interesting to benchmark the
compile time itself.

I've attached a small script that I put together just now. Note how we can

pass sage expressions in symbolic ring to symengine functions.

Timings are below. First one is sage and the second is symengine.

one element
625 loops, best of 3: 68 μs per loop
625 loops, best of 3: 12.9 μs per loop

create an output numpy array of 1000 elements
5 loops, best of 3: 175 ms per loop
625 loops, best of 3: 18.1 μs per loop

compile time
625 loops, best of 3: 478 μs per loop
125 loops, best of 3: 2.69 ms per loop

SymEngine LLVM backend has optimization levels (0, 1, 2, 3). 3 is the default.

By setting to optimization level 0, compile time is half with a performance penalty

of around 10%.

Isuru

sage-fc.py

Isuru Fernando

unread,

Aug 27, 2021, 3:28:23 PM8/27/21

to sage-devel

Here's the correct benchmark script, https://gist.github.com/isuruf/857e2236d2443ebd9085273b3e6ada3b

Isuru

William Stein

unread,

Aug 27, 2021, 4:40:41 PM8/27/21

to sage-devel

Isuru -- thanks; those benchmarks are fantastic! I'm really glad this
code exists (that you wrote).

Also, Richard Fateman wrote this about symbolic integration (but isn't
subscribed to sage-devel so I'm forwarding this from him):

"
If dgamma (x,a,b) is the value at x of the density function of a
Gamma(a,b) random variable with a,b>0 then ...
In Maxima, do load(distrib) to get you the function pdf_gamma(x,a,b).
The answer to your integration is given as

(gamma_incomplete(a,0)*b^a-gamma_incomplete(a,1/b)*b^a)/(gamma(a)*b^a)

is this what you want?

I suppose it is pointless to mention, again, the relative inefficiencies
inherent in the
idea that people should spend time on pynac or other "let's start from
scratch and re-do everything because python doesn't have so many
parentheses" projects.
Maxima is open source, gpl, github, is able to accommodate new
contributors, has an Algol-ish command language that can be used for
many tasks.
The underlying implementation language, lisp is good for some things,
and frankly, if you can't learn lisp in 2 weeks, you're probably not
such a hot programmer in python, either.

And with a bit of research you can learn how to call out from Lisp to
functions that were written in other languages. C. Python.

I'm no longer looking at Sage mail, so thanks for bringing this to my
attention.

I hope you are all staying safe and well.
Regards
Richard

> --
> 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voMGc5aayc%2BuAdjNa-orR%3D0cWjiZqqpFSwsDuk-NDKw%2Bxw%40mail.gmail.com.

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

Dima Pasechnik

unread,

Aug 27, 2021, 5:39:20 PM8/27/21

to sage-devel

On Fri, Aug 27, 2021 at 6:56 PM Isuru Fernando <isu...@gmail.com> wrote:
>
> Hi,
>
> A SymEngine maintainer here.
>
> > Pynac has a lot of I think nontrivial efficient hooks back into Sage
> for working with various data types, and doing things like equality
> testing, fast evaluation of expression (fast_float, etc.),
>
> With SymEngine, we do have fast evaluation of expressions with
> several backends. One backend is LLVM, where we compile the function
> using LLVM and generate a callable C function using that.
>
> As part of my GSoC project 5 years ago, I added a lot of functionality
> that was missing in SymEngine like MPFR types, MPC types, etc.
> We also have sage interoperability where we can use an arbitrary
> pynac/sympy function object and pass it around in C++ and evaluate when
> necessary.
>
> I think the biggest obstacle would be the quirks of different CASs
> instead of the functionality needed.
> Some design decisions would impact a lot of downstreams.
> For eg: SymEngine doesn't expand 2*a - (b + a) automatically
> unless specifically asked to, while SymPy does.
>
> If there's specific functionality you are looking for, please let us know and
> we'll probably be able to find someone to do it through GSoC.

a humble request is to get pkg-config supporting symengine.
Otherwise the task of determining version etc gets quite tricky.
See https://trac.sagemath.org/ticket/32421

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voOtDmTgwQAN-t1f%3DUDBGpwWmeh75DXOfRvcjXBiMTZpbw%40mail.gmail.com.

Matthias Koeppe

unread,

Aug 27, 2021, 9:38:04 PM8/27/21

to sage-devel

On Friday, August 27, 2021 at 11:23:22 AM UTC-7 wst...@gmail.com wrote:

Do you know how it compares to Sage's
fast_float and fast_callable "compilers" in terms of speed?

As a side note, https://trac.sagemath.org/ticket/32234 removes the fast_float implementation (the predecessor of fast_callable). Needs review.

kcrisman

unread,

Aug 28, 2021, 9:03:00 AM8/28/21

to sage-devel

> How are these integrals above computed by Sage? Via Maxima, or in some
> other way?

When I implemented this, they were all computed in Maxima by default,
unless otherwise requested. Thus symbolic integration may be
orthogonal to the pynac vs symengine discussion.

That is still the case (as Emanuel points out). We now have more possible engines for integrals, but Maxima is still the default.

Matthias Koeppe

unread,

Sep 26, 2021, 7:01:38 PM9/26/21

to sage-devel

This has just been merged in 9.5.beta2.

Reply all

Reply to author

Forward