Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

To make discussion on this point easier, I have made a GitHub 
issue: https://github.com/sagemath/sage/issues/37626

For progress on this code, we have all doctests passing from the old 
implementation except:

- we cannot define toric varieties over rings, so we can't have 
hyperelliptic curves over rings
- we cannot use the current rational_points method from algebraic_schemes 
due to missing methods in the homset of toric varieties

We are also working on pairings as well as isomorphisms on top of 
supporting all older features.

On Friday, March 15, 2024 at 6:47:02 PM UTC Giacomo Pope wrote:

> Back again with more class questions and general advice help
>
> While getting all the old sage code into this new project, I realised 
> there are places where we really rely on the underlying curve classes. One 
> example is that we need
>
> ```
> def dimension():
> return 1
> ```
>
> To avoid some crashes, but more generally we also need `rational_points()` 
> which lives all the way inside `Algebraic_scheme`. There's also a whole 
> bunch of other things...
>
> I started exploring more and I found `Curve_generic` which we can create 
> with the data I already have:
>
> ```
> sage: H = HyperellipticCurveSmoothModel(x^5 + x + 1)
> sage: C = Curve_generic(H._projective_model.ambient_space(), 
> H._projective_model.defining_polynomials())
> sage: type(C)
> 
> sage: C
> Generic Curve over Rational Field defined by -X^5*Z - X*Z^5 - Z^6 + Y^2
> sage: C.ambient_space()
> 2-d toric variety covered by 3 affine patches
> ```
>
> this gets us some of the way and I think is an OK starting point, but then 
> things like asking for the curve crash for weighted projective space:
>
> ```
> sage: Curve(H)
> ---
> TypeError Traceback (most recent call last)
> .
> TypeError: ambient space neither affine nor projective
> ```
>
> and calls to things like C.rational_points() have more issues
>
> ```
> sage: C.rational_points(bounds=2)
> ---
> KeyError  Traceback (most recent call last)
> .
> AttributeError: 'SchemeHomset_points_subscheme_toric_field_with_category' 
> object has no attribute 'points'
> ```
>
> Which just goes to show that these toric varieties are a little 
> underdeveloped.
>
> Something which might be really nice would be 
>
> ```
> class WeightedProjectiveCurve(Curve_generic, 
> AlgebraicScheme_subscheme_toric):
> ```
>
> Intended to mirror the similar:
>
> ```
> class ProjectiveCurve(Curve_generic, AlgebraicScheme_subscheme_projective):
> ```
>
> This could then be the class which is inherited by the Hyperelliptic curve 
> class and we could aim for better coverage here.
>
> Any opinions on this? Any idea of people who might have thought about or 
> made progress in this area?
>
> Otherwise, the project continues. Functions for finite fields are all 
> working, generic functions mostly and the padic functions are a WIP as we 
> need to adapt to the fact we have different points at infinity (and I dont 
> know how to properly handle the case when there's two (yet)).
>
> Finally, looking at the rational_points() method itself, this is something 
> people have at least considered:
>
> ```
> .. TODO::
>
> Implement Stoll's model in weighted projective space to
> resolve singularities and find two points (1 : 1 : 0) and
> (-1 : 1 : 0) at infinity.
> ```
>
>
> On Wednesday, March 13, 2024 at 6:23:38 PM UTC Giacomo Pope wrote:
>
>> Thanks so much for the context
>>
>> Oh interesting. In this case I wonder whether we should work on and 
>> include a new class (maybe something as simple as a WeightedProjectiveSpace 
>> and a curve from this) mirroring the implementation for the plane curves. 
>> Alternatively I could go into the old plane curve code and write these 
>> useful functions specifically for the hyperelliptic curves (and here even 
>> gain that these algorithms can be optimised). For example, I already had to 
>> include a `dimension()` method on the curve to properly compute the 
>> Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
>> inheritance
>>
>> On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:
>>
>>> One thing that may deserve a cursory check is the overhead involved in 
>>> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
>>> structures are optimized for prolonged use *after* creation and may do a 
>>> lot of caching/precomputation. There may be scenarios where one wants to 
>>> construct *lots* of hyperelliptic curves (for instance, when computing 
>>> reductions of hyperelliptic curves mod lots of primes). An expensive parent 
>>> may then add undue overhead. In that case it may be better to spin off the 
>>> functionality required into a "lightweight" structure that gets wrapped in 

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

Back again with more class questions and general advice help

While getting all the old sage code into this new project, I realised there 
are places where we really rely on the underlying curve classes. One 
example is that we need

```
def dimension():
return 1
```

To avoid some crashes, but more generally we also need `rational_points()` 
which lives all the way inside `Algebraic_scheme`. There's also a whole 
bunch of other things...

I started exploring more and I found `Curve_generic` which we can create 
with the data I already have:

```
sage: H = HyperellipticCurveSmoothModel(x^5 + x + 1)
sage: C = Curve_generic(H._projective_model.ambient_space(), 
H._projective_model.defining_polynomials())
sage: type(C)

sage: C
Generic Curve over Rational Field defined by -X^5*Z - X*Z^5 - Z^6 + Y^2
sage: C.ambient_space()
2-d toric variety covered by 3 affine patches
```

this gets us some of the way and I think is an OK starting point, but then 
things like asking for the curve crash for weighted projective space:

```
sage: Curve(H)
---
TypeError Traceback (most recent call last)
.
TypeError: ambient space neither affine nor projective
```

and calls to things like C.rational_points() have more issues

```
sage: C.rational_points(bounds=2)
---
KeyError  Traceback (most recent call last)
.
AttributeError: 'SchemeHomset_points_subscheme_toric_field_with_category' 
object has no attribute 'points'
```

Which just goes to show that these toric varieties are a little 
underdeveloped.

Something which might be really nice would be 

```
class WeightedProjectiveCurve(Curve_generic, 
AlgebraicScheme_subscheme_toric):
```

Intended to mirror the similar:

```
class ProjectiveCurve(Curve_generic, AlgebraicScheme_subscheme_projective):
```

This could then be the class which is inherited by the Hyperelliptic curve 
class and we could aim for better coverage here.

Any opinions on this? Any idea of people who might have thought about or 
made progress in this area?

Otherwise, the project continues. Functions for finite fields are all 
working, generic functions mostly and the padic functions are a WIP as we 
need to adapt to the fact we have different points at infinity (and I dont 
know how to properly handle the case when there's two (yet)).

Finally, looking at the rational_points() method itself, this is something 
people have at least considered:

```
.. TODO::

Implement Stoll's model in weighted projective space to
resolve singularities and find two points (1 : 1 : 0) and
(-1 : 1 : 0) at infinity.
```


On Wednesday, March 13, 2024 at 6:23:38 PM UTC Giacomo Pope wrote:

> Thanks so much for the context
>
> Oh interesting. In this case I wonder whether we should work on and 
> include a new class (maybe something as simple as a WeightedProjectiveSpace 
> and a curve from this) mirroring the implementation for the plane curves. 
> Alternatively I could go into the old plane curve code and write these 
> useful functions specifically for the hyperelliptic curves (and here even 
> gain that these algorithms can be optimised). For example, I already had to 
> include a `dimension()` method on the curve to properly compute the 
> Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
> inheritance
>
> On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:
>
>> One thing that may deserve a cursory check is the overhead involved in 
>> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
>> structures are optimized for prolonged use *after* creation and may do a 
>> lot of caching/precomputation. There may be scenarios where one wants to 
>> construct *lots* of hyperelliptic curves (for instance, when computing 
>> reductions of hyperelliptic curves mod lots of primes). An expensive parent 
>> may then add undue overhead. In that case it may be better to spin off the 
>> functionality required into a "lightweight" structure that gets wrapped in 
>> the expensive, full functionality parent. After all, for core algorithms a 
>> hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
>> the coefficients of the defining equation.
>>
>> There are of course also odd genus hyperelliptic curves that cover a 
>> genus 0 curve that is not isomorphic to a P^1, but computing in their 
>> Jacobians has its own problems, so you should probably not try to include 
>> them in your current design.
>>
>> One thing that may be worthwhile: hyperelliptic curves do inherit some 
>> interesting functionality from plane curves (particularly via their affine 
>> patch) in the form of "riemann_surface". It may be worth keeping that, even 
>> if the particular code there could be expanded to work much more 
>> efficiently on 

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

Thanks so much for the context

Oh interesting. In this case I wonder whether we should work on and include 
a new class (maybe something as simple as a WeightedProjectiveSpace and a 
curve from this) mirroring the implementation for the plane curves. 
Alternatively I could go into the old plane curve code and write these 
useful functions specifically for the hyperelliptic curves (and here even 
gain that these algorithms can be optimised). For example, I already had to 
include a `dimension()` method on the curve to properly compute the 
Jacobian. Potentially AlgebraicScheme_subscheme_toric is indeed the wrong 
inheritance

On Wednesday, March 13, 2024 at 6:18:12 PM UTC Nils Bruin wrote:

> One thing that may deserve a cursory check is the overhead involved in 
> inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
> structures are optimized for prolonged use *after* creation and may do a 
> lot of caching/precomputation. There may be scenarios where one wants to 
> construct *lots* of hyperelliptic curves (for instance, when computing 
> reductions of hyperelliptic curves mod lots of primes). An expensive parent 
> may then add undue overhead. In that case it may be better to spin off the 
> functionality required into a "lightweight" structure that gets wrapped in 
> the expensive, full functionality parent. After all, for core algorithms a 
> hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
> the coefficients of the defining equation.
>
> There are of course also odd genus hyperelliptic curves that cover a genus 
> 0 curve that is not isomorphic to a P^1, but computing in their Jacobians 
> has its own problems, so you should probably not try to include them in 
> your current design.
>
> One thing that may be worthwhile: hyperelliptic curves do inherit some 
> interesting functionality from plane curves (particularly via their affine 
> patch) in the form of "riemann_surface". It may be worth keeping that, even 
> if the particular code there could be expanded to work much more 
> efficiently on hyperelliptic curves.
>
> On Wednesday 13 March 2024 at 10:32:08 UTC-7 Giacomo Pope wrote:
>
>> Thanks David, there's a bunch of nice things we could do for genus two in 
>> various cases which would be worth including. The inert case, where all 
>> degree zero divisors (except the identity element) have u with degree 2 
>> would probably allow something particularly nice. 
>>
>> As another update I have done a fairly brutish refactoring of the proof 
>> of concept code to follow the design decisions of the previous 
>> implementation. https://github.com/GiacomoPope/HyperellipticCurves
>>
>> Hyperelliptic curves are created from a dynamic class constructor on top 
>> of the AlgebraicScheme_subscheme_toric class (before this was a curve over 
>> the plane projective curves)
>> A generic class offers most features, but other classes will cover the 
>> case of finite fields, rational fields and padic fields
>> The Jacobian is a small class built on top of `jacobian_generic` which is 
>> built from the curve
>> The set of rational points of the Jacobian is built on top of 
>> SchemeHomSet and the elements (divisors) are morphisms built on top of 
>> SchemeMorphism
>>
>> I will do my best to clean up and refactor code to the standard of code 
>> which is included into Sage now, but I would love to know any feedback 
>> advice on whether this structure is still the one to use. The older version 
>> of this code dates back to the beginning of Sage so it's very possible we 
>> have new ideas of how things should be done and if we're doing the work or 
>> rewriting the whole set of classes I may as well do a good job.
>>
>> Giacomo
>>
>> On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:
>>
>>> There is also this old trac ticket 
>>>  about implementing fast 
>>> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
>>> Mike Jabobson, who worked on it.
>>> David
>>>
>>>
>>> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  
>>> wrote:
>>>
 Thank you for linking this and I agree this is a great way to 
 cross-compare the work we have been doing. I am not an expert in this area 
 so I am not sure I should do a full review but I'm happy to look over it 
 if 
 this helps.

 As a small update on this work, I now have 

 class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)

 So this new class builds on top of AlgebraicScheme_subscheme_toric and 
 the smooth projective model is built using a toric variety. The points on 
 the curve are currently SchemeMorphism_point_toric_field, potentially I 
 will need to make a child class of these if methods on the points 
 themselves are required.

 With the working arithmetic and this new inheritance my work is now 
 going to be the rather slow and painful rewrite of all 

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Nils Bruin]

