Opened 10 years ago

Closed 9 years ago

#13214 closed enhancement (fixed)

Finite field homomorphisms and Frobenius endomorphisms

Reported by: Xavier Caruso Owned by: Alex Ghitza
Priority: major Milestone: sage-5.13
Component: finite rings Keywords: frobenius finite fields sd51
Cc: Thomas Feulner, Xavier Caruso, Darij Grinberg, Jean-Pierre Flori, Peter Bruin, Luca De Feo, Jenny Cooley, Dino Festi Merged in: sage-5.13.beta2
Authors: Xavier Caruso, Peter Bruin Reviewers: Paul Zimmermann, Peter Bruin, Volker Braun
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #8335 Stopgaps:

Status badges

Description (last modified by Frédéric Chapoton)

Here is a patch implementing:

  1. Frobenius endomorphisms over finite fields (generic implementation, plus special implementations for prime finite fields and givaro finite fields)
  2. embeddings between finite fields (with again a special implementation for givaro finite fields)
  3. hashing and rich comparisons for general morphisms

Apply: trac_13214-folded.patch

Attachments (4)

trac_13214_hom_finite_field.2.patch (48.4 KB) - added by Thomas Feulner 10 years ago.
trac_13214_hom_finite_field.patch (58.4 KB) - added by Xavier Caruso 9 years ago.
trac_13214-reviewer.patch (63.5 KB) - added by Peter Bruin 9 years ago.
(long) reviewer patch
trac_13214-folded.patch (64.5 KB) - added by Peter Bruin 9 years ago.
for convenience: unified patch combining trac_13214_hom_finite_field.patch and trac_13214-reviewer.patch

Download all attachments as: .zip

Change History (47)

comment:1 Changed 10 years ago by Xavier Caruso

Status: newneeds_review

comment:2 Changed 10 years ago by Thomas Feulner

I guess your patch should also contain some *.pxd files since I receive the following error message.

Building modified file sage/rings/finite_rings/hom_finite_field.pyx.
Traceback (most recent call last):
  File "setup.py", line 829, in <module>
    queue = compile_command_list(ext_modules, deps)
  File "setup.py", line 789, in compile_command_list
    dep_file, dep_time = deps.newest_dep(f,m)
  File "setup.py", line 696, in newest_dep
    for f in self.all_deps(filename, ext_module):
  File "setup.py", line 677, in all_deps
    for f in self.immediate_deps(filename, ext_module):
  File "setup.py", line 659, in immediate_deps
    self._deps[filename] = self.parse_deps(filename, ext_module)
  File "setup.py", line 647, in parse_deps
    raise IOError, msg
IOError: could not find dependency sage/rings/finite_rings/hom_finite_field.pxd included in sage/rings/finite_rings/hom_prime_finite_field.pyx.
Error installing modified sage library code.

comment:3 Changed 10 years ago by Thomas Feulner

Cc: Thomas Feulner added

comment:4 Changed 10 years ago by Paul Zimmermann

Xavier, if I define an element of GF(q2) which is in fact an element of GF(q), will this patch enable to convert it efficiently to the smaller field? If so, please can you tell me how?

Paul

comment:5 Changed 10 years ago by Xavier Caruso

Oh sorry, I forgot *.pxd files. Thanks!

