eclib dependencies

[John Cremona]

Currently the eclib spkg has pari, ntl and flint as dependencies.  The first two are essential, but flint is currently hardly used and everything works without it.  (It is only used at all to compute the ref of a matrix (with entries int or long int) mod p and if flint is not available it just uses ntl instead.)

It strikes me that there would be a small advantage within Sage to build eclib without flint: it would only affect the function CremonaModularSymbols() (and related) which are of very limited interest; it would not affect any of the elliptic curve functionality in eclib.

If no-one has any reason to keep things as they are I will make a PR with the relevant changes to build/pkgs/eclib.

Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put in a check for an exact eclib version (currently 20230424), which seems unnecessarily restrictive.  I would welcome suggestions for how to either check for a certain version *or later*, and/or check that the library has certain functions which we know that Sage wil need.

Not until after 10.2 is realeased, certainly.

John

[Dima Pasechnik]

On 16 November 2023 09:23:15 GMT, John Cremona <john.c...@gmail.com> wrote:
>Currently the eclib spkg has pari, ntl and flint as dependencies. The
>first two are essential, but flint is currently hardly used and everything
>works without it. (It is only used at all to compute the ref of a matrix
>(with entries int or long int) mod p and if flint is not available it just
>uses ntl instead.)
>
>It strikes me that there would be a small advantage within Sage to build
>eclib without flint: it would only affect the function
>CremonaModularSymbols() (and related) which are of very limited interest;
>it would not affect any of the elliptic curve functionality in eclib.

I don't think this is really worthwhile: only if there were flint-less versions of eclib abound on systems where Sage is installed, these would be acceptable.
But it's not the case, and flint is here anyway, so there is very little point in doing this.

>
>If no-one has any reason to keep things as they are I will make a PR with
>the relevant changes to build/pkgs/eclib.
>
>Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
>in a check for an exact eclib version (currently 20230424), which seems
>unnecessarily restrictive. I would welcome suggestions for how to either
>check for a certain version *or later*, and/or check that the library has
>certain functions which we know that Sage wil need.

indeed, we can relax to "or later". I suppose you're not going to break upward compatibility of functions used in Sage.

Dima

[John Cremona]

On Thu, 16 Nov 2023 at 09:44, Dima Pasechnik <dim...@gmail.com> wrote:

On 16 November 2023 09:23:15 GMT, John Cremona <john.c...@gmail.com> wrote:
>Currently the eclib spkg has pari, ntl and flint as dependencies.  The
>first two are essential, but flint is currently hardly used and everything
>works without it.  (It is only used at all to compute the ref of a matrix
>(with entries int or long int) mod p and if flint is not available it just
>uses ntl instead.)
>
>It strikes me that there would be a small advantage within Sage to build
>eclib without flint: it would only affect the function
>CremonaModularSymbols() (and related) which are of very limited interest;
>it would not affect any of the elliptic curve functionality in eclib.

I don't think this is really worthwhile: only if there were flint-less versions of eclib abound on systems where Sage is installed,  these would be acceptable.
But it's not the case, and flint is here anyway, so there is very little point in doing this.

OK.   What triggered this for me was having installed flint3 on my machine, as Sage doesn't (yet) work with that, and it therefore prevents Sage using my own installed eclib. 

The install script does have a now-redundant few lines of code relating to flint configuration, which can be simplified now anyway.

>
>If no-one has any reason to keep things as they are I will make a PR with
>the relevant changes to build/pkgs/eclib.
>
>Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
>in a check for an exact eclib version (currently 20230424), which seems
>unnecessarily restrictive.  I would welcome suggestions for how to either
>check for a certain version *or later*, and/or check that the library has
>certain functions which we know that Sage wil need.

indeed, we can relax to "or later". I suppose you're not  going to break upward  compatibility of functions used in Sage.

Not intentionally....

 

Dima
>
>Not until after 10.2 is realeased, certainly.
>
>John
>

--
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/DA83A1E2-A69D-4C75-9793-F890F21E5403%40gmail.com.

[Michael Orlitzky]

On 2023-11-16 09:23:15, John Cremona wrote:
>
> If no-one has any reason to keep things as they are I will make a PR with
> the relevant changes to build/pkgs/eclib.

From a packaging standpoint, fewer dependencies is better. For
example, upgrading flint would become a tiny bit easier if we didn't
have to worry about it breaking eclib. And on Gentoo we have a lot of
people who simply prefer to turn every optional feature off. So I
think it's a nice idea.

> Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
> in a check for an exact eclib version (currently 20230424), which seems
> unnecessarily restrictive. I would welcome suggestions for how to either
> check for a certain version *or later*, and/or check that the library has
> certain functions which we know that Sage wil need.

The version restrictions are usually about the tests passing and not
about what works. For example if foo-1.0 prints "1 + 2" and foo-2.0
prints "2 + 1", that can cause the tests to fail until we update them
to accept both outputs. In the meantime we would probably reject
foo-2.0 even though it too gives correct answers. (This will get
better as fewer people rely on sage-the-distribution for exact
versions.)

Anyway, in this case, there are two autoconf tests that need to be
changed from equality to greater-than-or-equality:

PKG_CHECK_MODULES([ECLIB], [eclib = SAGE_ECLIB_VER],...
AX_COMPARE_VERSION([$mwrank_version], [eq], [SAGE_ECLIB_VER],..

[John Cremona]

On Thu, 16 Nov 2023 at 12:15, Michael Orlitzky <mic...@orlitzky.com> wrote:

On 2023-11-16 09:23:15, John Cremona wrote:
>
> If no-one has any reason to keep things as they are I will make a PR with
> the relevant changes to build/pkgs/eclib.

From a packaging standpoint, fewer dependencies is better. For
example, upgrading flint would become a tiny bit easier if we didn't
have to worry about it breaking eclib. And on Gentoo we have a lot of
people who simply prefer to turn every optional feature off. So I
think it's a nice idea.

Thanks Michael.  AFter more thought I think I will leave flint as a dependency, as there are quite a few features of flint (especially in flint3) which could be used in eclib, and which improve it, if I find the time.  It's just that right now, if you omit "--with-flint" on eclib's configure then you still get a 100% wworking eclib.

 

> Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
> in a check for an exact eclib version (currently 20230424), which seems
> unnecessarily restrictive.  I would welcome suggestions for how to either
> check for a certain version *or later*, and/or check that the library has
> certain functions which we know that Sage wil need.

The version restrictions are usually about the tests passing and not
about what works. For example if foo-1.0 prints "1 + 2" and foo-2.0
prints "2 + 1", that can cause the tests to fail until we update them
to accept both outputs. In the meantime we would probably reject
foo-2.0 even though it too gives correct answers. (This will get
better as fewer people rely on sage-the-distribution for exact
versions.)

Anyway, in this case, there are two autoconf tests that need to be
changed from equality to greater-than-or-equality:

  PKG_CHECK_MODULES([ECLIB], [eclib = SAGE_ECLIB_VER],...
  AX_COMPARE_VERSION([$mwrank_version], [eq], [SAGE_ECLIB_VER],..

I'll try that out when I next upgrade eclib in Sage.  My latest version detects whether it has Flint version 2 or 3 and does slightly different things in those cases, both working correctly, but there is nothing to make it worth a new release of eclib.  I'll probably do that once the work of getting flint3 into Sage is finished.

John

 

--
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/ZVYH-QiUAXLbkkx-%40stitch.