Checking Mumford representations

[alexjbest]

Currently in schemes/hyperelliptic_curves/jacobian_morphism.py the initialisation for a new divisor in Mumford representation, line 382, the only check is that (b**2 + h*b - f)%a == 0 , the fact that a is monic and that the degrees are correct is not checked. (Other parts of the code might catch this, such as line 197, but this is not always called).

A related, but somewhat distinct issue is that in JacobianHomset_divisor_classes.__call__, schemes/hyperelliptic_curves/jacobian_homset.py line 131, a pair of integers will be interpreted as degree 0 polynomials and passed to the above, but a pair of degree 0 polynomials should almost never be a valid Mumford representation!

I would be glad to hear thoughts on whether these are real issues, and there isn't some error above/mathematical reason I'm missing why we might want to allow this.

If so I'll happily make the patch.

The reason I think changing these is nice is that a naive user (such as myself) may try to use J((2,3)) to create a point of a Jacobian, assuming that some Abel-Jacobi map is fixed behind the scenes, and then end up with completely nonsensical Mumford representations.

If the above changes are made, would anyone support implementing the functionality I assumed to exist, this is pure laziness as of course J(C(2,3)) would work but maybe principle of least surprise is applicable here.

Component: number theory

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

[nbruin]

comment:1

Wouldn't 2,3 be degree 0 polynomials? These could possibly be used to represent divisors supported at infinity?

In any case, a being monic and degree conditions on a,b are not really required to define a valid mumford representation.

Be careful that for even degree hyperelliptic models, Abel-Jacobi is not so straightforward.

[alexjbest]

comment:2

Oops yes, degree 0, changed it. I was assuming that 2,3 would be an invalid Mumford representation though, due to the docstring giving the monic and degree conditions at least. This should always represent the empty divisor though, is that right?

If these are really fine Mumford reps, maybe the doc could be changed to explain that one is allowed to do this? Or precisely what is allowed and what the consequences are.

It still seems the code does not handle this case well though to me. At the very least I think Cantor reduction should be performed on whatever input the user gives then, if I let p = J((2,3)) I see that p + p - p == p is false or even p + 0 == p is false, which must be undesirable in any group?

[alexjbest]

Description changed:

--- 
+++ 
@@ -1,6 +1,6 @@
 Currently in `schemes/hyperelliptic_curves/jacobian_morphism.py` the initialisation for a new divisor in Mumford representation, line 382, the only check is that `(b**2 + h*b - f)%a == 0` , the fact that  a is monic and that the degrees are correct is not checked. (Other parts of the code might catch this, such as line 197, but this is not always called).

-A related, but somewhat distinct issue is that in `JacobianHomset_divisor_classes.__call__`, `schemes/hyperelliptic_curves/jacobian_homset.py` line 131, a pair of integers will be interpreted as degree 1 polynomials and passed to the above, but a pair of degree 1 polynomials should almost never be a valid Mumford representation!
+A related, but somewhat distinct issue is that in `JacobianHomset_divisor_classes.__call__`, `schemes/hyperelliptic_curves/jacobian_homset.py` line 131, a pair of integers will be interpreted as degree 0 polynomials and passed to the above, but a pair of degree 0 polynomials should almost never be a valid Mumford representation!

 I would be glad to hear thoughts on whether these are real issues, and there isn't some error above/mathematical reason I'm missing why we might want to allow this.

[nbruin]

comment:3

Replying to @alexjbest:

Oops yes, degree 0, changed it. I was assuming that 2,3 would be an invalid Mumford representation though, due to the docstring giving the monic and degree conditions at least. This should always represent the empty divisor though, is that right?

It depends a bit if one uses polynomials in x to represent homogeneous forms. It looks like sage doesn't have this case implemented properly.

If we consider the weighted projective model C: y<sup>2=x</sup>6-z^6 then we have points

A=[1:1:0] B=[1:-1:0]

and hence A-B is a degree 0 divisor on this curve (representing a non-trivial divisor class).

One would normally represent that divisor as

2*A - K

where K is the pole divisor of the function x/z.

In coordinates, 2*A can be given as {z^2, y-x^3}

which basically is a Mumford representation ...