One thing that may deserve a cursory check is the overhead involved in 
inheriting from AlgebraicScheme_subscheme_toric class . Some parent 
structures are optimized for prolonged use *after* creation and may do a 
lot of caching/precomputation. There may be scenarios where one wants to 
construct *lots* of hyperelliptic curves (for instance, when computing 
reductions of hyperelliptic curves mod lots of primes). An expensive parent 
may then add undue overhead. In that case it may be better to spin off the 
functionality required into a "lightweight" structure that gets wrapped in 
the expensive, full functionality parent. After all, for core algorithms a 
hyperelliptic curve is just a 3*g+5 length sequence of ring/field elements: 
the coefficients of the defining equation.

There are of course also odd genus hyperelliptic curves that cover a genus 
0 curve that is not isomorphic to a P^1, but computing in their Jacobians 
has its own problems, so you should probably not try to include them in 
your current design.

One thing that may be worthwhile: hyperelliptic curves do inherit some 
interesting functionality from plane curves (particularly via their affine 
patch) in the form of "riemann_surface". It may be worth keeping that, even 
if the particular code there could be expanded to work much more 
efficiently on hyperelliptic curves.

On Wednesday 13 March 2024 at 10:32:08 UTC-7 Giacomo Pope wrote:

> Thanks David, there's a bunch of nice things we could do for genus two in 
> various cases which would be worth including. The inert case, where all 
> degree zero divisors (except the identity element) have u with degree 2 
> would probably allow something particularly nice. 
>
> As another update I have done a fairly brutish refactoring of the proof of 
> concept code to follow the design decisions of the previous implementation. 
> https://github.com/GiacomoPope/HyperellipticCurves
>
> Hyperelliptic curves are created from a dynamic class constructor on top 
> of the AlgebraicScheme_subscheme_toric class (before this was a curve over 
> the plane projective curves)
> A generic class offers most features, but other classes will cover the 
> case of finite fields, rational fields and padic fields
> The Jacobian is a small class built on top of `jacobian_generic` which is 
> built from the curve
> The set of rational points of the Jacobian is built on top of SchemeHomSet 
> and the elements (divisors) are morphisms built on top of SchemeMorphism
>
> I will do my best to clean up and refactor code to the standard of code 
> which is included into Sage now, but I would love to know any feedback 
> advice on whether this structure is still the one to use. The older version 
> of this code dates back to the beginning of Sage so it's very possible we 
> have new ideas of how things should be done and if we're doing the work or 
> rewriting the whole set of classes I may as well do a good job.
>
> Giacomo
>
> On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:
>
>> There is also this old trac ticket 
>>  about implementing fast 
>> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
>> Mike Jabobson, who worked on it.
>> David
>>
>>
>> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  wrote:
>>
>>> Thank you for linking this and I agree this is a great way to 
>>> cross-compare the work we have been doing. I am not an expert in this area 
>>> so I am not sure I should do a full review but I'm happy to look over it if 
>>> this helps.
>>>
>>> As a small update on this work, I now have 
>>>
>>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)
>>>
>>> So this new class builds on top of AlgebraicScheme_subscheme_toric and 
>>> the smooth projective model is built using a toric variety. The points on 
>>> the curve are currently SchemeMorphism_point_toric_field, potentially I 
>>> will need to make a child class of these if methods on the points 
>>> themselves are required.
>>>
>>> With the working arithmetic and this new inheritance my work is now 
>>> going to be the rather slow and painful rewrite of all hyperelliptic 
>>> methods from the current implementation to ensure everything works on the 
>>> smooth degree model.
>>>
>>> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:
>>>
 On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:

 As a small update, the repository now contains code to

 - perform arithmetic for
   - the imaginary model (ramified, one point at infinity) for all cases
   - the real model (split, two points at infinity) for all cases
   - the real model (inert, zero points at infinity) for even genus
   Which allows us to do "as much" as Magma does for Jacobians of 
 hyperellipticc curves from the perspective of arithmetic. 

 My current "test" for the arithmetic is that D - D = 0 for all cases, 
 that jacobian_order 

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

