Poll: make giacpy_sage a standard package

[Samuel Lelievre]

Please vote for making giacpy_sage a standard package. See

- Sage Trac ticket: 28918
  Make giacpy_sage a standard package
  https://trac.sagemath.org/ticket/28918

+1 from me

[Simon King]

Hi Samuel,

On 2020-02-03, Samuel Lelievre <samuel....@gmail.com> wrote:
> Please vote for making giacpy_sage a standard package.

Could you elaborate what giacpy is about, i.e., what functionality would
it add to SageMath resp. improve in SageMath? That question isn't
addressed on the ticket yet.

Best regards,
Simon

[Markus Wageringel]

Giacpy_sage provides C-bindings for Giac which is already a standard package. So making Giacpy_sage a standard package as well would allow to replace pexpect calls to Giac by C-calls, which is the overarching goal of #16688. Giac is currently used as fallback for symbolic integration where this change would be useful (see also #28913). In addition, Gröbner basis computations already use Giacpy_sage as alternative backend, so this would become more accessible if the package type is changed to standard.

Therefore,

+1 from me.

[Dima Pasechnik]

+1 from me too.

> --
> 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/efcae77d-6fc3-44eb-a65f-5aa14297ea4b%40googlegroups.com.

[Simon King]

On 2020-02-04, Markus Wageringel <markus.w...@gmail.com> wrote:
> Giacpy_sage provides C-bindings for Giac which is already a standard
> package. So making Giacpy_sage a standard package as well would allow to
> replace pexpect calls to Giac by C-calls, which is the overarching goal of
> #16688. Giac is currently used as fallback for symbolic integration where
> this change would be useful (see also #28913). In addition, Gröbner basis
> computations already use Giacpy_sage as alternative backend, so this would
> become more accessible if the package type is changed to standard.

As Giac is standard, it totally makes sense to me to make its C-bindings
standard, too.

So, +1 from me.

Best regards,
Simon

[mmarco]

+1

Also, I suggest that we consider the possibility of using giac as the default backend for symbolic integration. 

[Dima Pasechnik]

On Tue, Feb 4, 2020 at 9:46 AM mmarco <mma...@unizar.es> wrote:
>
> +1
>
> Also, I suggest that we consider the possibility of using giac as the default backend for symbolic integration.

I guess we need to develop a setup to switch from one default
integration backend to another.

>
>
> El lunes, 3 de febrero de 2020, 23:52:44 (UTC+1), Samuel Lelievre escribió:
>>
>> Please vote for making giacpy_sage a standard package. See
>>
>> - Sage Trac ticket: 28918
>> Make giacpy_sage a standard package
>> https://trac.sagemath.org/ticket/28918
>>
>> +1 from me
>

> --
> 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/911a8617-510c-4854-8c33-3d6bccdf401b%40googlegroups.com.

[mmarco]

You mean having a function (or global variable) to set which will be the default backend?

I find that having a workflow consisting on expressions like:

integrate(foo,x,algorithm='giac')

is not specially comfortable, but even then, I prefear it to something like:

set_integration_backend('giac')

integrate(foo,x)

since the latter is prone to confusion, when you forget that a while ago you did set the default and expect something different.

So I would really prefear to just have one fixed default, and then use explicit flags to use different ones in each call.

Explicit is better than implicit.

[Nathan Dunfield]

On Monday, February 3, 2020 at 4:52:44 PM UTC-6, Samuel Lelievre wrote:

Please vote for making giacpy_sage a standard package.

+1

The "giacpy_sage" optional package is one I always install when I build Sage and it has been robust in my experience.  As others have said, given that giac itself is included, allowing Python direct access to giac at the C level rather than going through pexpect is clearly an improvement.

Nathan

[Isuru Fernando]

How is making this standard affect the plans for making sage pip installable?

This would be the first package in a while that depends on sage-the-library that is also standard in sage-the-distribution.

Isuru

[Vincent Delecroix]

That is a good point which emphasizes the fact that there are two
libraries

- giacpy (https://pypi.org/project/giacpy/)
- giacpy-sage

Why is that the case that Sage is using a homemade version of the
giacpy package? The SPKG.txt is very elusive about that. To my mind,
it would be much better to enditify whether having these two packages
is really needed in the first place. We did create cypari2 and pplpy
out of SageMath... And these are pure Python libraries. I don't see
why the giac situation would be much more complicated.

Until the above is answered I would go for a -1 vote.

Vincent

[Han Frederic]

First, thank you for this discussion.

About the sage pip install project. The problem is that I don't know at all what will be available.
But if you are done with sage's  pyx files in src/sage/libs then it should be similar with giacpy_sage.

It is indeed rare for an spkg to be linked to the sage library and giacpy_sage is
more similar to the cython files in src/sage/libs than to an external package.

The original ticket https://trac.sagemath.org/ticket/15226 six years ago about giacpy_sage
was a sage patch. It just ended with no answer but with the current giacpy_sage
it is still easy to put 4 files of giacpy_sage in sage's source tree src/sage/libs, adjust
src/module_list.py and let sage's setup.py build giacpy_sage. Then you don't need an external package at all.

This is related to Vincent's question. There are many cython files in sage/libs related
to cypari2. Currently giacpy_sage have none. We need one of the following
(to not lose any features) either giacpy_sage is an external package linked to the sage library
or a part of giacpy_sage (or all of it, because it is just few files) is inside sage. Any of these
solutions is fine for me. But being in between is more work and my skills and time are limited.


The python package have a different name: giacpy. This was the only request I had during the previous vote where all the focus turned on giac and where giacpy_sage was forgotten.
(cf https://groups.google.com/d/topic/sage-devel/HI0uZra5_iI/discussion)
I don't see any conflict in having both. Sage could load the python package but it is just less interesting than loading giacpy_sage.

A minimal python is able to use the giacpy package obtain a full computer algebra system. I don't want to break this with the in between solution (1 python package and files in sage).
It is important for me that a window user with no development tools looks to be  able
to do with a minimal python installation:

python -m pip install giacpy

and have it. It was very difficult for me to provides these binaries, and I don't want to break this.

giac and sage are both computer algebra systems, so there have have many interactions that are meaningless in a standalone python.


Another remark:  giac is a standard package and giacpy_sage test it more. For instance this ticket
https://trac.sagemath.org/ticket/27306
was a giac bug in a new version of giac. It was not related to giacpy_sage and I guess that it would have been detected during the upgrade of the giac package if giacpy_sage was standard, while it was detected after.

Best

Frederic

[François Bissey]

I’ll claim responsibility for the name change request!

More seriously, after reading this and thinking a little bit I would
really prefer if it was merged in sage/libs. The alternative means that
we have a true circular dependency sage <-> giacpy_sage and things
will start to get wild as soon as you want to build the docs.
sage the distro probably can shrug it off but us in linux distros will
go seriously banana about it.

François

> --
> 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/f8f821da-50d7-4319-9477-57ff8a55fcfc%40googlegroups.com.

[Vincent Delecroix]

The cypari2 related files in sage/libs/pari/ are rather minimal

$ wc -l sage/libs/pari/*
4 pari/all.py
13 pari/convert_flint.pxd
158 pari/convert_flint.pyx
13 pari/convert_gmp.pxd
209 pari/convert_gmp.pyx
3 pari/convert_sage.pxd
296 pari/convert_sage.pyx
217 pari/__init__.py
3 pari/misc.pxd
25 pari/misc.pyx
1798 pari/tests.py
2739 total

As you can see, 65% of it are leftover tests from the old time
when we had the Cython interface to PARI inside sage. The remaining
941 lines of code are interfaces (with gmp, flint and Sage).

[Vincent Delecroix]

I am in favor of moving giacpy_sage inside sage/libs. But it does
not really fits Sage code standard. It is mostly undocumented
and untested.

This does not look so bad as most of the code is
"""
cdef class Pygen:

def functionXYZ(self, *args):
return GiacMethods['functionXYZ'](self, *args)
"""

Such thing could easily be automized together with the documentation
(as long as it is available from giac in a standardized format).

Best
Vincent

[Simon King]

Hi Frederic,

On 2020-02-07, Han Frederic <freder...@imj-prg.fr> wrote:
> It is indeed rare for an spkg to be linked to the sage library...

... but it is not the only one. p_group_cohomology is similar in that
regard.

> We need one of the following
> (to not lose any features) either giacpy_sage is an external package linked
> to the sage library
> or a part of giacpy_sage (or all of it, because it is just few files) is
> inside sage.

If giacpy_sage became standard, it indeed sounded reasonable to me to put
all Cython files into the SageMath library and only keep any non-cython
bits into a (standard) spkg.

Best regards,
Simon

[François Bissey]

> On 8/02/2020, at 1:20 AM, Simon King <simon...@uni-jena.de> wrote:
>
> On 2020-02-07, Han Frederic <freder...@imj-prg.fr> wrote:
>> It is indeed rare for an spkg to be linked to the sage library...
>
> ... but it is not the only one. p_group_cohomology is similar in that
> regard.

Being a downstream package that way is absolutely fine. It’s once you make
them standard that problems may happen.

François

[Vincent Delecroix]

Le 07/02/2020 à 13:20, Simon King a écrit :
> If giacpy_sage became standard, it indeed sounded reasonable to me to put
> all Cython files into the SageMath library and only keep any non-cython
> bits into a (standard) spkg.

Such pure Python package would be empty

$ ls giacpy-sage-0.6.7-62b706740aa8703900c8d35e95e097ed2dd692bb/
exemple.sage
giacpy_sage.pxd
giacpy_sage.pyx
INSTALL.txt
keywords.pxi
misc.h
README.txt
sage-release.txt
setup.py

[Vincent Delecroix]

Concrete proposal for moving giacpy_sage into sage source
code at

https://trac.sagemath.org/ticket/29171

Still some work to be done concerning indentation,
documentation formatting, code factorization, etc.

Vincent

[Matthias Koeppe]

+1 on Vincent's proposal.

>>> send an email to sage-...@googlegroups.com.