Support base_morphism for hom(im_gens)

[saraedum]

Currently, the method .hom(im_gens) on parents allows you to define the images of the generators of a structure. This is assuming that the coefficients of these generators can be sent to the codomain with some canonical coercion.

This is often insufficient, e.g., in the case of polynomial rings where you would also like to define a map that translate the ring of coefficients non-canonically. Note that function fields already have a specialized .hom() implementation that supports this feature.

See #26103 for a followup.

CC: @roed314 @xcaruso @sagetrac-swewers

Component: coercion

Keywords: padicBordeaux

Author: Julian Rüth, David Roe

Branch/Commit: 626f4ca

Reviewer: David Roe, Julian Rüth, Xavier Caruso

Issue created by migration from https://trac.sagemath.org/ticket/26105

[saraedum]

comment:1

roed, caruso: I am curious to hear what you think about this. I have been stumbling upon this several times during the past years.

[saraedum]

Description changed:

--- 
+++ 
@@ -1,3 +1,5 @@
 Currently, the method `.hom(im_gens)` on parents allows you to define the images of the generators of a structure. This is assuming that the coefficients of these generators can be sent to the codomain with some canonical coercion.
 
 This is often insufficient, e.g., in the case of polynomial rings where you would also like to define a map that translate the ring of coefficients non-canonically. Note that function fields already have a specialized `.hom()` implementation that supports this feature.
+
+See #26103 for a followup.

[jdemeyer]

comment:3

The problem with im_gens is that it's not really mathematically defined in the first place. So I wouldn't try to add more functionality to it.

Instead, I would define a specific morphism class for polynomial rings. Mathematically, a ring morphism from a polynomial ring is defined by a morphism of the base together with the images of the generators. That was my plan for #25558 but I stopped working on that...

[saraedum]

comment:4

Polynomial rings are just one example. Another one (see #26103) are extensions, say an extension of a finite field where I would like to define a map k(α)→l.

But I think I also had this issue with fraction fields before.

I agree, that specialized morphism classes can be nice because they might have more knowledge about the objects involved (say to implement is_injective()/is_surjective()) but I don't want to implement a new class whenever I need a map between new types of parents and generic code might do that as well.

Maybe I'll just use a SetMorphism if I shouldn't extend hom() though I personally don't like these.

Anyway, let me give a try at extending hom() and see what the result looks like.

[saraedum]

comment:5

Looking at the ring homomorphism code brings back bad memories from #23204. Maybe I don't want to add more to morphism.pyx and homset.py as these should probably be drastically simplified if anything.

[jdemeyer]

comment:6

Replying to @saraedum:

I agree, that specialized morphism classes can be nice because they might have more knowledge about the objects involved (say to implement is_injective()/is_surjective()) but I don't want to implement a new class whenever I need a map between new types of parents and generic code might do that as well.

Of course, if it works using generic code, that's fine for me. But it might be harder to do it that way. I'm pretty sure that some of the existing issues with morphism are precisely because code wants to be too generic and doesn't really know what it is doing.

[jdemeyer]

comment:7

Replying to @saraedum:

Another one (see #26103) are extensions, say an extension of a finite field where I would like to define a map k(α)→l.

But this is really a map induced by a polynomial ring map k[x] → l. We already have a class for such maps induced on a quotient, so we just need the polynomial ring map.

[saraedum]

comment:8

Replying to @jdemeyer:

Replying to @saraedum:

Another one (see #26103) are extensions, say an extension of a finite field where I would like to define a map k(α)→l.

But this is really a map induced by a polynomial ring map k[x] → l. We already have a class for such maps induced on a quotient, so we just need the polynomial ring map.

I am not sure I understand. If k is not a prime field, then how would I would I define my map k[x]→l?

[jdemeyer]

comment:9

Replying to @saraedum:

I am not sure I understand. If k is not a prime field, then how would I would I define my map k[x]→l?

By giving a map k → l and the image of x.

If k is not a prime finite field, then use recursion: k = f[α], so k → l is induced by a map f[x] → l.

[saraedum]

comment:10

Sorry, my question was how to do this in Sage precisely. So, I can map k(α)→k[x] by mapping the generator to x. Then I map k[x]→l[x] by using an induced map. Finally I use the evaluation l[x]→l. But are people really supposed to figure this out on their own?

If I understand your proposal in comment 7 above, you would like to see a shortcut to define k[x]→l as (k[x]).hom(α', base_morphism=k→l). But why not go all the way and allow people to write (k(α)).hom(α', base_morphism=k→l)?

[jdemeyer]

comment:11

Replying to @saraedum:

But why not go all the way and allow people to write (k(α)).hom(α', base_morphism=k→l)?

I'm only talking about the implementation. What you "allow people to write" is an entirely different discussion.