Paul, the answer to your question is probably yes... at least if q is small enough so that you can work with givaro fields (otherwise, it won't be so efficient).

Actually, I have not implemented automatic coercions between finite fields (essentially because embeddings between finite fields are not canonical). As a consequence it's not so easy to create embeddings. Nevertheless, here is what you can do:

sage: K.<x> = GF(5^3)
sage: L.<y> = GF(5^6)
sage: from sage.rings.finite_rings.hom_finite_field_givaro import FiniteFieldEmbedding_givaro
sage: f = FiniteFieldEmbedding_givaro(K,L); f
Embedding of Finite Field in x of size 5^3 into Finite Field in y of size 5^6
sage: g = f.section(); g
Section of Embedding of Finite Field in x of size 5^3 into Finite Field in y of size 5^6
sage: g(y^126)
3*x^2 + 1
sage: g(y)
Traceback (most recent call last):
...
ValueError: y is not in the image of Embedding of Finite Field in x of size 5^3 into Finite Field in y of size 5^6

If you are sure that you won't never use another embedding of K into L, you can even define f as a coerce map as follows:

sage: K._unset_coercions_used()
sage: K._populate_coercion_lists_(embedding=f)

Then the following will work:

sage: L(x)
2*y^5 + 3*y^4 + 3*y^2 + y + 2
sage: z = x*y; z
3*y^5 + 3*y^4 + 4*y^2 + 2*y + 1
sage: K(z/y)
x
sage: K(y)
Traceback (most recent call last):
...
ValueError: y is not in the image of Embedding of Finite Field in x of size 5^3 into Finite Field in y of size 5^6

comment:6 Changed 10 years ago by Xavier Caruso

Cc: Xavier Caruso added

comment:7 Changed 10 years ago by Jeroen Demeyer

Please fill in your real name as Author.

comment:8 Changed 10 years ago by Xavier Caruso

Authors: Xavier Caruso

comment:9 Changed 10 years ago by Paul Zimmermann

Xavier, I tried to apply the patch on top of Sage 5.1 but got:

sage: hg_sage.import_patch("trac_13214_hom_finite_field.patch")
cd "/usr/local/sage-5.1-linux-64bit-ubuntu_12.04_lts-x86_64-Linux/devel/sage" && sage --hg import   "/tmp/trac_13214_hom_finite_field.patch"
applying /tmp/trac_13214_hom_finite_field.patch
** unknown exception encountered, please report by visiting
**  http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.3 (default, Jul  9 2012, 15:05:17) [GCC 4.6.3]
** Mercurial Distributed SCM (version 1.8.4)
** Extensions loaded: color, mq, pager, rebase, relink
Traceback (most recent call last):
  File "/usr/local/sage-5.1-linux-64bit-ubuntu_12.04_lts-x86_64-Linux/local/bin/hg", line 38, in <module>
    mercurial.dispatch.run()
  File "/usr/local/sage-5.1-linux-64bit-ubuntu_12.04_lts-x86_64-Linux/local/lib/python/mercurial/dispatch.py", line 16, in run
    sys.exit(dispatch(sys.argv[1:]))
  File "/usr/local/sage-5.1-linux-64bit-ubuntu_12.04_lts-x86_64-Linux/local/lib/python/mercurial/dispatch.py", line 36, in dispatch
    return _runcatch(u, args)
...
  File "/usr/local/sage-5.1-linux-64bit-ubuntu_12.04_lts-x86_64-Linux/local/lib/python/mercurial/patch.py", line 339, in readgitpatch
    gp.setmode(int(line[-6:], 8))
ValueError: invalid literal for int() with base 8: '</pre>'

Should I apply it on top of Sage 5.2 or later?

Paul

comment:10 Changed 10 years ago by Paul Zimmermann

please discard my last comment, I downloaded the patch in html form...

Paul

comment:11 Changed 10 years ago by Paul Zimmermann

Reviewers: Paul Zimmermann
Status: needs_reviewneeds_work
Work issues: failing doctests

on top of Sage 5.1 I get the following failures with this patch:

sage -t  devel/sage-13214/sage/categories/modules_with_basis.py # 3 doctests failed
sage -t  devel/sage-13214/sage/rings/finite_rings/finite_field_base.pyx # 2 doctests failed
sage -t  devel/sage-13214/sage/rings/finite_rings/finite_field_givaro.py # 2 doctests failed
sage -t  devel/sage-13214/sage/rings/finite_rings/hom_finite_field.pyx # 2 doctests failed

Paul

comment:12 Changed 10 years ago by Xavier Caruso

Dear Paul,

I cannot reproduce the three last failures on my computer[*]. Could you please give me the complete output of 'sage -t'?

[*] I'm currently working with sage 5.1.rc0; it's probably the reason.

comment:13 in reply to:  12 Changed 10 years ago by Thomas Feulner

These are the failures Paul observed (here on Sage 5.3) with this patch:

sage -t  "devel/sage-codecan/sage/categories/modules_with_basis.py"
**********************************************************************
File "devel/sage-codecan/sage/categories/modules_with_basis.py", line 1149:
    sage: TestSuite(phi).run() # known issue
Expected:
    Failure in _test_category:
    ...
    The following tests failed: _test_category
Got:
    Failure in _test_category:
    Traceback (most recent call last):
      File "local/lib/python/site-packages/sage/misc/sage_unittest.py", line 275, in run
        test_method(tester = tester)
      File "element.pyx", line 499, in sage.structure.element.Element._test_category (sage/structure/element.c:4702)
      File "local/lib/python2.7/unittest/case.py", line 420, in assertTrue
        raise self.failureException(msg)
    AssertionError: False is not true
    ------------------------------------------------------------
    Failure in _test_eq:
    Traceback (most recent call last):
      File "local/lib/python/site-packages/sage/misc/sage_unittest.py", line 275, in run
        test_method(tester = tester)
      File "element.pyx", line 545, in sage.structure.element.Element._test_eq (sage/structure/element.c:4907)
      File "morphism.pyx", line 214, in sage.categories.morphism.Morphism.__richcmp__ (sage/categories/morphism.c:3398)
      File "element.pyx", line 876, in sage.structure.element.Element._richcmp (sage/structure/element.c:8370)
      File "element.pyx", line 923, in sage.structure.element.Element._richcmp_c_impl (sage/structure/element.c:8671)
      File "morphism.pyx", line 228, in sage.categories.morphism.Morphism._cmp_c_impl (sage/categories/morphism.c:3708)
    NotImplementedError
    ------------------------------------------------------------
    The following tests failed: _test_category, _test_eq
**********************************************************************
File "devel/sage-codecan/sage/categories/modules_with_basis.py", line 1384:
    sage: TestSuite(phi).run() # known issue; see ModuleMorphism above
Expected:
    Failure in _test_category:
    ...
    The following tests failed: _test_category
Got:
    Failure in _test_category:
    Traceback (most recent call last):
      File "local/lib/python/site-packages/sage/misc/sage_unittest.py", line 275, in run
        test_method(tester = tester)
      File "element.pyx", line 499, in sage.structure.element.Element._test_category (sage/structure/element.c:4702)
      File "local/lib/python2.7/unittest/case.py", line 420, in assertTrue
        raise self.failureException(msg)
    AssertionError: False is not true
    ------------------------------------------------------------
    Failure in _test_eq:
    Traceback (most recent call last):
      File "local/lib/python/site-packages/sage/misc/sage_unittest.py", line 275, in run
        test_method(tester = tester)
      File "element.pyx", line 545, in sage.structure.element.Element._test_eq (sage/structure/element.c:4907)
      File "morphism.pyx", line 214, in sage.categories.morphism.Morphism.__richcmp__ (sage/categories/morphism.c:3398)
      File "element.pyx", line 876, in sage.structure.element.Element._richcmp (sage/structure/element.c:8370)
      File "element.pyx", line 923, in sage.structure.element.Element._richcmp_c_impl (sage/structure/element.c:8671)
      File "morphism.pyx", line 228, in sage.categories.morphism.Morphism._cmp_c_impl (sage/categories/morphism.c:3708)
    NotImplementedError
    ------------------------------------------------------------
    The following tests failed: _test_category, _test_eq
**********************************************************************
File "devel/sage-codecan/sage/categories/modules_with_basis.py", line 1762:
    sage: TestSuite(phi).run() # known issue; see ModuleMorphismByLinearity.__init__
Expected:
    Failure in _test_category:
    ...
    The following tests failed: _test_category
Got:
    Failure in _test_category:
    Traceback (most recent call last):
      File "local/lib/python/site-packages/sage/misc/sage_unittest.py", line 275, in run
        test_method(tester = tester)
      File "element.pyx", line 499, in sage.structure.element.Element._test_category (sage/structure/element.c:4702)
      File "local/lib/python2.7/unittest/case.py", line 420, in assertTrue
        raise self.failureException(msg)
    AssertionError: False is not true
    ------------------------------------------------------------
    Failure in _test_eq:
    Traceback (most recent call last):
      File "local/lib/python/site-packages/sage/misc/sage_unittest.py", line 275, in run
        test_method(tester = tester)
      File "element.pyx", line 545, in sage.structure.element.Element._test_eq (sage/structure/element.c:4907)
      File "morphism.pyx", line 214, in sage.categories.morphism.Morphism.__richcmp__ (sage/categories/morphism.c:3398)
      File "element.pyx", line 876, in sage.structure.element.Element._richcmp (sage/structure/element.c:8370)
      File "element.pyx", line 923, in sage.structure.element.Element._richcmp_c_impl (sage/structure/element.c:8671)
      File "morphism.pyx", line 228, in sage.categories.morphism.Morphism._cmp_c_impl (sage/categories/morphism.c:3708)
    NotImplementedError
    ------------------------------------------------------------
    The following tests failed: _test_category, _test_eq
**********************************************************************
3 items had failures:
   1 of   8 in __main__.example_40
   1 of   9 in __main__.example_45
   1 of   9 in __main__.example_55
***Test Failed*** 3 failures.
sage -t  "devel/sage-codecan/sage/rings/finite_rings/finite_field_base.pyx"
**********************************************************************
File "devel/sage-codecan/sage/rings/finite_rings/finite_field_base.pyx", line 793:
    sage: k.frobenius_endomorphism(6) == Frob
Expected:
    True
Got:
    False
**********************************************************************
File "devel/sage-codecan/sage/rings/finite_rings/finite_field_base.pyx", line 796:
    sage: k.frobenius_endomorphism(5) == IdentityMorphism(k)
Expected:
    True
Got:
    False
**********************************************************************
1 items had failures:
   2 of  13 in __main__.example_38
sage -t  "devel/sage-codecan/sage/rings/finite_rings/finite_field_givaro.py"
**********************************************************************
File "devel/sage-codecan/sage/rings/finite_rings/finite_field_givaro.py", line 651:
    sage: k.frobenius_endomorphism(6) == Frob
Expected:
    True
Got:
    False
**********************************************************************
File "devel/sage-codecan/sage/rings/finite_rings/finite_field_givaro.py", line 654:
    sage: k.frobenius_endomorphism(5) == IdentityMorphism(k)
Expected:
    True
Got:
    False
**********************************************************************
1 items had failures:
   2 of  13 in __main__.example_21
***Test Failed*** 2 failures.
sage -t  "devel/sage-codecan/sage/rings/finite_rings/hom_finite_field.pyx"
**********************************************************************
File "devel/sage-codecan/sage/rings/finite_rings/hom_finite_field.pyx", line 74:
    sage: Frob == Frob^15
Expected:
    True
Got:
    False
**********************************************************************
File "devel/sage-codecan/sage/rings/finite_rings/hom_finite_field.pyx", line 76:
    sage: Frob^14 == Hom(k,k).identity()
Expected:
    True
Got:
    False
**********************************************************************
1 items had failures:
   2 of  26 in __main__.example_0
***Test Failed*** 2 failures.

Changed 10 years ago by Thomas Feulner

comment:14 Changed 10 years ago by Thomas Feulner

Description: modified (diff)
Status: needs_workneeds_review

I changed the coercion in sage/rings/finite_rings/homset.py. Now, this patch passes all doctests except for the one documented in sage/categories/modules_with_basis.py. I did not change the error messages there, because I wanted to discuss the failure first.

Last edited 10 years ago by Thomas Feulner (previous) (diff)

comment:15 Changed 10 years ago by Xavier Caruso

Dependencies: #13184
Description: modified (diff)

Thanks for catching this!

I now understand why I didn't see this failure: it's just because this patch actually depends on #13184 and that the corresponding patch was applied on my computer. Sorry for this!

I also attach a new version of my patch fixing the problem in modules_with_basis.py; I'm not really happy with my solution (but it has the advantage to be very short). Please let me now if you have some comment!

comment:16 Changed 10 years ago by Xavier Caruso

Work issues: failing doctests

comment:17 Changed 10 years ago by Frédéric Chapoton

for the bot:

Apply trac_13214_hom_finite_field.2.patch

comment:18 Changed 10 years ago by Frédéric Chapoton

Dependencies: #13184

let me remove the dependency to #13184 from the ticket description and see what happens (waiting for the bot to run)

comment:19 Changed 10 years ago by Frédéric Chapoton

Dependencies: #13184
Description: modified (diff)

let us now try with dependency to #13184 put back

for the bot:

apply trac_13214_hom_finite_field.patch

comment:20 Changed 10 years ago by Frédéric Chapoton

Status: needs_reviewneeds_work
Work issues: does not build

please provide a patch that applies, builds and pass all tests

Last edited 10 years ago by Frédéric Chapoton (previous) (diff)

comment:21 Changed 10 years ago by Darij Grinberg

Cc: Darij Grinberg added

comment:22 Changed 10 years ago by Jean-Pierre Flori

Cc: Jean-Pierre Flori added

Not sure how this relates to #8335, but it might be worth having a look there.

Changed 9 years ago by Xavier Caruso

comment:23 Changed 9 years ago by Xavier Caruso

Description: modified (diff)
Status: needs_workneeds_review

I've just posted a patch that should apply on sage-5.10 (let's wait and see).