Thanks David, there's a bunch of nice things we could do for genus two in 
various cases which would be worth including. The inert case, where all 
degree zero divisors (except the identity element) have u with degree 2 
would probably allow something particularly nice. 

As another update I have done a fairly brutish refactoring of the proof of 
concept code to follow the design decisions of the previous 
implementation. https://github.com/GiacomoPope/HyperellipticCurves

Hyperelliptic curves are created from a dynamic class constructor on top of 
the AlgebraicScheme_subscheme_toric class (before this was a curve over the 
plane projective curves)
A generic class offers most features, but other classes will cover the case 
of finite fields, rational fields and padic fields
The Jacobian is a small class built on top of `jacobian_generic` which is 
built from the curve
The set of rational points of the Jacobian is built on top of SchemeHomSet 
and the elements (divisors) are morphisms built on top of SchemeMorphism

I will do my best to clean up and refactor code to the standard of code 
which is included into Sage now, but I would love to know any feedback 
advice on whether this structure is still the one to use. The older version 
of this code dates back to the beginning of Sage so it's very possible we 
have new ideas of how things should be done and if we're doing the work or 
rewriting the whole set of classes I may as well do a good job.

Giacomo

On Wednesday, March 13, 2024 at 3:36:09 AM UTC David Roe wrote:

