Added Conway polynomials to the database ... #5

S17A05 · 2024-04-30T09:34:28Z

... for primes in the range $[65537, 109987]$ and degrees $(1,2,3)$ to fix an inconsistency issue in Sage, which currently disrupts the generation of certain finite fields, e.g. GF((65537, 12)) (see sagemath/sage#35357).

Note: I believe that only the polynomials of degree $2$ are needed to fix the bug, since the degree $1$ polynomials seem to be computed correctly by the code for pseudo-Conway polynomials in Sage and the degree $3$ polynomials are not related to the issue. I have added all polynomials up to degree $4$ for consistency with previous entries, but if it is preferable to keep the database small, I could also modify the update to only include the polynomials of degree $2$ and $4.$

The polynomials were computed via calls to GAP using the following code:

from sage.rings.polynomial.polynomial_ring_constructor import PolynomialRing
primes = [x for x in range(65537, 110000) if is_prime(x)]
for p in primes:
    # only need degrees 2,4; added 1,3 for completeness, but can be removed
    for i in range(1,5):
        gap_poly = gap.ConwayPolynomial(p, i)
        gap_coeff = list(gap_poly.CoefficientsOfUnivariatePolynomial())
        print(str([p, i, [GF(p)(x) for x in gap_coeff]]).replace(" ","") + ",")

Since the diff is quite large, here is a consistency check: There are $3911$ primes in the given range, and $3 \cdot 3911 = 11733$ lines were added to the file.

Please let me know

if this is not the correct way to contribute/request this update,
which other files I need to modify for the update, and
if you prefer a different solution to the issue (as far as I can tell, this inconsistency will always come up when computing certain higher degree Coway polynomials with use of the database).

... for primes in the range [65537, 109987] and degree (1,2,3) to fix an inconsistency issue in Sage, which currently disrupts the generation of certain finite fields, such as GF((65537, 12)). The polynomials were computed using GAP. Consistency check: There are 3911 primes in the given range, and 3*3911 = 11733 = 47092 - 35359 added lines in the file

S17A05 · 2024-04-30T14:43:09Z

As I'm not sure who manages the GitHub workflow in this repository, here is a ping to the people listed as contributors: @orlitzky @tornaria @mkoeppe

orlitzky · 2024-04-30T15:29:48Z

Hi, thanks for the ping. The file CPimport.txt is simply a copy of the database maintained by Frank Luebeck: http://www.math.rwth-aachen.de/~Frank.Luebeck/data/ConwayPol/index.html

He's a GAP contributor, so the first think you might try is contacting him to include these in the database?

We'd have to make a new release of conway-polynomials afterwards, but that's no big deal.

S17A05 · 2024-04-30T16:18:16Z

Hi, thanks for the ping. The file CPimport.txt is simply a copy of the database maintained by Frank Luebeck: http://www.math.rwth-aachen.de/~Frank.Luebeck/data/ConwayPol/index.html

He's a GAP contributor, so the first think you might try is contacting him to include these in the database?

We'd have to make a new release of conway-polynomials afterwards, but that's no big deal.

I wrote him a mail with the updated CPimport.txt - I'll keep you posted on the progress.

orlitzky · 2024-04-30T16:30:10Z

Sounds good. If he doesn't want to add them for some reason I'm sure we can work out some other way to include them in this package. Probably just in a separate file -- the reason we include our own "pristine" copy of CPimport.txt is to be able to diff it against the upstream copy.

S17A05 · 2024-05-06T15:38:51Z

Frank Lübeck has checked the new entries with GAP and has updated the database on his website. I guess you can merge this PR or close it and take the file from the website, as you prefer. Also there is a consistency check of the database length in sage.databases.conway that needs to be updated - should I open a pull request in sagemath/sage for it or will this be part of the database update?

orlitzky · 2024-05-06T15:58:29Z

If you don't mind, could you open a PR for the length check in sage, but allow it to support both the old and new versions? That way no coordination is needed between the conway-polynomials release and sage.

orlitzky · 2024-05-07T20:34:17Z

I just pushed v0.10 with the new database, it should appear on pypi in a minute. I grabbed the new database from Frank's site but gave you credit in the commit message and NEWS file. Thanks for working on this.

tornaria · 2024-05-08T19:57:40Z

@orlitzky

With sagemath 10.4.beta5 I get:

sage -t --warn-long 63.7 --random-seed=60083050922623589883729284203106801396 /usr/lib/python3.12/site-packages/sage/databases/conway.py  # 1 doctest failed
sage -t --warn-long 63.7 --random-seed=60083050922623589883729284203106801396 /usr/lib/python3.12/site-packages/sage/schemes/elliptic_curves/ell_point.py  # 7 doctests failed

orlitzky · 2024-05-08T20:55:51Z

@orlitzky

With sagemath 10.4.beta5 I get:

sage -t --warn-long 63.7 --random-seed=60083050922623589883729284203106801396 /usr/lib/python3.12/site-packages/sage/databases/conway.py  # 1 doctest failed
sage -t --warn-long 63.7 --random-seed=60083050922623589883729284203106801396 /usr/lib/python3.12/site-packages/sage/schemes/elliptic_curves/ell_point.py  # 7 doctests failed

The database test is fixed by sagemath/sage#37949. Not sure about the others yet.

S17A05 · 2024-05-08T21:04:22Z

@orlitzky
With sagemath 10.4.beta5 I get:

sage -t --warn-long 63.7 --random-seed=60083050922623589883729284203106801396 /usr/lib/python3.12/site-packages/sage/databases/conway.py  # 1 doctest failed
sage -t --warn-long 63.7 --random-seed=60083050922623589883729284203106801396 /usr/lib/python3.12/site-packages/sage/schemes/elliptic_curves/ell_point.py  # 7 doctests failed

The database test is fixed by sagemath/sage#37949. Not sure about the others yet.

The others are probably related to the exact results given in tests involving GF(65537^2), as the database polynomial being used for the generation after the update likely results in a different output; not sure if that covers all failures, though.

Update: The hardcoded point Q in the Sage implementation test of .weil_pairing() is not a point on the curve anymore due to the minimal polynomial change.

S17A05 · 2024-05-08T21:18:06Z

Same issue for the Tate pairing test; these can both be fixed by instead choosing

sage: P = E(1671*z2 + 14716, 20251*z2 + 47780)
sage: Q = E(63794*z2 + 31906, 16175*z2 + 1067)

which results in

sage: P.weil_pairing(Q, 7282, algorithm='sage')
38064*z2 + 59346

and

sage: P.tate_pairing(Q, 7282, 2)
43061*z2 + 33961

in the respective tests.

Update: The above updates to the tests of .weil_pairing and .tate_pairing indeed fix all doctest failures. I can open a PR with these fixes, but would that force some coordination?

Update 2: Ideas to avoid coordination:

For the test of .weil_pairing, one might instead pick random linear combinations of the 7282-torsion basis and check that the arguments algorithm="sage" and algorithm="pari" yield the same result.
The test of .tate_pairing is basically there to check if the switch to PARI still gives the same result as the earlier Sage implementation, which does not appear in the file anymore. Checking with SageMathCell (where the old Sage implementation is still used), this is consistent for the above example - but it might be worth considering to just remove this explicit test example.

orlitzky · 2024-05-08T22:08:33Z

Update 2: Ideas to avoid coordination:

Neither of those sound too crazy to me. I think you should do what you think is right and ping @JohnCremona, @GiacomoPope, @yyyyx4, or someone else who has worked on that file recently for a rubber stamp. I wound up maintaining conway-polynomials because I like to create python boilerplate, not because I know anything about elliptic curves.

tornaria · 2024-05-08T22:53:38Z

Anything that makes the tests independent of the FF representation is good. But since the tests are also examples, there's some advantage on showing explicit elements.

Maybe just hardcode the description of GF(65537^2), e.g.:

--- a/src/sage/schemes/elliptic_curves/ell_point.py
+++ b/src/sage/schemes/elliptic_curves/ell_point.py
@@ -1836,9 +1836,10 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the original Sage implementation still works::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
+            sage: F = GF(65537^2, modulus=[3, 46810, 1], name='z2')
+            sage: F.inject_variables()
             Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
             sage: Q = E(-93, 40438*z2 + 31573)
             sage: P.weil_pairing(Q, 7282, algorithm='sage')
@@ -2052,9 +2053,10 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the PARI output matches the original Sage implementation::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
+            sage: F = GF(65537^2, modulus=[3, 46810, 1], name='z2')
+            sage: F.inject_variables()
             Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
             sage: Q = E(-93, 40438*z2 + 31573)
             sage: P.tate_pairing(Q, 7282, 2)

This is using the old definition, maybe it's preferable to use GF(65537^2, modulus=[3,-1,1], name='a') which is the new one. With the change of variables z2 = 30028*a + 27118 I get this:

--- a/src/sage/schemes/elliptic_curves/ell_point.py
+++ b/src/sage/schemes/elliptic_curves/ell_point.py
@@ -1836,13 +1836,14 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the original Sage implementation still works::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
-            Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: F = GF(65537^2, modulus=[3, -1, 1], name='a')
+            sage: F.inject_variables()
+            Defining a
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
-            sage: Q = E(-93, 40438*z2 + 31573)
+            sage: Q = E(-93, 2728*a + 64173)
             sage: P.weil_pairing(Q, 7282, algorithm='sage')
-            19937*z2 + 65384
+            53278*a + 36700
 
         Passing an unknown ``algorithm=`` argument should fail::
 
@@ -2052,13 +2053,14 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the PARI output matches the original Sage implementation::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
-            Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: F = GF(65537^2, modulus=[3, -1, 1], name='a')
+            sage: F.inject_variables()
+            Defining a
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
-            sage: Q = E(-93, 40438*z2 + 31573)
+            sage: Q = E(-93, 2728*a + 64173)
             sage: P.tate_pairing(Q, 7282, 2)
-            34585*z2 + 4063
+            19078*a + 45623
 
         The point ``P (self)`` must have ``n`` torsion::

S17A05 · 2024-05-08T23:11:01Z

Anything that makes the tests independent of the FF representation is good. But since the tests are also examples, there's some advantage on showing explicit elements.

Maybe just hardcode the description of GF(65537^2), e.g.:

--- a/src/sage/schemes/elliptic_curves/ell_point.py
+++ b/src/sage/schemes/elliptic_curves/ell_point.py
@@ -1836,9 +1836,10 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the original Sage implementation still works::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
+            sage: F = GF(65537^2, modulus=[3, 46810, 1], name='z2')
+            sage: F.inject_variables()
             Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
             sage: Q = E(-93, 40438*z2 + 31573)
             sage: P.weil_pairing(Q, 7282, algorithm='sage')
@@ -2052,9 +2053,10 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the PARI output matches the original Sage implementation::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
+            sage: F = GF(65537^2, modulus=[3, 46810, 1], name='z2')
+            sage: F.inject_variables()
             Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
             sage: Q = E(-93, 40438*z2 + 31573)
             sage: P.tate_pairing(Q, 7282, 2)

This is using the old definition, maybe it's preferable to use GF(65537^2, modulus=[3,-1,1], name='a') which is the new one. With the change of variables z2 = 30028*a + 27118 I get this:

--- a/src/sage/schemes/elliptic_curves/ell_point.py
+++ b/src/sage/schemes/elliptic_curves/ell_point.py
@@ -1836,13 +1836,14 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the original Sage implementation still works::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
-            Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: F = GF(65537^2, modulus=[3, -1, 1], name='a')
+            sage: F.inject_variables()
+            Defining a
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
-            sage: Q = E(-93, 40438*z2 + 31573)
+            sage: Q = E(-93, 2728*a + 64173)
             sage: P.weil_pairing(Q, 7282, algorithm='sage')
-            19937*z2 + 65384
+            53278*a + 36700
 
         Passing an unknown ``algorithm=`` argument should fail::
 
@@ -2052,13 +2053,14 @@ class EllipticCurvePoint_field(SchemeMorphism_point_abelian_variety_field):
         Check that the PARI output matches the original Sage implementation::
 
             sage: # needs sage.rings.finite_rings
-            sage: GF(65537^2).inject_variables()
-            Defining z2
-            sage: E = EllipticCurve(GF(65537^2), [0,1])
+            sage: F = GF(65537^2, modulus=[3, -1, 1], name='a')
+            sage: F.inject_variables()
+            Defining a
+            sage: E = EllipticCurve(F, [0,1])
             sage: P = E(22, 28891)
-            sage: Q = E(-93, 40438*z2 + 31573)
+            sage: Q = E(-93, 2728*a + 64173)
             sage: P.tate_pairing(Q, 7282, 2)
-            34585*z2 + 4063
+            19078*a + 45623
 
         The point ``P (self)`` must have ``n`` torsion::

Thanks for the suggestion! I'll move the removed tests to the examples with fixed moduli instead, but for .weil_pairing I will also keep the more generic check that both algorithms return the same result.

JohnCremona · 2024-05-09T09:29:42Z

Ping received. I am happy with the solutions proposed

…eparation for database update Motivated by sagemath#35357, the database of Conway polynomials will be enlarged to ensure compatibility in the generation of finite fields (see sagemath/conway-polynomials#5 for details). To prepare for this update, we slightly relax the length check in `sage.databases.conway` to be compatible with both the old and the new version of the database. URL: sagemath#37949 Reported by: Sebastian A. Spindler Reviewer(s): Michael Orlitzky, Sebastian A. Spindler

@yyyyx4

…or Conway database update As part of the Conway polynomials database update, two tests in `schemes.elliptic_curves.ell_point` caused issues due to their dependency on the precise implementation of the finite field `GF(65537^2)`: - The first test (of `.weil_pairing`) checks whether the Sage implementation still works for an example of fixed `7282`-torsion points - The second test (of `.tate_pairing`) checks whether the new implementation, which uses PARI up to reduction of the pairing, coincides with the old Sage implementation (still used e.g. in SageMathCell, but not available in the current code anymore) To help with the database update, we adapt these tests to not be dependent on the exact minimal polynomial used for finite field generation: - We turn both tests into examples (with fixed moduli) for their respective methods - We modify the test of `.weil_pairing` to check for two randomly chosen `7282`-torsion points whether `algorithm="sage"` and `algorithm="pari"` yield the same result Please let me know if you think other polynomial-independent tests are better suited as replacements. See sagemath/conway-polynomials#5 (especially [comment 10](https://github.com/sagemath/conway- polynomials/pull/5#issuecomment-2101462886) and Update 2 in [comment 11](https://github.com/sagemath/conway- polynomials/pull/5#issuecomment-2101498241)) for more details. CC: @yyyyx4 @GiacomoPope @JohnCremona URL: sagemath#37967 Reported by: Sebastian A. Spindler Reviewer(s):

…eparation for database update Motivated by sagemath#35357, the database of Conway polynomials will be enlarged to ensure compatibility in the generation of finite fields (see sagemath/conway-polynomials#5 for details). To prepare for this update, we slightly relax the length check in `sage.databases.conway` to be compatible with both the old and the new version of the database. URL: sagemath#37949 Reported by: Sebastian A. Spindler Reviewer(s): Michael Orlitzky, Sebastian A. Spindler

@yyyyx4

…or Conway database update As part of the Conway polynomials database update, two tests in `schemes.elliptic_curves.ell_point` caused issues due to their dependency on the precise implementation of the finite field `GF(65537^2)`: - The first test (of `.weil_pairing`) checks whether the Sage implementation still works for an example of fixed `7282`-torsion points - The second test (of `.tate_pairing`) checks whether the new implementation, which uses PARI up to reduction of the pairing, coincides with the old Sage implementation (still used e.g. in SageMathCell, but not available in the current code anymore) To help with the database update, we adapt these tests to not be dependent on the exact minimal polynomial used for finite field generation: - We turn both tests into examples (with fixed moduli) for their respective methods - We modify the test of `.weil_pairing` to check for two randomly chosen `7282`-torsion points whether `algorithm="sage"` and `algorithm="pari"` yield the same result Please let me know if you think other polynomial-independent tests are better suited as replacements. See sagemath/conway-polynomials#5 (especially [comment 10](https://github.com/sagemath/conway- polynomials/pull/5#issuecomment-2101462886) and Update 2 in [comment 11](https://github.com/sagemath/conway- polynomials/pull/5#issuecomment-2101498241)) for more details. CC: @yyyyx4 @GiacomoPope @JohnCremona URL: sagemath#37967 Reported by: Sebastian A. Spindler Reviewer(s):

…eparation for database update Motivated by sagemath#35357, the database of Conway polynomials will be enlarged to ensure compatibility in the generation of finite fields (see sagemath/conway-polynomials#5 for details). To prepare for this update, we slightly relax the length check in `sage.databases.conway` to be compatible with both the old and the new version of the database. URL: sagemath#37949 Reported by: Sebastian A. Spindler Reviewer(s): Michael Orlitzky, Sebastian A. Spindler

@yyyyx4

…or Conway database update As part of the Conway polynomials database update, two tests in `schemes.elliptic_curves.ell_point` caused issues due to their dependency on the precise implementation of the finite field `GF(65537^2)`: - The first test (of `.weil_pairing`) checks whether the Sage implementation still works for an example of fixed `7282`-torsion points - The second test (of `.tate_pairing`) checks whether the new implementation, which uses PARI up to reduction of the pairing, coincides with the old Sage implementation (still used e.g. in SageMathCell, but not available in the current code anymore) To help with the database update, we adapt these tests to not be dependent on the exact minimal polynomial used for finite field generation: - We turn both tests into examples (with fixed moduli) for their respective methods - We modify the test of `.weil_pairing` to check for two randomly chosen `7282`-torsion points whether `algorithm="sage"` and `algorithm="pari"` yield the same result Please let me know if you think other polynomial-independent tests are better suited as replacements. See sagemath/conway-polynomials#5 (especially [comment 10](https://github.com/sagemath/conway- polynomials/pull/5#issuecomment-2101462886) and Update 2 in [comment 11](https://github.com/sagemath/conway- polynomials/pull/5#issuecomment-2101498241)) for more details. CC: @yyyyx4 @GiacomoPope @JohnCremona URL: sagemath#37967 Reported by: Sebastian A. Spindler Reviewer(s):

S17A05 mentioned this pull request May 6, 2024

Adapt length check in sage.databases.conway in preparation for database update sagemath/sage#37949

Merged

orlitzky closed this May 7, 2024

S17A05 mentioned this pull request May 8, 2024

Modify tests in ell_point.py to be more generic for Conway database update sagemath/sage#37967

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added Conway polynomials to the database ... #5

Added Conway polynomials to the database ... #5

S17A05 commented Apr 30, 2024

S17A05 commented Apr 30, 2024

orlitzky commented Apr 30, 2024

S17A05 commented Apr 30, 2024

orlitzky commented Apr 30, 2024

S17A05 commented May 6, 2024 •

edited

Loading

orlitzky commented May 6, 2024

orlitzky commented May 7, 2024

tornaria commented May 8, 2024

orlitzky commented May 8, 2024

S17A05 commented May 8, 2024 •

edited

Loading

S17A05 commented May 8, 2024 •

edited

Loading

orlitzky commented May 8, 2024

tornaria commented May 8, 2024 •

edited

Loading

S17A05 commented May 8, 2024

JohnCremona commented May 9, 2024

Added Conway polynomials to the database ... #5

Added Conway polynomials to the database ... #5

Conversation

S17A05 commented Apr 30, 2024

S17A05 commented Apr 30, 2024

orlitzky commented Apr 30, 2024

S17A05 commented Apr 30, 2024

orlitzky commented Apr 30, 2024

S17A05 commented May 6, 2024 • edited Loading

orlitzky commented May 6, 2024

orlitzky commented May 7, 2024

tornaria commented May 8, 2024

orlitzky commented May 8, 2024

S17A05 commented May 8, 2024 • edited Loading

S17A05 commented May 8, 2024 • edited Loading

orlitzky commented May 8, 2024

tornaria commented May 8, 2024 • edited Loading

S17A05 commented May 8, 2024

JohnCremona commented May 9, 2024

S17A05 commented May 6, 2024 •

edited

Loading

S17A05 commented May 8, 2024 •

edited

Loading

S17A05 commented May 8, 2024 •

edited

Loading

tornaria commented May 8, 2024 •

edited

Loading