Jean-Pierre, I was actually not aware about your work with David Roe on lattices of finite fields. I had a quick look at what you have implemented. Unfortunately, it seems to me that our philosophy is a bit different: if I understand correctly, you are trying to make all finite fields canonical whereas my idea was to ask explicitely to the user which embeddings (between finite fields) are canonical and which ones are not.

But, you're right. We should definitely understand precisely how our respective patches relate and merge them if necessary (or discard one of them, i.e. mine).

Note: Actually, my main motivation for this patch was to implement Frobenius endomorphisms. I think you patch does not provide this functionality. Is that correct?

comment:24 Changed 9 years ago by Jean-Pierre Flori

I agree that the purposes of both patches are quite orthogonal: the point of our patch is a first step toward having compatible embeddings in lattices of finite fields automatically, i.e. mimic what Magma does where the user does not have to pay attention to such things and it just works.

And I feel we should merge both patches if possible, even if at some later point it could make sense to refactor some pieces of code.

comment:25 Changed 9 years ago by Peter Bruin

Cc: Peter Bruin added

This looks interesting. One question at the moment: it does not appear to relate to the basic functionality that currently exists (in sage/rings/finite_rings/homset.py). Is that intentional? I can already type, for example,

sage: F9.<a>=GF(3^2)         
sage: F81.<b>=GF(3^4)
sage: f=F9.hom((b^10,))        
sage: f
Ring morphism:
  From: Finite Field in a of size 3^2
  To:   Finite Field in b of size 3^4
  Defn: a |--> 2*b^3 + 2*b^2 + 1
