advice needed for what to do in subscheme polynomial morphism initialization

[Ben Hutz]

I'm working on an issue with initialization of affine and projective morphisms over subschemes (Trac #20018).
In looking at this I've uncovered a sticky issue that I'm not sure what the right fix is. Essentially, over a subscheme the coordinate ring is a quotient ring. Thus, when initializing the morphism, the two choices are to reduce the defining polynomials by the quotient or not to.

Currently, in elliptic curve/jacobian and toric/variety there are one or two examples that use that reduction.

You get a different factorization without reducing
{{{
        sage: R.<a,b,c> = QQ[]
        sage: f = a^3+b^3+60*c^3
        sage: Jacobian(f)
        sage: Jacobian(f.subs(c=1))
        sage: h = Jacobian(f, curve=Curve(f));  h
        sage: h([1,-1,0])

    Plugging in the polynomials defining `h` allows us to verify that
    it is indeed a rational morphism to the elliptic curve::

        sage: E = h.codomain()
        sage: E.defining_polynomial()(h.defining_polynomials()).factor()
        (-10077696000000000) * c^3 * b^3 * (a^3 + b^3 + 60*c^3) * (b^6 + 60*b^3*c^3 + 3600*c^6)^3
}}}


The form is different if you don't reduce.
{{{
            sage: P1xP1 = toric_varieties.P1xP1()
            sage: P1 = toric_varieties.P1()
            sage: hom_set = P1xP1.Hom(P1);  hom_set
            sage: P1xP1.inject_variables()
            sage: P1 = P1xP1.subscheme(s-t)
            sage: hom_set = P1xP1.Hom(P1)
            sage: hom_set([s,s,x,y])
            Scheme morphism:
              From: 2-d CPR-Fano toric variety covered by 4 affine patches
              To:   Closed subscheme of 2-d CPR-Fano toric variety covered by 4 affine patches defined by:
              s - t
              Defn: Defined on coordinates by sending [s : t : x : y] to
                    [s : s : x : y]

            sage: hom_set = P1.Hom(P1)
            sage: hom_set([s,s,x,y])
            Scheme endomorphism of Closed subscheme of 2-d CPR-Fano toric
            variety covered by 4 affine patches defined by:
              s - t
              Defn: Defined on coordinates by sending [s : t : x : y] to
                    [t : t : x : y]

}}}

However, there are situations where reduction leads to issues. The original bug is actually a case where the reduction cannot be done since the base ring is not a field
{{{
sage: R.<t>=PolynomialRing(QQ)
sage: P.<x,y,z> = ProjectiveSpace(R,2)
sage: X = P.subscheme(x^2-y^2)
sage: H = Hom(X,X)
sage: f = H([x^2,y^2,x*z])
}}}

Another case is essentially any rational map over an affine subscheme since typically Sage won't compute the quotient of a reduction.
{{{
sage: A.<x,y,z>=AffineSpace(QQ,3)
sage: X=A.subscheme([x^2-y^2])
sage: H=Hom(X,X)
sage: u,v,w = X.coordinate_ring().gens()
sage: H([u,v,(u+1)/v])
}}}


As an example of weird behavior: the map (x^2,y^2,z^2) on the subscheme (x-y), a fixed point (1,1,1) gives back the multplier (0,2//0,2), when it should be (2,0//0,2). This is because the map is reduced and initialized as (y^2,y^2,z^2). Also, in this form it does not extend to a morphism of P^2, where as mathematically it most certainly does.
{{{
sage: P.<x,y,z> = ProjectiveSpace(QQ,2)
sage: X=P.subscheme([x^2-y^2])
sage: H = End(X)
sage: f = H([x^2,y^2,z^2])
sage: f.multiplier(X([1,1]),1)
[0 2]
[0 2]
}}}


Perhaps compounding all this is that the actual representation of the map is lifted to the covering ring (after reducing in the quotient). I understand the reasoning for reducing and it is certainly not mathematically incorrect to do so. However, neither is it mathematically incorrect not to reduce as it is just a different representation. I find myself uncertain what the "correct" fix is.

So, I'm looking for some feedback on what to do with initialization of morphisms over subschemes. To reduce the defining polynomials or not to. The third option is not to reduce by default and to provide an additional function/option that provides a reduced representation.

Thanks,
  Ben

[Ben Hutz]

I've now gone ahead and implemented a preliminary solution(http://trac.sagemath.org/ticket/20018). This had a slight effect on elliptic_curve/jacobian.py and toric/variety.py, so please take a look and provide feedback. The particularities are described in the ticket.

Thanks,
 Ben