> There is also this old trac ticket 
>  about implementing fast 
> arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed 
> Mike Jabobson, who worked on it.
> David
>
>
> On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  wrote:
>
>> Thank you for linking this and I agree this is a great way to 
>> cross-compare the work we have been doing. I am not an expert in this area 
>> so I am not sure I should do a full review but I'm happy to look over it if 
>> this helps.
>>
>> As a small update on this work, I now have 
>>
>> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)
>>
>> So this new class builds on top of AlgebraicScheme_subscheme_toric and 
>> the smooth projective model is built using a toric variety. The points on 
>> the curve are currently SchemeMorphism_point_toric_field, potentially I 
>> will need to make a child class of these if methods on the points 
>> themselves are required.
>>
>> With the working arithmetic and this new inheritance my work is now going 
>> to be the rather slow and painful rewrite of all hyperelliptic methods from 
>> the current implementation to ensure everything works on the smooth degree 
>> model.
>>
>> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:
>>
>>> On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:
>>>
>>> As a small update, the repository now contains code to
>>>
>>> - perform arithmetic for
>>>   - the imaginary model (ramified, one point at infinity) for all cases
>>>   - the real model (split, two points at infinity) for all cases
>>>   - the real model (inert, zero points at infinity) for even genus
>>>   Which allows us to do "as much" as Magma does for Jacobians of 
>>> hyperellipticc curves from the perspective of arithmetic. 
>>>
>>> My current "test" for the arithmetic is that D - D = 0 for all cases, 
>>> that jacobian_order * D = zero and that order_from_multiple(D) works. If 
>>> people have other ideas for tests, please let me know. Of course at the 
>>> moment these tests are over finite fields but you can reasonable use other 
>>> fields (as Sabrina's message shows) but I am less sure about how to do 
>>> randomised testing here.
>>>
>>>
>>> I just set https://github.com/sagemath/sage/pull/35467 to "needs 
>>> review" status. The PR implements Jacobian arithmetic for general 
>>> projective curves.
>>>
>>> It is slow compared with Jacobian arithmetic using Mumford 
>>> representation, but could be used to crosscheck the computations.
>>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[David Roe]

There is also this old trac ticket
 about implementing fast
arithmetic in genus 2 Jacobians, which never made it into Sage.  I've CCed
Mike Jabobson, who worked on it.
David


On Tue, Mar 12, 2024 at 12:10 PM Giacomo Pope  wrote:

> Thank you for linking this and I agree this is a great way to
> cross-compare the work we have been doing. I am not an expert in this area
> so I am not sure I should do a full review but I'm happy to look over it if
> this helps.
>
> As a small update on this work, I now have
>
> class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)
>
> So this new class builds on top of AlgebraicScheme_subscheme_toric and the
> smooth projective model is built using a toric variety. The points on the
> curve are currently SchemeMorphism_point_toric_field, potentially I will
> need to make a child class of these if methods on the points themselves are
> required.
>
> With the working arithmetic and this new inheritance my work is now going
> to be the rather slow and painful rewrite of all hyperelliptic methods from
> the current implementation to ensure everything works on the smooth degree
> model.
>
> On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:
>
>> On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:
>>
>> As a small update, the repository now contains code to
>>
>> - perform arithmetic for
>>   - the imaginary model (ramified, one point at infinity) for all cases
>>   - the real model (split, two points at infinity) for all cases
>>   - the real model (inert, zero points at infinity) for even genus
>>   Which allows us to do "as much" as Magma does for Jacobians of
>> hyperellipticc curves from the perspective of arithmetic.
>>
>> My current "test" for the arithmetic is that D - D = 0 for all cases,
>> that jacobian_order * D = zero and that order_from_multiple(D) works. If
>> people have other ideas for tests, please let me know. Of course at the
>> moment these tests are over finite fields but you can reasonable use other
>> fields (as Sabrina's message shows) but I am less sure about how to do
>> randomised testing here.
>>
>>
>> I just set https://github.com/sagemath/sage/pull/35467 to "needs review"
>> status. The PR implements Jacobian arithmetic for general projective curves.
>>
>> It is slow compared with Jacobian arithmetic using Mumford
>> representation, but could be used to crosscheck the computations.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAChs6_njyXKS4797cJxVpFsBdVdGt%2B7XFPNXyDEEfK%3DAPks%2BFA%40mail.gmail.com.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

Thank you for linking this and I agree this is a great way to cross-compare 
the work we have been doing. I am not an expert in this area so I am not 
sure I should do a full review but I'm happy to look over it if this helps.

As a small update on this work, I now have 

class HyperellipticCurveSmoothModel(AlgebraicScheme_subscheme_toric)

So this new class builds on top of AlgebraicScheme_subscheme_toric and the 
smooth projective model is built using a toric variety. The points on the 
curve are currently SchemeMorphism_point_toric_field, potentially I will 
need to make a child class of these if methods on the points themselves are 
required.

With the working arithmetic and this new inheritance my work is now going 
to be the rather slow and painful rewrite of all hyperelliptic methods from 
the current implementation to ensure everything works on the smooth degree 
model.

On Monday, March 11, 2024 at 6:23:38 AM UTC Kwankyu Lee wrote:

> On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:
>
> As a small update, the repository now contains code to
>
> - perform arithmetic for
>   - the imaginary model (ramified, one point at infinity) for all cases
>   - the real model (split, two points at infinity) for all cases
>   - the real model (inert, zero points at infinity) for even genus
>   Which allows us to do "as much" as Magma does for Jacobians of 
> hyperellipticc curves from the perspective of arithmetic. 
>
> My current "test" for the arithmetic is that D - D = 0 for all cases, that 
> jacobian_order * D = zero and that order_from_multiple(D) works. If people 
> have other ideas for tests, please let me know. Of course at the moment 
> these tests are over finite fields but you can reasonable use other fields 
> (as Sabrina's message shows) but I am less sure about how to do randomised 
> testing here.
>
>
> I just set https://github.com/sagemath/sage/pull/35467 to "needs review" 
> status. The PR implements Jacobian arithmetic for general projective curves.
>
> It is slow compared with Jacobian arithmetic using Mumford representation, 
> but could be used to crosscheck the computations.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7f646c6d-bd0b-452d-a730-30144415f590n%40googlegroups.com.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Kwankyu Lee]

On Friday, March 8, 2024 at 7:37:04 PM UTC+9 Giacomo Pope wrote:

As a small update, the repository now contains code to

- perform arithmetic for
  - the imaginary model (ramified, one point at infinity) for all cases
  - the real model (split, two points at infinity) for all cases
  - the real model (inert, zero points at infinity) for even genus
  Which allows us to do "as much" as Magma does for Jacobians of 
hyperellipticc curves from the perspective of arithmetic. 

My current "test" for the arithmetic is that D - D = 0 for all cases, that 
jacobian_order * D = zero and that order_from_multiple(D) works. If people 
have other ideas for tests, please let me know. Of course at the moment 
these tests are over finite fields but you can reasonable use other fields 
(as Sabrina's message shows) but I am less sure about how to do randomised 
testing here.


I just set https://github.com/sagemath/sage/pull/35467 to "needs review" 
status. The PR implements Jacobian arithmetic for general projective curves.

It is slow compared with Jacobian arithmetic using Mumford representation, 
but could be used to crosscheck the computations.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/08bd8615-d323-43a3-aa04-314687d64c6an%40googlegroups.com.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Giacomo Pope]

As a small update, the repository now contains code to

- perform arithmetic for
  - the imaginary model (ramified, one point at infinity) for all cases
  - the real model (split, two points at infinity) for all cases
  - the real model (inert, zero points at infinity) for even genus
  Which allows us to do "as much" as Magma does for Jacobians of 
hyperellipticc curves from the perspective of arithmetic. 

My current "test" for the arithmetic is that D - D = 0 for all cases, that 
jacobian_order * D = zero and that order_from_multiple(D) works. If people 
have other ideas for tests, please let me know. Of course at the moment 
these tests are over finite fields but you can reasonable use other fields 
(as Sabrina's message shows) but I am less sure about how to do randomised 
testing here.

- We also have a function which can randomly (but not uniformly) sample 
elements of the Jacobian for all the cases.
- We can compute the order of the Jacobian from the frob. polynomial and 
using the arithmetic and in-build `order_from_multiple` then find the order 
of divisors

I think the next thing to do is to look at isomorphisms and maybe even 
isogenies (Richelot only for genus two perhaps?)

If you are interested in this area and want to contribute, then I think 
fleshing out the code in this repo will be easier during these early stages 
and once it feels complete we can look at replacing the current code in 
sagemath with this newer version.

On Thursday, March 7, 2024 at 9:40:58 PM UTC Sabrina Kunzweiler wrote:

> Thanks for mentioning the related discussion. We checked that in the new 
> implementation in Giacomo's repository, this issue is solved. 
>
> In the example that was given in the chat, we obtain the following output:
> ```
> sage: R. = QQ[]
> sage: f = 144*x^6 - 240*x^5 + 148*x^4 + 16*x^3 - 16*x^2 - 4*x + 1
> sage: H = HyperellipticCurveNew(f)
> sage: J = Jacobian(H)
> sage: P = J(H([0,1]))-J(H([0,-1]))
> sage: (5*P).is_zero()
> False
> sage: 5*P
> (1, 0 : 2)
> ```
> Here, this means $$ 5 P = (1:12:0) - (1:-12:0) $$ which coincides with the 
> result from magma. 
>
>
> Kwankyu Lee schrieb am Donnerstag, 7. März 2024 um 05:44:33 UTC+1:
>
>> It's still here: https://github.com/sagemath/sage/issues/32024
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/16695996-c9bc-4a08-a1a4-37179e7a8956n%40googlegroups.com.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Sabrina Kunzweiler]

Thanks for mentioning the related discussion. We checked that in the new 
implementation in Giacomo's repository, this issue is solved. 

In the example that was given in the chat, we obtain the following output:
```
sage: R. = QQ[]
sage: f = 144*x^6 - 240*x^5 + 148*x^4 + 16*x^3 - 16*x^2 - 4*x + 1
sage: H = HyperellipticCurveNew(f)
sage: J = Jacobian(H)
sage: P = J(H([0,1]))-J(H([0,-1]))
sage: (5*P).is_zero()
False
sage: 5*P
(1, 0 : 2)
```
Here, this means $$ 5 P = (1:12:0) - (1:-12:0) $$ which coincides with the 
result from magma. 


Kwankyu Lee schrieb am Donnerstag, 7. März 2024 um 05:44:33 UTC+1:

> It's still here: https://github.com/sagemath/sage/issues/32024

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b9905212-152b-4424-8687-2178e6e9fe5bn%40googlegroups.com.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Kwankyu Lee]