sage: f(a^2+a)
b^3 + b^2
sage: type(f)
<class 'sage.rings.finite_rings.homset.FiniteFieldHomomorphism_im_gens'>
Last edited 9 years ago by Peter Bruin (previous) (diff)

comment:26 Changed 9 years ago by Peter Bruin

As for the differing purposes of the two approaches, there should probably be two categories into which a finite field can be put:

  • the category of all finite fields. In this category, between any two objects there are either several morphisms or none at all, but no canonical one.
  • the category of finite subfields of a given algebraic closure of Fp. In this category there is at most one morphism beteen any two objects, namely the inclusion qua subfields of the given algebraic closure.

comment:27 in reply to:  26 ; Changed 9 years ago by Jean-Pierre Flori

Replying to pbruin:

As for the differing purposes of the two approaches, there should probably be two categories into which a finite field can be put:

  • the category of all finite fields. In this category, between any two objects there are either several morphisms or none at all, but no canonical one.

Which is basically what we currently have and also what this ticket does.

  • the category of finite subfields of a given algebraic closure of Fp. In this category there is at most one morphism beteen any two objects, namely the inclusion qua subfields of the given algebraic closure.

I would like this to be the default at some point, just like in Magma, not because I want to replicate Magma but for usual computations it seems a more practical choice. #8335 provides such an imlementation, though it not really practical for large fields and there is no proper categorical framework as you suggest.

