add a specialized parent object for elliptic-curve morphisms

[yyyyx4]

Currently, the set of morphisms between elliptic curves is a generic SchemeHomset. However, the morphisms between abelian varieties such as elliptic curves have a lot more structure, which should be reflected in Sage by a specialized parent object.
This patch adds such a parent. The current implementation does not really do much except to enable convenience syntax for scalar multiplications. More advanced functionality (structure computation, finding elements, ...) can be added later.

[GiacomoPope]

Seems like a sensible parent class to create to allow for more complex and interesting code to be included in the future. I cannot think of a reason not to add this parent class

[tscrim]

I would say there is a more natural way to set up the map from $\mathbb{Z}$ by using _coerce_map_from_, which could return True and then let _element_constructor_ handle constructing the map, which seems like the more natural case here. The other option would be to have _coerce_map_from_ simply return the map. The class for the morphism should be on its own with doctests too (if it survives this change).

[yyyyx4]

Thanks for your comments, I think I've addressed them all with the new commits.

[tscrim]

Thank you for the changes. Sorry for a more incremental review (I am doing more parenting right now and having limited time because of that). There are a few smaller things, but I also have one bigger comment:

I am not sure if we want to instead have the endomorphisms as a separate subclass. I guess since the identity() method is implemented for general homsets, we would want to keep things together. Likewise, I am wondering if there is a use in overriding identity() to return a EllipticCurveHom_scalar.

After these comments are addressed, then it will be a positive review.

[tscrim]

So right now we get a really annoying but trivial (and dumb) doctest failures:

sage -t --long --random-seed=286735480429121101562228604801325644303 sage/doctest/forker.py
**********************************************************************
File "sage/doctest/forker.py", line 1560, in sage.doctest.forker.SageDocTestRunner.report_unexpected_exception
Failed example:
    sage0.eval("u")
Expected:
    '...EllipticCurve_field.__init__(self, K, ainvs)'
Got:
    '> /sage/src/sage/schemes/elliptic_curves/ell_field.py(51)__init__()\n-> super().__init__(R, data, category=category)'
**********************************************************************
File "sage/doctest/forker.py", line 1562, in sage.doctest.forker.SageDocTestRunner.report_unexpected_exception
Failed example:
    sage0.eval("p ainvs")
Expected:
    '(0, 0, 0, 0, 0)'
Got:
    "*** NameError: name 'ainvs' is not defined"
**********************************************************************

This comes from the fact that the construction is done differently, so the steps needed by Pbd are different. At least, I believe that to be the problem. Basically, this is a very brittle test, but we will have to fix it. `:/

Some additional comments on the category:

• _endomorphism_ring_is_commutative should be a method of the elliptic curve since it
• Sorry it this is mathematically wrong; I am not an expert in this area. You could at least check if the characteristic is 0 for the endset's extra_super_categories() since that would be a quick check. Of course you can do the full check there, but it seems from your code comments that it would be (relatively) expensive to do on construction (without enough benefits). Of course, you could refine the category in is_commutative(), but I don't think we would get any benefits from doing that.

[yyyyx4]

Fixed the doctest (we have to do u twice now) and turned _endomorphism_ring_is_commutative() into a method.

It's true that characteristic 0 implies commutative endomorphism rings for elliptic curves, but this is no longer true for higher-dimensional abelian varieties: For example, a product of an elliptic curve with itself has $\mathbb Z^{2\times 2}$ in its endomorphism ring. So we cannot set this as a subcategory; it really depends on the object of which we take the End(), just like the .endomorphism_ring_is_commutative() method for elliptic curves over finite fields does. Anyway, I'd argue that this is a non‑issue for the moment: We have no obligation to register something with the finest possible category in which it lies, and I find it hard to imagine that anyone would run End(X) in CommutativeRings() rather than just End(X).is_commutative() as things stand.

[github-actions]

Documentation preview for this PR (built with commit 157ea69; changes) is ready! 🎉

[tscrim]

Thank you for fixing that and the explanations.

Yes, I agree that we do not need to give the most refined category. It could be done lazily by refining the category when is_commutative() is called.

Thanks for all the fixes. This LGTM now; positive review. We can always make further improvements later on.

[tscrim]

PS - Sorry for the delay in getting the final review done.

[yyyyx4]

No worries, thanks for the review!