It's still here: https://github.com/sagemath/sage/issues/32024

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4dc27a25-cd0a-4d1e-be5b-e28a0cb8b32an%40googlegroups.com.

Re: [sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Zachary Scherr]

Just wanted to mention that I posted about something similar a few years
ago here:
https://groups.google.com/g/sage-support/c/j1Y9yuu-VuE/m/cA7N8iqCCAAJ.  At
the time a trac ticket was opened, but I'm not sure about the status
especially post the github migration.

On Wed, Mar 6, 2024 at 11:55 AM Nils Bruin  wrote:

> On Wednesday 6 March 2024 at 04:52:16 UTC-8 Giacomo Pope wrote:
>
>
> I think aside from maybe needing additional methods on the hyperelliptic
> curve, once the projective model is right and points on the curve are well
> defined for all cases. I do not have any intuition on whether the balanced
> model will for example have issues with the p-Adic implementation as I have
> no experience in this area.
>
> Tiny bit of feedback on the p-adic bit: as far as I know, things like
> Cantor's algorithm use euclidean division, wwhich is a big problem
> p-adically: coefficients may vanish unexpectedly and p-adically you cannot
> distinguish that from loss of precision. I think that's already a problem
> in the existing implementation and I think it will be in yours as well. So
> I think you can ignore p-adics to begin with. If you can get it working
> usefully and reliably for p-adic base fields as well then that's a real
> win!
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/f4de3410-1d9e-4cc7-b518-7471f6c1ecean%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAKLKTSQVthP93H3dqkK5UBdo_1xQi1iAVZjUP6oo-7YAo2QPaw%40mail.gmail.com.

[sage-devel] Re: Help and Advice | Arithmetic of Jacobians in the Split/Real Model is Broken

[Nils Bruin]

On Wednesday 6 March 2024 at 04:52:16 UTC-8 Giacomo Pope wrote:


I think aside from maybe needing additional methods on the hyperelliptic 
curve, once the projective model is right and points on the curve are well 
defined for all cases. I do not have any intuition on whether the balanced 
model will for example have issues with the p-Adic implementation as I have 
no experience in this area.

Tiny bit of feedback on the p-adic bit: as far as I know, things like 
Cantor's algorithm use euclidean division, wwhich is a big problem 
p-adically: coefficients may vanish unexpectedly and p-adically you cannot 
distinguish that from loss of precision. I think that's already a problem 
in the existing implementation and I think it will be in yours as well. So 
I think you can ignore p-adics to begin with. If you can get it working 
usefully and reliably for p-adic base fields as well then that's a real 
win! 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f4de3410-1d9e-4cc7-b518-7471f6c1ecean%40googlegroups.com.