Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[kcrisman]

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ea4a3905-27d9-44ae-9bf9-228879eae67an%40googlegroups.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Matthias Koeppe]

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.



>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/37743509-c65a-42a1-9ecf-ee53be05c49fn%40googlegroups.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Dima Pasechnik]

On Fri, Aug 27, 2021 at 6:56 PM Isuru Fernando  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

>
> Isuru Fernando
>
> On Fri, Aug 27, 2021 at 12:45 PM William Stein  wrote:
>>
>> On Fri, Aug 27, 2021 at 2:21 AM Dima Pasechnik  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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CACLE5GBhpFYXvbfqE8u-AU42cdDN8dQP320znbPHRkvivPXVRA%40mail.gmail.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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CA%2B01voOtDmTgwQAN-t1f%3DUDBGpwWmeh75DXOfRvcjXBiMTZpbw%40mail.gmail.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 

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[William Stein]

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
"

On Fri, Aug 27, 2021 at 12:28 PM Isuru Fernando  wrote:
>
> Here's the correct benchmark script, 
> https://gist.github.com/isuruf/857e2236d2443ebd9085273b3e6ada3b
>
> Isuru
>
> On Fri, Aug 27, 2021 at 2:14 PM Isuru Fernando  wrote:
>>
>> Hi,
>>
>> On Fri, Aug 27, 2021 at 1:23 PM William Stein  wrote:
>>>
>>> Hello Isuru -- thanks for popping in to comment!
>>>
>>> On Fri, Aug 27, 2021 at 10:56 AM Isuru Fernando  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
>
> --
> 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+unsubscr...@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)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CACLE5GC_rX5jD2Z33b2Dr-em%2BLxRUUeM8NmUwWyV5%3Dj4zmbioQ%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Isuru Fernando]

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

Isuru

On Fri, Aug 27, 2021 at 2:14 PM Isuru Fernando  wrote:

> Hi,
>
> On Fri, Aug 27, 2021 at 1:23 PM William Stein  wrote:
>
>> Hello Isuru -- thanks for popping in to comment!
>>
>> On Fri, Aug 27, 2021 at 10:56 AM Isuru Fernando  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
>

-- 
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+unsubscr...@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.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Isuru Fernando]

Hi,

On Fri, Aug 27, 2021 at 1:23 PM William Stein  wrote:

> Hello Isuru -- thanks for popping in to comment!
>
> On Fri, Aug 27, 2021 at 10:56 AM Isuru Fernando  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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CA%2B01voPC7KbXXzxhrjztPynBeNs0fNyUj%2BCJkfYY5LX-4p95hQ%40mail.gmail.com.
wilk = prod((x-i) for i in [1 .. 20]);
fc_wilk = fast_callable(wilk, vars=[x])
import numpy as np
N = 1000
arr = np.random.rand(N)
def run():
arr2 = np.empty_like(arr)
for i in range(N):
arr2[i] = fc_wilk(arr[i])
return arr2

import symengine
fc_wilk_se = symengine.Lambdify([x], [wilk_se], backend="llvm")
def run_se():
return fc_wilk_se(arr).reshape(N)

assert np.allclose(run(), run_se())

print('one element')
timeit('fc_wilk(0.0)')
timeit('fc_wilk_se(0.0)')

print('create an output numpy array of 1000 elements')
timeit('run()')
timeit('run_se()')

print('compile time')
timeit('fc_wilk = fast_callable(wilk, vars=[x])')
timeit('fc_wilk_se = symengine.Lambdify([x], [wilk_se], backend="llvm")')

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[William Stein]

Hello Isuru -- thanks for popping in to comment!

On Fri, Aug 27, 2021 at 10:56 AM Isuru Fernando  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

> 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
>
> On Fri, Aug 27, 2021 at 12:45 PM William Stein  wrote:
>>
>> On Fri, Aug 27, 2021 at 2:21 AM Dima Pasechnik  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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CACLE5GBhpFYXvbfqE8u-AU42cdDN8dQP320znbPHRkvivPXVRA%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop 

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Dima Pasechnik]

On Fri, 27 Aug 2021, 20:45 William Stein,  wrote:

> On Fri, Aug 27, 2021 at 2:21 AM Dima Pasechnik  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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/CACLE5GBhpFYXvbfqE8u-AU42cdDN8dQP320znbPHRkvivPXVRA%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq3epDa2EDNE9xviZ%2BRuiUXfh56YfcEFOtCB9D0EjH-0pQ%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Isuru Fernando]

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

On Fri, Aug 27, 2021 at 12:45 PM William Stein  wrote:

> On Fri, Aug 27, 2021 at 2:21 AM Dima Pasechnik  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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/CACLE5GBhpFYXvbfqE8u-AU42cdDN8dQP320znbPHRkvivPXVRA%40mail.gmail.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CA%2B01voOtDmTgwQAN-t1f%3DUDBGpwWmeh75DXOfRvcjXBiMTZpbw%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[William Stein]

On Fri, Aug 27, 2021 at 2:21 AM Dima Pasechnik  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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CACLE5GBhpFYXvbfqE8u-AU42cdDN8dQP320znbPHRkvivPXVRA%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Dima Pasechnik]

On Fri, Aug 27, 2021 at 9:42 AM Emmanuel Charpentier
 wrote:
>
> 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)
>

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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0kcukS4RfSJ4oaxNM0yZHt3n5zFvdGk%2BuRr34M6YZ2SA%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Emmanuel Charpentier]

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 
…)
​

-- 
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+unsubscr...@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.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[kcrisman]

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/009310e6-580c-4a17-b255-43585e1c1177n%40googlegroups.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Dima Pasechnik]

On Wed, Aug 25, 2021 at 6:17 PM Matthias Koeppe
 wrote:
>
> 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  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.

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+unsubscr...@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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0PMf268P2tXkavjjuAibG-DXSkbY-rTJh%2BaTxh351UjA%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Matthias Koeppe]

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

 

-- 
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+unsubscr...@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.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Matthias Koeppe]

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.

 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/95213155-242e-4515-ad2e-7eb38716600an%40googlegroups.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[William Stein]

On Wed, Aug 25, 2021 at 9:58 AM Dima Pasechnik  wrote:
>
>
>
> On Wed, 25 Aug 2021, 19:37 Nils Bruin,  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+unsubscr...@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+unsubscr...@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)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CACLE5GDYXaLpc84X6%3DAt_rOwsDxDrSTw8QbfzWCk2HiievEDyQ%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Dima Pasechnik]

On Wed, 25 Aug 2021, 19:37 Nils Bruin,  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+unsubscr...@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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0N7FBETRevL9sWo05dmosH4Nq%3DxJfmiWXz9Fj7Nki32g%40mail.gmail.com.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Nils Bruin]

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)

-- 
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+unsubscr...@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.

Re: [sage-devel] Refactoring/modularization work on the Symbolic Ring

[Dima Pasechnik]

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, 
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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq2HKu3mtwRQnN6SNb%3DZRWwo2jmGXH9yPe_V6TxiZQwrWw%40mail.gmail.com.