This framework could be implemented in an independent ticket (and should if we want to be able to merge some tickets in a finite amount of time).

comment:28 in reply to:  27 Changed 9 years ago by Peter Bruin

Replying to jpflori:

Which is basically what we currently have and also what this ticket does.

Yes, and precisely for this reason I think it is important to have a clear picture of what belongs in the "category of all finite fields" framework, what belongs in the future "finite subfields of a given algebraic closure" framework, and what is independent of the framework. Among the category-independent things would certainly be the various classes implementing the interfaces to FLINT, Givaro, NTL and PARI, and to a large extent the FiniteField base class itself.

  • the category of finite subfields of a given algebraic closure of Fp. In this category there is at most one morphism beteen any two objects, namely the inclusion qua subfields of the given algebraic closure.

I would like this to be the default at some point, just like in Magma, not because I want to replicate Magma but for usual computations it seems a more practical choice.

That probably depends strongly on the application. Often one just needs to work with a single finite field. In such cases it would be nicer if creating this field would give you a sparse polynomial for efficiency, not one that has been constructed to fit in an algebraic closure that you are unlikely to use.

Of course it would be best if one could do both at the same time, like Magma (see references at #8751), by having an implementation that allows using sparse polynomials while still being able to put the fields in a compatible system/algebraic closure. However, that should probably be done on top of the distinction between the two categories mentioned above, not by muddling this distinction.

comment:29 in reply to:  25 Changed 9 years ago by Xavier Caruso

Replying to pbruin:

This looks interesting. One question at the moment: it does not appear to relate to the basic functionality that currently exists (in sage/rings/finite_rings/homset.py). Is that intentional?

Yes, more or less.

Actually, my first motivation was to implement Frobenius endomorphism and, according to me, FrobeniusEndomorphism? should not derive from RingHomomorphism_im_gens. Indeed, defining Frobenius endomorphisms by giving its value on the generator is not really appropriate for many operations we would like to perform (i.e. evaluation if the field has a small characteristic and a big size, composition, computation of the order or of the subfield of fixed points).

On the other hand, I agree that it makes sense to derive the various classes of embeddings from FiniteFieldHomomorphism_im_gens. I can actually change this if you think that it is better.

As for the differing purposes of the two approaches, there should probably be two categories into which a finite field can be put:

  • the category of all finite fields. In this category, between any two objects there are either several morphisms or none at all, but no canonical one.
  • the category of finite subfields of a given algebraic closure of Fp. In this category there is at most one morphism beteen any two objects, namely the inclusion qua subfields of the given algebraic closure.

This sounds good. And the second category should be a subcategory of the first one, right (a finite subfield of a given algebraic closure of Fp is in particular a finite field)? If so, all category-independant functions should go to the first category (even if the second one is the default, as suggested by Jean-Pierre). This is the case in particular for Frobenius endomorphisms.

comment:30 Changed 9 years ago by Luca De Feo

Cc: Luca De Feo added

comment:31 Changed 9 years ago by Peter Bruin

Keywords: sd51 added
Work issues: does not build

This might be a good target for Sage Days 51 (22-26 July, http://wiki.sagemath.org/sagedaysleiden). For now I just checked that the patch applies to 5.11.beta3 (with some fuzz) and passes doctests. I got one failure (a different embedding than expected is generated), probably because I am working under #14888.

comment:32 Changed 9 years ago by David Loeffler

Apply trac_13214_hom_finite_field.patch​

(for patchbot)

comment:33 Changed 9 years ago by Frédéric Chapoton

for the bot:

apply only trac_13214_hom_finite_field.patch

Changed 9 years ago by Peter Bruin

Attachment: trac_13214-reviewer.patch added

(long) reviewer patch

comment:34 Changed 9 years ago by Peter Bruin

Authors: Xavier CarusoXavier Caruso, Peter Bruin
Cc: Jenny Cooley Dino Festi added
Component: basic arithmeticfinite rings
Dependencies: #13184#8335
Description: modified (diff)
Reviewers: Paul ZimmermannPaul Zimmermann, Peter Bruin
Summary: Frobenius endomorphism over finite fieldsFinite field homomorphisms and Frobenius endomorphisms

In principle I am giving this a positive review, but since the reviewer patch I just uploaded contains some non-trivial changes, I think it is best if someone else reviews those changes first.

Summary of changes in trac_13214-reviewer.patch:

  • Do not add inverse() method to Section; it is currently not used and does not seem to be the best name, since its return value (the original map) is only a one-sided inverse.
  • Add method gens() to CombinatorialFreeModule to fix a doctest failure in modules_with_basis.py. I guess this is the same failure discussed in comment:14 above.
  • Rename [Section]FiniteFieldEmbedding_* to [Section]FiniteFieldHomomorphism_*; even though finite field homomorphisms are automatically injective, I think "homomorphism" fits better with existing code. Furthermore, to me "embedding" makes it sound too much like finite field homomorphisms are canonical.
  • Derive FiniteFieldHomomorphism_generic from RingHomomorphism_im_gens as suggested above.
  • Replace the existing FiniteFieldHomomorphism_im_gens by the new FiniteFieldHomomorphism_generic.
  • Better integration of the new code into the existing finite field code.
  • Remove the _repr_() method of FiniteFieldHomomorphism_generic, so that the output is the same as for the old FiniteFieldHomomorphism_im_gens.
  • Do not automatically generate a section for every finite field homomorphism.
  • Numerous whitespace edits and some other typographical changes.

Changed 9 years ago by Peter Bruin

Attachment: trac_13214-folded.patch added

for convenience: unified patch combining trac_13214_hom_finite_field.patch and trac_13214-reviewer.patch

comment:35 Changed 9 years ago by Jeroen Demeyer

Milestone: sage-5.11sage-5.12

comment:36 Changed 9 years ago by Frédéric Chapoton

Description: modified (diff)

apply only trac_13214-folded.patch

comment:37 Changed 9 years ago by Peter Bruin

Milestone: sage-5.12sage-5.13

comment:38 Changed 9 years ago by Jean-Pierre Flori

I'm currently at Sage Days 53 and could spare some time on this one... unless Luca is nearing completion of his review?

If I understand correctly, what needs to be done is to check Peter's changes as he already went over what Xavier did?

comment:39 in reply to:  38 Changed 9 years ago by Luca De Feo

Replying to jpflori:

I'm currently at Sage Days 53 and could spare some time on this one... unless Luca is nearing completion of his review?

I'm rather nearing completion of the new class I'm starting next week... so feel free to go ahead :)

comment:40 in reply to:  38 Changed 9 years ago by Peter Bruin

Replying to jpflori:

I'm currently at Sage Days 53 and could spare some time on this one... unless Luca is nearing completion of his review?

If I understand correctly, what needs to be done is to check Peter's changes as he already went over what Xavier did?

Yes, it would be nice if you could take a look either at my reviewer patch or at the combined one (the combined patch is only a little larger and probably easier to review).

comment:41 Changed 9 years ago by Volker Braun

patchbot: only

Apply trac_13214-folded.patch​

comment:42 Changed 9 years ago by Volker Braun

Reviewers: Paul Zimmermann, Peter BruinPaul Zimmermann, Peter Bruin, Volker Braun
Status: needs_reviewpositive_review

The review patch looks good to me.

comment:43 Changed 9 years ago by Jeroen Demeyer

Merged in: sage-5.13.beta2
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.